Якщо розробник бачить ваду в побажаннях замовника, він повинен якомога ввічливіше вказати йому на це і постаратися обговорити з замовником цю ваду.
Щоб точно оцінити трудовитрати, пов'язані з реалізацією побажань замовника, розробник повинен добре розуміти, що хоче замовник. Якщо розробник не може дати точну оцінку, він повинен оцінити трудовитрати хоча б приблизно і попросити замовника надати йому додатковий час, протягом якого він більш детально досліджує проблему і сформує точну оцінку.
Замовник - одна з найважливіших ролей в команді. Кожен замовник має сильними і слабкими сторонами. Деякі замовники описують побажання з надмірною кількістю подробиць. Інші формулюють побажання дуже приблизно, покладаючи детальне опрацювання на розробника. Іноді розробник знайомий з предметною областю в більшій мірі, ніж замовник. У деяких випадках замовник представляє інтереси конкретних кінцевих користувачів програмного продукту, в інших же випадках кінцевий користувач є чисто гіпотетичним суб'єктом.
Хороший замовник повинен:
• досконально знати предметну область, для якої розробляється програмний продукт;
• розуміти, які переваги дасть розробляється програмний продукт в цій предметній області;
• налаштуватися на постійне створення невеликих проміжних результатів, в яких реалізовано, можливо, мало нових функцій;
• приймати рішення щодо того, які функції повинні бути реалізовані в першу чергу;
• ніколи не скасовувати терміни поставки програмного продукту;
• довіряти оцінкам трудовитрат, які роблять розробники, незважаючи на те, що останні можуть помилятися;
• вміти взяти на себе основну відповідальність за успіх або провал проекту;
У гнучких технологіях процес планування навмисно абстрагується для двох учасників - замовника і розробника (команди розробників). Насправді, абстрактну роль замовника можуть грати кілька людей. До них відносяться кінцеві користувачі розроблюваного програмного продукту, оповідачі (члени команди, які формулюють вимоги за допомогою історій користувача (User Story)), приймальники (оповідачі або особи, що діють від їх імені, які виконують приймальні тести), фінансисти (забезпечують ресурси для проекту) , планувальники (складають розклад випуску версій системи, встановлюють ступінь реалізації функціональних можливостей продукту, визначають необхідність випуску нової версії).
5.2. Планування версій Для кожної версії програмного продукту замовник відбирає список побажань, які повинні бути реалізовані в офіційно публікується версії продукту.
Планування версій складається з трьох етапів:
• дослідження (exploration) - на цьому етапі необхідно визначити, що повинен робити програмний продукт;
• підтвердження (exploration) - на цьому етапі необхідно вирішити, яке підмножина вимог замовника необхідно задовольнити в наступній версії програмного продукту;
• управління (exploration) - на цьому етапі необхідно управляти процесом розробки в міру того, як реальність вносить свої корективи в план.
Зміна етапів здійснюється циклічно.
Випуск версій зазвичай здійснюється один раз протягом декількох місяців. Якщо випускати версії частіше, вони будуть мало відрізнятися один від одного. Якщо ж випускати версії рідше, можна відстати від конкурентів.
Етап дослідження Етап дослідження включає в себе наступні дії:
• написання побажань (User Story) замовником;
• оцінювання побажань розробником;
• поділ побажань замовником.
Оцінювання побажань розробником Після того, як побажання складені, розробники повинні оцінити трудовитрати на реалізацію кожного побажання і записати їх, використовуючи спеціальні одиниці вимірювання в правому верхньому куті картки. Приклад картки з побажанням і проставленою оцінкою трудовитрат наведено на рис. 14.
Зауваження розробника Рис. 14. Приклад картки з побажанням і оцінкою трудовитрат В якості одиниць виміру праці в гнучких технологіях [3] прийнято використовувати ідеальний час - період часу, протягом якого розробник працює тільки над одним завданням, не відволікаючись на будь-яку іншу діяльність з продуктивністю, близькою до максимальної . На практиці часто в якості одиниці часу використовується ідеальна людино-тиждень або ідеальна половина людини-тижні. Друга оцінка більш реальна, так як є безліч перешкод, в тому числі листування по електронній пошті, наради, допомога членам команди, вихідні дні, хвороба, відпустки, які не дозволяють використовувати ідеальний час в якості одиниці для оцінки трудомісткості.
Кожна оцінка повинна бути обдумана, перевірена і підкріплена досвідом та додатковими міркуваннями. Найпростіший і ефективний спосіб визначення обсягу трудовитрат - порівняти подібне побажання з побажаннями, які розробник реалізовував раніше. Якщо раніше розробник не стикався зі схожою завданням, він повинен провести додаткове обстеження (провести додаткове обговорення побажання з замовником, виконати попереднє програмування і т.п.).
Процес формування побажань і їх оцінка є ітеративним і вимагає багаторазових зустрічей замовника з розробниками. Формування побажань і оцінка трудовитрат на їх реалізацію - це спільна праця замовника і розробників. У деяких випадках розробник може записати в спеціальному полі картки зауваження до побажання замовника.
Слід особливо відзначити, що оцінка трудовитрат - це не обіцянка виконати реалізацію побажання абсолютно точно в зазначений на картці термін. Тому при оцінці трудовитрат потрібно приділяти увагу таким ключовим моментам:
• на картці потрібно записувати приблизну оцінку часу;
• при оцінці трудовитрат не слід заглиблюватися в деталі проектування або кодування, однак не слід їх повністю ігнорувати;
• слід обмежувати час, необхідний для оцінки одного побажання.
Оцінка трудовитрат в гнучких технологіях є, можливо, самим важким процесом для тих команд, у кого недостатньо досвіду. Разом з тим це конструктивний процес, в ході якого оцінки стають все точніше.
Чим більше він виконується, тим більше виходить реальних оцінок, тим точніше команда може оцінити трудовитрати. Тому не потрібно чекати хороших результатів від початкових оцінок, оскільки з часом вони будуть ставати все точніше і точніше. Щоб механізм оцінок трудовитрат заробив в повній мірі, необхідно обов'язково фіксувати реальні трудовитрати на реалізацію конкретних побажань з тим же ступенем подробиць, що і при плануванні.
Побажання користувача повинні реалізовуватися за принципом «все або нічого». Якщо обсяг побажання занадто великий (трудомісткість реалізації більше 5 одиниць), замовника просять розбити його на частини. В цьому випадку в правому верхньому кутку картки записується слово «розділити».
Розподіл побажань користувача є завданням замовника. Розробник лише може давати рекомендації, як найкраще виконати поділ, але в кінцевому підсумку вирішальне слово залишається за замовником.
Кращий спосіб розділити побажання замовника - постаратися створити два або більше незалежних побажання. Це досить просто зробити, якщо замовник в побажанні записав більше одного дії, які можуть виконуватися незалежно один від одного. Таке рішення не тільки зменшує трудовитрати на реалізацію одного побажання, але і зводить до мінімуму залежності між побажаннями.
Якщо ж на картці записано одне побажання, але воно занадто велике, слід прибрати декорації, тобто ті додавання в побажання, які надають йому додаткову цінність, але без яких можна обійтися. Прибрати декорації можна шляхом їх виключення з реалізації або шляхом створення нового побажання з найменшим пріоритетом. Наприклад, побажання з прикладу, наведеного на рис. 14, спочатку могло б містити вимогу виведення списку готелів з їх логотипами.
Етап підтвердження На цьому етапі замовник повинен визначити обсяг робіт і дату виходу наступної версії, а розробники повинні з усією впевненістю підтвердити, що вони в змозі виконати намічений обсяг робіт до заданого терміну. Етап підтвердження включає в себе чотири кроки.
обов'язкові - без реалізації цих побажань програмний продукт не зможе функціонувати або буде марний замовнику;
необов'язкові - реалізація цих побажань може бути поки відкладена.
Порядок реалізації побажань для замовника визначається їх пріоритетом.
• Сортування побажань відповідно до ризиком.
побажання, які можна оцінити з високим ступенем точності;
побажання, які можна оцінити з прийнятною ступенем точності;
побажання, які практично неможливо оцінити.
Розробники вважають за краще починати реалізацію з побажань, що мають найбільший ризик. При такому підході, якщо в процесі реалізації виникнуть проблеми, у розробників буде достатньо часу на їх рішення.
• Визначення швидкості реалізації.
Розробники повідомляють замовнику, скільки одиниць часу команді потрібно для реалізації запланованих побажань.
• Визначення обсягу робіт - замовник вибирає набір карток для чергової версії. Існує дві основні стратегії визначення обсягу робіт:
замовник встановлює дату завершення роботи над версією і вибирає набір побажань відповідно до їх оцінкою і швидкістю роботи над проектом;
замовник вибирає набір побажань відповідно до їх оцінкою, на підставі чого потім встановлюється дата завершення роботи.
Складно підібрати побажання так, щоб сумарна кількість одиниць праці, необхідних для реалізації відібраних побажань, точно відповідало розміру ітерації. Наприклад, три найпріоритетніших побажання вимагають для реалізації 24 одиниці праці, в той час як обчислений розмір ітерації складає 26 днів. У подібній ситуації рекомендується краще залишити невеликий запас часу, ніж зірвати терміни реалізації ітерації або неякісно виконати роботу. Якщо протягом декількох підряд ітерацій планується зробити менше, ніж розмір ітерації, на наступну ітерацію можна запланувати обсяг робіт, що перевищують розмір ітерації.
Яким чином вирішуються колізії між послідовністю реалізації побажань, пропонованої замовником, і тієї, послідовністю, яку пропонують розробники Якщо розробники передбачають великі ризики, замовник повинен прислухатися до їхніх аргументів. Побоювання розробників можуть викликатися декількома причинами, серед яких найбільш часто зустрічаються такі:
• розробники не впевнені, що зможуть точно оцінити обсяг трудовитрат для реалізації даного побажання;
• реалізація деякого побажання пов'язана з використанням програмного забезпечення, яке розроблялося третіми особами, в зв'язку з чим йому не можна повністю довіряти;
• розробники не знають, як домогтися заданої продуктивності програмного продукту;
• розробники не знають, яким чином виконати проектування програмного забезпечення, щоб в майбутньому реалізація якого-небудь з незапланованих побажань не привела до переробки всього коду.
У будь-якому випадку послідовність реалізації побажань визначає замовник. Завдання розробників - відкрито попередити про наявність всіх ризиків, а не приймати рішення за замовника.
Етап управління Існує кілька причин, які можуть змусити команду повернутися до процесу планування версій системи. Основні з них - це зміна пріоритетів в побажаннях замовника і зміна швидкості роботи розробників. У порівнянні з традиційними методологіями, в гнучких технологіях замовник до початку робіт не повинен детально описувати те, який програмний продукт він хоче отримати. Поява нових побажань - заздалегідь прогнозований і виправданий процес.
Етап управління включає в себе наступні дії:
• Ітерація - на початку кожної ітерації, яка триває протягом від однієї до трьох тижнів, замовник вибирає кілька найцінніших для нього побажань, які будуть реалізовані в рамках даної ітерації. В результаті реалізації побажань найпершої ітерації повинен вийти працює від початку до кінця програмний продукт, нехай навіть в самому зародковому стані.
• Регенерація - якщо розробники приходять до висновку, що вони переоцінили власну швидкість, вони узгоджують із замовником, який набір найбільш важливих побажань слід зберегти в рамках поточної версії. При визначенні цього набору враховуються переглянуті швидкість і оцінки.
• Нове побажання - якщо в середині роботи над черговою версією замовник приходить до висновку, що в версію необхідно додати нове побажання, він може його написати. Розробники оцінюють нову побажання, після чого замовник прибирає з залишився набору побажання з еквівалентної сумарної оцінкою і додає до плану нове побажання.
• Переоцінка - якщо розробники приходять до висновку, що план більше не відповідає точної картині розробки, вони можуть заново оцінити залишилися побажання і заново визначити обсяг робіт і швидкість розробки.
На практиці виникають ситуації, які вимагають суттєвої переробки плану. До таких ситуацій належать наступні:
• відкладених «на потім» побажань стає занадто багато;
• істотно змінюється швидкість роботи команди.
У цих випадках доводиться вважати, що план стає недійсним і необхідно розробити новий план.
Переробка плану починається з того, що розробники заново оцінюють обсяг трудовитрат. До цього часу у розробників з'явився конкретний досвід роботи над даним проектом, тому в процесі роботи над планом вони вже можуть оперувати реальними показниками, взятими з минулих побажань, і тим самим більш точно оцінювати обсяг майбутньої роботи. Особливо важливо повторно переценіть трудовитрати на реалізацію побажань, які планувалися на початку роботи, так як перші плани завжди виходять найменш точними.
Як тільки розробники уточнять трудовитрати, замовник знову переглядає всі побажання і сортує їх відповідно до необхідного порядком реалізації. Далі процес планування виконується як звичайно.
Як показує практика, план випуску версій доводиться переробляти кожні три-чотири ітерації. Особливо великим змінам піддається перший план випуску версій, так як коли він складається, ніякої статистики та реалізованих побажань ще не існує. Перший план служить деякою відправною точкою, від якої можна відстежувати хід реалізації проекту, накопичувати статистичні дані по проекту.