Подготовка к первой итерации, называемой спринт (Sprint), начинается после того, как владелец продукта разработал план проекта, определил требования и отсортировал их в количестве, достаточном для наполнения одной итерации. Такой список требований называется журналом продукта (Product Backlog). При планировании итерации происходит детальная разработка сессий планирования спринта (Sprint Planning Meeting), который начинается с того, что владелец продукта, Scrum-команда и Scrum-мастер проверяют план развития продукта, план релизов и список требований. Scrum-команда проверяет оценки требований, убеждается, что они достаточно точны, чтобы начать работать, решает, какой объем работы она может успешно выполнить за спринт, основываясь на размере команды, доступном времени и производительности. Важно, чтобы Scrum-команда выбирала первые по приоритету требования из журнала продукта. После того как Scrum-команда обязуется реализовать выбранные требования, Scrum-мастер начинает планирование спринта. Scrum-команда разбивает выбранные требования на задачи, необходимые для его реализации. Эта активность в идеале не должна занимать больше четырех часов, и ее результатом служит список требований, разбитый на задачи, — журнал спринта (Sprint Backlog). Необходимо, чтобы все участники команды приняли на себя обязательство по реализации выбранной цели.
После окончания планирования начинается итерация. Каждый день Scrum-мастер проводит «скрам» (Daily Scrum Meeting) — пятнадцатиминутное совещание, цель которого — достичь понимания того, что произошло со времени предыдущего совещания, скорректировать рабочий план к реалиям сегодняшнего дня и обозначить пути решения существующих проблем. Каждый участник Scrum-команды отвечает на три вопроса: что я сделал со времени предыдущего скрама, что меня тормозит или останавливает в работе, что я буду делать до следующего скрама? В этом митинге может принимать участие любое заинтересованное лицо, но только участники Scrum-команды имеют право принимать решения. Правило обосновано тем, что они давали обязательство реализовать цель итерации, и только это дает уверенность в том, что она будет достигнута. На них лежит ответственность за их собственные слова, и, если кто-то со стороны вмешивается и принимает решения за них, тем самым он снимает ответственность за результат с участников команды.
В конце каждого спринта проводится демонстрационный митинг (Sprint Review Meeting) продолжительностью не более четырех часов. Сначала Scrum-команда демонстрирует владельцу продукта сделанную в течение спринта работу, а тот в свою очередь ведет эту часть митинга и может пригласить к участию всех заинтересованных заказчиков. Владелец продукта определяет, какие требования из журнала спринта были выполнены, и обсуждает с командой и заказчиками, как лучше расставить приоритеты в журнале продукта для следующей итерации. Во второй части митинга производится анализ прошедшего спринта, который ведет Scrum-мастер. Scrum-команда ищет использованные в последнем спринте положительные и отрицательные способы совместной работы, анализирует их, делает выводы и принимает важные для дальнейшей работы решения. Scrum-команда также определяет программы, которые могут работать лучше, и ищет пути для увеличения эффективности дальнейшей работы. Затем цикл замыкается, и начинается планирование следующего спринта.
В начале проекта владелец продукта готовит журнал продукта — список требований, отсортированный по значимости, а Scrum-команда дополняет этот журнал оценками стоимости реализации требований. Список должен включать функциональные и технические требования, необходимые для реализации продукта. Самые приоритетные из них должны быть достаточно детально прописаны, чтобы их можно было оценить и протестировать. О своевременной детализации требований должен заботиться владелец продукта и предоставлять необходимый объем в нужное время. В этом смысле программисты являются заказчиками требований для владельца продукта. И отношение владельца продукта должно быть соответствующее — каковы требования, такова и их реализация. В дальнейшем остальные требования должны постепенно уточняться и детализироваться до такого же уровня. Главное, чтобы у команды всегда был достаточный объем подготовленных к реализации требований.
После того как команда во время сессии планирования выбрала и обязалась реализовать набор требований из журнала продукта, эти требования разбиваются на более мелкие задачи, составляющие детализированный список требований — журнал спринта. Разбивка на задачи должна быть сделана таким образом, чтобы выполнение одной задачи занимало не больше двух дней (считается, что менее детальная, например, полдня, разбивка приводит к более грубой оценке, чем приемлема в большинстве проектов, использующих методологию Scrum). Разбивка на задачи поможет так спланировать итерацию, чтобы в конце не осталось ни одной невыполненной задачи и, соответственно, достичь ее цели. После завершения детализации оценка журнала спринта сравнивается с первичной оценкой в журнале продукта. Если существует значительное расхождение, команда договаривается с владельцем продукта об объеме работ, который должен быть выполнен в течение итерации, и о том, какой объем будет перенесен на следующую. Менее важные и мало влияющие на цель итерации задачи выносятся из журнала спринта.
График спринта (Burndown Chart) показывает ежедневное изменение общего объема работ, оставшегося до окончания итерации. Это график позволяет команде разработчиков делать анализ текущей ситуации и своевременно реагировать на отклонения. График спринта позволяет также владельцу продукта наблюдать за ходом итерации — если общий объем работ не уменьшается каждый день, значит, что-то идет не так. Во время сессии планирования команда находит и оценивает задачи, которые надо выполнить для успешного завершения итерации. Сумма оценок всех задач в журнале спринта является общим объемом работы, который надо выполнить за итерацию. После завершения каждой задачи Scrum-мастер пересчитывает объем оставшейся работы и отмечает это на графике спринта. Только в том случае, если объем работ по окончании итерации закончился (в журнале спринта не осталось незавершенных задач), итерация считается успешной. График спринта используется как вспомогательный инструмент, позволяющий корректировать работу для завершения итерации вовремя, с работающим кодом и требуемым качеством.
Время между итерациями — это время принятия основополагающих решений, влияющих на ход всего проекта. Во время итерации никакие изменения извне не могут быть сделаны. После того как команда дала обязательство реализовать журнал спринта, он фиксируется, и изменения в нем могут быть сделаны только по следующим причинам:
Scrum-команда в течение итерации получила лучшее представление о требованиях и нуждается в дополнительных задачах для успешного завершения итерации;
найдены дефекты, которые нужно обязательно исправить для успешного завершения итерации;
Scrum-мастер и Scrum-команда могут решить, что небольшие изменения, не влияющие на общий объем работ, могут быть реализованы в связи с возникшей у владельца продукта необходимостью.
Исходя из того что журнал спринта не может быть изменен извне во время итерации, нужно выбирать ее длину, основываясь на стабильности требований. Если требования стабильны, меняются или дополняются редко, то можно выбрать шестинедельный цикл. В этом случае экономится время на переключение команды с активной разработки на планирование и демонстрационные митинги. Если требования часто меняются и дополняются, нужно отталкиваться от двухнедельного цикла, в любом случае длина итерации — это величина экспериментальная.
Основной упор методология Scrum делает на управление проектами и не задает никаких технических практик, что дает возможность использовать весь технический багаж, накопленный компанией. При внедрении Scrum чаще всего возникает две трудности. Первая — добиться активного участия от каждого разработчика и слаженной коллективной работы в команде. Похожую задачу решает тренер спортивной команды. Вторая — вовлечь поставщика требований в активное участие в проекте, заинтересовать его динамикой развития продукта, дать возможность быть активным болельщиком и спонсором команды. [4]
1.4 Альтернативные продукты, основанные на Scrum
Для разработки программных продуктов, основанной на Scrum, уже существует по крайней мере одна система, которая называется Agilo for Scrum. Она также разработана на языке Python. Является расширением известной системы Trac, и соответственно имеет аналогичный интерфейс по работе с задачами и ошибками. Для тех, кто является поклонником Trac или привык им пользоваться, переход на Agilo не вызовет особых проблем. Однако многим эта система кажется неудобной, по крайней мере, в качестве полноценного ведения процесса разработки, потому что создана в большей степени для отслеживания ошибок программистов.
Она практически не обладает способностью настраивать наборы типов, статусов, приоритетов задач, статистику по проектам отражает только burndown chart, однако нигде нельзя увидеть общий ход разработки в целом по программистам, сколько задач у кого открытых, сколько закрытых, сколько обнаружено ошибок; просмотривать данные о проекте и сводную информацию о спринтах также достаточно неудобно.
В качестве языка программирования для написания системы управления проектами был выбран Python. Он является одним из модных объектно-ориентированных динамических языков, который отличается от классических (Pascal, C, C++) в первую очередь тем, что он современный. А это значит, что в нем исправлены многие вещи, которые были сделаны в тех языках не очень хорошо. Кроме того, многие приемы программирования (паттерны проектирования), которые сложились за долгое время, добавлены прямо в синтаксис языка. Python является стандартным языком для Web-разработки, он широко используется в организации динамических Web-сайтов. Кроме того, он позволяет организовывать удобную совместную работу над продуктами. Одной из причин выбора именно этого языка программирования стало преимущественное его использование для разработки проектов в компании-заказчике. Благодаря модулям для подключения к базам данных он позволяет работать с Oracle, Interbase, PostgreSQL, MySQL и др. В Python предусмотрена возможность перезагрузки модулей в работающую программу, поэтому разрабатываемую систему можно обновлять без остановки. Это возможно благодаря отсутствию в интерпретаторе утечек памяти.