Знижуйте кількість WIP і робіть часті релізи

У 2004 році я працював із двома командами в компанії Motorola. Обидві розробляли мережевий код для серверної частини мобільних застосунків. Одна команда працювала над сервером для бездротового скачування (over-the-air, OTA) рингтонів, ігор та інших програм і даних. Друга розробляла сервер для бездротового управління пристроя­ми (OTA DM). Обидві команди дотримувалися методології Feature Driven Development (FDD). Обидві мали приблизно однакову чисельність — вісім розробників, один архітектор, до п’яти тестувальників плюс менеджер проєкту. Працюючи спільно з маркетологами, команди самостійно здійснювали аналіз і проєктування. Обом командам допомагали окремі команди проєктування взаємодії з користувачами (UX) і розробки документації для користувачів (технічні письменники).

WIP, час виконання і помилки

На рис. 3.1 показано накопичувальну діаграму потоку для команди, що займалася створенням ОТА. Накопичувальна діаграма потоку — це зонований графік, що відтворює обсяг роботи, яка перебуває в певному стані. Стани, наведені на діаграмі: «запаси» — тобто обсяг роботи, що перебуває в черзі на виконання; «розпочато» — означає, що вимоги до функціоналу вже пояснені розробникам; «спроєктовано» — тобто для функції вже розроблено UML-діаграму послідовності; «закодовано» — тобто функціонал розроблений відповідно до діаграми послідовності; «завершено» — усі unit-тести пройшли успішно, був здійснений перегляд коду, і керівники групи розробки (тім ліди) прийняли код і переда­ли його на тестування.

Перша лінія на діаграмі на рис. 3.1 показує кількість функцій, які треба зробити в проєкті. Ці функції власники бізнесу надсилали двома великими партіями. Друга лінія показує кількість розпочатих функцій. Третя лінія — кількість спроєктованих, четверта — закодованих, а п’ята — кількість завершених і готових до тестування функцій.

Рис. 3.1. Накопичувальна діаграма потоку (cumulative flow diagram, CFD) ­команди завантажень OTA за період осінь 2003 — зима 2004 рр.

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

Команді сервера завантажень ОТА не вистачало чи то дисципліни, чи то мотивації для використання методу FDD. Вони не працювали спільно, як вимагає FDD, а видавали великі порції функцій окремим розробникам. Зазвичай на одного розробника в них у будь-який час ­припадало до десяти функцій в розробці. А команда з розробки OTA DM дотримувалась методу FDD у точній відповідності до підручника. Вони добре співпрацювали і розробляли unit-тести для 100 % своїх функцій. І найважливіше — вони працювали над невеликою кількістю функцій одночасно, зазвичай це було 5–10 функцій на всю команду будь-якої конкретної миті. Орієнтиром для характеристики в FDD, схоже, були 1,6–2,0 функціональні точки коду.

У команди з розробки сервера завантажень OTA, що перебувала в Сіетлі, середній час виконання становив близько трьох місяців на функцію від початку роботи до її завершення і передачі для інтеграційного тестування у місто Шампейн в Ілінойсі (як показано на рис. 3.1). У команди з розробки OTA DM середній час виконання коливався від 5 до 10 днів, що можна побачити на рис. 3.2. Різниця у початковій яко­сті між командами, що вимірювалася в кількості помилок, виявлених при інтеграційному тесті або вже у працюючій системі, перевищувала 30 разів. Команда з розробки OTA DM продемонструвала початкову якість на рівні лідерів індустрії — дві або три помилки на 100 функцій, а ­команда з розробки сервера завантажень OTA продемонструвала середній по індустрії результат — близько двох помилок на функцію.

Рис. 3.2. Накопичувальна діаграма потоку (CFD) команди OTA DM (зима 2004 р.)

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

Існує причинно-наслідковий зв’язок між кількістю WIP і середнім часом виконання, і ця залежність лінійна. У виробництві ці залежно­сті відомі як закон Літтла. Приклад двох команд із Motorola свідчить про наявність кореляції між збільшенням часу виконання і зниженням якості. Схоже, що збільшення часу виконання призводить до істотного погіршення якості. У нашому випадку збільшення середнього часу виконання у 6,5 разів спричинило понад тридцятикратне збільшення початкових помилок. Більший час виконання пов’язаний також зі збільшенням кількості WIP. Отже, точкою прикладання управлінських зусиль для поліпшення якості є зменшення кількості WIP. Після виявлення цього факту я розпочав використовувати WIP як засіб контролю за якістю та переконався в наявності взаємозв’язку між кількістю WIP і початковою якістю коду. Однак на момент написання цієї книжки не існує наукових підтверджень цього емпірично отриманого результату.

Зниження кількості WIP або скорочення тривалості ітерації серйозно впливає на початкову якість. Судячи з усього, співвідношення між кількістю WIP і початковою якістю нелінійне, тобто кількість помилок зростає непропорційно збільшенню кількості WIP. Отже, очевидно, що двотижневі ітерації краще за чотиритижневі, а тижневі ще краще. Коротші ітерації підвищують якість.