Как создавать тренинги — практическое руководство на личном примере

practical-guide

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

Скажу сразу, что я не претендую на звание мега «тренера тренеров». Я начал проводить тренинги еще в 2007 году. Но с тех пор я многому научился, в том числе и сам прошел «тренинг для тренеров». Как показывает практика, если что-то долго делать, опыт и знания все-таки появятся 🙂

Работая с коллегами-консультантами, приходилось не раз обучать начинающих тренеров. Я уверен: даже если мои ученики не ведут тренинги регулярно, то полученные навыки не раз им пригодились.

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

Этап 1. Хочу создать тренинг. С чего начать?
Я убежден: тренинг – продукт. А для продуктов я рекомендую создавать «Видение Продукта», которое помогает ответить на простые вопросы и держать в фокусе конечный результат.

Первый вопрос: «Для кого этот тренинг?»

Для команды, которая только думает о внедрении Agile-методов? Для команды, которая их уже практикует, но хочет переосмыслить, что и как они делают? Для группы менеджеров компании, которые хотят побольше узнать, как работать по Scrum-методологии? Для отдела DevOps, который внедряет Kanban? А может для HR-отдела, который хочет узнать новые слова или, наоборот, внедрить некие легковесные процессы, чтобы лучше делать свое дело? 🙂

Второй вопрос: «Зачем ИМ этот тренинг?»
Частично он выходит из ответа на первый вопрос, добавляя фокус и цели тренинга. Тренинг может быть направлен на ознакомление с широким кругом принципов и методов или на практические навыки в одной узкой области. Особенно хорошо, если участники соберутся уже на следующий день, чтобы использовать полученные знания и навыки.

Вопрос третий: «Какие у нас ограничения?»
Первое и самое распространенное ограничение – время. Если у меня есть один день, тогда можно рассчитывать на раскрытие 3-4-х тем, с учетом теории и практических упражнений. Два и больше дней, а это, можно сказать, уже роскошь, дают возможность глубоко погрузиться в разные темы, которые вместе создают целостное понимание отдельных частей общей картины. Но иногда время строго лимитировано и есть только полдня (примерно 4 часа) или мастер-класс на два часа. В таком случае нужно выбрать более узкий фокус и отказаться от многих интересных тем, которые вы не успеете рассмотреть.

Другое, не такое критическое ограничение – материалы. Флипчарт, стикеры и распечатки вы можете найти в любом офисе. Отлично, если есть возможность заранее собрать дополнительные материалы для упражнений – монеты, карточки для упражнений и прочие домашние заготовки. Поэтому, несмотря на мою безграничную любовь к Lego, я предпочитаю не использовать его для тренинга: нужно таскать с собой огромную коробку. А так я готов провести тренинг почти в любое время и в любом месте с минимальной подготовкой.

Конечно, на фоне всего этого у вас должна проскочить мысль о месте для тренинга. Где вы его проведете? Какое помещение вам доступно? Есть ли там столы для работы в группах и другие материалы? Об этом поговорим позже, когда приступим к упражнениям.

Дополнительные вопросы: «Какие критические атрибуты?» и «На что может быть похож этот тренинг?».

Частично они уже понятны из всех предыдущих ответов. Но стоит обратить внимание на один важный аспект: количество участников. Я сторонник концепции «Training from the back of the room» (тренинг из дальнего конца комнаты). Другими словами, я считаю, что в тренинге должно быть больше интерактива между участниками и меньше «монопольных» рассказов тренера. Лучше всего тренинг проходит в относительно небольших группах от 8 до 16 человек. При максимуме в 20 человек еще можно рассчитывать на внимание тренера к каждой группе участников. Если же у вас больше участников, то нужно будет думать о помощниках или об упражнениях, которые не требуют особого внимания тренера.

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

Еще Сократ сказал, что вовлечение в обучение способствует запоминанию. Это знают все, кто так или иначе знаком с проблемой обучения практическим навыкам (а гибкие методы работы – тоже навык).

Хорошая новость: в арсенале тренера множество способов интерактива. Например: обдумывание вопроса самостоятельно, обсуждение в парах или группах до 5 человек, участие в упражнении (serious play), разбор кейсов или просто общее интерактивное обсуждение с тренером и многое другое. Обо всем этом мы поговорим в следующих статьях, когда будем наполнять наш тренинг.

Итак, давайте посмотрим, что у вас может получиться и создадим тренинг вместе, как я и обещал в самом начале.

Создаем тренинг для участников, которые пока еще мало знакомы с Agile-принципами разработки и в частности Scrum-методом. Это может быть отдельная команда или сборная группа в компании. Цель тренинга – раскрытие основных тем, таких как понимание идеи Agile, знание практик работы по Scrum-методологии, методы командной оценки и планирования итераций и проектов. Также обязательно получение практических навыков, чтобы начать их применять сразу после тренинга. По времени мы можем рассчитывать на однодневный тренинг при оптимальном количестве в 15 человек.

