Кен Швабер: истоки и будущее Скрама
Кен, вы в Скраме долгое время, более 10 лет. Это на самом деле совсем иной подход к разработке ПО. Что побудило вас тогда, в те давние годы, перейти от прогнозирующего подхода к эмпирическому? Кен Швабер : Я работаю над идеями Скрама 23 года. Некогда мы разрабатывали первые инструменты ALM в Берлингтоне (Массачусетс), но работали они не очень-то хорошо. Они были онлайновыми, и их не приняли. И мы искали способ подключить к инструментам методологию, чтобы они стали работать лучше. Это было замечательно, за исключением того, что я использовал одну из ранних объектно-ориентированных технологий, и в то же время заказчик хотел изменений - новых встроенных возможностей или кастомизаций. Мы едва не рехнулись тогда! И вот способность разбираться одновременно и с техническими трудностями, и постоянными запросами на изменения и привела меня к началу идей Скрама и Agile. И в те же самые времена мой друг Джефф Сазерленд сталкивался с теми же проблемами. Выяснилось, что мы пытаемся одолеть одни и те же трудности, поэтому мы начали сотрудничать и обнаружили, что делали практически одно и то же. Джефф формализовал идеи будущего Скрама, и мы стали заниматься им вместе. Потом мы еще поработали, я начал использовать терминологию Скрама по мере того, как она вырисовывалась. К 1995 году у нас появился довольно хорошо описанный процесс, который мы назвали Скрамом: там были и Скрам-мастер, и владелец продукта, и много других идей, которые есть сейчас. К этим идеям меня привела попытка отвечать на запросы множества заказчиков и держать их в курсе дела. Мы бы вылетели из бизнеса, если бы не работали таким образом. Пока мы с Джеффом старались формализовать Скрам, нам пришло письмо от Кента Бека, который видел нашу начальную работу в OOPSLA. Он сказал, что идеи здравые и спросил, можно ли позаимствовать некоторые из них - вот как раз поэтому вы можете наблюдать некоторые общие моменты экстремального программирования и Скрама. Я всегда надеялся, особенно когда работал над «Манифестом Agile» в 2001, что мы сможем как-нибудь объединиться, потому что Скрам - это ответ на вопрос, как разрабатывать в гибком окружении. Чарльз : Я читал много исследований, и в них говорится, что применение Скрама в Agile-компаниях превышает 84%. Многие компании используют Скрам как основной фреймворк. Это вас удивляет? Кен: По последним данным Форестера уже 92% Agile-организаций используют Скрам. Я ожидал где-то 90-92 у Скрама и, возможно, 85% у экстремального программирования. Так что это меня не удивляет, потому что я думаю, что эта статистика - забавная штука. Эти данные не говорят ничего о том, сколько компаний разрабатывает ПО, используя чистый Скрам, а сколько кроме него использует современные инженерные техники. Они лишь указывают, кто использует Скрам в принципе. Думаю, если бы вопрос был задан иначе, ответ был бы где-то в районе 30-40%, что, в принципе, довольно разумно. Но самое приятное в том, мне кажется, что мы, наконец, отвратили людей от мысли, что каскадная структура - это хороший подход к разработке ПО. Ведь пока такой тип мышления сохранялся, всегда оставалась вероятность, что мы снова окажемся с чем-нибудь вроде каскада или RUP. Чарльз : Как вы считаете, что больше всего угрожает росту либо принятию Скрама? Кен : Думаю, самая большая угроза - это стремление людей к определенности и вера, что если каким-то образом застолбить всё получше, то эта определенность появится. Поэтому им по душе SAFe и DAD, даже Канбан больше вяжется с этим желанием, поскольку в нем больше определенности, чем в Скраме. Я вижу эти края, надкусанные теми, кто хочет определенности. Даже внутри Скрама идут разговоры, как сделать скорость более предсказуемой, как точнее рассчитать усилия на планёрке спринта, чтобы быть более уверенными в том, какие результаты мы получим к его концу. Всё это напрочь противоречит главной идее Скрама: «Давайте использовать короткие циклы, чтобы можно было не заботиться о том, сколько мы создаем, потому что очень скоро мы и так это выясним». Год назад на ALM-конференции я слышал, как один парень делал доклад, доказывая, что Agile - это новомодная причуда, что в разработке ПО каждые 10 лет появляется какой-нибудь заскок, и рассуждал о том, каким может быть следующий. Это испугало меня, потому что я думаю, что основная идея - это изменить стиль мышления при помощи Скрама в направлении эмпиризма и сложности. Если же на это смотрят, как на причуду, то всё может вернуться обратно к «А давайте попробуем всё это контролировать», - и это опасно. В последние три года я вижу, что только ленивый не выдвинул нового способа делать деньги при помощи Agile. Происходит то же, что с CMMI, которая погибла, потому что из набора хороших идей превратилась в просто способ делать деньги. Я наблюдаю всё это и вижу, что это, скорее, не умысел, а всего лишь применение старого мышления к движению Agile, но у этого есть значительные шансы разрушить Agile. превратив его в замечательный набор идей, которые встречают уважение на словах, но не на деле. Чарльз : Каким вам видится следующее большое новшество в Скрам-фреймворке? Кен : Для нас, думаю, следующий большой шаг - это доказательный менеджмент (evidence-based management - EBM), показывающий ценность выполнения работы тем или иным способом. Это нужно не только для того, чтобы бизнес увидел эту цифру, но и для понимания, что если бизнес действует не в соответствии с этой цифрой, то тем самым наносит урон своей компании. Доказательный менеджмент просто говорит: «Вот показатели, которые можно использовать, чтобы посмотреть, как у нас дела». С этими данными можно идти прямо к руководству - и показывать. Идея привлекательна уже тем, что изначально она не предлагает ничего менять - просто посчитать, что именно происходит, что само по себе очень хорошо. Есть такая проблема, когда руководство рассматривает IT только как статью расходов, не приносящую особых ценностей. Если мы измеряем бизнес-ценность, то меняется сама структура взаимодействия с высшим руководством. Они думают: «И правда, почему бы нам не перевести всё в термины ценности и посмотреть, сколько же на самом деле производит IT». Конечно, вы не можете с ходу перевести всё в абсолютные величины и сказать: «Ценность равна 17,4 унций», - но можете начать закладывать некий фундамент, чтобы можно было сравнивать тенденции и предсказывать, что будет, на основе ваших действий сейчас. Другая проблема в том, что гибкость не измерить. Мы с Джеффом снова и снова видим компании, которые очень, очень преуспели в Agile, а их руководство не верит, что от этого будет хоть какая-то польза. Идея доказательного менеджмента в том, что если у вас есть, в чем измерять - как вес измеряют в килограммах и товары в штуках - то вы сможете увидеть эффект от перемен и внедрения Agile. У вас появляется новый способ сообщить руководству, хорошо идут дела или плохо. Тут я возлагаю надежды на два фактора. Первый в том, что менеджмент не измерял ни IT, ни разработку ПО. Никогда в жизни. Тем менее на них давят, им надо иметь какой-то способ измерения, чтобы можно было отчитаться вышестоящему руководству, и доказательный менеджмент дает им ответ. Второй фактор в том, что таким образом делается акцент на действия и становится виден некий уровень производительности - точно так же, как и во всей остальной компании. Это действительно хитрый ход, который поднимает прозрачность на уровне менеджмента так, как мы это имеем на уровне разработки. Чарльз: Судя по сказанному, доказательный менеджмент дает менеджерам и свободу, и ответственность. Свобода - в том, что им не надо полагаться на собственные суждения и интуицию, и ответственность - в том, что они знают, каким образом будут измерены результаты их труда, причем это не простые механические единицы. Кен: Да. Именно. Думаю, некоторым менеджерам такой подход придется не по душе, потому что они единственные отвечают, почему проект не поставлен вовремя, и могут винить в этом кого-то еще. Это очень, очень испугает многих менеджеров, которые не уверены в том, что делают. Но, полагаю, когда они присмотрятся к показателям и начнут видеть, что происходит на самом деле, все будет довольно интересно. Одна из хитрых вещей в доказательном менеджменте - это индекс гибкости. Это самая первая метрика, которую можно отслеживать как тренд внутри вашей организации (и поначалу всё будет выглядеть пугающе), но можно собрать данные для сравнения и по разным компаниям (например, внутри одной отрасли). Всё, что нужно сделать, - это собрать в один отчет показатели компаний и представить его в Форестере, Гартнере, других газетах, - и вы увидите, как начнется множество интересных дискуссий. Идея привлекательна, однако стоит начать ее использовать - она обращается против вас и вам приходится делать что-то, чтобы улучшить вашу организацию. В этом и трюк, спрятанный внутрь доказательного менеджмента.
Автор: Чарльз Сущек Источник: http://www.agileconnection.com/print/int[...]-and-future-scrum-interview-ken-schwaber Кен Швабер вместе с Джефф Сазерлендом в начале 90х разработал процесс Скрам, чтобы помочь компаниям в борьбе со сложными проектами разработки ПО. Кен - основатель Scrum.org и один из тех, кто подписывал «Манифест Agile» в 2001. Он основал поочередно «Agile-альянс» и «Скрам-альянс». Недавно он покинул «Скрам-альянс», чтобы основать Scrum.org. Ветеран индустрии разработки ПО с 30-летним стажем (от мойщика бутылок до босса), Кен написал три книги про Скрам: «Гибкая разработка и Скрам (Agile Software Development with Scrum)», «Гибкое управление проектами и Скрам (Agile Project Management with Scrum)» и «Предприятие и Скрам (The Enterprise and Scrum)». Др. Чарльз Сущек - национально признанный лидер Agile, который специализируется на внедрении гибкой разработки ПО на уровне предприятий. Он один из немногих тренеров scrum.org, сертифицированный обучать полной программе. За более 25 лет профессионального опыта, др. Сущек занимал должности архитектора процессов, директора по исследованиям, консультанта, профессора и профессионального тренера в ведущих компаниях Америки. Он выступал на таких национальных и международных конференциях, как ыAgile 200X, OOPSLA и ECOOP, на темы, связанные с гибким управлением проектами, и часто публикуется - на его счету свыше 30 публикаций. Перевод: Александра Родсет |
Сертифицированные курсыАндрей Плетенев. Онлайн курс Agile. SCRUM. Курс включает более 20 уроков с практическими заданиями, которые индивидуально проверяются и комментируются тренером.
Еще интересные статьи на эту тему:
|
