Я думаю, що це правда, в деяких умовах Agile використовується як привід для жодної дисципліни. Справжня проблема полягає в тому, що ми втратили зір, чому ми маємо будь-яку методологію. Особисто я вважаю, що методологія є архітектурним питанням у тому сенсі, що архітектура системи повинна вирішувати нефункціональні атрибути якості, методологія повинна вирішувати деякі ті самі атрибути (ремонтопридатність, продуктивність розвитку, передача знань, та ін.)
Якщо розглядати методологію як контроль атрибутів процесу, то випливає декілька моментів: 1) без метрик ми не можемо порівняти ефективність однієї методології над іншою; 2) потрібно прийняти активне рішення щодо важливих атрибутів (час доставки проти коду якість проти передачі знань).
Не маючи і метрики, і відчутної мети, ми просто обираємо методологію як наше "чарівне перо", що якщо ми будемо триматися за жорсткі, ми зможемо поставити програмне забезпечення.
Зараз наймовники Agile, XP, Scrum тощо говорять про крихкість саме цієї категорії методологій. Аргумент: чому використовувати методологію, яку може саботувати одна людина, якій не вистачає дисципліни, щоб дотримуватися всіх правил? Питання є правильним; однак, це симптом, а не причина. Якщо точний і змістовний (це найважча частина) набір метрик процесу визначений, перевірений та наданий своєчасний зворотній зв'язок, я думаю, що ми виявимо, що конкретна методологія має мало спільного з успіхом. (Анекдотично кажучи, я бачив успішні проекти з використанням безлічі методологій і вдвічі більше невдач, використовуючи ті самі методики)
То що таке показники? Вони залежать від проекту до проекту, команди до команди та періодично. Корисно, коли графік доставки важливий, тим, що я особисто використовував, є вміння оцінювання та якість. Більшість розробників можуть точно оцінити завдання, що тривають тиждень або менше. Таким чином, один підхід полягає в тому, щоб розділити проект на завдання, який триває тиждень розробника, і відстежити, хто зробив оцінку. У міру продовження проекту вони можуть змінити свої кошториси. Після завершення завдання, якщо його вимкнено більше ніж на 10% (1/2 на день), ми трактуємо це так само, як і помилку - ми визначаємо, чому оцінка була вимкнена (тобто таблиця бази даних не враховувалася), ідентифікуйте коригуючу дію (тобто залучайте DBA до оцінки), а потім рухайтесь далі. Використовуючи цю інформацію, ми можемо створювати такі показники, як кількість помилок оцінювання на тиждень, кількість помилок на розробника,
І що? Ось тоді приходять методики - якщо у вас є модель прогнозування, яка не відповідає стандартам якостей процесу, ви можете додати або вилучити якийсь аспект методології та подивитися, як це впливає на вашу модель. Зрозуміло, ніхто не хоче грати з процесом розвитку, боячись невдачі, але ми вже не вдається зі стабільно високою та передбачуваною швидкістю. Вносячи індивідуальні зміни та вимірюючи результат, ви можете виявити, що Agile - це ідеальна методологія для вашої команди, але ви так само легко зможете знайти RUP, водоспад або просто високий підйом найкращих практик як ідеальний.
Тож моя пропозиція дозволяє перестати хвилюватися про те, що ми називаємо процесом, встановити перевірки, що відповідають нашим цілям процесу розвитку, та експериментувати з різними методами для вдосконалення цього процесу.