Так и назовем его – «Однодневный Scrum-тренинг»

Далее мы поговорим о том, как создать структуру тренинга, чтобы упаковать туда все необходимые темы. Обсудим, как сбалансировать расписание и подобрать интерактивные упражнения, которые объединяют теорию и практику.

Постараюсь не откладывать следующие статьи в долгий ящик. С нетерпением жду комментариев и вопросов, чтобы понять насколько эта тема интересна. Оставайтесь с нами.

Scrum Card Game — настольная Scrum игра

Scrum Card Game - настольная Scrum игра
Когда я только начинал вести тренинги по Scrum методологии и принципам Agile разработки, пришло понимание — теория легко забывается. Проще учится на своем опыте. Так мне понадобилась Scrum игра.

Существует много Scrum игр и симуляций, и все-таки большинство из них мне не нравятся. Они либо излишне упрощены, либо наоборот громоздки и тренеру необходимо носить с собой килограммы материалов для упражнений.

Так родилась идея, а затем и настольная игра — Scrum Card Game. С тех пор она отлично послужила мне и многим моим коллегам-консультантам. Меня неоднократно просили сделать ее доступной для широкой публики те, кто хоть раз в нее играл.
Настало время! 🙂

Официальная страница Scrum игры содержит ссылку на самую актуальную версию. Сейчас доступна английская версия игры, вскоре будет версия на русском, и уже в недалеком будущем появится немецкий вариант.

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

Для игры вам понадобится сделать игровые карточки: достаточно скачать инструкцию на странице игры Scrum Card Game — там же внутри есть шаблон карточек для печати. Вам также понадобятся два кубика (игральные кости) на каждую команду. Команды рекомендую собирать по 4-5 человек, максимум 6. Они работают независимо друг от друга, поэтому игру можно использовать и для большой аудитории, лишь бы были запасные наборы 🙂

Итак, объявите цель игры: каждая команда разрабатывает новый продукт и после третьей итерации выходит в “production” со всем, что они успеют сделать.

Каждая команда должна Запланировать спринт, Исполнить спринт и Адаптироваться на основе своего опыта. Зайдите на страницу игры и скачайте подробные инструкции.

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

Scrum Card Game опубликована по Creative Commons Attribution-ShareAlike 4.0 International License. Это означает, что вы можете свободно использовать игру в своей работе, даже в коммерческих тренингах и проектах, при условии, что упомянете авторство и источник, а также при условии, что все производные игры публикуются под такой же лицензией.

С удовольствием обсужу ваш опыт игры или идеи по ее развитию. Вы можете связаться со мной на странице «Контакты».

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 вне ИТ активно применяется компаниями. Особенно когда речь идет о людях, решениях и процессах. Все это позволяет командам быть более гибкими и лучше достигать целей.

Мы дождались её: книга “Scrum. Революционный метод управления проектами» вышла на русском языке

Книга Книга "Scrum. Революционный метод управления проектами"Эту книгу ждали очень долго и вот она вышла на русском языке в издательстве «Манн, Иванов и Фербер». Дочитав книгу, хочу поделиться своими впечатлениями.

Уверен, что Книга «Scrum. Революционный метод управления проектами» в издании «Манн, Иванов и Фербер» станет книгой для каждого из вас: от читателей моего блога и знакомых из Agile сообществ до всех, кто хочет управлять проектами эффективно. Таких людей наберется немало, ведь быстрая реализация проектов кажется недостижимой мечтой. Но Джефф Сазерленд, автор самой популярной, из семейства Agile, методологии Scrum, так не думает. Он мыслит конструктивно, подкрепляя свою теорию интересными примерами. Название книги в английском варианте звучит очень амбициозно:»The Art of Doing Twice the Work in Half the Time”. Пожалуй, если бы автором был другой человек, я бы, мягко говоря, удивился. Но в случае с Джеффом Сазерлендом и невероятные истории становятся реальностью.

Начинается книга с рассказа о том, что натолкнуло автора на создание его методологии. Когда-то я уже переводил пост из блога Сазерленда «Как появился Scrum». Расширенный рассказ о появлении Scrum есть в первой главе, которая задает тон этому бестселлеру. Плюсы всей книги в простой и живой манере рассказчика, легком повествовании и умеренном объеме. С первых страниц создалось ощущение, что будто мы, я и старина Джефф, сидим рядом после конференции. И этот гуру управления делится со мной своим опытом. Что-то в стиле «один мой сосед задумал отремонтировать дом за 6 недель. Мы ему, конечно не поверили. Но ровно через 6 недель пришли к нему в гости отмечать новоселье…» Одна из многих динамичных историй, в которых участвовал сам Джефф Сазерленд и которые подчеркивают примеры применения Scrum. Не скучная реклама, а вдохновляющий на поступки опыт.

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

