2015-04-12
654
Історія. У 1986 японські фахівці Hirotaka Takeuchi і Ikujiro Nonaka опублікували повідомлення про новий підхід до розробки нових сервісів і продуктів (не обов'язково програмних). Основу підходу складала згуртована робота невеликої універсальної команди, яка розробляє проект на всіх фазах. Приводилася аналогія з регбі, де вся команда рухається до комірів супротивника як єдине ціле, передаючи (пасуючи) м'яч своїм гравцям як вперед, так і назад. На початку 90-х років даний підхід почав застосовуватися в програмній індустрії і знайшов назву Scrum (термін з регбі, що означає, - сутичка), в 1995 році Jeff Sutherland і Ken Schwaber представили опис цього підходу на OOPSLA '95 – одній з найавторитетніших конференцій в області програмування. З тих пір метод активно використовується в індустрії і багато разів описаний в літературі. Scrum активно використовується також в Росії.
Загальний опис. Метод Scrum дозволяє гнучко розробляти проекти невеликими командами (7 чоловік плюс/мінус 2) в ситуації вимог, що змінюються. При цьому процес розробки итеративен і надає велику свободу команді. Крім того, метод дуже простий – легко вивчається і застосовується на практиці. Його схема зображена на рис. 17.1.
Рис. 17.1.
Спочатку створюються вимоги до всього продукту. Потім з них вибираються найактуальніші і створюється план на наступну ітерацію. Протягом ітерації плани не міняються (цим досягається відносна стабільність розробки), а сама ітерація триває 2-4 тижні. Вона закінчується створенням працездатної версії продукту (робочий продукт), яку можна пред'явити замовникові, запустити і подемонстрировать, хай і з мінімальними функціональними можливостями. Після цього результати обговорюються і вимоги до продукту коректуються. Це зручно робити, маючи після кожної ітерації продукт, який вже можна якось використовувати, показувати і обговорювати. Далі відбувається планування нової ітерації і все повторюється.
Усередині ітерації проектом повністю займається команда. Вона є плоскою, ніяких ролей Scrum не визначає. Синхронізація з менеджментом і замовником відбувається після закінчення ітерації. Ітерація може бути перервана лише в особливих випадках.
Ролі. У Scrum є всього три види ролей.
Власник продукту (Product Owner) – це менеджер проекту, який представляє в проекті інтереси замовника. У його обов'язки входить розробка початкових вимог до продукту (Product Backlog), своєчасна їх зміна вимог, призначення пріоритетів, дат постачання і ін. Важливо, що він абсолютно не бере участь у виконанні самої ітерації.
Scrum-мастера (Scrum Master) забезпечує максимальну працездатність і продуктивну роботу команди – як виконання Scrum-процесса, так і вирішення господарських і адміністративних завдань. Зокрема, його завданням є огорожа команди від всіх дій ззовні під час ітерації.
Scrum-команда (Scrum Team) – группа, состоящая из пяти–девяти самостоятельных, инициативных программистов. Первой задачей команды является постановка для итерации реально достижимых и приоритетных для проекта в целом задач (на основе Project Backlog и при активном участии владельца продукта и Scrum-мастера). Второй задачей является выполнение этой задачи во что бы то ни стало, в отведенные сроки и с заявленным качеством. Важно, что команда сама участвует в постановке задачи и сама же ее выполняет. Здесь сочетается свобода и ответственность, подобно тому, как это организовано в MSF. Здесь же "просвечивает" дисциплина обязательств.
Практики. У Scrum визначені наступні практики.
Sprint Planning Meeting. Проводиться на початку кожного Sprint. Спочатку Produсt Owner, Scrum-мастер, команда, а також представники замовника і ін. зацікавлені особи визначають, які вимоги з Project Backlog найбільш пріоритетні і їх слід реалізовувати в рамках даного Sprint. Формується Sprint Backlog. Далі Scrum-мастер і Scrum-команда визначають те, як саме буде досягнута певна вище мета з Sprint Backlog. Для кожного елементу Sprint Backlog визначається список завдань і оцінюється їх трудомісткість.
Daily Scrum Meeting – пятнадцатиминутное каждодневное совещание, целью которого является достичь понимания того, что произошло со времени предыдущего совещания, скорректировать рабочий план сообразно реалиям сегодняшнего дня и обозначить пути решения существующих проблем. Каждый участник Scrum-команды отвечает на три вопроса: что я сделал со времени предыдущей встречи, мои проблемы, что я буду делать до следующей встречи? В этом совещании может принимать участие любое заинтересованное лицо, но только участники Scrum-команды имеют право принимать решения. Правило обосновано тем, что они давали обязательство реализовать цель итерации, и только это дает уверенность в том, что она будет достигнута. На них лежит ответственность за их собственные слова, и, если кто-то со стороны вмешивается и принимает решения за них, тем самым он снимает ответственность за результат с участников команды. Такие встречи поддерживают дисциплину обязательств в Scrum-команде, способствуют удержанию фокуса на целях итерации, помогают решать проблемы "в зародыше". Обычно такие совещания проводятся стоя, в течение 15-20 минут.
Sprint Review Meeting. Проводиться в кінці кожного Sprint. Спочатку Scrum-команда демонструє Product Owner зроблену протягом Sprint роботу, а той у свою чергу веде цю частину мітингу і може запросити до участі всіх зацікавлених представників замовника. Product Owner визначає, які вимоги з Sprint Backlog були виконані, і обговорює з командою і замовниками, як краще розставити пріоритети в Sprint Backlog для наступної ітерації. У другій частині мітингу проводиться аналіз минулого спринту, який веде Scrum-мастер. Scrum-команда аналізує в останньому Sprint позитивні і негативні моменти спільної роботи, робить виводи і ухвалює важливі для подальшої роботи рішення. Scrum-команда також шукає шляхи для збільшення ефективності подальшої роботи. Потім цикл повторюється.
Рис. 17.2.
