Agile Podcast #3. Сезон 1. Цикл в Agile и внедрение

Участники:
Андрей Степанов, Асхат Уразбаев, Денис Миллер, Никита Филиппов

Темы
* Жизненный цикл.
* Этапы разработки в Agile.
* Почему Agile не получается и проваливается?
* Политика и эффективная работа.
* Внедрение сверху и внедрение снизу.
* Боевой пример: советы по внедрению Agile в стартапе (приглашенный гость)
* Вредные советы.

Ждём ваши комментарии и вопросы. Будем отвечать и обсуждать в Agile Podcast!



Прямая ссылка на Звук
Ссылка: http://agilepod.ru

Agile Digest №4: Agile, Lean и не много Product Management

Для тех, кто разобрался с Agile и готов совершенствовать процессы в компании на более высоком уровне Richard Durnall и Kraig Parkinson из ToughtWorks подготовили доклад на тему Lean Concepts for IT Professionals размещенный на InfoQ. В докладе рассказывается история происхождения Lean и как этот подход можно применить в ИТ среде.

Вчера на тренинге меня в очередной раз спросили: "Какие Scrum Tools вы рекомендуете использовать..." Мое мнение таково - если нет распределенной команды, достаточно TaskBoard и Wiki. Но поскольку вопросы на эту тему не смолкают, предлагаю обратиться к достаточно интересным обзорам Бориса Глогера. На его блоге вы можете почитать про Agile Buddy, BananaScrum, ScrumDesk, XPplanner и Mingle.

Пару интересных переведенных статей о Продукт Менеджменте в Agile и потребности ухода от глубокой Аналитической философии менеджмента продуктов. В первой статье, описывается фреймворк (сам его использую) работы Product Manager в Agile. Вторая статья рассказывает нам о том на сколько сложны и ненужны могут быть классические MRD, PRD и другие документы для разработки продукта.

Ну и на десерт, не мог обойти стороной. Меня постоянно мучают вопросом почему вы называете себя коучами, а не тренерами или консультантами. Mentoring, Coaching and Training - What is the Difference? Просто и доступно объясняет разницу между Тренерством, Коучингом и Менторингом.

Примеры ретроспективы

Тут попросили написать примеры проблем, с которыми сталкивалась команда: http://blog.scrumtrek.ru/2009/05/blog-post_27.html

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

Плюсы

* Помощь коллектива - человек, работающий в команде не чувствует себя "брошенным" на произвол судьбы. Команда оказывает всяческую помощь своим участникам.

* Доска (Planning board).

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

Проблемы

1 Медленный компьютер у ИМЯРЕК

- Upgrade (замена) компьютера на более мощный

2 Нерегулярное время скрам-митинга

- Решено проводить скрам-митинг в 12.45. Если участник опаздывает, он звонит (пишет смс) и предупреждает об этом.

3 Положение тикетов не всегда соответствовали реальной ситуации На скрам-митинге

- решено проверять положение тикета

4 Затягивание скрам-митинга

- См. пункты 1, 2 и 8 в разделе Идеи

5 Тормоза svn

- Перевод svn на использование его родного протокола а не http, FishEye

Идеи

1. Подготовка к скрам-митингу заранее (за 5-7 минут до начала)

- Вспомнить что делал вчера , с какими столкнулся проблемами

2. Уведомление о скрам-митинге за 10-15 минут до его начала

- Рассылка по аське (почте) напоминания членам команды о скрам-митинге

3. Ключевое слово на тикете

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

4. Крупнее шрифт на списке с задачами на итерацию

5. Заранее готовиться к планированию

- Заранее составлять back-log на итерацию, выделять задачи требующие дополнительного исследования/подготовки

6. Завести отдельный вид бумажек на задачи по исследованию

- На таких стикерах будут вести учет задачи по исследованию

7. Считать focus factor, реально потраченное время В конце итерации

- подсчитывать focus factor и фактически потраченное время в итерации

8. Дробление на подзадачи

- Большие по объёму задачи необходимо дробить на более мелкие длительностью не более 6 часов (1 раб. день)

9. Action Items

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

10. Более тщательное дробление на таски в джире

- Если на форуме в ветке, посвященной обсуждению какой-либо проблемы, находится более чем 1 проблема - заводить их в отдельные таски в джире. Не кидать все в один большой таск

11. Именование тасков в Jira

