1. Коротко про гнучку (Agile) розробці ПО
2. полегшуємо перехід
3. планування ітерацій
4. Створення призначених для користувача історій
5. Малюнок 1. Розбиття епопеї на призначені для користувача історії
6. Виявлення власника продукту
7. резерв продукту
8. Малюнок 2. Резерв продукту служить джерелом для заповнення інших резервів
9. резерв релізу
10. резерв ітерації
11. Призначення балів призначеним для користувача історіям
12. Вимірювання продуктивності
13. Малюнок 3. Графік продуктивності протягом декількох ітерацій.
14. Таблиця 1. Кількість балів за ітерацію
15. Малюнок 4. Екстраполяція обсягу завершеної роботи
16. Висновок
17. Ресурси для скачування

Поради з перших рук про ведення розробки з використанням гнучкого планування

«Ми ведемо гнучку розробку, адже ми працюємо ітераціями». Таке часто можна почути від команд, які заявляють, що вони застосовують гнучкі методології. Але працювати ітераціями - це далеко не все, що потрібно, щоб бути по-справжньому гнучким.

Традиційно команда розробників працює над релізами продукту із заздалегідь визначеним змістом і термінами. На початку роботи над кожним релізом команда менеджерів вступає в ритуальну сутичку з командою розробників, погоджуючи зобов'язання, як за термінами, так і за змістом робіт.

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

Коротко про гнучку (Agile) розробці ПО

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

На схожих фундаментальних концепціях засновані наступні сучасні методи аналізу і операційного управління:

• «Економне» (lean) виробництво: виробнича практика, яка вважає марнотратними будь-які витрати ресурсів, що не приносять користі кінцевим замовникам.
• Методологія м'яких систем: спосіб, найкраще підходить для аналізу складних ситуацій, що допускають різні варіанти визначення проблеми (наприклад, «Як діяти в катастрофічній ситуації?»).
• Методологія "шести сигм": Підхід, який намагається виявити і усунути причини наявних в робочому процесі дефектів і помилок за допомогою набору методів управління якістю та створення спеціальної інфраструктури людей всередині організації ( «чорні пояси» і т.д.), які є експертами в цих методах .

Дана стаття допоможе вам подолати ці складності і перейти від просто итеративной розробки до дійсно гнучкою розробці. У статті зачіпаються наступні теми:

