Agile вне ИТ или как построить машину, пользуясь Agile-принципами

agileWIKISPEED

Один из самых популярных вопросов, который мне задают на тренингах как применять Agile-методы в не IT-проектах.  Разработка нового или развитие существующего программного обеспечения всегда была областью высокой неопределенности. Тут сложно рассчитывать на то, что даже типовой проект пойдет точь-в-точь как предыдущие. Вопрос не в том, будут ли изменения в первоначальных требованиях, а скорее в том, как быстро они появятся.  В тоже время, многие другие проекты условно сводятся к “производству”: изготавливаются почти одинаковые продукты по типовому процессу.  Эти проекты условно-линейные и полностью поддаются планированию.

И все же люди из обычного мира бизнеса часто сравнивают разработку ПО и автомобильный конвейер. Иногда на моем тренинге или после доклада слегка наивный слушатель заявляет: “Мы же не можем собирать машину по частям: сначала колеса, потом двигатель, потом капот”. Подобное заблуждение возникло из-за подмены понятия конвейера, где идет сборка однообразных моделей тех же машин, и работы дизайнерского бюро. Разработка ПО — проблема из области дизайна, а не производства.

Чтобы окончательно развеять заблуждение относительно автомобилей, давайте посмотрим на проект разработки автомобиля с использованием Agile-принципов. Я имею ввиду проект WIKISPEED. Он участвовал в конкурсе суперэкономичных автомобилей, как автомобиль пригодный для езды по официальным дорогам, который потребляет два литра на 100 километров.  До этого попытки собрать подобный автомобиль велись на протяжении уже десятка лет. Это должен быть не просто некий космический болид, где пилот лежа проедет по идеально ровной пустыне. Речь идет о машине, в которой мы с вами можем ездить по городу и автотрассам. Машине, у которой расход на 100 км чуть больше 2-х литров.

В своем интервью автор проекта  Джо Джастис (Joe Justice) рассказывает, что с самого первого места работы он работал менеджером в Agile-командах. Для него это был, по сути, образ мысли и стиль жизни. Джастису довелось работать над разработкой ПО в маленьких и больших распределенных командах. Опять же, перед ним НЕ стояла задача сделать “Agile-машину” или “Lean-машину”. У него была цель создать ультра-эффективный автомобиль с помощью команды волонтеров, распределенной по всему миру. И уже как лидер и менеджер Джо Джастис выбирал методологию, которая помогла группе работать результативно.

Нельзя ставить целью внедрение процесса, методов или принципов. Такие цели не долговечны, они не помогают организации двигаться к созданию ценности, не мотивируют команду и встречают много сопротивления. Другое дело, если цель компании в принесении максимальной пользы, а роль менеджера в этом помочь делать все это быстро и эффективно. Итогом является максимизация результата для клиента и креативной работы сотрудников. При этом минимизация бумажной волокиты, рутины, ненужных заседаний и всего, что не является работой над созданием результата и пользы. Agile, Lean и Scrum набор организационных инструментов для максимизации результата, видимого клиентам и пользователем.

Итак, команда взялась собрать машину. Участники знали общие требования: обычная комплектация машины, комфортная для каждого. Также они знали дополнительные требования — необходимое для “быть пригодным к езде по официальным дорогам”.

Сам Джо, автор проекта, выступил экспертом, так как незадолго до этого участвовал в разработке ПО для учета машин. Тогда они изучали много требований пригодности от федеральной службы дорог. Разработка велась итерациями, в результате каждой из которых был создан некий функциональный прототип. Своей работой он показывал всей команде, насколько текущий результат далек от их цели, а также помогал выбрать,  каким будет следующий шаг и цель следующей итерации.

Это то, что я называю «Agile продукта». Для меня этот термин обобщает все методы и принципы принятия решений. Все, что надо делать дальше, чтобы приносить определенную пользу. Она может выражаться как в результате, потребляемом пользователями, так и в знании или прояснении рискованных областей. Если интересно, погуглите на темы “Lean Design Thinking” и “Agile Product Design”. Та же, популярная нынче, концепция Lean Startup большей частью адресует эту область.   

Одной из проблем проекта WIKISPEED было то, что команда распределена. Десятилетия назад говорил о том, что Agile методы лучше работают для команд, сидящих рядом. За последнее время появилось много инструментов, которые могут обеспечить команде общую среду общения: YouTube для записи демонстрации, Google Docs, онлайн доски задач, сервис конференц-звонков и, немаловажное, общая email рассылка на команду. Эти инструменты позволили распределенной команде волонтеров чувствовать себя так же, как Scrum команды, сидящие в одной комнате.

Плюс к тому же, одним из обязательных условий для них была  прозрачность всех обсуждений и документов. Даже если они создаются “другими” командами, каждый может посмотреть материалы соседей, когда ему это необходимо. Сюда же стоит добавить большую автономность принятия решений у команд, которые работают над развитием тех или иных частей машины. В проекте участвовали 44 человека. Все они были волонтерами, для которых проект WIKISPEED был хобби.