- Стараться давать таскам понятные и осмысленные имена которые дают представление о проблеме без вчитывания в суть проблемы. Некоторые хорошие идеи описаны в статье Правила оформления записей в JIRA

12. Бранчинг итераций в svn Заводить отдельные бранчи в svn на каждую итерацию

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

Канбан против Scrum

7 июля, во вторник, состоится очередная встреча сообщества Agile Russia. Тема, которую мы обсудим в этот раз - Канбан против Scrum. В последнее время всё чаще наряду с Agile и Scrum упомянаются Lean и Kanban. И хотя первые два зародились в сообществе разработчиков ПО (т.е. непосредственно в нашем "особом мирке"), а последние пришли из производства (точнее из автопрома, еще точнее - из Toyota), их часто упоминаю все вместе - чуть ли ни как синонимы. В итоге не мудрено запутаться и потеряться в этом многообразии хитро переплетенных терминов. Дело дошло до того, что сам Хенрик Книберг (Henrik Kniberg - широкоизвестный в узких кругах автор книги "Scrum and XP from the Trenches") написал весьма познавательную и полезную статейку "Scrum vs. Kanban" (http://www.crisp.se/henrik.kniberg/Kanban-vs-Scrum.pdf). Не пора ли и нам пролить свет на эту тему, а заодно и обсудить, неужели и впрямь можно отказаться от итераций и жесткого time-boxing-а, не потеряв при этом управляемость и прозрачность процесса?! А, может, правильно не выбирать Agile или Lean и Scrum или Kanban, а как-то хитро сочетать одно с другим? Прочитайте материалы по следующим ссылкам и приходите обсуждать: * http://www.crisp.se/henrik.kniberg/Kanban-vs-Scrum.pdf * http://availagility.wordpress.com/2008/10/28/kanban-flow-and-cadence/ * http://en.wikipedia.org/wiki/Lean_software_development Время: 7 июля, во вторник. Начало - 19-00. Окончание - 22-00. Место проведения: центр Москвы, офис компании Заказные ИнформСистемы Условия участия: Бесплатно. Регистрация обязательная. Просто заполнитерегистрационную форму или напишите письмо на askhat@agilerussia.ru Ждем :-). be ag;)e

Agile Podcast #2. Сезон 1. Как начинать проект используя Agile

Участники:
Асхат Уразбаев, Денис Миллер, Никита Филиппов

Темы

* Мысли о предыдущем подкасте. Waterfall как Agile с 1 Итерацией

* С чего начинается проект-

* Общее видение проекта. Продукт вижн.

* Роль Product Owner.

* Анонс следующего подкаста

Прямая ссылка на Звук
У подкаста появился сайт: http://agilepod.ru

Поездка на AgileEE вместе с AgileRussia

AgileRussia и компания ScrumTrek организуют коллективную поездку на конференцию AgileEE. Конференция проходит в Украине, и некоторым российским компаниям может оказаться трудным оплатить ее официальным образом. Компания ScrumTrek является соорганизатором конференции. Мы можем помочь оплатить участие в конференции и мастер-классах официально. Это не предполагает никаких дополнительных затрат :-)

Мы также планируем культурную программу для участников в Киеве, между прочим, красивейшем городе Европы.

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

Дайджест №3. Рефакторинг, тесты, самоорганизация

Интересная статья на InfoQ о проблеме рефакторинга. Это выжимка из обсуждения на группе Refactoring в Yahoo. Как известно, в Agile рефакторинг, как правило, идет одновременно с разработкой новых фич. Спор идет о том, можно ли останавливать разработку новых фич и заниматься исключительно рефакторингом текущего кода.

Недавно мы активно обсуждали с одним стартапом, нужно ли писать тесты в самом начале проекта. Пока проект только начался, процент переделок из-за меняющихся требований концепций просто небывало высокий. Писать тесты просто дорого. К тому же они замедляют разработку и, как следствие, замедляют скорость обратной связи от рынка. Однако в какой то момент все-таки начать писать тесты все таки надо! Как и когда это делать? Статья на InfoQ, которая называется Kent Beck Suggests Skipping Testing for Very Short Term Projects может дать вам несколько интересных идей на эту тему.

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

Вот этот пост Ryan Martens под заголовком "Agile and Lean Software Development - an Oxymoron?" инициирует дискуссию о том, как соотносятся Lean и Agile. Лично мне больше всего понравилась картинка, суммирующая развитие методологий по разработке ПО на уровне концепций с 50-х годов до нашего времени.

