Начинать данную статью с различных вводных матчастей о «Великой силе SCRUM'а» и «ущербности водопадной методологии» считаю пустой тратой времени, поскольку в интернете и так достаточно много ресурсов, позволяющих узнать всё: от историй предпосылок создания технологий до всех преимуществ и недостатков в текущих реализациях. Как говорится: «Кто ищет, тот всегда найдет...» (с) :-).
Хочу поделиться неким опытом и даже скорей всего своим мнением о «существующем зоопарке ПО» в некоторых ИТ-компаниях, а именно подходах и реализациях.
Итак, начнем…
Естественно, для написания нового или улучшения существующего продукта предварительно нужно исследовать рынок, проанализировать потребность заказчиков, написать кучу каких-то нелепых концепций и ТЗ, в которых для «большего страха и мощи системы» необходимо как можно больше применять такие выражения как: «… на основе существующих артефактов, разработанная метамодель поможет реальным пользователям ...», обязательно использовать только термины и аббревиатуры и конечно же обязательным условием является описание «сферических коней в вакууме». Затем надо детально проанализировать все эти концепции, обрасти еще миллионами моделей: от простых IDEF-диаграмм до огромных UML-моделей со всякими ассоциациями, агрегациями и прочей «атрибутикой». В итоге получаются все новые и новые «пауки». Конечным пользователям глубоко наплевать на эти модели, диаграммы и т.д., им нужны рабочие кнопки…
После этого начинается непосредственно разработка, программисты начинают «клепать» то задуманное, о чем писалось в ТЗ. Опустим документирование и тестирование… перейдем сразу к выходу продукта на рынок. Маркетологи разработали кучу бумажек о выходе продукта «СуперМегаСистемаПро», которая позволит не только быть «системой, автоматизирующей то-то и то-то», но также (причем без лишней скромности)… она… она… она вообще позволяет «автоматизировать весь мир» :-). Вроде все хорошо, система мощная, современная, но почему-то заказчики недовольны… вроде система обо всем, а на самом деле не о чем. В итоге существующие продукты начинают ругать все кому не лень, а внедренцы в тихоря при помощи SDK (если есть) «клепают» все новые и новые плагинчики, лишь бы заказчик был доволен. Следствие, зоопарк разрастается…
Существующие проблемы ПО находятся прямо «на поверхности», их не надо искать, а уж тем более вытаскивать из глубины. Но тем не менее, начинаются новые обсуждения, новые концепции… в итоге «кто в лес, кто по дрова»… но главное, существующие недостатки завуалированы емкими терминами и как следствие новая система только стала еще сложнее и не понятнее. Жалко потраченного времени (2-5 лет), а уже тем более жалко выкидывать «тонны кода», ведь программисты не виноваты.
После разведенной мною демагогии о «водопадном подходе» :-) имеет смысл перейти к реально рабочей технологии SCRUM. Данная технология действительно помогает оживлять продукты и способствует разработке новых и качественных продуктов.
Инициативная группа разработки решила поработать по SCRUM, пытаясь исправить существующее положение вещей. Была сформирована команда в составе: программисты, аналитики и тестировщики, в которой как и положено технологии был ProductOwner со своим ProductBacklog'ом и SCRUM-мастер.
Процесс
Практику SCRUM мы объединили с некоторыми практиками XP (eXtreme Programming). SCRUM позволяет решить вопросы управления и организации, а XP специализируется на инженерных практиках. Из XP мы позаимствовали: парное программирование, рефакторинг, CodeReview и стилевое описание кода. Также на ретроспективах мы определили для себя ряд правил, которых мы придерживаемся. Для проектирования качественного GUI применяем практику использования персонажей.
Используем только легковесное документирование: диаграмма БД и UML-модель, которые разрастаются только в ходе разработки, соответственно — это не такие страшные пауки, как было описано выше.
Планирование
Планирование спринта в нашей команде длится практически целый день, НО если некачественно спланировать спринт, итерацию можно просто-напросто «завалить». Поэтому планирование является самой важной частью любого SCRUM-проекта.
Для подсчета идеальных часов мы используем фокус-фактор равный 0.4. В принципе такой показатель является средним по всем итерациям и является оптимальным, поскольку обычно запланированные задачи мы успеваем сделать вовремя.
Планирование как правило происходит возле «стены проектирования» (доски с маркерами) или за столом с компьютером, где наглядно можно посмотреть предыдущий функционал и GUI. Некоторые диалоги рисуются сразу на доске и фотографируются, затем эти фотографии будут задействованы при реальном выполнении задач. Для оценки трудоемкости используем PlanningPoker, практически все задачи являются тестируемые, что позволяет сразу выявить все ошибки.
SCRUM — митинг
Ежедневные встречи проводятся 2 раза в день возле SCRUM-доски. После встречи делается отметка на графике сгорания. Задача считается выполненной, т.е. переносится в «Done», только после тестирования. Программист может взять следующую задачу в «InProgress» только после одобрения аналитиком предыдущей задачи, взятой на выполнение. Диаграмму сгорания «подбивает» Скрам-мастер. Чтобы не превышать временной 15-минутный лимит, встреча проводится стоя. На встрече мы определяем, что мы сделали, что будем дальше делать, какие проблемы. Стараемся не обсуждать технические детали, но не всегда получается. Обычно встреча длится не более 10 минут. Если на митинге были определены некоторые технические проблемы, то их обсуждение проводится после скрам-митинга возле «стены проектирования» (доска с маркерами).
SCRUM — доска
В качестве скрам-доски мы используем обыкновенную пробковую доску. Область доски мы разделили на три части: ToDo (что надо сделать), InProgress (В работе), Done (Выполнено).
Однако, мы ведем и электронную версию доски (UserStory, задачи, % участия задействованных участников команды и т.д.) в программе. Это делается «для истории», в работе мы пользуемся только доской.
График сгорания
График сгорания является наглядным индикатором прогресса. Ось X — это ось времени. Ось Y — трудоемкость невыполненных задач. Задача считается выполненной если она проверена тестировщиком, во всех остальных случаях задача не выполнена.
Выполненные задачи переносятся в раздел «Done» скрам-доски. Таким образом график отображает сумму трудоемкости задач, находящихся в разделах «ToDo» и «InProgress». После ежедневных митингов, диаграмма сгорания «подбивается» с учетом выполенных задач за день. Также информация о выполнении заносится в программу, в которой наглядно отображается дата взятия задачи в «InProgress», дата выполнения данной задачи. В продукте автоматически подсчитывается средняя скорость команды, фокус-фактор. Данная информация иногда может помочь в переоценке трудоемкости задач и фокус-фактора команды.
Демонстрация
Демонстрация обычно проходит во второй половине дня. Стараемся приглашать как можно больше заинтересованных людей, принимать во внимание их пожелания.
Ретроспектива
Ретроспективу мы обычно проводим сразу после демо с чем-нибудь вкусненьким, хотя многие гуру SCRUM предлагают проводить ретроспективу в барах, пабах и т.д. Думаем, что можно как-нибудь рассмотреть эту идею.
На ретроспективе каждый участник команды рассказывает о тех моментах, которые ему понравились или не понравились, предлагает идеи для совершенствования процесса в команде. Также обсуждаются некоторые организационные моменты, взаимодействие в команде.
Для проведения ретроспективы используем доску с маркерами, которая условна разделена на 4 блока: минусы, плюсы, идеи и план. После того как все участники высказались и все идеи были записаны, мы проводим голосование путем расставления магнитных фишечек. Практически все, что было записано в блок «План» мы стараемся впоследствии соблюдать.
В результате работы по SCRUM наша команда смогла решить многие из тех проблем «на поверхности» быстро и качественно (правда систему не оживляли, писали с нуля).
Да пребудет с нами «великая сила SCRUMа» и дайте пользователям рабочие кнопки!!!
