Привет, друзья! Данный пост не о преимуществах или недостатках скрама, а о том, как он устроен у нас в распределенной команде.
Кто мы?
Команда разработчиков, находящаяся частично в Самаре, частично в Оренбурге. Заказчик у нас в Москве (неожиданно, правда? 🙂
Что мы делаем?
Разрабатываем iOS приложение, посвященное тайм-менеджменту по методике Глеба Архангельского. Мы рискнули, несмотря на то, что опыт работы других разработчиков с методикой Тайм Драйв был не особо вдохновляющим. Как вы сможете увидеть в конце статьи, у нас все получилось 😉
Что мы делаем для того, чтобы распределенная команда чувствовала себя единым коллективом и работала эффективно?
1. Ведем бэклог и спринтлоги в удобном Issue tracker’e
Предлагаю взглянуть на нашу доску — на ней представлены парочка пользовательских историй из текущего спринта. Мы используем Jetbrains Youtrack — замечательный issue tracker, который имеет отличную Agile доску, в которой легко добавлять и удалять колонки, выстраивая процесс разработки так, как удобно именно вашей команде.
2. Совместно проводим оценку историй и планирование релизов
Оценку историй и разбивку их на задачи делаем в два этапа. Один раз в неделю мы проводим грумминг, на котором оцениваем истории и разбиваем их на подзадачи, выясняем, есть ли какие-нибудь пробелы в знаниях, и что нам еще необходимо уточнить, чтобы успешно сделать историю. На планировании еженедельного спринта мы просто берем в работу истории, которые нагруммили, ставим цель спринта (чтобы понимать, чего делать не нужно), и начинаем разработку. Сначала мы пробовали обходиться только планированием итерации, но практика быстро показала, что регулярные грумминги позволяют не растягивать удовольствие от планирования на 3-4 часа и здорово экономить время, заранее планируя и проводя исследования, необходимые для реализации будущих историй.
Мы оцениваем трудоемкость каждой истории относительно одной простой истории, принятой за единицу (эталон) и затем разбиваем их на задачи. Оценки в человек-часах мы не используем. Почему? Думаю, лучший ответ на этот вопрос дал Сергей Дмитриев в своем блоге Agile Coach.
Оценки в человеко-днях у нас давали такую погрешность оценивания объема задач для итерации, что переход переход на стори поинты был очень заметен — итерации удалось стабилизировать очень быстро.
Для составления плана релизов мы используем среднюю скорость команды в story point’ах, которую Scrum Master отслеживает постоянно в течение проекта. Все оцененные истории бэклога распределяются по спринтам. Далее, если скорость разработки меняется, или происходят изменения в наборе функционала, план релизов легко корректируется на очередном грумминге и планировании, и мы всегда можем сориентировать заказчика, когда будет поставлен тот или иной функционал.
3. Построили отлаженный конвеер для выдачи свежего функционала
Код мы храним на github.com, что для распределенной команды весьма удобно, так как позволяет делать дельты для code review.
Под любую историю заводим отдельную ветку. Как только история выполнена, по ней проводится code review другим членом команды. Так как истории небольшие, мы постоянно находимся в курсе изменений на проекте, и нам не приходится потом выделять несколько дней жизни на изучение тонн чужого кода. Ну и конечно повышается качество кода в целом, с ним потом легче работать. После code review производится merge ветки в master, откуда изменения подхватывает наш Continuous Integration server. Для этого на отдельной машинке заведен TeamCity, который собирает сборки по каждому коммиту, гоняет тесты и выдает сборку в Testflight, откуда сборка автоматически уходит на тестирование внутреннему отделу QA.
4. Придерживаемся принятого регламента разработки
Любая задача в пользовательской истории проходит через следующие этапы:
- Open — никто за задачу не брался
- In Progress — в данный момент ее пилят
- Code Review — ожидаем code review
- Fixed — готово для тестирования, вливается в master. Тестировщик (он же Product Owner у нас) смотрит на доску и видит, что уже можно проверять
- Verified — все проверено, косяков нет, багов нет, историю со всеми задачами можно показывать заказчику
5. Много общаемся между собой и с заказчиком
Доска для нас, в первую очередь, средство коммуникации в команде. Броский взгляд на нее дает нам понять, все ли мы успеваем, где у нас проседают истории (затягивается тестирование или code review), и что можно сделать, чтобы зафиксить ситуацию.
Каждый день в назначенное время проходит встреча (daily meeting) для синхронизации команды. Поскольку у нас команда распределена на разным городам, приходится договариваться и выбирать удобное для всех участников время встречи и проводить созвон по Skype.
В начале проекта после завершения каждой итерации наш Product Owner проводил демонстрацию результатов спринта заказчику, но с недавних пор демо стали проводить сами программисты, потому что на демо часто возникают вопросы технического характера, да и зачем лишать людей удовольствия показать результаты своей работы? Сначала мы созванивались с заказчиком через skype и использовали разные конструкции для демонстрации функционала на устройстве через камеру, но сейчас чаще проводим встречу через Adobe Connect, где шарим экран и показываем сделанные user story в симуляторе. Здесь же происходит генерация новый идей и обсуждение стратегического развития продукта. Заряд маны после проведение демо командой возрастает значительно.
Обычно сразу же после демо проводится ретроспектива, где мы обсуждаем проблемы в наших процессах и думаем, как их пофиксить.
Резюме
Описанный процесс в нашей команде выстроился не сразу, а итеративно, в процессе набивания шишек и наступания на разные грабли. Разумеется, завершенного Agile быть в принципе не может, как и идеального процесса. Однако то, что мы используем, позволяет нам стабильно выдавать результат и постоянно развиваться, а это самое главное. Надеюсь, что описанный опыт сможет кому-то помочь, и может быть даже взят за основу для работы в ваших проектах.
P.S. Так что же у нас получилось? Ответ на этот вопрос — на момент написания статьи приложение “Тайм-Драйв” находится в Топ-30 Free iPhone apps overall Russia и в ТОП-1 категории Business среди бесплатных приложений.
ссылка на оригинал статьи http://habrahabr.ru/post/173873/
Добавить комментарий