Если вы работаете в распределенной команде и применяете гибкие методологии, посмотрите, как решают проблему присутствия на рабочем месте в одной из компаний :-). Идея мне кажется безумно интересной, однако просто страшно, до чего может его довести воображение. Представьте, что компьютеру с вашим виртуальным изображением мы дадим возможность перемещаться по офису и манипулятор - хотя бы для перемещения задач на таскборде :-). Будущее наступило!

Agile Podcast #1. Что такое Agile

Участники:
Асхат Уразбаев, Денис Миллер, Никита Филиппов

Обсуждаемые темы:
* Проблемы разработки ПО
* Что такое Agile?
* Чем приятен Waterfall
* Сравниваем Agile и не-Agile

* Буддизм в Agile

Дайджест №2. Scrum of Scrum, модели зрелости Agile, способы провалить Agile, канбан

Замечательный и очень практичный гид по тому, как проводить митинги Scrum of Scrum от Mike Cohn. Если коротко, то идеи такие:
* Члены команды на скраме выбирают того, что будет представлять их команду на Scrum of Scrum (SoS)
* Частота SoS определяется командой. По опыту Майка вполне достаточно встречаться 2-3 раза в неделю
* SoS состоит из двух частей: первая часть напоминает обычный Scrum, вторая предназначаена для решения проблем. Длительность SoS в итоге больше: от 30 до 60 минут
* К трем вопросам традиционного скрама добавляется новый: "Собираетесь ли вы как то помешать другой команде?" :-)
* На первой части SoS запрещается говорить имена - это позволяет сфокусировать обсуждение на достаточно высоком уровне абстракции
* Команда поддеживает список проблем, которые надо обсудить на SoS

Интересная статья Ryan Martens с критикой попыток компании IBM во главе с известным Agile-евангелистом Scott Ambler создать модель зрелости для Agile. Модель создается во многом по аналогии с CMMi и будет называться Agile Process Maturity Model. По мнению авторов, ее целью является не идентифицировать уровень организации в соответствии с некоторым уровнем зрелости, а "помочь организациям категоризировать и понять Agile". Товарищ Martens уверен, что в этом случае модель не имеет ценности как модель зрелости. К тому же Agile'у она не нужна, так как никаких общих подходов по внедрению Agile в организации просто не существует, а в качестве общекомпанейской модели зрелости вполне можно взять CMMi.

Отличный пост о том, какие причины провала внедрения Agile наиболее типичны. Jean Tabaka делится 12-тью такими способами (хотя я подозреваю, их сильно больше).

Список всех имеющихся почтовых мейл-листов по Agile тематике. Их оказывается, очень много.

Автор блога (понятия не имею, кто он) рассказывает о своем опыте применения BurnDown Chart'ов. Он предлагает отдельно считать burndown отдельно по разным пунктам Definition of Done.

А в общем и целом интернет переполнен постами на тему Kanban.

Отличный и полноценный сборник ссылок на материалы про kanban в блоге компании TargetProcess. Прислал Michael Dubakov.

Как всегда, отличный материал отHenrik Kniberg, на этот раз о Kanban. Ссылку прислал Андрей Сатарин. Вот еще одна очень приличная статья от Jeff Patton

Впрочем, не буду более об Kanban, лучше почитайте дайджест Michael Dubakov и новости от lean thought leader David Anderson

"Рука судьбы" помогает понять Agile

На конференции Software People мы опробовали новую симуляционную игру "Рука судьбы". Получилось весьма интересно :)
- Минимум теории, максимум практики
- На примерах раскрываются типичные ошибки внедрения Agile
- Игровая форма помогает объяснить, как пользоваться основными артефактами Scrum.
- Меняет майнд-сет разработчиков с "разработки по требованиям" на "разработку фитч имеющих ценность для бизнеса"!

- Объясняет преимущества итеративной и инкрементальной разработки

Вот собственно на фото продукт одной итерации. Если кто не посетил конференцию и не увидел этого грандиозного зрелища - приглашаем на наши базовые 4 часовые тренинги :). Ближайший тренинг 17 июня.

Agile-Дайджест #1. Lean, kanban, ретроспективы