Это то, что я называю “Agile людей”. Принципы самоорганизации, совместная работа группы над одной целью итерации, общая ответственность за результат просто неотъемлемые части Agile-методов и самой философии “гибкости” и сотрудничества. Многие современные книги о менеджменте, мотивации, лидерстве и командообразовании говорят о том как использовать эти принципы для достижения максимума в работе “креативных команд”. Если покопаться, то термин “Intelectual workers” ввел еще дедушка Питер Друкер. В современном мире большинство работ относится к этому типу, а не только разработка ПО.

Ну и понятно, что учитывая опыт главного менеджера-организатора, все команды WIKISPEED работали по Scrum, адаптированному для их ситуации. У них были спринты-итерации и небольшие команды, которые фокусировались на улучшении тех или иных параметров автомобиля. В течение итерации команды ежедневно синхронизировались и  активно общались. Как правило в режиме “информация для всех”. А в конце итерации собиралась новая версия автомобиля. Члены команды вместе смотрели на полученный результат и обсуждали, что можно улучшить как в продукте, так и в их способе работы над ним.

Это то, что я называю “Agile процессов”. Все методологии и фреймворки, которые помогают быстро начать двигаться к результату, адаптируются под условия проекта. К сожалению они наиболее видимая часть “айсберга”, который мы называем Agile. По той же причине популярен Scrum — для него проще всего найти курсы или тренинги. При этом нередко совершенно забывают об остальных, упомянутых выше аспектах. На мой взгляд, они гораздо важнее любой методологии.

Если оглянуться и присмотреться, то сегодня многие компании, далекие от разработки ПО, применяют принципы и философию Agile. И дело не только в примере об автомобиле. Кроме разработки автомобиля, я знаю много других случаев: написание  сценария телесериала, ведение юридической практики, оказание контент-услуг. Agile вне ИТ активно применяется компаниями. Особенно когда речь идет о людях, решениях и процессах. Все это позволяет командам быть более гибкими и лучше достигать целей.

Как выявить свои бессознательные цели

4-pory-goda-na-odnom-snimke

Про всякие цели, списки, задачи и т.п. много всего написано, и даже в этом блоге огромная доля статей на эту тематику. Тем не менее, не всегда удается достичь целей, не смотря на огромную теоретическую подготовку и большое желание. Поэтому сегодня хочется пойти немножко другим путем и несколько даже философски взглянуть на тему достижения целей.

На самом деле, не все свои цели мы ставим сознательно. Бывает так, что цель формируется бессознательно, и только после того как что-то сделано, приходит понимание, чего же на самом деле хотелось. Это как в анекдоте: «Никогда не говори: «Я ошибся», лучше скажи: «Надо же, как интересно получилось…» (далее…)

Дайджест: про оценки и планирование

digest

Я не раз повторял, что этот блог во многом сборник мыслей и пояснений, которые мы в разное время рассказывали в виде докладов, тренингов или во время работы с командами. Естественно, за многие годы жизни блога здесь скопились разные статьи, опубликованные в разное время, которые адресуют одну или связанные темы.

Как-то один из читателей сказал: «а почему бы не сделать дайджест?«, и эта мысль засела у меня в голове на некоторое время. Вот наконец-то я решил ее реализовать, и теперь постараюсь регулярно публиковать подборку статей связанных одной темой, чтобы вы, читатели, могли ее использовать, как навигатор.

Первая тема дайджеста, на мой взгляд, самая популярная «про оценки и планирование«. (далее…)

Почему недельная длина Спринта хуже, чем двухнедельная

В 90-х Джеф Сазерленд и Кен Швабер экспериментировали со своими командами и вырабатывали подходы, которые потом и назвали Scrum методологией. Они говорили о коротком цикле разработки длиной в один месяц. На фоне долгосрочных многолетних проектов – это была уже сама по себе революция, которая обеспечивала быструю обратную связь и гибкость всего проекта. Сегодня две недели стали уже де-факто стандартом длины итерации (спринта). Более того, некоторым компаниям две недели оказываются слишком долгими, и они требуют от своих команд коротких недельных итераций.

«Почему недельная  длина спринта хуже?», — этот вопрос мне часто задают команды, с которыми я работаю, во время моих тренингов и просто в общении со знакомыми Скрам мастерами. Попробую обобщить свои мысли на эту тему. (далее…)

"Раскрась свой Бэклог!" или о чем я рассказывал на Agile Eastern Europe

На прошедшей недавно конференции Agile Eastern Europe, я решил поддержать рускоязычную сцену и выступил с докладом «Раскрась свой Бэклог! или о том, как принимать решения на основе разных типов элементов бэклога».

Ниже под катом находится слайдкаст моего выступления — те, кто не смог присутствовать, могут и посмотреть и послушать.

