Scrum і XP: нотатки з передової. Як ми робимо Scrum 39164

Передмова — Ей! А Scrum-працює!

Scrum працює! Принаймні, нам він підійшов (я маю на увазі проект мого клієнта зі Стокгольма, чиє ім'я я не хотів би називати). Сподіваюсь, вам він теж підійде! І, можливо, саме ця книга допоможе вам на шляху освоєння Scrum'а.

Це був перший випадок у моєму житті, коли я побачив як методологія (ну так, Кен [1], - фреймворк) працює «з коробки». Просто підключи і працюй. І при цьому всі щасливі: і розробники, і тестери, і менеджери. Всупереч всім колотнеч на ринку і скорочення штату співробітників, Scrum допоміг нам вибратися зі складної ситуації, дозволив сконцентруватися на наших цілях і не втратити свій темп.
Не хочеться говорити, що я здивований, але... так і є. Після побіжного знайомства з парою книг по темі, Scrum справив на мене гарне враження, навіть занадто добре, щоб бути схожим на правду. Так що не дивно, що я був налаштований дещо скептично. Однак після року використання Scrum'а, я настільки вражений (і більшість людей у моїх командах теж), що, швидше за все, буду використовувати Scrum у всіх нових проектах, ну, хіба що крім випадків, коли є вагома причина не робити цього.

Передмова Джефа Сазерленда

Командам необхідно знати основи Scrum'а. Як створити й оцінити product backlog? Як отримати з нього sprint backlog? Як працювати з burndown-діаграмою і обчислювати продуктивність(velocity) своєї команди? Книга Хенріка — це базове керівництво для початківців, яке допоможе командам перейти зі стану «ми пробуємо Scrum» в стан «ми успішно працюємо по Scrum'у».

Хороша реалізація Scrum'а стає все важливішим і важливіше для команд, які хочуть отримати інвестиції. Я виступаю в якості тренера по гнучких методологій для групи компаній з венчурними інвестиціями, допомагаючи їм у прагненні вкладати гроші тільки в справжні Agile-компанії. Голова групи інвесторів вимагає від компаній, що складають інвестиційний портфель, відповіді на запитання, чи знають вони продуктивність своїх команд. Багатьох це питання ставить у глухий кут. Майбутні інвестиції вимагають від команд знання власної продуктивності розробки програмного забезпечення.

Чому це так важливо? Якщо команда не знає власної продуктивності, отже product owner не може розробити стратегічний план розвитку продукту з достовірними датами релізів. Без такого плану компанію може спіткати невдача, в результаті чого інвестори втратять свої гроші.
З цією проблемою стикаються різноманітні компанії: великі і маленькі, старі і нові, з фінансуванням і без. Під час нещодавнього обговорення реалізації Scrum'а компанією Google на лондонській конференції я вирішив дізнатися у аудиторії, що складається з 135 людей, хто з них використовує Scrum? Я отримав ствердну відповідь лише від тридцяти осіб. Потім я поцікавився, чи відповідає їхнім процес Nokia-стандарту ітеративної розробки. Итеративная розробка — це ключове положення Agile Manifest'а: «Постарайтеся надавати версії працюючого програмного забезпечення як можна частіше і раніше». В результаті проведення ретроспектив з сотнями Scrum-команд протягом декількох років, Nokia виробила деякі базові вимоги до ітеративної розробки:
• Ітерації повинні мати фіксовану довжину і не перевищувати шести тижнів.
• ДО кінця кожної ітерації код повинен бути протестований відділом якості (QA) і працювати як слід.
З тридцяти людей, які сказали, що працюють за Scrum'y лише половина підтвердила, що їх команди дотримуються першого принципу Agile Manifest'а й відповідаю Nokia-стандарту.
Потім я запитав їх, чи дотримуються вони Scrum-стандарту, розробленого Nokia:
• У Scrum-команди повинен бути один product owner і команда повинна знати, хто це.
• У Product owner'а повинен бути один product backlog з історіями і їх оцінками, виконаними командою.
• У команди повинна бути burndown-діаграма, а сама команда повинна знати свою продуктивність.
• протягом спринту ніхто не повинен втручатися в роботу команди.

З тридцяти команд, які впроваджують Scrum, тільки у трьох процес розробки відповідав стандартам Nokia. Я думаю, що тільки ці три команди отримають подальші інвестиції від венчурних капіталістів.
Основна цінність книги Хенріка полягає в тому, що якщо ви будете слідувати його порадам, то у вас буде і product backlog, і для оцінки product backlog'а, і burndown-діаграма. Ви також будете знати продуктивність вашої команди і зможете використовувати всі найбільш важливі практики високоефективних Scrum-команд. Ви пройдете Nokia Scrum-тест, за що інвестори вас оцінять по достоїнству.

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

Джефф Сазерленд, доктор наук, співавтор Scrum

Передмова Майка Кона

І Scrum, і ХР (екстремальне програмування) вимагають від команд завершення цілком відчутного шматка роботи, який можна надати користувачеві в кінці кожної ітерації. Ці ітерації плануються таким чином, щоб бути короткими і фіксованими по часу. Така цілеспрямованість на випуск робочого коду за короткий проміжок часу означає тільки одне: в Scrum і ХР немає місця теорії. Agile-методології не женуться за красивими UML моделями, виготовленими за допомогою спеціальних case-засобів, за створенням деталізованих специфікацій або написанням коду, який зійде на всі випадки життя. Замість цього Scrum і ХР команди концентруються на тому, щоб завершити необхідні завдання. Ці команди можуть миритися з помилками в ході роботи, але вони розуміють, що найкращий засіб виявити ці помилки — це перестати думати про софт на теоретичному рівні аналізу і дизайну, і, засукавши рукава, повністю присвятити себе створенню продукту.
Саме акцент на дії, а не на теорії яскраво виділяє цю книгу серед інших. Те, що Хенрік поділяє ці погляди, видно з самих перших сторінок книги. Він не пропонує нам довгий опис того, що таке Scrum; замість цього він просто посилається на необхідні веб-ресурси. Першим ділом Хенрік починає з опису того, як його команда працює зі своїм product backlog'ом. Потім він проходить по всім елементам і практикам правильно поставленого agile-проекту. Без теоретизування. Без довідкових даних. Нічого цього не потрібно: книга Хенріка — не філософське пояснення, чому Scrum працює або чому ми повинні робити так, а не інакше. Це опис того, як працює одна успішна agile-команда.

Хенрік пропонує набір обраних практик і описує живі приклади, щоб допомогти нам зрозуміти, як використовувати Scrum і ХР на передовій.

Майк Кон
Автор книг Agile Estimating and Planning і User Stories Applied for Agile Software Development.