Зосередження на якості

В «Agile-маніфесті» нічого не сказано про якість, хоча в «Принципах маніфесту» йдеться про майстерність, що передбачає концентрацію на якості. Але якщо якість не фігурує в «Agile-маніфесті», чому вона посідає перше місце в моєму рецепті успіху? Сенс у тому, що велика кількість помилок призводить до найістотніших втрат в розробці ПЗ. Ці цифри вражаючі, вони демонструють амплітуду відхилень на кілька порядків.

Кейперс Джонс повідомляє, що у 2000 році під час «економічної бульбашки доткомів» він оцінював якість програм для північноамериканських команд, і вона коливалася від шести помилок на одну функціональну точку до менш ніж трьох помилок на 100 функціональних точок, тобто відхилення складало 200 до 1. Серединою буде приблизно одна помилка на 0,6–1,0 функціональних точок. А це означає, що ­команди часто витрачають понад 90 % своїх зусиль на усунення помилок. Як пряме свідчення цього, наприкінці 2007 року Аарон Сандерс, один із перших послідовників Канбан, писав в Yahoo!-групі «Kanbandev», що команда, з якою він працював, 90 % доступних ресурсів витрачала на виправлення помилок.

Заохочення високої початкової якості неабияк вплине на продуктивність і пропускну здатність команд із високими показниками помилок. Можна очікувати збільшення пропускної здатності у два-чотири рази. А з командами, які пасуть задніх, концентрація на якості дозволяє збільшити цей показник удесятеро.

Поліпшення якості ПЗ є добре зрозумілою проблемою.

І гнучка розробка, і традиційні підходи до якості мають свої переваги. Їх слід поєднувати. Тестуванням повинні займатися професійні тестувальники. Вони знаходять дефекти і запобігають їхньому потраплянню до готового продукту. Але якщо ви попросите розробників писати unit-тести і автоматизувати їх для автоматизованого регресивного тестування, це також матиме вражаючі наслідки. Схоже, якщо просити розробників писати тести перед написанням коду, то це дає передусім психологічну перевагу. Так звана розробка через тестування (TDD) дійсно, судячи з усього, допомагає зробити тестове покриття більш ґрунтовним. Щоправда, дисципліновані команди, які я очолював і які писали тести вже після функціонального кодування, теж демонстрували якість найвищого рівня. Проте очевидно, що якщо у середній ­команді наполягати на написанні тестів перед розробкою функціоналу, її якість підвищиться.

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

Спільний аналіз і проєктування поліпшують якість. Коли команди просять спільно працювати над аналізом проблем і проєктуванням рішень, якість зазвичай вища. Я заохочую команди до проведення сесій спільного командного аналізу та проєктування. Проєктування слід проводити часто і малими порціями. Скотт Амблер називає це Аgile-моделювання.

Використання шаблонів проєктування підвищує якість. Шаблони проєктування містять відомі рішення відомих проблем. Завдяки їм на ранніх етапах життєвого циклу проєкту стає доступно більше інформації, а помилки проєктування усуваються.

Використання сучасних інструментів розробки підвищує якість. Багато сучасних інструментів містять функції здійснення статичного й динамічного аналізу коду. Їх потрібно використовувати і налаштовувати для кожного проєкту. Ці засоби аналізу допомагають програмістам уникнути елементарних помилок на кшталт загальновідомих «дірок» у безпеці.

Більш екзотичні сучасні інструменти розробки — такі як виробничі лінії програмних продуктів (або фабрики програмного забезпечення) і предметно-орієнтовані мови — усувають помилки. Фабрики ПЗ можна використовувати для готових шаблонів проєктування у вигляді готового коду, тим самим зменшуючи вірогідність внесення помилок при написанні коду вручну. Можна використовувати ці інструменти і для автоматичного перевикористання функціоналу в коді, що також зменшує ймовірність внесення помилок при написанні коду вручну. Використання фабрик ПЗ також скорочує необхідність переглядів коду, оскільки «фабричний» код не потребує повторної перевірки — його якість доведено.

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

І ще одна річ…

Скорочення обсягу незавершеного проєктування істотно підвищує якість ПЗ!