Ну что ж, это наш первый опыт создания дайджестов о том, что происходит в мире Agile за рубежом и в СНГ. Мы планируем делать их раз в неделю. Выходить они будут по понедельникам, так что welcome on board :-)

Итак, если говорить в общем о тенденциях развития Agile, то в последнее время очень сильно обсуждается Lean и Agile. Оно и понятно, очень часто "просто внедрить" Agile нельзя. Нужно перестраивать организацию в целом. Lean дает инструменты, которые позволяют это сделать.

Продолжаются споры о том, нужно ли оценивать в Agile или нет. С точки зрения Lean - это в общем-то waste, то есть потеря. Тем не менее, Agile в большой степени полагается на оценки, в частности при составлении объема итерации. Несколько доводов за и против можно почитать здесь и здесь

Так что если вы ничего не оцениваете, то вы можете смело заявлять, что у вас Lean и смело продолжать в этом духе. А то и бросайте это непростое дело. Стойте, я пошутил!

Вы знаете, что такое Kanban? Это такая карточка, которую применяют в Toyota для "заказа" нужной части. Если вы сборщик и вам нужно 4 двери, вы отправляете 4 канбана. Сборщики двери отправляют дальше канбаны на замки и т.д. В итоге, все делают ровно столько, сколько нужно. В итоге нет ненужных деталей на складе, да и дефектов намного меньше, ведь бракованную деталь обнаруживают сразу. В этой статье на InfoQ Kenji Hiranabe внятно рассказывает о канбан. Там же несколько соображений о том, как это соотносится с Software Development.

И наконец, последняя ссылка по теме Lean - сравнение Six Sigma, Lean и теории ограничений от Dave Nave. В конце приводится итоговая интересная таблица сравнения подходов.

Насчет нашей блогосферы. Из относительно новенького появился интересный блог http://blog.laway.in.ua/, который амбициозно называется "Лучшие реализации Scrum-практик". Стоит добавить в ваш RSS reader, автор пишет довольно дельные вещи.

В частности, почитайте о том, делить или не делить команду на части. Первая часть () и вторая часть

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

Дмитрий Зданович описывает классический вид ретроспективы

Денис Миллер отвечает ему.

Ну и я тоже не выдержал

На сегодня все. Продолжение на следующей неделе. Присылайте интересные ссылки!

Продуктовая стратегия в мире Agile. Потребность или Архаизм?

Я тут недавно общался с одной Agile-командой, они были очень недовольны своей работой; Последние полгода разработка превратилась в "чеканку фитч", как они выразились. C их точки зрения, Product Owner не имел никакого понятия о конечной цели: куда все это движется или чем разработка должна закончится.

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

Это, конечно, не первый случай, когда я встречаю такую путаницу в восприятии Agile методологий. И я боюсь, проблема создания правильной, эффективной Стратегии развития продукта пала жертвой неожиданного перехода на "Agile - рельсы". Раз в книгах про Agile ничего не написано про продукт - значит о нем не нужно думать -- Главное быть Гибким! И мне кажется, было бы полезно обсудить что такое Продуктовая стратегия (или Концепция Продукта), почему она важна и как это уживается с Agile методологиями.

Во-первых, Продуктовая стратегия предназначена для описания видения того, чего вы стремитесь достичь разрабатывая тот или иной продукт. Как правило, сроки описываемые в продуктовых стратегиях от года до пяти лет (в России, по моему опыту, чаще 1-1,5 года). Это долгосрочный план работы и он должен быть убедительным и обоснованным. Это ни в коем случае не мечты о сверхприбылях или фантазии по развитию компании - это совершенно четкий план. С другой стороны, это определенно и НЕ спецификация всех работ на ближайшие годы.

Часто продуктовая стратегия оформляется в виде простой странички в Wiki или на Листке А4, иногда в виде презентации или даже видео-ролика. Размер документа зависит от того, нужно ли вам донести Стратегию развития до 5 человек или до 100 сотрудников, можете ли вы поговорить со всеми лицом к лицу и ответить на вопросы или ваш документ должен быть исчерпывающим и самостоятельным. Самое главное, что какой бы ни была ваша стратегия развития продукта, она должна быть понятна каждому, убедительная и вдохновляющая.
Как измениться мир, когда ваш сервис или продукт будет выпущен? Я имею введу не то какие он фитчи будет содержать, а то, какие преимущества получат пользователи? Какую проблему мы решаем выпуская наш продукт? Почему пользователи должны полюбить его?

