Методологія визначає багато: склад команди, спосіб взаємодії з клієнтом, порядок роботи і багато іншого.
При виборі методології треба розуміти самим і роз'яснити клієнту, що вимоги до проекту у клієнта будуть змінюватися. І чим жорсткіше використовувана методика, тим складніше вносити зміни до вимог. Клієнт спочатку може не усвідомлювати частини своїх вимог, частина вимог може помінятися з часом, це об'єктивний процес. Тому, якщо клієнт наполягає на жорсткому процесі, то він повинен бути готовий до ускладнення і подорожчання процесу розробки.
Вибір методології залежить і від складу команди, наявної в розпорядженні студії. Якщо ж клієнт наполягає на якомусь конкретному процесі, то доведеться шукати людей під нього.
Чим сильніше в професійному плані команда, що є у розпорядженні, тим більш гнучкі методології можна використовувати. Для високопрофесійних співробітників можна використовувати XP - екстремальне програмування. Вчорашні студенти в режимі XP завалять найпростіший проект. Для колишніх студентів чим більш формалізований процес, тим робота буде успішніше. З такими співробітниками доведеться застосовувати Водоспад.
Слабка команда і один сильний розробник
Перше. Все максимально формалізувати і спростити. (Що це означає в плані використання, наприклад, Bitrix Framework. Використання стандартних компонентів, використання стандартної адміністративної частини, зробити все, що б люди якомога менше написали коду. Правити компоненти, шаблони, верстку правити, настройки міняти, не більше.)
Друге. Побудувати процес розробки максимально близький до водоспаду. Недосвідчений співробітник не може правильно оцінити складність завдання і підібрати адекватні методи її вирішення. Для нього досвідчений розробник повинен все розписати у вигляді докладного плану проекту з діаграмою Ганта.
Проект краще розбити на ітерації великої тривалості (2-3 місяці) для зниження ризиків. Перший етап - це створення сайту з інтегрованою версткою на основі стандартного функціоналу. Тобто все те, що можна реалізувати без складних робіт, пред'явити клієнтові як результат першого етапу.
Другий і наступні етапи - якась частина складного високонавантаженого функціоналу, наприклад, об'ємний каталог. Створюється, тестується, накочується на зроблене, здається.
Середня по силі команда
В цьому випадку можлива менша формалізація ітераційного процесу. Можна не робити аудит коду, можна робити менше гілок контролю версій, детально не вказувати параметри налаштувань компонентів, модулів, можна зробити більш короткими ітерації (приблизно місяць - півтора). Для таких команд підходить RUP, Agile, Kanban.
Сильна команда постійного складу - рідкісний випадок. Підходять всі види процесів, вибирати які потрібно в залежності від проекту. Складні і великі проекти можуть зажадати Водоспад і для сильної команди, але в більшості випадків сильні команди працюють за технологіями XP, з елементами Agile, Scrum або Continuous Integration. Ітерації можуть ставати коротше, приблизно 2-3 тижні.
Як оцінювати необхідний час і складність завдань
Точність оцінки залежить від якості проектування і від кваліфікації розробників. Як правилноє, для оцінки використовується технологія Planning Pocker.
Технологія дуже проста: оголошується завдання, обговорюється і розробники викидають карти із зазначенням часу необхідного на реалізацію цього завдання. Час на картах зазначено в числах Фібоначі.
Велике розбіжність в оцінках часу виконання говорить про слабкість команди, або неясною завдання. У слабких командах краще не проводити колективну оцінку необхідного часу, а довіритися думку сильного розробника. Менеджер не повинен оцінювати сам складність завдань. В цьому випадку у програмісти можуть видавати неякісний код, аби встигнути в строк. Але якщо розробник недобросовісний або хитрий, то він буде прагнути завищити термін. Менеджер повинен враховувати і цей ризик.
При проведенні оцінки завдань Planning Pocker 'ом менеджер повинен бути впевнений, що завдання зрозуміле команді. Інакше її неможливо правильно оцінити. Будуть названі або завищені терміни, з боязні не встигнути, або занижені, через недооцінку складності. В обох випадках терміни виявляться під ризиком зриву, а якість виконання - невисоким.
Можна застосовувати модифікацію Planning Pocker. коли розробники оцінюють завдання за критерієм: Просто \ Середньо \ Складно. Якщо у менеджера вже є сформована оцінка скільки часу піде на задачу кожного типу.