Софт за 30 дней. Как Scrum делает невозможное возможным

Прежде чем начать разработку программного обеспечения, следует уяснить его идею, видение, полезные функции. Мы думаем, что мы знаем, как выполнять работу более эффективно, или мы думаем, что знаем, как создать программное обеспечение, которое другие сочтут полезным. Мы можем очень четко описать определенные аспекты того, как программное обеспечение должно работать, и требования, которым оно должно соответствовать. Но есть и менее очевидные аспекты программного обеспечения – их можно на какое-то время оставить неопределенными. Все, что нам известно, мы ранжируем: от критически важного и хорошо понятного до, возможно, имеющего отношение к проекту и смутно понятного. Мы создаем список идей, который называем бэклог, или требования (табл. 2.1).

Таблица 2.1. Бэклог требований для организации бизнес-операций

Бэклог – это постоянно меняющийся список наших идей для этого продукта, мы можем добавлять, изменять и удалять из него пункты, когда захотим. В бэклоге продукта мы определяем порядок работы, поэтому наиболее важные требования должны быть вверху списка.

Во-первых, мы должны удостовериться, что наша идея осуществима. Сможем ли мы в течение 30 или меньше дней создать то, что будет полезным и оправдает дальнейшую работу над программным обеспечением?

Мы встречаемся с командой разработчиков и делимся с ними нашими идеям и начальными требованиями. Несмотря на то что вся система может быть обширной, мы должны сосредоточиться только на самом важном, чтобы понять, что это возможно и хотим ли мы продолжать. Также необходимо получить первую оценку практической части нашей идеи. Мы просим команду разработчиков оценить, какую часть требований, по их мнению, в течение следующих 30 дней они смогут перевести в работающую стадию, в законченный функционал.

Мы начинаем с наиболее важных пунктов, но члены команды могут добавлять идеи, которые, как они считают, должны быть включены в бэклог, – например, стабильность программного обеспечения. Мы обсуждаем эти требования, а затем помогаем команде разработчиков продумать лучший способ их реализовать. Несмотря на то что мы не разработчики программного обеспечения, мы можем выбирать среди альтернатив и уточнять вопросы для них.

Давайте сформулируем определения для того, что мы описали.

Итерация. Это повторение серии шагов или процессов, обычно с целью приближения к желаемой цели или результату. Каждое повторение процесса также называется итерацией, а результаты одной итерации используются как стартовая точка следующей. Для вас первые 30 дней – это первая итерация.

Частота

. Этот термин относится к длине итерации. Частые итерации контролируют риски путем постоянного инспектирования прогресса, чтобы гарантировать, что потери не происходят и контроль сохраняется. Оптимальная частота находится в диапазоне не меньше недели и не более месяца.

Инкремент (приращение). Это частица целого, которая увеличивается со временем. Функциональный результат итерации в процессе разработки называется инкрементом. Приращение создается повторение за повторением, пока мы не получим полезную систему.

Прозрачность. Инкремент должен быть полностью законченным и пригодным к использованию, без необходимости доработки. Незаконченную работу, или прототипы, нельзя считать прозрачной, потому что мы не можем проверить, насколько прототипы закончены и сколько работы осталось, чтобы их закончить.

Итеративно-инкрементальный процесс. Это способ разработки программного обеспечения через последовательность итераций, каждая из которых генерирует полное приращение функционала, основанное на всех предыдущих приращениях. Итерации продолжаются до тех пор, пока цель не будет достигнута.

Мы начинаем первую итерацию. Команда разработки превращает наши требования в прирост функционала. Каждая итерация начинается с планирования, затем команда разрабатывает то, что было запланировано, и потом все проверяют результирующий инкремент программного обеспечения.

На разработку системы, соответствующей нашим требованиям и видению, может потребоваться несколько или огромное количество итераций. Время каждой из них определено, то есть мы всегда можем выделить и использовать полную итерацию без изменения ее длины. Каждая итерация создает инкремент потенциально полезного программного обеспечения (рис. 2.1). Функционал становится законченным, нет необходимости что-то доделывать. Результат предыдущей итерации используется как стартовая точка для следующей.

Рис. 2.1. Одна итерация производит один прозрачный инкремент