Сама идея того, что в Бэклоге Продукта могут быть разные типы элементов, очень быстро приходит к тем, кто начинает практиковать Scrum или другую Agile методологию. Ведь Бэклог — это и инструмент взаимодействия с внешним миром, и инструмент планирования на разных уровнях. Достаточно быстро становится очевидным, что туда должно попадать все, на что нужно инвестировать время команды, чтобы получить в результате рабочий продукт.

Что же вы положите в Бэклог и, на что это повлияет?
(далее…)

Какую проблему решает буфер времени при планировании итерации

В прошлой статье я рассказывал об одной технике, которая применяется при планировании итерации. Судя по комментариям, которые на мой взгляд отходят от темы, я понял, что в прошлой статье не раскрыл главный вопрос — зачем и когда применять эту технику 🙂

Действительно, любой здравомыслящий человек, прежде чем применять новый подход, должен задаваться вопросом: «Какую проблему я решаю?».

Итак, какую проблему мы решаем с помощью буфера времени? Моя статья была навеяна проблемой планирования итерации, которую я обсуждал со своими клиентами. Вы наверное видели ниспадающие (burndown) графики в Cпринте, вроде этого:

График команды "опоздали"

или этого:

График хорошей команды

Они говорят о том, что команда планирует больше, чем реально может сделать. Это может происходить из-за того, (далее…)

Когда подстилать соломку или планирование Спринта с учетом вашей реальности

Когда-то, я писал о Разноцветном Бэклоге, т.е. о применении идеи цветовых маркировок для разных типов элементов Бэклога. Да-да, не удивляйтесь, Бэклог Продукта может содержать элементы разного типа — это иногда оказывается «новостью» для тех, кто только начинает практиковать Scrum и прочел только несколько статей или короткую книжку 😉 Одна только работа с Бэклогом содержит много нюансов, о которых я рассказывал во время онлайн курса или уже неоднократно писал. Так что если вы хотите больше узнать, то почитайте мои статьи на эту тему.

Другой вопрос, который я получаю сразу после того, как читатели, или слушатели тренинга, разобрались с идеей разных элементов Бэклога: «Как их учитывать при планировании Спринтов или целых выпусков?». Иногда просто так и спрашивают: «Как оптимально планировать итерацию?». Ответ прост, как и все из того, что применяется в Agile методах и о чем я рассказываю в этом блоге.  (далее…)

О взятых на себя обязательствах или стоит ли изменять план Спринта

Моя прошлая статья про «вред наказания за ошибки» помогла мне самому разобраться с одним интересным вопросом, который мне часто задают. Вопрос озвучивается по разному, например: «Что делать, если команда видит, что не успевает сделать все, что запланировала в спринте?» или иногда вот так «Что делать, когда наш график оставшейся работы (Burndown) выше идеальной линии?». Вариантов вопроса может быть много, хотя по сути все сводится к тому, что делать, если команда не может выполнить взятые на себя обязательства.

Допустим, в начале спринта вы честно планировали, исходя из своих возможностей, и делали максимально реалистичный план. А потом все пошло как-то не так – в разработке ПО такое часто случается :-). Обычно, вы увидите это на графике оставшейся работы, когда он покажет, что у вас осталось больше, чем вы можете сделать. И вот тут-то наступает самый интересный момент – что делать команде? (далее…)

Почему совместные оценки все-таки помогают Agile командам

На прошедшей недавно конференции Agile Base Camp | Crew Drill я умудрился выступить сразу с двумя сессиями: практической игрой-симуляцией Канбан процесса и докладом о том, почему коллективные оценки, все-таки работают для Agile команд.

Про игру напишу в одной из следующих статей, а сейчас спешу поделиться презентацией.

Уже успел добавить звук, поэтому те, кто не попал, но очень хотел, могут послушать слайд-каст. Конечно, эффект не тот, что от присутствия в зале, хотя общее представление о сути можно получить.

Попробую обобщить доклад до нескольких строк и выделить основные тезисы. (далее…)

Еще раз об оценках проектов или Knowledge Hub вебинар 13 марта 2012

Так получилось, что в основном я работаю с иностранными заказчиками. И тренинги чаще веду на английском 🙁 Поэтому меня не удивило, когда коллеги из Словакии обратились с предложением провести вебинар в рамках Knowledge Hub инициативы местного Agile-сообщества. Инициатива хороша, дело нужное, и я с удовольствием согласился 🙂

Во вторник 13 марта мы поговорим об оценках требований, и как это помогает планированию проектов. Учитывая долгие годы практического опыта, на эту тему уже много было написано в нашем блоге. Также мы разбирали эту тему с участниками на моих тренингах по управлению проектами. И все равно, уверен, найдутся желающие послушать и пообщаться.

В течении 40 минут мы поговорим о том, почему традиционные методы оценки «замерами» не работают в ИТ. Что дают «гибкие» подходы к оценке и какие они бывают. Как быстро оценить проект, чтобы отвечать на вопросы заказчика «Сколько стоит?» и «Когда будет готово?» 🙂 Немного обсудим, как использовать оценку для отслеживания состояния проекта. Ну и, конечно, оставим еще время для ответов на вопросы участников. (далее…)