Всем привет! На протяжении года мы разрабатываем сервис «Эльба». В нашем проекте мы ввели практики аджайла для всей команды: для аналитиков, интерфейсологов, инженерных психологов, документаторов, тестировщиков и продвиженцев, а не только для разработчиков. Кажется, получилось хорошо, и мы хотим поделиться этим опытом.
Кент Бек во время тренинга в Контуре рассказал нам, как он придумал экстремальное программирование. К тому моменту было известно несколько хороших практик: программирование в парах, тестирование кода модульными тестами, непрерывная интеграция, работа итерациями и т.д. Ноу хау Кента состояло в том, что он предложил использовать все эти практики одновременно и делать это не от случая к случаю, а вообще всегда. То есть слово «экстремальное» в данном случае происходит от «экстремума», а не от «экстремизма».
Наша ситуация в начале работы над проектом была чем-то похожа: разработчики знали практики аджайла и применяли их, но всех остальных людей в команде было в несколько раз больше, чем разработчиков. Тогда возникла идея попробовать распространить эти практики на всех людей, вовлеченных в работу. Так наш аджайл стал «экстремальным» :)
Эльба — это замена бухгалтера для небольших компаний: формирует счета и акты, считает налоги, готовит отчетность, подсказывает, когда и какой отчет нужно сдать — молодец, одним словом.
Специфика нашего проекта:
Итого: 21 человек, которые должны достичь общий результат. Практики, которые мы используем для этого — ниже.
Это самый легкий паттерн, польза от него ощущается сразу. Поначалу мы сидели на разных этажах, общались почтой и тратили на это массу времени. Как только переехали в одну комнату — сразу ощутили эффект: перестали писать длинные письма и вообще начали меньше писать. Вопросы теперь решаются гораздо быстрее, успешнее и позитивнее.
Зачем мы планируем?
Итак, в первый день итерации вся команда собирается у доски планирования. Задачи на текущую итерацию планируются детально. Также мы планируем несколько ближайших итераций, но приблизительно, не декомпозируя задачи. Если сильно упростить, то планирование выглядит так:
Таким образом, задача «всплывает» к дате релиза.
На самом деле не каждая задача проходит такой длинный путь до разработки. Скорее так происходит с крупными и сложными задачами. В исключительных случаях мы засовываем задачу прямо в итерацию разработчиков. Например, когда возникла идея сделать промокоды для партнеров, все так прочувствовали важность этой задачи, что отрелизили ее на следующий же день. А вообще, в жизни доска планирования выглядит несколько запутаннее.
После того, как общее планирование закончено, группы расходятся по углам и оценивают задачи, набранные в итерацию. Этим занимаются не все — только разработчики, интерфейсологи и аналитики: деятельность остальных групп плохо планируется. Для оценки задач играем в planning poker. Если после оценки оказывается, что задачи не помещаются в итерацию — решаем, что нужно выбросить.
Первое время мы готовили длинное подробное ТЗ (по привычке), но разработчики вообще не любят читать, и наши разработчики — не исключение. Кроме того, во время итерации нет времени на чтение, тем более парное (а разработчики почти всегда сидят в парах), поэтому ТЗ справедливо переименовалось в ХЗ.
Как работать по ХЗ? Вот так:
Программисты смотрят не в текст, а в прототипы интерфейсов, разработанные проектировщиками. Прототипы не нужно читать — по ним сразу ясно, что надо делать, а вот за формулами и форматами программисты все же идут в ТЗ.
Как только аналитики прорабатывают очередную тему (например, отчетность в Пенсионный фонд), они устраивают презентацию для всей команды. После презентации все, хотя бы в общих чертах, представляют себе, что к чему.
Мы сидим рядом, поэтому, когда возникает вопрос, не появляется желания искать ответ в ТЗ — просто спрашиваешь у аналитика. Вообще, мы довольно много общаемся и ощущаем пользу от этого (даже аналитики :).
И ТЗ, и прототипы интерфейса, не готовятся целиком для всей системы: на это нет времени, да и смысла в этом нет — даже если получится спроектировать детальный прототип интерфейса на год вперед — он устареет через месяц. Мы готовим аналитику и проектируем только то, что в ближайшее время идет в разработку.
У нас нет выделенного человека, который бы раздавал всем задачи, большую роль играет самоорганизация. Чтобы она работала, необходимо координировать свои действия с другими — каждый должен быть в курсе, что делают и собираются делать остальные. Эту проблему решают ежедневные летучки: все собираются в одно и то же время каждый день у доски итерации.
На доске итерации собраны задачи, которые мы запланировали сделать в текущую итерацию (листочки-задачи в начале итерации переклеиваются с доски планирования на эту доску).
Идем сверху вниз — каждая группа сообщает, что сделано за день, что планирует сделать завтра и перевешивает задачи.
На летучке сразу видно, если кто-то не делает задачу, которую кто-то другой считает очень важной, или что решение задачи затягивается.
Все это занимает около 20 минут.
Демонстрация проходит в конце итерации. На ней направления показывают и обсуждают то, что за итерацию было сделано. Это еще один способ распространить информацию по всем участникам проекта.
На ретроспективе вся команда рефлексирует — что было хорошо, а что плохо в прошедшую итерацию. Каждый может рассказать, что его волнует — в течение итерации не всегда есть время на это.
В результате ретроспективы получается план того, что нужно сделать в следующую итерацию, чтобы всем стало лучше. Обычно это нефункциональные задачи: например, взять верстальщика в команду, или сфотографироваться с попкорном для твиттера.
Вот так в общих чертах выглядит процесс разработки в условиях «экстремального аджайла™». Позже мы бы хотели познакомить вас с некоторыми аспектами более подробно, а также мы готовы ответить на ваши вопросы в комментариях. Чтобы процесс ответов на ваши вопросы не превратился в толкучку за моим рабочим местом было бы здорово, если бы кто-нибудь поделился инвайтами с авторами статьи и главными идеологами аджайла в нашей команде — Женей Кобзевым и Семёном Молотковым (адреса дам в личку).
Продолжение здесь: habrahabr.ru/blogs/agile/113419
Почему экстремальный?
Кент Бек во время тренинга в Контуре рассказал нам, как он придумал экстремальное программирование. К тому моменту было известно несколько хороших практик: программирование в парах, тестирование кода модульными тестами, непрерывная интеграция, работа итерациями и т.д. Ноу хау Кента состояло в том, что он предложил использовать все эти практики одновременно и делать это не от случая к случаю, а вообще всегда. То есть слово «экстремальное» в данном случае происходит от «экстремума», а не от «экстремизма».
Наша ситуация в начале работы над проектом была чем-то похожа: разработчики знали практики аджайла и применяли их, но всех остальных людей в команде было в несколько раз больше, чем разработчиков. Тогда возникла идея попробовать распространить эти практики на всех людей, вовлеченных в работу. Так наш аджайл стал «экстремальным» :)
А на самом деле мы просто хотели назвать статью погромче, чтобы все сразу заинтересовались. Ну, и упомянуть про тренинг Кента Бека в Контуре, чтобы увеличить свойчлвес в глазах общественности.
О проекте
Эльба — это замена бухгалтера для небольших компаний: формирует счета и акты, считает налоги, готовит отчетность, подсказывает, когда и какой отчет нужно сдать — молодец, одним словом.
Специфика нашего проекта:
- В проекте нет конкретного заказчика, который любезно разъяснит, что ему нужно, а потом еще и оплатит этот праздник жизни. Мы лишь в довольно общих чертах представляем то, что хотим сделать, поэтому существенная часть времени тратится на исследования пользователей.
- Делать отчетность не так-то просто: законодательство у нас запутанное, правила периодически меняются, да еще и противоречат друг другу, поэтому другую, не менее существенную, часть времени нужно потратить на перевод нормативных документов с птичьего языка на человеческий.
- Наши пользователи не знакомы с бухгалтерией, и нам нужен очень понятный интерфейс, который избавит их от кошмаров законодательства, а хороший интерфейс нельзя сделать с наскока, поэтому перед началом разработки нужно потратить еще одну существенную часть времени на проектирование прототипа интерфейса и юзабилити-тестирование.
Итого: 21 человек, которые должны достичь общий результат. Практики, которые мы используем для этого — ниже.
Все в одной комнате
Это самый легкий паттерн, польза от него ощущается сразу. Поначалу мы сидели на разных этажах, общались почтой и тратили на это массу времени. Как только переехали в одну комнату — сразу ощутили эффект: перестали писать длинные письма и вообще начали меньше писать. Вопросы теперь решаются гораздо быстрее, успешнее и позитивнее.
Планирование
Зачем мы планируем?
- Планы задают ритм и мотивируют команду. Мы стараемся сделать все задачи, взятые в итерацию, и это держит нас в тонусе.
- Как мы уже писали, в нашем случае нельзя просто взять и начать программировать: задача должна быть обработана разными группами — аналитиками, интерфейсологами, психологами. Планирование синхронизирует наши действия.
Итак, в первый день итерации вся команда собирается у доски планирования. Задачи на текущую итерацию планируются детально. Также мы планируем несколько ближайших итераций, но приблизительно, не декомпозируя задачи. Если сильно упростить, то планирование выглядит так:
Таким образом, задача «всплывает» к дате релиза.
На самом деле не каждая задача проходит такой длинный путь до разработки. Скорее так происходит с крупными и сложными задачами. В исключительных случаях мы засовываем задачу прямо в итерацию разработчиков. Например, когда возникла идея сделать промокоды для партнеров, все так прочувствовали важность этой задачи, что отрелизили ее на следующий же день. А вообще, в жизни доска планирования выглядит несколько запутаннее.
После того, как общее планирование закончено, группы расходятся по углам и оценивают задачи, набранные в итерацию. Этим занимаются не все — только разработчики, интерфейсологи и аналитики: деятельность остальных групп плохо планируется. Для оценки задач играем в planning poker. Если после оценки оказывается, что задачи не помещаются в итерацию — решаем, что нужно выбросить.
ТЗ=ХЗ
Первое время мы готовили длинное подробное ТЗ (по привычке), но разработчики вообще не любят читать, и наши разработчики — не исключение. Кроме того, во время итерации нет времени на чтение, тем более парное (а разработчики почти всегда сидят в парах), поэтому ТЗ справедливо переименовалось в ХЗ.
Как работать по ХЗ? Вот так:
Прототип интерфейса — лучшее ТЗ
Программисты смотрят не в текст, а в прототипы интерфейсов, разработанные проектировщиками. Прототипы не нужно читать — по ним сразу ясно, что надо делать, а вот за формулами и форматами программисты все же идут в ТЗ.
Презентации аналитиков
Как только аналитики прорабатывают очередную тему (например, отчетность в Пенсионный фонд), они устраивают презентацию для всей команды. После презентации все, хотя бы в общих чертах, представляют себе, что к чему.
Не знаешь — спроси
Мы сидим рядом, поэтому, когда возникает вопрос, не появляется желания искать ответ в ТЗ — просто спрашиваешь у аналитика. Вообще, мы довольно много общаемся и ощущаем пользу от этого (даже аналитики :).
Проектирование кусками
И ТЗ, и прототипы интерфейса, не готовятся целиком для всей системы: на это нет времени, да и смысла в этом нет — даже если получится спроектировать детальный прототип интерфейса на год вперед — он устареет через месяц. Мы готовим аналитику и проектируем только то, что в ближайшее время идет в разработку.
Ежедневные летучки
У нас нет выделенного человека, который бы раздавал всем задачи, большую роль играет самоорганизация. Чтобы она работала, необходимо координировать свои действия с другими — каждый должен быть в курсе, что делают и собираются делать остальные. Эту проблему решают ежедневные летучки: все собираются в одно и то же время каждый день у доски итерации.
На доске итерации собраны задачи, которые мы запланировали сделать в текущую итерацию (листочки-задачи в начале итерации переклеиваются с доски планирования на эту доску).
Идем сверху вниз — каждая группа сообщает, что сделано за день, что планирует сделать завтра и перевешивает задачи.
На летучке сразу видно, если кто-то не делает задачу, которую кто-то другой считает очень важной, или что решение задачи затягивается.
Все это занимает около 20 минут.
Демонстрация
Демонстрация проходит в конце итерации. На ней направления показывают и обсуждают то, что за итерацию было сделано. Это еще один способ распространить информацию по всем участникам проекта.
- Разработчики показывают систему. Не всегда к концу итерации все работает красиво и правильно, но всегда есть, что показать.
- Проектировщики показывают прототипы. Объясняют тонкости, которые из прототипа не видны. Часто этот прототип разработчики берут на следующую итерацию в разработку, поэтому им демонстрация особенно кстати.
- Графический дизайнер показывает баннеры, листовки и графический дизайн новых разделов системы.
- Документаторы показывают справочные ролики.
- Аналитики, психологи и продвижение обычно ничего не показывают, результаты их работы не так наглядны.
Ретроспектива
На ретроспективе вся команда рефлексирует — что было хорошо, а что плохо в прошедшую итерацию. Каждый может рассказать, что его волнует — в течение итерации не всегда есть время на это.
В результате ретроспективы получается план того, что нужно сделать в следующую итерацию, чтобы всем стало лучше. Обычно это нефункциональные задачи: например, взять верстальщика в команду, или сфотографироваться с попкорном для твиттера.
Вот так в общих чертах выглядит процесс разработки в условиях «экстремального аджайла™». Позже мы бы хотели познакомить вас с некоторыми аспектами более подробно, а также мы готовы ответить на ваши вопросы в комментариях. Чтобы процесс ответов на ваши вопросы не превратился в толкучку за моим рабочим местом было бы здорово, если бы кто-нибудь поделился инвайтами с авторами статьи и главными идеологами аджайла в нашей команде — Женей Кобзевым и Семёном Молотковым (адреса дам в личку).
Продолжение здесь: habrahabr.ru/blogs/agile/113419