• Пропозиції щодо полегшення переходу команди до застосування гнучкого планування.
• Поради по організації ітерацій. Наскільки довгим вони повинні бути? Чи повинна команда працювати итеративно тільки під час роботи над черговим релізом продукту? Чим слід займатися команді в перервах роботи над релізами?
• Розуміння ролі власника продукту (product owner) і рекомендації по створенню користувацьких історій. Що таке для користувача історії (user story)? Хто повинен їх створювати? У чому різниця між епопеєю (epic) і призначеної для користувача історією? Який обсяг роботи повинна містити в собі для користувача історія? Хто такий власник продукту? Яка роль власника продукту в робочому процесі?
• Практичні поради з планування та управління резервом робіт (backlog - об'ємом запланованої на виконання роботи) на рівні продукту, релізу та ітерації. Кожному рівню планування відповідає свій резерв робіт. Що повинні містити ці різні резерви робіт? Який рівень точності оцінок необхідний для кожного рівня планування?
• Прийоми вимірювання та інтерпретації продуктивності команди. Які прогнози ви можете робити на основі даних про продуктивність команди?

полегшуємо перехід

Перед переходом на новий процес слід звернути увагу на наступне:

• Важливо розуміти, що саме ви хочете отримати від нового процесу. Деякі люди болісно сприймають зміни. Тому вам потрібно розуміти, у чому ви на перших порах готові піти на компроміс, щоб отримати бажаний результат. Коли ви потім покажете, що домагаєтеся потрібних результатів, ви зможете відіграти поступки, мотивуючи це тим, що нові зміни - це ще один крок в еволюції процесу.
• Не форсуйте перехід. Якщо процес впроваджується в команду примусово і команда не має відповідної підготовки, це веде до неприйняття і загальної невпевненості в новому процесі.
• Пам'ятайте, що навчання - ваш друг. Отримайте необхідні знання, свикнітесь з ними і почніть застосування гнучких методик з невеликих проектів, щоб виявити і усунути неполадки процесу. Вивчившись самі, навчайте свою команду. Перед початком роботи переконайтеся, що всі однаково розуміють термінологію і сам процес. У процесі навчання ви зможете заповнити прогалини і в своїх власних знаннях.
• Чи не відступайте від процесу. Почавши працювати, не озирайтеся назад. Повинно бути, магістр Йода мав на увазі саме це, коли говорив «Або роби, або не роби ... Для спроб місця немає». Якщо щось починає йти не так, корегуйте новий процес, а не повертайтеся до старого способу роботи.

Щоб домогтися успіху, потрібно, щоб вся команда була залучена в процес. Щоб завоювати довіру команди, ви повинні самі вірити в процес. Гнучке планування добре підійде вашій команді, якщо вся команда буде прагнути його освоїти.

планування ітерацій

Почнемо з популярного питання: «Наскільки довгою повинна бути ітерація?». Мета роботи ітераціями - налагодження регулярного взаємодії зі сторонами, зацікавленими в ваш продукт (клієнтами, власником продукту і т.д.)

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

Ітерації - це серцевий ритм вашої команди. Ви завжди повинні працювати ітераціями, навіть коли ви не працюєте над черговим релізом продукту. Це дозволяє команді запланувати попереднє дослідження (етап розробки архітектури, так званий architecture spike), прототипування або створення призначених для користувача історій для наступного релізу продукту. Виконання цієї роботи перед початком «офіційних» ітерацій роботи над продуктом допоможе вам виявити ризики і при необхідності виробити плани щодо їх пом'якшення.

Намагайтеся в процесі роботи не змінювати довжину ітерацій тільки для того, щоб встигнути поставити продукт до певної дати. Можливо, ви і без цього зіткнетеся в команді з деяким опором до змін, а постійна зміна довжини ітерації аж ніяк не демонструє впевненість керівництва команди в новому процесі. Також змінна довжина ітерації ускладнює обчислення продуктивності команди (про який ми розповімо пізніше в розділі Вимірювання продуктивності ).

Єдиний випадок, коли можна віддати перевагу вкорочений ітерацію, - це остання ітерація. Якщо остання ітерація в основному полягає в завершальній роботі, такий як глобалізація та усунення дефектів, то її вкорочення не заподіє особливої ​​шкоди.

В якості альтернативи укороченою останньої ітерації ми можете зробити короткими (наприклад, 2 тижні) все ітерації. При такому підході, якщо дата релізу продукту не співпадатиме з кінцем ітерації, ви зможете завершити роботу над релізом на тиждень раніше.

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

Створення призначених для користувача історій

Призначені для користувача історії (або user story) - це короткі (в один рядок) пропозиції, що описують вимоги клієнтів. Уявіть собі, що ви пояснюєте замовнику, чим ви зараз займаєтеся. Призначені для користувача історії фокусуються на потребах замовника і не містять в собі деталей реалізації.

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

Як <роль>, я хочу <мета>, щоб <ділова вигода>.

Призначені для користувача історії також можна вибудовувати в ієрархії. Епопеї (epic) - це розповідь користувача, що описують потрібну функціональність на високому рівні. Епопеї можнео розбивати на більш дрібні завдання і створювати для них нові призначені для користувача історії та епопеї. На малюнку 1 показана епопея, розділена на кілька користувальницьких історій меншого розміру.

Малюнок 1. Розбиття епопеї на призначені для користувача історії

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

Не можна допускати, щоб розмір призначених для користувача історій був порівнянний з розміром ітерації. Наприклад, якщо довжина ітерації складає чотири тижні і ви помістіть в неї дуже велику користувача історію, то в кінці ітерації може виявитися, що команда не в силах виконати в термін заплановану роботу.

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

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

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

Виявлення власника продукту

Далі потрібно визначити власника продукту. Власник продукту - це хтось, хто взаємодіє з клієнтами і розуміє їхні потреби. Власник продукту визначає, якими якостями повинен володіти продукт, щоб досягти успіху на ринку і задовольнити потреби клієнтів.

Відносини між власником продукту і командою розробників дуже схожі на відносини між замовником і постачальником. Важливо пам'ятати, що команда розробників завжди повинна працювати над тими речами, які власник продукту вважає важливими. Саме тому і резерв продукту, і резерв релізу є списками з пріоритетами.

Навіть якщо власник продукту сам розставляє остаточні пріоритети, необхідні хороші стосунки між командою розробників і власником продукту. Розробники повинні бути впевнені, що потреби власника продукту, виражені в роботі над архітектурою для реалізації історій з резерву релізу, правильно зрозумілі і мають правильні пріоритети.

Власник товару повинен стежити за правильною розстановкою пріоритетів історій в резерві продукту і резерві релізу, щоб гарантувати, що команда працює над найважливішими речами.

резерв продукту

Власник продукту відповідає за резерв продукту (product backlog) - набір призначених для користувача історій, які повинні бути реалізовані в продукті. Для кожної історії має бути виставлений пріоритет.

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

Історії в резерві продукту повинні мати пріоритети, щоб власник продукту міг вибирати для реалізації найбільш важливі побажання. Одна вимога може містити десять призначених для користувача історій, проте якщо команда реалізує п'ять найважливіших з них, цього може виявитися достатнім для задоволення потреб замовника.

Малюнок 2. Резерв продукту служить джерелом для заповнення інших резервів

Команда повинна оцінити розміри високорівневих історій в резерві продукту в балах (так званих story points). В процесі оцінки беруть участь всі команди, залучені в реалізацію історії (розробники, тестери, технічні письменники). Ці оцінки дають власникові продукту уявлення про відносну вартості кожного шматка функціональності.

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

Чому резерв не повинен бути дуже довгим? Ця пропозиція відбувається з принципу економічної розробки (див. Врізку Коротко про гнучку розробку ПО ). Немає ніякої користі в тому, щоб тримати в черзі обсяг роботи більший, ніж ви можете виконати за розумну кількість часу. Якщо з резерву випадає хороша ідея, то через деякий час вона туди повернеться, якщо це справді цінна ідея, що відповідає потребам замовника. Тому не бійтеся виключати деякі речі і не намагайтеся їх зберігати якомусь своєму секретному резервному списку.

резерв релізу

Перед початком роботи над черговим релізом продукту власник продукту переглядає резерв продукту, виявляє історії, які повинні бути реалізовані в цьому релізі, і переносить їх у резерв релізу (release backlog).

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

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

Команда по роботі з клієнтами погоджує пріоритети нових історій з власником продукту і поміщає їх в резерв релізу. Потім команда розробників оцінює в балах кожну історію. Мета цього етапу - дати команді розробників оцінити нову функціональність, представлену невеликими порціями, і оцінити складність роботи.

У міру роботи над одними історіями протягом ітерацій власник продукту і розробники набувають нові знання. Ці знання можуть привести до створення нових користувальницьких історій або показати, що деякі зі старих історій насправді не так важливі. Для нових історій розробники і власник продукту повинні також виробити пріоритет і оцінку. Історії, які опинилися менш важливими, слід або виключити з резерву релізу, або просто знизити пріоритет в резерві. Також на основі отриманих знань команда розробників може змінювати оцінки знаходяться в резерві історій.

Хоча резерв релізу - динамічний список, але після початку ітерації власник продукту вже не може змінювати роботу, заплановану на цю ітерацію. Це не відноситься до іншої ситуації, коли, почавши роботу, команда розуміє, що певні речі не можуть бути реалізовані в цій ітерації або навіть релізі, яку ми розглянемо в наступному розділі. Під час ітерації команда розробників повинна мати можливість сконцентруватися на тому, що треба зробити.

резерв ітерації

На качана ітерації власник продукту может скорегуваті Пріоритети історій в резерві релізу, щоб команда розробніків знала, чим їй займатіся (в Цій ітерації). Половину першого дня ітерації власник продукту и команда розробніків повінні віділіті для Наради з планування ітерації. На цій нараді команда розробників повинна вибрати якомога більше високопріоритетних історій і перенести їх з резерву релізу в резерв ітерації (iteration backlog).

Щоб зуміти спланувати ітерацію за півдня, ваш резерв релізу повинен бути готовий до роботи. Якщо команда буде витрачати дорогоцінний час на створення призначених для користувача історій на початку кожної ітерації (замість того щоб робити це якомога раніше), то в підсумку, на планування буде йти більше часу. Також ви ніколи не будете знати, як багато роботи насправді заплановано на поточний реліз.

На нараді з планування команда повинна для кожної користувальницької історії з резерву ітерації виявити завдання, які потрібно виконати для її реалізації. Необхідно виявити завдання для всіх, що беруть участь в роботі над історією (розробники, тестери, технічні письменники). Команда повинна оцінити кожну із завдань в годинах і додати ці оцінки в план.

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

Іншою небезпекою тут є пропуск будь-яких завдань, необхідних для реалізації історії. На жаль, в перших ітераціях такі помилки будуть відбуватися. Такі припущення завдання можуть накопичуватися і заважати вам завершити історію в термін. Ось два типові приклади подібних помилок:

• Завдання з тестування не враховують час для написання тестових сценаріїв.
• Завдання для команди розробників не включають в себе написання автоматичних юніт-тестів.

Перед тим як команда повернеться до резерву релізу, переконайтеся, що всі історії, заплановані на ітерацію, дійсно виконані (а потім перевірте це ще двічі!). Чи всі завдання виконані? Якщо історія ще не до кінця протестована, можливо, вам варто попросити розробника допомогти тестеру закінчити роботу. Виправте дефекти, заведені на всі розроблені в цій ітерації історії. Контролюйте якість: важливо не те, як багато роботи ви зробите за ітерацію, а то, наскільки мало помилок виявиться в кінцевому продукті.

Корисно сформулювати критерії завершення ітерації. Наприклад, щоб історія вважалася завершеною, все високопріоритетні дефекти (важливості 1 і 2) повинні бути виправлені. Всі фонові дефекти (важливості 3 і 4) будуть додані в резерв релізу і повинні бути виправлені в наступній ітерації. Важливо не відкладати занадто надовго виправлення дефектів. Інакше в кінці роботи над релізом їх може накопичитися дуже багато, і ви опинитеся в неприємному становищі.

Іноді в процесі роботи стає зрозуміл, що якась історія складніше, ніж спочатку вважалося, і тому не може бути реалізована в ітерації або взагалі в цьому релізі. Про таких ситуаціях потрібно заявляти якомога раніше. Важливо визначити, які у вас залишаються варіанти. Чи є можливість спростити функціональність і все ж реалізувати щось корисне в поточному релізі? Якщо так, створіть відповідні призначені для користувача історії і обговоріть їх з власником продукту. Але спрощена версія - це лише проміжне рішення. Що б ви зробили, якби мали часом зробити все як слід? Створіть для користувача історії і для цього варіанту, і також обговоріть з власником продукту. Можливо, вони потраплять в один з наступних релізів продукту.

Команда може додавати до плану ітерації роботу будь-якого роду. Якщо для роботи над історією необхідно попередньо спроектувати архітектуру системи, створіть для цього призначену для користувача історію і заведіть в ній такі завдання, як «Проектування», «Створення прототипу» або «Дослідження». Мета створення таких історій - дати можливість власнику продукту виставити їм пріоритети. Якщо власник продукту вважає вартість проведення дослідження занадто високою, він знизить пріоритет цієї історії або взагалі виключить її з поточного релізу.

Призначення балів призначеним для користувача історіям

Команда розробників призначає бали (story points) кожної користувальницької історії з резерву продукту і резерву релізу. Чому слід використовувати саме бали, а не одиниці часу, наприклад годинник? Основною причиною є те, що на ранніх етапах розробки ви не знаєте, скільки часу вам фактично буде потрібно для реалізації тієї чи іншої історії. А якщо ви заздалегідь проведете аналіз і спроектуєте архітектуру, це може перешкоджати подальшому розвитку архітектури в міру того, як ви будете більше дізнаватися про функціональність.

Іншою причиною використання балів замість одиниць часу є те, що ідеальний час для різних людей може бути різним. Якщо оцінку виконує не та людина, яка фактично буде робити роботу, оцінка може виявитися неточною.

І, нарешті, ще одна причина використання балів: оцінка ідеального часу може бути помилково витлумачена як оцінка фактичного часу. Фактичний час - це час, який займе робота, з урахуванням всіх переривань робочого процесу, що відбуваються протягом звичайного робочого дня. Наприклад, на завдання, оцінене в п'ять робочих днів, фактично може піти вісім-дев'ять днів, якщо врахувати щоденні наради, телефонні розмови, ведення переписки по електронній пошті і перевірки (інспекції).

Оцінюючи призначені для користувача історії в балах, ви фактично порівнюєте відносну складність їх реалізації. Оцінюючи одну історію в один бал, а другу - в п'ять балів, ви фактично заявляєте, що реалізувати другу історію в п'ять разів складніше, ніж першу. Однак, зауважте, це не обов'язково означає, що часу на другу історію потрібно в п'ять разів більше.

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

Спочатку вам буде складно оцінювати історії в балах через відсутність еталона для порівняння. Але з часом команда буде робити все більше і більше оцінок і поступово їх точність збільшиться. Для оцінки історій в балах можна використовувати спосіб покеру Планування.

Покер Планування - це спосіб командного узгодження оцінки складності або об'єму роботи при розробці програмного забезпечення. У цьому способі робиться спроба мінімізувати вплив, який чиниться на оцінку передчасними коментарями учасників команди. Для кожного оцінюваного завдання кожен член команди вибирає свою карту оцінки (карти мають значення 0, 0.5, 1, 2, 3, 5, 8, 13, 20, 40, 100), таким чином, що його карту не бачить ніхто з інших гравців . Після того як всі гравці зробили свій вибір, карти розкриваються (і відбувається обговорення).

Вимірювання продуктивності

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

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

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

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

Малюнок 3. Графік продуктивності протягом декількох ітерацій.

Користь підрахунку продуктивності в тому, що через деякий час ви зможете використовувати цю статистику для екстраполяції майбутнього графіка робіт.

Таблиця 1. Кількість балів за ітерацію

Ітерація Бали 1 28 2 32 3 36 4 34 5 33 6 37 7 31 8 35

У таблиці 1 показано кількість балів, зароблених командою за кожну минулу ітерацію. На основі цих даних ви можете вирахувати наступні показники:

• Середня кількість балів, заробляє за ітерацію - 33.
• Поточна продуктивність команди - 35 балів за ітерацію.
• Середня продуктивність за 3 самі повільні ітерації - 30 балів.

Тому, припускаючи, що до закінчення роботи над релізом залишається 6 ітерацій, можна зробити наступні припущення:

• При роботі з середньою продуктивністю команда зможе завершити історій ще на 198 балів (6 х 33).
• При роботі з поточної продуктивністю команда зможе завершити історій ще на 210 балів (6 х 35).
• При роботі з низькою продуктивністю команда зможе завершити історій ще на 180 балів (6 х 30).

На малюнку 4 показаний резерв релізу, розділений на 3 секції. У середній секції показано, скільки роботи може бути виконано на основі зроблених вище припущень.

Малюнок 4. Екстраполяція обсягу завершеної роботи

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

Висновок

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

Те, що не всі заплановані історії потраплять в реліз, як правило, не є згубним для власника продукту. Однак він, звичайно ж, буде незадоволений, якщо команда витратила надто багато часу на не найважливіші речі і через це не встигла закінчити всі важливі історії. Ставтеся до власника продукту як до вашого замовнику і завжди робіть в першу чергу те, що він хоче найбільше.

Я висловлював в цій статті свої власні погляди, які можуть не збігатися з думкою IBM.

Ресурси для скачування

Схожі теми

• оригінал статті (EN).
• Ознайомтеся з наступними публікаціями, використаними при створенні цієї статті:
  • Agile Estimating and Planning (EN, видавництво Prentice Hall PTR, 2005) - посібник з оцінки та планування agile-проектів, що описує, в тому числі, філософський і практичний підходи до питання.
  • книга User Stories Applied: For Agile Software Development (EN, видавництво Addison-Wesley, 2004 року) фокусується на важливості для користувача історій для процесу гнучкої розробки.
• Такоже Ознайомтеся з курсами, навчальними гнучкою розробці .
• покер Планування - це спосіб, що дозволяє розподіленим командам спільно оцінювати майбутню роботу.
• Серія статей "Architectural manifesto: Adopting agile development" на developerWorks (EN, березень 2008 - січень 2009 року) може допомогти вам вирішити, чи підійде гнучка розробка для ваших потреб:
• У подкасті " Scott Ambler on Agile development "(EN, developerWorks, квітень 2007 року) експерт IBM щодо практичного застосування гнучкої розробки розповідає про це итеративном і послідовний підхід до розробки, призводить економічне обґрунтування його використання і розвінчує деякі пов'язані з ним міфи.
• У статті " Agile software development: A tour of its origins and authors "На developerWorks (EN, березень 2007 р) розкривається, що насправді означає термін" agile ".
• Переважно розділі Linux і в розділі Linux для новачків ви знайдете безліч ресурсів для Linux-розробників; також перегляньте наші найпопулярніші статті та керівництва (EN).
• Ознайомтеся з іншими порадами и керівництвами по Linux на сайті developerWorks (EN).

Підпішіть мене на ПОВІДОМЛЕННЯ до коментарів