Джефф Сазерленд - Scrum. Навчись робити вдвічі більше за менший час

Спринти ще часто називають «часовими проміжками». Вони мають визначену тривалість. Не можна робити однотижневий спринт, а потім тритижневий. Слід бути послідовним. Потрібно встановлювати такий ритм роботи, де люди знатимуть, скільки вони зможуть виконати в заданий період часу. Доволі часто цей обсяг стає сюрпризом для них самих.

При цьому одним із надзвичайно важливих елементів спринту є те, що, як тільки команда береться за виконання роботи, завдання блокуються. Ніхто за межами команди не може вже нічого додати до переліку. На причинах цього я детальніше зупинюсь нижче, але зараз вам досить запам’ятати, що втручання та відволікання значно зменшують швидкість роботи команди.

Як я вже згадував, у першому Scrum ми використовували чотиритижневі спринти. Десь під кінець першого спринту ми відчули, що просуваємось недостатньо швидко і можемо робити більше. Тоді ми якраз дивилися відео, як All Blacks виконують хаку , а потім проривають оборону супротивника. «Чому ми не такі? – питали ми себе. – Чому не маємо такого бойового духу?» Ми вирішили поставити собі за мету стати не просто доброю командою, а найкращою. Як це можна було зробити? І знову відповідь полягала в простій речі, яку ми поцупили в когось іншого, – щоденних зустрічах.

На виїзді з одного міста, яке я не можу назвати, в компанії, яку я не повинен згадувати, кожного дня збирається група людей, обговорюючи, як відправити інших людей у космос. Оскільки космічні кораблі, по суті, є міжконтинентальними балістичними ракетами з людським зарядом, інформація про це приватне підприємство космічних подорожей пов’язана з дотриманням певного рівня безпеки й таємності. Крім того, це бізнес , а не просто примха ексцентричного мільярдера. Поки я пишу ці рядки, чергова приватна ракета якраз стикується з Міжнародною космічною станцією, причому вже вдруге. Навіть уряд США не має таких можливостей на даний момент.

Але в цій конкретній будівлі цього конкретного дня ці конкретні люди б’ються над питанням, якого розміру має бути блок бортової радіоелектроніки ракети. Це обладнання повідомляє ракеті, куди вона летить і як туди дістатись. Вважайте його мозком космічного корабля.

Маємо дві команди по сім людей: одна займається апаратним, а друга – програмним забезпеченням. Кожного дня одна і друга команди збираються перед великою лекційною дошкою заввишки від підлоги до стелі та завдовжки в усю стіну. Точно як у «Команди WIKISPEED », цю дошку розкреслено на кілька колонок: «Беклог», «Виконується», «Виконано». У колонках перелічуються лише ті завдання, які команді потрібно виконати в конкретному спринті. Завдання варіюються від роботи з одним із кількох постачальників спеціальних мікросхем до визначення взаємодії акселерометра з рештою корабля. Scrum -майстер – особа, яка відповідає за процес, – ставить кожному членові команди три запитання:

1. Що ви робили вчора, щоб допомогти команді завершити спринт?

2. Що ви робитимете сьогодні, щоб допомогти команді завершити спринт?

3. Які перешкоди стоять на шляху команди?

І все. На цьому зустріч закінчується. Якщо вона займає більш ніж п’ятнадцять хвилин, то ви робите щось не так. І вона допомагає всім членам команди чітко розуміти перебіг спринту та стадії розв’язання його завдань. Чи будуть усі завдання виконані вчасно? Чи є можливості допомогти іншим членам команди в подоланні перешкод? Завдання не розподіляються згори – команда автономна. Її члени роблять усе самі . Немає детального звітування перед керівництвом. Будь-хто з керівництва або іншої команди може зайти подивитись на дошку команди авіоніки й чітко зрозуміти, на якій стадії все перебуває.

Отже, коли перша Scrum -команда прагнула визначити, як їм стати схожими на All Blacks , вони звернулися до літератури, щоб пошукати причини успіху найкращих команд. У розробці програмного забезпечення добре те, що через надзвичайно погану ситуацію на самому початку та марнування мільярдів доларів щороку люди витрачали чимало часу на вивчення причин, а тому дані були про все.

Одним із тих, хто витратив роки на вивчення ситуації з програмним забезпеченням, був Джим Копліен із легендарного дослідницького центру Bell Labs компанії AT&T . Копліен багато років вивчав сотні проектів програмного забезпечення, намагаючись визначити, чому так мало з них виконуються добре, а більшість закінчується катастрофою. На початку 1990-х його запросили для вивчення проекту корпорації Borland Software з розробки нового редактора електронних таблиць під назвою Quattro Pro для Windows . Для проекту вже було прописано мільйон рядків програмного коду. На це пішов тридцять один місяць роботи восьми людей. Це означає, що кожен член команди писав тисячу рядків коду на тиждень. То було швидше за всі інші команди серед його записів, і Джим хотів знати, як їм це вдавалося.