Привет, хабрадруг. Считаешь ли ты, что waterfall (каскад) при разработке ПО — это единственный расово-верный подход? Да или нет — спеши под кат.
Мы, например, для разработки своего web-сервиса SmartNut используем scrum с техническими практиками eXteme Programming внутри. Как иначе мы бы смогли доставлять клиентам бизнес-ценности каждые 2 недели (релизный цикл). Считаю, что нас можно отнести к ребятам, делающим Lean Startup.
Scrum c XP использовались и в моей прошлой команде, но здесь мы развиваем тему более продуктивно.
Постараюсь коротко рассказать вам основные техники scrum и XP, которые мы сумели внедрить, поддерживаем, изменяем и улучшаем для увеличения эффективности.
0. Наша команда
Product owner (PO), team, scrum master, всё как в книжке. PO — владелец продукта, ответственный за истории и приоритезацию задач. В нашу команду, реализующую требования PO, входят разработчики и тестировщики. Scrum master является членом команды и кроме функций scum master’а является ещё и разработчиком продукта.
1. Итерации
До последнего времени итерации были недельными, а обновление приложения мы выполняли раз в две недели.
Возникло ощущение, что основной мотивацией для выполнения задачи были именно релизы, а не итерации. Поэтому часто задачи переходили из итерации в итерацию, если это не мешало выпуску релиза.
Сейчас мы привязали итерации к релизному циклу, чтобы испытать, насколько это будет удобнее, сможем ли мы уменьшить накладные расходы, и сможет ли большее количество длинных задач помещаться в двухнедельную итерацию.
Насколько же мы гибки на каждом из этапов реализации проекта?
2. Планирование
У нас есть product vision, на основании него периодически создаются планы на релиз. Релизом считается некоторый набор функций, которые могут быть реализованы за какое-то конечное время, и имеющих наивысший приоритет для доставки клиентам на данный момент.
Планирование таких релизов позволяет видеть «генеральную линию» развития нашего продукта. Не все задачи из этого релиза будут реализованы, главное — это направление.
Микрорелизы выпускаются каждые 2 недели.
Product owner пишет истории к началу итерации. Чтобы они были гладкими и шелковистыми, PO должен посвятить обсуждению историй с командой некоторое количество времени в предыдущей итерации, что он и делает. Некоторые постановки принимаются, в некоторые вносятся изменения, а некоторые откладываются до появления реальной необходимости в их выполнении.
Например, есть две задачи: первая добавляет новую функциональность, а вторая — развивает её или улучшает юзабилити.
Если мы сомневаемся, что первая задача «выстрелит», т.е. принесёт какую-то ощутимую пользу нашим клиентам, то мы можем отложить вторую задачу — до сбора статистики и получения обратной связи.
2.5 Оценка
Мы убедились на собственном опыте и знаем, что индивидуальная оценка в днях и часах очень неточна. Поэтому мы оцениваем в баллах и очках с использованием Planning Poker для обеспечения независимости оценок. Это, кстати, ещё и весело!
Из интересного: раньше мы всегда пытались прийти к единой оценке. Но Jeff Sutherland (на фото) предлагает решение с расчётом среднего арифметического, если все игроки выбросили карты, которые идут подряд в ряде Фибоначчи.
3. Условия труда
Для нашей команды выделен отдельный большой и светлый кабинет. Ничего не мешает нам обсуждать задачи, проводить митинги, искать и ликвидировать препятствия. Каждое утро в 11-30 мы проводим стендап митинг, который в лучших традициях длится 15 минут. Мы считаем скорость и стараемся, чтобы она всё время росла, не считая рост самоцелью.
Посидеть рядом с программирующим коллегой не считается преступлением. Помощь в решении инфраструктурных задач и проблем с окружением считается почётной работой.
4. Дизайн системы
Самое сложное — вести разработку так, чтобы система была простой и понятной как для конечного пользователя, так и для всех программистов команды. Если фича не очевидна, если 2 человека из коридора не могут, сев за компьютер, раскусить, что же задумал PO или разработчики, значит нужно что-то менять. Мы, как команда, двигаемся в направлении простоты, не всегда это получается, но мы стараемся.
То же относится и к функциям, потребности в которых рынок ещё не показал. Очень хочется добавить их, вроде бы это и просто и нужно, но кто ими будет пользоваться?
5. В процессе разработки
Если возникают вопросы по постановкам, то сидящий в нашем кабинете Product owner может ответить на все из них.
У нас есть стандарты написания кода, что позволяет смотреть на чужой код как на свой без лишних эмоций.
TDD мы не используем. Тесты пишутся после написания кода, а так же — на найденные ошибки.
Мы используем Jenkins для Continious integration процесса. Если Jenkins получает сигнал, что код в svn обновился, то проходит автоматическая сборка проекта. Запускаются тесты, запускается статический анализатор кода. О негативных результатах, если они имеют место быть, оповещаются люди, чьи изменения попали в сборку.
В связи с отсутствием парного программирования в явном виде, мы проводим процедуру code review. Проведение CR является критерием готовности задачи.
Каждый имеет право вносить изменения во все части системы, что повышает ответственность и уменьшает вероятность пропуска недочетов.
Кроме unit-тестов, у нас есть и приёмочные тесты на основные функции системы, которые так же проходят после обновления кода в репозитории.
Ещё один критерий готовности задачи — протестированность и проверка на соответствие постановке до коммита. Когда разработчик считает, что задача готова, он отдаёт её на тестирование. Тестировщик проверяет задачу и только после того, как он удовлетворён качеством и полнотой, задача может считаться выполненной. Это позволяет экономить время на переключении между задачами и заливать код в репозиторий уже в оттестированном виде.
Эта процедура не исключает приёмочного тестирования перед выкатыванием релиза тестировщиком и Product owner’ом после завершения каждой истории, которая может состоять из нескольких задач.
Для достижения максимальной продуктивности в команде разработки должно использоваться максимальное количество практик XP, к чему мы стремимся. Но нельзя забывать и о полном наборе практик командного framework’а Scrum.
Scrum говорит, что одной из задач scrum master’а является выяснение и ликвидация препятствий. До последнего времени мы мало задумывались о коренном улучшении процесса. Хотя в техниках scrum для этого предусмотрен специальный митинг — ретроспектива, на которой нужно смотреть назад, искать препятствия и закреплять использованные положительные практики. Сейчас мы проводим ретроспективу каждую итерацию и используем листы A3 (а три) для выявления узких мест в процессе.
Ко всему прочему в конце каждой итерации мы проводим демо, хвастаемся перед окружающими, коллегами из других отделов что же мы сделали за итерацию. Получаем кучу полезных и не очень предложений, а так же, бывает, находим незамеченные ранее баги.
В общем, с каждой итерацией мы получаем обратную связь от наших клиентов, и можем с уверенностью сказать, что при помощи SmartNut делаем мир вокруг немножечко лучше. Каждые две недели.
Если и ваша цель — быть на гребне волны и получать удовольствие только от настоящих водопадов, доставляйте клиенту обновления как можно чаще. А в этом вам поможет scrum и xp.
P.S. Если ты, хабрадруг, ещё считаешь, что то, что мы делаем идеологически неверно или наоборот хочешь похвалить, то добро пожаловать в комментарии.
