Цели
Рассмотреть пожалуй самого яркого представителя из мира
Agile - методологию Scrum. Описать типичный процесс работы в условиях этого подхода. Выделить достоинства и недостатки.
Предисловие
Это уже вторая заметка на тему Agile, конкретизированная в реальном приложении. Первая -
Extreme Programming -
инженерного плана методология, более конкретная и близкая к насущным вопросам, таким как
тестирование,
парное программирования.
Scrum, в отличие от Extreme Programming предлагает подход не к разработке программного обеспечения, а более акцентирует внимание на
управлении этим процессом. И с точки зрения управления (менеджмента) для реализации всех принципов (о них далее) необходимо наличие, во-первых,
заказчика (или его представителя), который отдаст проекту своё время и мысли (выражающие желаемый результат,
требования), а во-вторых, команды
первоклассных специалистов по части проектирования и реализации кода.
Термины
Scrum - методология управления разработкой ПО, включающая множество моделей (о которых ниже) и ролей (ScrumMaster, Product Owner, Team).
ScrumMaster - руководитель, направляет команду по пути Scrum.
Product Owner - заказчик, клиент.
Team - команда разработчиков.
Backlog - список требований.
Sprint - фиксированная итерация, термин сугубо Scum'овский; далее по тексту "спринт".
Порядок изложения
Для начала выделяются общие требования, которые свойственны Scrum, а также следствия из свойств. Далее будут показаны основные этапы (модели или практики), которые с позиции именно менеджмента, что есть особенность подхода: составление списка требований, оценка сложности реализации, планирование спринта (этот пункт и далее в
части 2), собственно спринт, тактическое планирование (на один день), оценки прогресса, подведение итогов по итерации. Последним этапом рассматривается вопрос масштабирования методологии Scrum на крупные проекты.
Общие положения
Как было отмечено выше, для нормального Scrum понадобятся: заказчик и команда.
Заказчик вовлечён в процесс разработки, это одна из ключевых претензий. Команда состоит из профессионалов, видавших виды людей. Члены коллектива равноправны, то есть не выделяется определённого механизма подчинения: каждый
участник имеет
право голоса и его голос может стать ключевым. Основное свойство команды:
взаимодействие. Только посредством общих усилий достигаются все поставленные цели. Главный инструмент в их руках - коммуникации,
общение, прямой разговор (друг с другом, с заказчиком).
Другим моментом является
планирование, которое
не пытается предвосхитить
все детали и проработать
все ответы на возникающие (а что там будет?) трудности. По факту
планирование занимается разрешением текущих задач и знаменует собой лишь
направление движения. Оно и понятно: изменяющиеся условия делают невозможным (или в крайнем случае затруднительным) учёт всех факторов, хотя сам
учёт (в традиционной модели) отнимает очень
много времени, производя
документацию.
Большое внимание уделяется организации рабочего пространства и инструментарию для, например, оценки прогресса. Одним из атрибутов Scrum является
доска (настенная либо реализуемая программно), на которой крепятся: список требований, текущие задачи, задачи в процессе выполнения, готовые для тестирования, наконец, полностью законченные. Таким образом, можно оперативно узнать на каком
этапе находится программный продукт, какие задачи ключевые, какие выполнены.
Следствия. Команда и её численность такова, чтобы гармонично кооперировать. Очевидно, большими такие команды быть не могут. А значит, это накладывает ограничение на величину проекта. Для
крупных проектов применяется модель распределённых (по всему миру) команд. Как согласовывать их действия? Это
проблемное положение, но выходы находятся (об этом в
части 2).
Список требований
Список требования (backlog) может быть пополнен каждым членом команды. Но
приоритеты расставляет только
заказчик. В результате получается список, наверху которого расположены наиболее важные
требования (которые звучат по типу "Я как (роль пользователя) имею возможность (действие) для достижения (результат)"). Каждый пункт составляется только с
позиции бизнеса: наиболее приближенным к клиенту и исключающим техническую сторону. Делается это для большей наглядности с целью
исключения непонимания со стороны заказчика. Будучи составленными (а на деле они всегда эволюционируют)
требования должны быть всегда "под рукой",
доступны для команды (вспоминаем доску на стене).
Оценка сложности требований
Оценка требований производится на верхнем уровне. До конца глубина задачи не ясна, поэтому это оптимальный вариант. По каждому пункту из списка требований команда делает вывод о том, насколько сложной является реализация. Вывод, как не сложно догадаться, основан
на опыте разработчиков. Более того, ценным является
индивидуальный подход, то есть требование не обсуждается совместно, а каждый член коллектива даёт свою
оценку. Далее оценки усредняются здравым смыслом. Как показывает практика, вариант действенен. Теперь о
системе баллов. Оценка производится исключительно с использованием своей системы (численной). Что это будет за система, не имеет особого значения. Основной смыл - выразить
относительную сложность. Временные оценки исключены (никаких человеко-часов). Участие заказчика в этом процессе ни к чему, он не имеет представления о системе координат команды, а вводить его в курс дела затратное по времени и нервам занятие.
продолжение в
части 2.