Сильная сторона книги в том, что рассказ построен на контрасте. С одной стороны, неэффективные проекты и организации (и такие до сих пор есть! мы знаем). С другой стороны, команды, которые достигли качественно иных результатов, применив Scrum.

Помню, в одном обзоре кто-то в шутку возмутился, мол эту книгу надо было написать еще 10 лет назад. Но я, например, не удивлен этому. Издание важно тем, что в нем много примеров об использовании Scrum или его отдельных принципов даже вне индустрии разработки софта. Маркетинг, строительство, да что угодно. Я сам сторонник такой тенденции. Потому что организационный фреймворк Scrum подходит для любых проектов. В блоге мы уже писали на эту тему: пояснение Scrum на примере организации мероприятия.

Так что мой вывод прост. Книга «Scrum. Революционный метод управления проектами» интересная и универсальная, обязательная к прочтению. Джефф Сазерленд написал ее не столько для айтишников и убежденных “аджалистов”, а скорее для представителей бизнеса, менеджеров всех уровней и просто людей, которые хотят понять феномен Scrum.

 

P.S. После чтения книги у меня осталось много заметок. Значит мы еще вернемся к некоторым важным темам. Оставайтесь с нами.

“Дзен Скрам” — рекомендуемая презентация для вводного рассказа про Agile и Scrum

The Zen of Scrum - Russian

Уверен, у многих читателей, как и у меня, рано или поздно возникала необходимость объяснить, что такое Agile и Scrum. У меня такая необходимость возникала множество раз:

  • для групп слушателей малознакомых с темой Agile;
  • для команд, которым сказали “вы работаете по Scrum”, но забыли объяснить, что это такое, хотя бы вкратце;
  • для осведомленных и заинтересованных узнать больше.

Да мало ли, когда и как у вас может возникнут необходимость пойти и рассказать про Agile Scrum. Другой вопрос, как вы все визуализируете — будете ли вы создавать “с нуля” свой рассказ и слайды или возьмете одну из качественных презентаций и используете ее, как основу для своего рассказа.

Лично мне уже много много лет задают вопрос: “где взять готовую презентацию про Agile и Scrum?”. Когда-то я перевел на русский язык презентацию “Все о Скрам” от Майка Кона. Эта презентация долгое время меня выручала и, в принципе, отлично выполняет свою задачу. Но мне всегда не хватало визуальности в этой презентации. Те, кто видел мои доклады на конференциях, семинарах и других мероприятиях, знают, что я сторонник ярких наглядных презентаций, которые приносят как информационное, так и эстетическое удовольствие.

Именно по этой причине, я считаю, что настало время для нового образца “переиспользуемой” презентации про Agile и Scrum. В качестве слайдов для такого рассказа я предлагаю использовать презентацию Юргена Аппело “Дзен Скрам”, которую я недавно перевел на русский. Кроме понятного и доходчивого рассказа по теме гибкой (Agile) разработки программного обеспечения и Scrum методу, презентация еще очень яркая визуально. Отлично подобранные картинки создают запоминающийся ряд и, точно, не дадут заснуть вашей аудитории. Итак, встречайте новый де-факто стандарт презентации для ознакомления с темой Agile и Скрам:

Кстати, если кто-то из читателей еще не знает, Юрген Аппело (Jurgen Appelo) автор книг “Management 3.0” и “How to Change the World” и автор популярного блога Noop.nl. В свое время он ярко представился всему восточно-европейскому сообществу на конференции Agile Eastern Europe, где в течении нескольких лет делал яркие доклады. И только потом я обнаружил, что первая его презентация на SlideShare была именно “The Zen of Scrum”. Юрген будет рад, если вы используете его презентацию для своего следующего рассказа, единственное условие — сохраните указание автора и первоисточника.

Видео "Гибкое управление продуктом в двух словах" на русском языке

Гибкое управление проектами

Про роль Владельца Продукта я уже писал не раз. И даже рассказывал о некоторой «мифичности» этой роли и ссылался на видео Хенрика Книберга, где дается краткая подборка всей теории для исполнения этой роли, а заодно и лучшего понимания Agile Software Development в целом.

Поэтому мне отдельно приятно сообщить о выходе русской версии видео, в переводе Бориса Вольфсона. Видео порадует всех, кто интересуется концепциями и практиками Гибкой Разработки ПО и особенно тех, кто еще не смотрел оригинал 🙂

(далее…)

Вебинар "Визуальная мотивация"

visual-motivation

