Pull to refresh

Экстремальный аджайл — танцуют все!

Reading time 6 min
Views 13K
Всем привет! На протяжении года мы разрабатываем сервис «Эльба». В нашем проекте мы ввели практики аджайла для всей команды: для аналитиков, интерфейсологов, инженерных психологов, документаторов, тестировщиков и продвиженцев, а не только для разработчиков. Кажется, получилось хорошо, и мы хотим поделиться этим опытом.

Почему экстремальный?


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

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

О проекте


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

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

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

Все в одной комнате


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

Планирование


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

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


Таким образом, задача «всплывает» к дате релиза.
На самом деле не каждая задача проходит такой длинный путь до разработки. Скорее так происходит с крупными и сложными задачами. В исключительных случаях мы засовываем задачу прямо в итерацию разработчиков. Например, когда возникла идея сделать промокоды для партнеров, все так прочувствовали важность этой задачи, что отрелизили ее на следующий же день. А вообще, в жизни доска планирования выглядит несколько запутаннее.

После того, как общее планирование закончено, группы расходятся по углам и оценивают задачи, набранные в итерацию. Этим занимаются не все — только разработчики, интерфейсологи и аналитики: деятельность остальных групп плохо планируется. Для оценки задач играем в planning poker. Если после оценки оказывается, что задачи не помещаются в итерацию — решаем, что нужно выбросить.

ТЗ=ХЗ


Первое время мы готовили длинное подробное ТЗ (по привычке), но разработчики вообще не любят читать, и наши разработчики — не исключение. Кроме того, во время итерации нет времени на чтение, тем более парное (а разработчики почти всегда сидят в парах), поэтому ТЗ справедливо переименовалось в ХЗ.

Как работать по ХЗ? Вот так:

Прототип интерфейса — лучшее ТЗ


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



Презентации аналитиков


Как только аналитики прорабатывают очередную тему (например, отчетность в Пенсионный фонд), они устраивают презентацию для всей команды. После презентации все, хотя бы в общих чертах, представляют себе, что к чему.

Не знаешь — спроси


Мы сидим рядом, поэтому, когда возникает вопрос, не появляется желания искать ответ в ТЗ — просто спрашиваешь у аналитика. Вообще, мы довольно много общаемся и ощущаем пользу от этого (даже аналитики :).

Проектирование кусками


И ТЗ, и прототипы интерфейса, не готовятся целиком для всей системы: на это нет времени, да и смысла в этом нет — даже если получится спроектировать детальный прототип интерфейса на год вперед — он устареет через месяц. Мы готовим аналитику и проектируем только то, что в ближайшее время идет в разработку.

Ежедневные летучки


У нас нет выделенного человека, который бы раздавал всем задачи, большую роль играет самоорганизация. Чтобы она работала, необходимо координировать свои действия с другими — каждый должен быть в курсе, что делают и собираются делать остальные. Эту проблему решают ежедневные летучки: все собираются в одно и то же время каждый день у доски итерации.


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

Демонстрация


Демонстрация проходит в конце итерации. На ней направления показывают и обсуждают то, что за итерацию было сделано. Это еще один способ распространить информацию по всем участникам проекта.
  • Разработчики показывают систему. Не всегда к концу итерации все работает красиво и правильно, но всегда есть, что показать.
  • Проектировщики показывают прототипы. Объясняют тонкости, которые из прототипа не видны. Часто этот прототип разработчики берут на следующую итерацию в разработку, поэтому им демонстрация особенно кстати.
  • Графический дизайнер показывает баннеры, листовки и графический дизайн новых разделов системы.
  • Документаторы показывают справочные ролики.
  • Аналитики, психологи и продвижение обычно ничего не показывают, результаты их работы не так наглядны.
Жизнь показала, что для многих членов команды демонстрация — единственный шанс увидеть систему до релиза :)

Ретроспектива


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

Вот так в общих чертах выглядит процесс разработки в условиях «экстремального аджайла™». Позже мы бы хотели познакомить вас с некоторыми аспектами более подробно, а также мы готовы ответить на ваши вопросы в комментариях. Чтобы процесс ответов на ваши вопросы не превратился в толкучку за моим рабочим местом было бы здорово, если бы кто-нибудь поделился инвайтами с авторами статьи и главными идеологами аджайла в нашей команде — Женей Кобзевым и Семёном Молотковым (адреса дам в личку).

Продолжение здесь: habrahabr.ru/blogs/agile/113419
Tags:
Hubs:
+103
Comments 84
Comments Comments 84

Articles