Існує 2 основних типи, на які діляться методології розробки програмного забезпечення (software development methodology). Це структурні і гнучкі методології.
Структурні методології припускають високоформалізованний підхід до розробки ПЗ (каскадна модель).
Гнучкі методології (Agile) орієнтовані в основному на ітеративну розробку з мінімально допустимої формалізацією процесу.
Про основні засади гнучких методологій я розповім в іншій статті. А звернути вашу увагу хочу ось на що. Agile методології дуже добре себе зарекомендували і зараз навіть самий високоформалізованний процес важко собі уявити без "гнучких" елементів, зокрема мітингів.
Важливою частиною цієї методології є SCRUM-мітинги, які повинен займатися компетентна людина - SCRUM-Master (найчастіше project manager або team lead). Такі мітинги для більшого ефекту потрібно проводити щодня в один і той же час. Тривалість мітингу краще обмежувати 15-30 хвилинами. Кожен учасник проектної команди повинен відповісти на 3 прості запитання:
- 1. Що було зроблено з моменту попереднього SCRUM-мітингу?
- 2. Які виникли проблеми під час роботи?
- 3. Якими завданнями буду займатися після мітингу?
Якщо ви ще не проводите SCRUM-мітинги всередині своєї команди, ось очевидний список переваг цього підходу:
1. За дуже короткий проміжок часу project manager і всі члени команди можуть оцінити статус проекту.
2. Усі виниклі проблеми вирішуються дуже швидко так як доносяться до всіх учасників проекту (серед яких потенційно є компетентні в даному питанні люди).
3. Співробітники вчаться слухати інших, розуміти їх, а також чітко висловлювати свої власні думки.
4. Учасники проекту вчаться ставити перед собою реальні завдання і відповідати за статус їх виконання.
Мені, звичайно, ще далеко до SCRUM-майстра і тим більше до Project-менеджера, тим не менш, хочу поділитися деякими своїми спостереженнями:
- Існують проблеми, які потребують негайного вирішення. Такі проблеми потрібно вирішувати відразу, навіть якщо мітинг через це може трохи затягнутися.
- Не дивлячись на це, SCRUM-майстер повинен розуміти, що тривалі конфліктні обговорення найчастіше закінчуються компромісом (а не консенсусом, як повинно бути в ідеалі).
- Команди більше 7-9 чоловік бажано розбивати на групи, кожна з яких є свій SCRUM-Master. Приклад: провівши паралельно наради для тестувальників і розробників можна заощадити час і сили членів команди. Після цього SCRUM-майстри можуть обговорити між собою виникли проблеми і вирішити їх за участю зацікавлених осіб.
- Бувають ситуації, коли людину краще звільнити від участі в мітингу: якщо він дуже сконцентрований на вирішенні деякої задачі, на мітингу він буде менш уважний, та й після мітингу йому буде важче заново вникнути в суть проблеми.