На тему мотивации в команде на сегодня уже столько статей, тренингов и семинаров, что даже самому структурированному  человеку порой сложно разобраться. И казалось бы, ну что еще можно добавить, когда уже и так много сказано. Тем не менее, коллеги из Unusual Concepts решили сделать вебинар на тему «Мотивация в команде», где выступят сами с интересными рассказами, и меня позвали как приглашенного эксперта.

Итак 5 декабря 2013 (уже завтра!) в 19:00 по Киеву, в 21:00 по Москве можно будет послушать три таких доклада:

  • Илья Павличенко — «5 инструментов для мотивации Скрам команды»
  • Тимофей Евграшин — «Визуальная мотивация или наглядность наше все»
  • Олег Дмитриев— «5 примеров того как топ-менеджмент демотивирует команду»

Мой рассказ о визуальной мотивации будет собственно о том,  как наглядность помогает в разных аспектах мотивации, примеры известных визуальных Agile инструментов с пояснением их воздействия, плюс примеры мало известных инструментов.

Присоединяйтесь! Участие бесплатное. Детали всего мероприятия здесь. Регистрация здесь.

До встречи!

Agile Pecha Kucha, AgileEE и всякое другое про Agile:)

agile

Всего пара дней остается до конференции AGILE Eastern Europe. Кроме того, что в этом году, как обычно, конференция радует составом докладчиков: в их числе такие признанные эксперты как Dr. Alistair Cockburn, David Hussman, Tobias Mayer, Fred George, Karl Scotland, Elizabeth Keogh, Bjarte Bogsnes, Petri Heiramo, Andrea Provaglio, Boris Gloger, Gil Zilberfeld, я проведу Agile Pecha Kucha.

Если вдруг кто не помнит, то pechakucha — это формат коротких рассказов 20 слайдов по 20 секунд. В этом формате в первый день конференции можно будет послушать такие рассказы на английском языке:

  • David Hussman — Cutting an Agile Groove
  • Vyacheslav Moskalenko — Cultural Transformation
  • Oleksandr Lutsaievskyi — Get Up! Stand Up! Patterns for effective Stand Up meetings
  • Philip Torchinsky  — Most impressive features of new YouTrack issue tracker
  • Izzet Mustafaiev — Development environment in Agile way
  • Anton Zotin — Successful Demo in complex distributed environment

Кроме всего прочего, приглашаю на свой доклад. Конференция проходит уже в пятый раз, и в пятый раз я буду здесь выступать. Тему я выбрал, на мой взгляд, очень интересную. Звучит она так: «WTF is LRM, YAGNI, JIT?» или вы не знаете основные Agile-принципы». Рассказ будет о том, что нас делает действительно гибкими, о том, как термины неправильно трактуются, что на практике означают эти принципы и как они помогают принимать решения на проекте и в обычной жизни, например, даже при подаче доклада на конференцию. Очень рассчитываю на интересную дискуссию после доклада:-)

Приходите, буду рад, а если вдруг вы еще не зарегистрировались, то успейте это сделать.

Каков ты, Agile? Scrum на свете всех милей…

the best scrum

В одном из прошлых постов я поделился моим собственным анализом результатов ежегодного опроса «State of Agile Development». Отчет настолько обширен, что из него можно извлекать информацию кусками, в зависимости от того, что вы ищите. Отдельно, я хочу поделиться наблюдениями на тему, популярности Scrum среди всех остальных Agile методологий.

У меня часто бывает, что я спрашиваю компанию или людей из команд: «Как вы работаете?», и в ответ слышу: «У нас Scrum«, или еще лучше: «У нас Agile!». Самое интересное происходит, когда спрашиваешь: «А как именно вы работаете?» или «Какую именно Agile методологию вы используете?». Вот тут можно услышать что-то вроде: «Ну, у нас есть Ежедневный Скрам» или «А что, разве Agile методологий несколько???» 🙂

Поэтому прежде чем говорить о популярности Scrum, давайте отойдем на шаг назад и посмотрим, кто приносит эту заразу идею Agile в компанию. Т.е. как говорят «who champions» внедрение гибких методов, а вместе с этим заказывает тренинги и коучинг.

Согласно результатам упомянутого опроса, (далее…)

Каков ты Agile? Или зачем и почему компании выбирают гибкие методологии

agile

Отчет о ежегодном опросе «State of Agile Development» уже несколько лет удивляет интересными наблюдениям. В рамках этого исследования раз в год публикуются результаты, которые так или иначе позволяют увидеть, куда движется индустрия разработки программного обеспечения.

В 2010 году, этот отчет вдохновил меня на альтернативное исследование состояния Agile в Украине, о котором я докладывал на международной конференции Agile Eastern Europe.

Последний отчет о результатах опроса в 2012 году дает интересные факты для размышлений и позволяет делать интересные выводы, которыми и хочу поделиться. (далее…)