Во-вторых, стратегия продукта является связующем звеном между Бизнес-стратегией и Scrum Product Backlog'ом (в классических методологиях - Product RoadMap). Стратегия продукта драйвится потребностями бизнеса, а Product Backlog описывает то, как именно вы собираетесь из того что есть сейчас, сделать то, что написано в Стратегии продукта.
Не путайте Бизнес-стратегию и Продуктовую стратегию. Для примера, в бизнес-стратегии может быть написано: "Наши интернет-магазины должны позволять принимать заказы из Азии и Европы", в продуктовой же стратегии будет описан сервис требующий поддержку многоязычности, возможность конвертировать в локальную национальную валюту, возможность поддерживать местные платежные системы, способы доставки - все те вещи которые решают поставленную бизнес-проблему.

Третья и наверное самая важная вещь для хорошей стратегии продукта - это Хороший Product Owner. Это не легко, но если у вас нет хорошего P.O. - шансов на успех мало. Как в старой поговорке: "Если не знаешь куда идти - все пути одинаковы".
Разработка Стратегии продукта начинается с достижения глубокого понимания того, кем являются наши конечные пользователи. Для этого P.O. понадобится вовлечь лучших специалистов, как из технарей так и дизайнеров, заказчиков и всех-всех заинтересованных лиц.
Стратегия продукта обсуждается со всей командой, начиная от Топ-менеджеров до исполнителей. Очень важно чтобы ваша команда разработчиков полностью осознавала и разделяла продуктовую стратегию.

Многие P.O. очень часто совершают большую ошибку, считая, что Продуктовая стратегия "спускается" разработчикам сверху-вниз, как священное писание. Это может сработать в стартапах, где часто есть Визионер aka генератор идей, которой всех "зажигает", описывая что и как мы делаем. Как правило, в большой компании необходимо согласовывать стратегию, как с менеджментом наверху, так и с исполнителями внизу и убедиться, что вся компания идет в нужном направлении.
Разрабатывать фитчи без Продуктовой стратегии - пустая трата денег.

В четвертых, Стратегия Продукта никак не должна ограничивать или устанавливать порядок разработки фитч, которые вы отражаете в Product Backlog'е. В отличии от Продуктовой стратегии, вы можете и должны конфигурировать ваш Product Backlog, каждый раз когда вы получаете обратную связь от ваших пользователей, рынка, отдела маркетинга и так далее.

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

Надеюсь вы смогли почувствовать важность и преимущества наличия видения того, что вы собираетесь делать. И то, что в Agile-разработке, это обязано быть так же, как и в любой другой разработке ПО. И знать куда движется ваш продукт обязанность вашего P.O: Product Owner достаточно важная роль и его обязанности не просто выдавать фитчи от итерации к итерации.

Итак, если у вас нет Продуктовой стратегии, я предлагаю глубоко вздохнуть, сделать "шаг назад" и спросить себя: что же мы пытаемся сделать? Каков конечный результат? Что должно произойти с вашим проектом/продуктом/сервисом в ближайший год-два? Как вы собираетесь этого достичь? После этого донесите информацию до вашего менеджмента и продуктовой команды, особенно до ваших разработчиков - они тоже хотят знать куда мы движемся. Это поможет вам поддерживать высокую мотивацию, поверить в то что вы как менеджер предлагаете фитчи в итерацию не просто так, а с осознанием того, что и как нужно разрабатывать, чтобы достичь целей поставленных перед продуктом, командой и компанией в целом.

*В разных информационных источниках: Стратегия продукта = Продуктовая стратегия, Стратегия развития продукта, Концепция продукта, Концепция проекта.

Scrum Master: управление командами в Agile

18-19 июня в Москве состоится тренинг "Scrum Master: управление командами в Agile"!
Тренинг предназначен для начинающих и опытных скрам-мастеров, тимлидов и менеджеров проектов. В его основе лежат ответы на вопросы, которые возникают у каждого лидера команды и скрам-мастера: как создать хорошую команду, как внедрять новые практики, как «продать» Agile заказчику, что делать, если в команде конфликт, как превратить митинги в эффективные.
Тех кто готов к участию в данном тренинге - ждем вас! А кто не готов, ждем на базовом тренинге, который пройдет 17 июня, продолжительность 4 часа!
Подробности можно посмотреть на сайте www.scrumtrek.ru