Каждая из сложнейших программных систем прошлого (в первую очередь, с точки зрения внутренних спецификаций), на «плечах» которых и держится современная компьютерная индустрия - DR DOS, MS DOS, Windows 3.1/95, Photoshop 5.0, CorelDraw 5.0, инструментальные системы Delphi 5.0 и Builder 5.0, системы проектирования Web-страниц GoLive, Dreamweaver - создавались талантливыми мастерами при строгой и очень продуманной организации работ.

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

Отсюда и гораздо большая ответственность за принимаемые решения и их последствия.

Поэтому не стоит удивляться, что более чем 30-летние наработки в области организации разработки программного обеспечения сегодня вылились во вполне конкретную методологию под название Scrum, что с английского - «схватка».

Как уверяют авторы методологии, а вернее те, кто смог обобщить опыт предшественников, а главное, поставить его на «коммерческие» рельсы, её главная задача – сделать акцент на качественном контроле процесса разработки. Ну, так это не новость, это было всегда в таких фирмах как Digital Research, Microsoft, IBM, Apple. Просто встала задача привнести строгий и качественный контроль за разработками в каждую компанию (а часто её размер в пределах 5-10 человек).

Идея простая – чем меньше компания, тем лучше её управляемость, тем меньше затраты на её содержание, тем больше отдача от выполненной разработки для руководителя-инвестора проекта. В конце концов, теперь таких компаний-проектов может быть не одна – их под одним управлением может быть с десяток. Массовость в свою очередь и порождает значительно больший доход.



Другими словами, методология Scrum – давняя и проверенная жизнью идея, хорошо «упакованная» новым опытом в области разработки программного обеспечения. Причём, что интересно, применение этой идеи, по заверениям самих авторов Scrum, с успехом возможно и в процессе сопровождения разработанного ПО, и в процессе продвижения его на рынке.

Первыми идею методологии предложили японцы Хиротака Такэути и Икудзиро Нонака в статье одного из журналов Гарварда в начале 1986 года. Они первыми дали всем понять, что IT-индустрия таит в себе большой бизнес-потенциал, а значит, придётся считать деньги и заниматься оптимизацией как численного состава разработчиков, так и способами их управления. Другими словами, грядёт эра, когда за меньше деньги придётся разрабатывать гораздо более дорогостоящие проекты.

Японцы проанализировали целый ряд уже осуществлённых проектов и пришли к выводу, что гораздо лучшие результаты дают небольшие, но тесно «спаянные» коллективы разноплановых, порой узкоспециализированных, разработчиков. Тот левый крайний, тот получетвертной, тот защитник – почти как в регбийной схватке, отсюда и название – Scrum – очень тесно, дружно, но по строгой специализации.

Только спустя 10 лет после статьи в Гарварде, в 1996-ом, на ежегодной Конференции по объектно-ориентированным языкам программирования и приложениям (OOPSLA) Швабер и Сазерленд обнародовали Scrum-методологию, как строго описанную систему управления.

Парадигмы Scrum-методологии

Методология держится на следующих основных парадигмах:

• Скрам-процесс – набор чётко определённых коротких периодов разработки – спринтов,результатом которых является получение очередной версии программы с определёнными, самыми приоритетными на данный момент, функциями для конечного пользователя.
• Спринт – короткий период текущей разработки от заранее определённой начальной точки до точки очередного роста программы. Длительность спринта строго определена и обычно не превышает 4 недель. Активно внедряющая Scrum фирма Nokia определила для своей компании длительность спринта в пределах 6 недель. В общем случае необходимо стремиться к сокращению длительности спринта – чем он короче, тем легче управляемость разработкой, тем проще выявлять возможные ошибки и оперативнее на них реагировать. Чаще всего, при становлении компании, длительность спринта устанавливается опытным путём, а потом постепенно корректируется.
• Журнал пожеланий проекта – весь ход разработки строго документируется в журнале пожеланий. Именно этот журнал содержит постепенно редактируемый список требований к проекту, отсортированных по степени важности. Каждую строку журнала пожеланий принято называть пользовательскими историями или элементами беклога (back log).
• Журнал пожеланий спринта – список задач проекта, которые необходимо решить в текущем спринте. Все задачи носят оперативный характер и подлежат постоянному обсуждению командой разработчиков.
• Диаграмма сгорания задач – диаграмма графически отображает ход разработки и носит, при должном развитии каждого спринта, нисходящий характер. Таким образом отражается постепенное уменьшение количества стоящих перед проектом задач.
• Диаграмма сгорания задач спринта – отражаем количество выполненных и оставшихся задач в спринте.

Вторичные определения

Парадигмы Scrum-методологии поддерживаются следующими вспомогательными определениями:

• История спринта – всё содержимое спринта в процессе работы над ним;
• Остановка спринта – обычно связана с аварийной ситуацией, переоценкой проекта, когда руководство приходить к выводу невозможности достичь поставленных целей;
• Покер планирования или Очки за пользовательскую историю – шкала оценки сложности спринта без учёта реальных трудозатрат, измеряемых в человекочасах. Известны следующие, реально применяемые, системы очков:
  1. по числам Фибоначчи - 1, 2, 3, 5 и так далее – каждое последующее число является суммой двух предыдущих;
  2. обычная арифметическая прогрессия с шагом 1 и первым членом также равным 1;
  3. обычная геометрическая прогрессия степени двойки;
  4. абстрактная система, взятая из системы определения размера одежды - XS, S, M, L, XL.
• Задачи истории спринта – оперативно добавляемые в спринт задачи, подлежащие немедленному выполнению в пределах короткого промежутка времени (на практике – не больше суток);
• Критерии готовности – критерии определения готовности каждой строки из журнала пожеланий пользователя;
• Скорость команды – позволяет оценить скорость команды в спринте, обычно оценивается в суммарных очках.