Весенний бум мероприятий: Agile Fundamentals, Leading SAFe, ScrumDayUA, AgileEE и IT Spring

Радует, что сегодня можно много куда сходить и много чему поучиться. Выбирайте на свой вкус:)

Начну со своих тренингов:

24-25 марта 2017 года в Киеве проведу Agile FundamentalsПрограмма тренинга аккредитована International Consortium for Agile (ICAgile). Курс рассчитан на тех, кто мало знаком с принципами гибкой разработки, либо желает структурировать свои знания. По окончании тренинга участники получают именной сертификат ICAgile Certified Professional (ICP), который признается во всем мире. Детали, программа и регистрация здесь. И конечно же, промокод TIM дает возможность 10% скидки:)

26-27 марта 2017 года все в том же Киеве проведу Leading SAFe (Scaled Agile Framework). Это открытый сертификационный курс Leading SAFe, в котором мы детально изучим один из самых популярных фреймворков для масштабирования компании с помощью Agile — Scaled Agile FrameworkДетали, программа и регистрация здесь. И тут тоже промокод TIM дает возможность 10% скидки:)

Теперь по поводу конференций:

11 марта 2017 года в Киеве пройдет конференция ScrumDayUA, название  говорит само за себя: много интересных докладов и докладчиков. Если вы еще не решились, то поторопитесь, тем более что есть промокод ScrumTim на 10% скидки.

7-8 апреля 2017 года в Киеве Международная конференция Agile Eastern EuropeEsse quam videri — “Быть, а не казаться” — лозунг Восьмого сезона конференции AgileEE. Организаторы  уверены, чтобы по-настоящему быть Agile, а не казаться, необходим прорыв. Очень рекомендую посетить конференцию.  Зарегистрируйтесь на конференцию по промокоду 55YWXS5WPM1H и получите скидку 5%

28-29 апреля  2017 года уже в Минске (Беларусь) пройдет международная конференция о лидерстве и менеджменте — IT Spring 2017.  Это крупнейшая международная конференция, посвященная IT-бизнесу, которая однозначно стоит посещения!

 

Упражнение для обсуждения ролей в Scrum или другом Agile-методе

agiletopicscards-35

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

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

Самое простое, что приходит на ум для обсуждения ролей — сортировка терминов. В итоге механизм упражнения (или “игры”) предельно прост: участники делятся на группы по 2-4 человека и сортируют пачку терминов, которые относятся к ролям Scrum (в Scrum их 3, но вы можете ввести необходимое вам количество ролей). После работы в группах материал лучше закрепить общим обсуждением и уточнением, чтобы не было ошибок в понимании и разницы в трактовке. Я называют это “игра в бинго”. Мы берем одну роль, и каждая группа по очереди называет термин, который она отнесла к ней. Если остальные группы тоже отнесли термин к этой роли, они кричат “бинго”. Если нет — начинается обсуждение. Именно за обсуждения я и люблю это упражнение — в них мы проясняем понимание и углубляемся в аспекты той или иной практики, принципа или концепции.  Даже если у вашей группы достаточно опыта и расхождений в сортировке терминов нет, просите участников привести практические примеры. Так вы можете проверить их знания более глубоко.

Но где взять термины? Долгое время я использовал набор фраз, которые составил вместе с моими коллегами-консультантами. Но они были не совсем понятны участникам. С тех пор, как я узнал про Agile Topic Cards, я заменил фразы карточками, и все стало работать во много раз лучше!

Как вы помните (или можете прочитать), Agile Topic Cards представляют собой карточки, на которых нарисованы Agile-термины. Зеленые — это практики, синие — принципы, а красные — концепции. Из 166 карточек можно выбрать любое количество, которое покажется вам необходимым для дискуссии.

Лично я выбрал следующие номера:

Microsoft PowerPoint - Agile Topics Cards v3
2 – Definition of Done
По моему мнению, это ответственность команды, хотя Scrum-мастер может отвечать за внедрение и поддержку этого внутреннего договора.

Microsoft PowerPoint - Agile Topics Cards v3
3 – Vision
9 – User Story

agiletopicscards-10

10 – Backlog
Имеется в виду Product/Project Backlog, за которые отвечает Владелец Продукта.

agiletopicscards-11

11 – Trade Offs
Для меня это — договоренности и компромиссы, которых Владелец Продукта достигает между бизнесом и командой, но всегда можно обсудить, как это понимаете вы.

agiletopicscards-14-25
14 – Team Performance (Velocity и другие)
25 – 1:1s

Microsoft PowerPoint - Agile Topics Cards v3
26 – Vertical Slice
Это — хитрая карточка. Прежде всего имеется в виду, что Владелец Продукта должен мыслить функциональностью (Features), а не задачами. Но также нужно, чтобы команда сфокусировалась на всех технических аспектах и делала функциональность целостной — от UI до глубин БД. Эта дискуссия может перекликаться с тем, о чем я писал в статье “Какого цвета ваш Бэклог”.

agiletopicscards-31
31 – Adaptive Planning
Это ответственность Владельца Продукта. Картинка показывает движение к Цели (эта Цель — звезда, нарисованная на карточке Vision(#3)).

agiletopicscards-40-41-42-47-54
40 – Code Review
41 — Slicing
42 – Test Driven Development
47 – KPI’s
54 — Timebox

agiletopicscards-60
60 – Team Development
Эта картинка означает модель развития команды Брюса Такмана: Forming-Storming-Norming-Performing.

agiletopicscards-63
63 – End to End testing

agiletopicscards-64

64 – Decision Making
По-моему, это Владелец Продукта решает, чего не делать, и говорит пожеланиям “да” или “нет”.

agiletopicscards-66

66 – Face to Face conversation
Эту картинку я трактую так: команда должна предпочитать прямое общение другим типам коммуникации.

agiletopicscards-68
68 – Pair Programming

agiletopicscards-69
69 – Autonomy
Здесь подразумевается, что cross-functional-команда должна иметь достаточно автономности.

agiletopicscards-71-99
71 – Collective Code Ownership
72 — Visualization
78 – Motivation
83 – Transparency
84 – Sprint Burndown
85 – Release Burnup
86 – Forecasts and Velocity
87 – Retrospective
89 – Team dependencies
94 – Relative Estimation
95 – Poker Planning
99 – Iterative & Incremental

agiletopicscards-100

100 – Backlog Grooming
Тут я обычно даю выбрать большинству. Иногда Владелец Продукта заинтересован в том, чтобы узнать от команды “цену” следующих элементов бэклога. Иногда Scrum-мастер заинтересован в том, чтобы команда получила качественные Элементы Бэклога (PBI) до начала планирования следующего спринта.

agiletopicscards-101-107

101 – Continious Deployment
102 – Continious Delivery
104 – Clean Code
107 – Daily StandUp

agiletopicscards-111
111 – Demo
Продемонстрировать результаты и получить обратную связь — это ответственность команды (!). Во всяком случае, в нормальных компаниях :).

agiletopicscards-114

114 – Risks
Риски, о которых заботится Владелец Продукта, или менеджер, который стоит за командой и Sсrum-мастером (на картинке основные категории рисков: Бизнес, Технологии, Социальный, Дедлайны).

agiletopicscards-117
117 – Outcome VS Output
Владелец Продукта занимается тем, что максимизирует результат (Outcome) – больше счастливых пользователей.

agiletopicscards-120-143
120 – Continious Integration
126 – Servant Leadership
128 — Refactoring
132 – Automated Test Checking
143 – Sprint Backlog

agiletopicscards-146
146 – Team Kick-off/Lift-off
Это означает запуск новых команд или запуск нового проекта в команде.

Итак, все, что нужно для этого упражнения — перемешать, не взбалтывать и разделить на три или более пачки в соответствии с ролями в вашем Agile-процессе. Приятного обсуждения!

Конференции, открытые тренинги и воркшопы в ближайшее время

safe-icagile-scrum-game

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

13 мая 2016 года (on-line) в формате вебинара поговорим о том, как «Масштабировать компанию по Agile принципам«. Эта тема все больше и больше обсуждается и я решил собрать свои мысли и заодно дать небольшие пояснения об элементах, которые используются в Scaled Agile фреймворках. Участие бесплатное, регистрация обязательна.

15 мая 2016 года (Киев, Украина) играем в Scrum Card Game, о которой я недавно писал. Это хорошая возможность для всех: и тех, кто хочет немного соприкоснуться со скрамом, и для тех, кто хочет научиться фасилитровать эту игру, чтобы в игровой форме обучить основам Scrum. Количество мест ограничено, присоединяйтесь.

19-20 мая 2016 года (Киев, Украина) проводим первый в Украине открытый тренинг Leading SAFe (SAFe Agilist certification). На этом тренинге мы будем детально разбирать Scaled Agile Framework, практиковаться на симуляции, проводить планирование группой команд и учиться управлять портфолио на основе ценности для бизнеса. Скидка 20% по промо-коду www./ (Да-да, это для внимательных читателей 🙂 )

24-25 мая 2016 года (Минск, Беларусь) в рамках конференции IT Spring 2016 провожу также открытый тренинг Leading SAFe (SAFe Agilist certification), впервые в Беларуси. Еще раз напоминаю, что это тренинг по масштабированию Agile процессов для лидеров разработки и руководителей различных уровней.

26-27 мая 2016 года (Минск, Беларусь), также в рамках конференции IT Spring 2016, проводим тренинг ICP Agile Project Management. Это тренинг международного консорциума по гибким методологиям ICAgile по управлению Agile проектами для менеджеров проектов, а также Scrum мастеров, стремящихся к менеджменту проектов. Тренинг продвинутого уровня требует наличие одного из сертификатов мирового уровня по базовым владениям гибкими методологиями (CSM, CSPO, PSM или ICP).

29-30 мая 2016 года (Минск, Беларусь) конференция IT Spring 2016. 29 мая в рамках Keynotes Day буду говорить про «Масштабирование компании по Agile-принципам», на второй день проведу воркшоп «Scaled Ball point game».
Если вы хотите посетить и тренинги и конференцию — обратитесь к организаторам, у них есть интересное предложение 🙂

2-3 июня 2016 года (Днепропетровск, Украина) конференция ITEM (IT Evolution Meeting), где до конференции, 1 июня, проведу мастер-класс по созданию обучающих упражнений и игр AGILE GAME JAM, а во время конференции буду модерировать поток Project Management и выступлю с рассказом «Закат эпохи Agile или The Force Awakening» о том, как мы докатились до того, что известный бренд на букву «A» уже хоронят и при этом по прежнему индустрия нуждается в развитии и изменениях.

До встречи!

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

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

Притчи о любви к пользователям

love-to-users2

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

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

В повседневной жизни становятся очевидными многие вещи. Например, видно невооруженным взглядом, что полученный результат совершенно не соответствует нуждам пользователей. Такая ситуация наталкивает на мысль, что работники (не ИТ) в своей работе руководствовались какими-то другими критериями и уж явно не беспокоились о среднестатистическом клиенте.

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

Притча первая: "Туалет в торговом центре"

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

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

В задании наверняка было указано так: «должно быть четыре умывальника, четыре мыльницы для них и большое зеркало». Вот так — коротко и ясно.

Разработчики однозначно следовали инструкциям: установили умывальники и зеркало. Настала очередь мыльниц. Вероятно, решив что сверлить дырки в зеркале слишком хлопотно, разработчики повесили мыльницы там, где им было удобнее.

Результат получился такой:
toilet mirror

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

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

Притча вторая: «Номер для двоих в отеле»

Современный человек обязан быть мобильным. Поездки по разным городам Украины и за границу стали частью жизни почти каждого из нас.

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

Природные потребности утром у каждого человека по сути одинаковые. Помочь пользователям их удовлетворить, не мешая друг другу можно, достаточно легко. Решение в гостинице меня просто поразило:
Pritcha2_hotel

Кажется, что разделить душ и туалет на две комнаты — ничего особенного. Но как известно, все гениальное — просто.  Так стандартное решение «как везде» превратили в другое, более удобное. И дизайнеры не испугались отойти от аксиомы «все так делают». Пользователи оказались важнее.

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

К чему я это все?

Я уже писал о том, что "мне не нужно техзадание". Старый подход, который давно изжил себя. Описание будущего продукта в стиле «система должна» совершенно неуместно. Система никому и ничего не должна: она неживая и сама по себе ничего не хочет. В современном мире фокус уже давно сместился на пользователя. Любое решение (будь то ПО или что-то другое) создается в первую очередь для нужд людей, которые будут его применять на практике. Неудачное решение, причиняющее постоянные неудобства, обречено быть забыто. Оно так и умрет, не отыскав своих покупателей.

Важно думать в стиле «пользователю нужно» или «пользователь хочет». Только так и никак иначе мы будем точно понимать, что мы делаем и зачем.

Большинство читателей уже знакомы с форматом записи требований, которые так и назвали «Истории Пользователя». Суть идеи проста, пишем в стиле:
Как <КТО>, я хочу <ЧТО>, потому что <ЗАЧЕМ> 

На первый взгляд, идея элементарная, но одновременно она очень мощная. Ведь мы сразу концентрируемся на (ЗАЧЕМ) — целях, которыми будет руководствоваться (КТО) — пользователь нашего решения. Таким образом, создавая свое решение, мы думаем о том, будет ли удобно пользоваться тем, что мы сделали.

Есть еще целый ряд Agile-методов анализа нужд и описания требований: Use Case, Story Mapping, Impact Mapping.

На мой взгляд, такая формула работает не только для разработки ПО, ее можно применять и в других сферах. Основная миссия — создать «продукт», который будет отвечать желаниям пользователей.

Сразу скажу: не обманывайтесь простотой формата. Есть и у него свои подводные камни. Требуется навык и небольшая «домашняя работа», чтобы начать предугадывать потребности своих пользователей во всем, что вы для них создаете. Пока просто постарайтесь думать о тех, для кого вы создаете продукт или оказываете сервис. Полюбите ваших пользователей 🙂

К этой теме я еще вернусь с более практическими советами. Оставайтесь с нами или задавайте вопросы в комментариях.

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 Eeastern Europe 2015: планируем Agile трансформацию

Agile Transformation is a ChangeДокладчики мирового уровня, новые взгляды и идеи, опыт зарубежных и местных компаний, мастер-классы и вдохновляющие неформальные беседы за кофе — все это вновь привлекает участников со всей Восточной Европы и не только.

Если вы вдруг еще не слышали, Agile Eastern Europe вновь состоится уже в эту пятницу. Желающие все еще могу зарегистрироваться и принять участие.

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

Отдельным треком идут воркшопы — это мастер-классы, мини тренинги, симуляции и другие практические виды обучения и обмена опытом. Именно к этому потоку я присоединяюсь со своим коллегой, Юрием Малишенко. Мы поговорим про Agile-трансформацию или изменение компаний в сторону Agile.

Изменение лежит в основе любой человеческой деятельности.

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

Когда мы говорим про agile – мы на самом деле имеем в виду то, что нам предстоит изменить существующий способ взаимодействия, чтобы стать более гибкими. Но что значит добиться успешного изменения? Что такое устойчивое изменение? Возможно ли управлять изменением?

Многие считают, что изменение это просто – оценили текущее состояние, нарисовали цель, подготовили план и поехали! Ничего не напоминает? Многие внедряют Agile, делая это совсем негибким способом.

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

Ждем вас на мастер-классе для экспертов, в пятницу 27 марта в потоке Workshops в рамках Agile Eastern Europe 2015.

Продуктивный тренинг — это заслуга участников

IC-Agile

Я большой сторонник концепции «Training from the back of the room». Кто хоть раз был у меня на тренинге знает, что большая часть времени — это интерактив с участниками и работа в группах. Поэтому я твердо уверен, что отличный тренинг — это большей частью заслуга участников 🙂

На днях мы проводили открытый тренинг «Гибкая разработка ПО», аккредитованый международным Agile консорциумом (ICAgile International Consortium for Agile). Напарником в этот раз был мой коллега Андрей Баглай, за что ему отдельное спасибо.

Я редко делюсь впечатлениями, так как обычно не доходят руки до этого. Но в этот раз хочется поделиться, так как группа оставила самые приятные впечатления. Группа помогла создать непринужденную атмосферу, и два дня буквально пролетели. Один из участников приехал аж из Казахстана. Мы получили множество хороших отзывов, да и сами получили массу удовольствия от совместной работы с участниками тренинга.

Кто-то может спросить, почему я НЕ опубликовал анонс тренинга, а сейчас пишу о нем пост-фактум. Причина проста, на тренинге не было свободных мест 🙂

Я уже получил ряд писем от людей, не успевших попасть и спрашивающих о следующих тренингах, поэтому и решил как-то исправить ситуацию. Хочу сообщить, что 28-29 ноября, 2014 года в Минске состоится такой же класс по Agile управлению проектами, также аккредитованный международным Agile консорциумом.

Более того, пока без четких дат, могу сказать, что возможно проведение такого же тренинга в Киеве в конце года (ориентировочно — декабрь). Если у вас есть желание попасть на него, то напишите мне и я обещаю уведомить вас до того, как будет сделан публичный анонс.

Еще раз спасибо всем участникам тренингов и читателям блога.
Оставайтесь с нами.

Видео: Scaled Agile Framework за 7 минут — все, что нужно знать о SAFe

safe

На сегодняшний день Scrum является наиболее популярным фреймворком среди всех методов Гибкой Разработки ПО (Agile Software Development). Это видно по тому, о чем чаще всего говорят в статьях и на конференциях, также популярность подтверждается результатами опросов.

В то же время, все больше компаний сталкиваются с ситуацией, когда у вас есть сразу несколько команд, работающих над одним продуктом или проектом. Очевидно, что «Простой Ванильный Скрам» (plain vanilla scrum) тут не подходит. Конечно, Кен Швабер давно уже упомянул «великую мудрость»: Скрам-Скрамов (Scrum of Scrums) — встречу синхронизации между командами. Но на практике, одна эта встреча не помогает решить все вопросы организации масштабного проекта и координации 2-х и более команд. Во всяком случае исходя из моего опыта 😉

Последние года три, я постоянно сталкиваюсь с такими крупными проектами и компаниями, которые создают Enterprise Agile методы и культуру. (далее…)