“Сподівання, що менеджер продукту чи проекту зможе магічним образом передбачити можливості інших, що є експертами в своїй роботі — це самогубство для бізнесу.”
“Чому Agile-методи оцінки та планування ефективніші за традиційні методи? Бо вони зосереджені на створенні цінності й формуванні довірчих відносин між бізнесом і проектними командами. Забезпечення цілковитої прозорості та наявність постійного інформування про зміни в міру їх виникнення дозволяють бізнесу приймати найкращі рішення.”
“Без гнучкого оцінювання та планування не можуть існувати будь-які гнучкі проекти.”
“Планування — це все. Плани ніщо. Фельдмаршал Гельмут фон Мольтке”
“Оцінка та планування мають вирішальне значення для успіху проекту з розробки ПЗ будь-якого розміру або масштабу.”
“Оцінка й планування — це не лише визначення термінів або календарних графіків. Планування — і перш за все безперервний ітераційний підхід до планування — це пошук цінності. Планування - це спроба знайти оптимальне рішення загального питання розробки продукту: що ми повинні створити? Для відповіді на це питання команда аналізує функціональність, ресурси й терміни. На таке питання не можна відповісти миттєво — на нього треба відповідати ітераційно й поступово.”
“Вдалий процес планування підтримує це шляхом: 1) скорочення ризиків; 2) зменшення невизначеності; 3) підтримки ухвалення кращих рішень; 4) встановлення довіри; 5) розповсюдження інформації.”
“при визначенні Agile-планування ми виявили, що він: 1) фокусується переважно на плануванні, а не на плані; 2) заохочує зміни; приводить до складання планів, що легко змінюються; 3) розподіляє процес планування по всьому терміну виконання проекту.”
“Мета планування - знайти оптимальну відповідь на глобальне питання розробки продукту — що саме створювати. Відповідь включає в себе функціональності, ресурси та календарний графік. Вона підтримується процесом планування, що знижує ризики, зменшує невизначеність, підтримує ухвалення кращих рішень, установлює довіру й забезпечує передачу інформації.”
“майже дві третини проектів значно перевищують кошторис витрат [Lederer and Prasad, 1992];”
“64 % функціональності, що включена в продукти, використовується рідко або взагалі не використовується (Johnson, 2002];”
“термін виконання середнього проекту перевищує календарний графік на 100 % [Standish, 2001].”
“Критична проблема традиційних підходів до планування полягає в тому, що вони сфокусували свою увагу на діяльності, а не на реалізації функціональності… Перша проблема з процесно-орієнтованим плануванням полягає в тому, що клієнти не отримують жодної цінності від виконання роботи. Функція - це одиниця цінності для клієнта. Планування, таким чином, має здійснюватися на рівні функцій, а не видів діяльності. Друга проблема виникає після аналізу вже складеного традиційного календарного графіка. Коли ми перевіряємо календарний графік, у якому вміщені види робіт, ми шукаємо продавлений вид діяльності, а не відсутність функцій. Подальші проблеми виникають тому, що процесно-орієнтовані плани найчастіше ведуть до проектів, що не вкладаються в календарні графіки.”
“Реальне знання, яке ми маємо взяти до уваги в подібній ситуації, полягає в тому, що коли робота займає більше часу, ніж заплановано, усі інші подібні роботи теж, імовірніше, заберуть більше часу, ніж планувалося.”
“багатозадачність допомагає, коли ви займаєтеся двома завданнями водночас: якщо виконання одного з них блокується, ви можете переключитися на інше. Також є логічним і те, що на рис. 2.2 показане швидке скорочення часу, який витрачається на виконання задач із додаванням цінності, коли їхня кількість перевищує дві.”
“Багато організацій плутають оцінки із зобовʼязаннями. Щойно команда надає оцінку, її негайно перетворюють на зобовʼязання.”
“Автори Agile-маніфесту писали, що передусім вони розділяють наступні цінності: 1) Люди та взаємодії важливіші за процеси та інструменти. 2) Працюючий продукт важливіший за вичерпну документацію. 3) Співпраця із замовником важливіша за обговорення умов контракту. 4) Готовність до змін важливіша за дотримання плану.”
“деяким з основних способів роботи Agile-команд, якщо вони: 1) Працюють єдиною командою. 2) Працюють короткими ітераціями. 3) Поставляють щось після кожної ітерації. 4) Фокусуються на бізнес-пріоритетах. 5) Інспектують та адаптують.”
“Перша роль — власник продукту. Серед основних обовʼязків власника продукту обовʼязково мають бути присутні формування спільного бачення проекту в усіх членів команди, визначення пріоритетів, що забез-печують, насамперед, розробку найціннішої функції, а також ухвалення рішень, спрямованих на отримання високої рентабельності інвестицій у проект. При розробці комерційного ПЗ власником продукту часто стає представник служби маркетингу або управління продуктами компанії.”
“Друга роль — це роль клієнта. Клієнт — це особа, яка ухвалює рішення про фінансування проекту або про придбання програмного забезпечення. У проекті з розробки ПЗ для внутрішнього користування клієнтом зазвичай стає представник іншої групи або підрозділу.”
“Ще одна суттєва роль — це розробник. Я використовую поняття розробник у дуже широкому сенсі, маючи на увазі будь-кого, хто розробляє ПЗ. Це програмісти, тестувальники, аналітики, інженери баз даних, юзабіліті-експерти, технічні письменники, системні архітектори, дизайнери тощо.”
“Остання роль — менеджер проекту. Як зазначає Гайсміт (2004а), роль менеджера проекту змінюється в разі застосування Agile-методів. Менеджери Agile-проектів зосереджені переважно на лідерстві, ніж на управлінні.”
“Користувацька історія — це короткий опис функціональності з погляду користувача або клієнта системи. Користувацькі історії викладаються у довільній формі, будь-які синтаксичні правила до їх складання відсутні. Проте загалом непогано дотримуватися такої форми: «Як [тип користувача] я хочу отримати [можливість], аби отримати [бізнес цінність ».”
“Agile-проект більш схожий на перегони із часом, ніж на стаєрський забіг: вам необхідно пробігти якомога далі за, припустимо, шістдесят хвилин. Отже, команда Agile-проекту знає, коли фінішує, але не знає, з яким результатом.”
“Проект генерує два нові види знань: знання про продукт і знання про проект.”
“Agile-команди використовують планування на трьох рівнях: планування релізу, планування ітерації та щоденне планування.”
“Пункти — це одиниця виміру загального розміру користувацької історії, функції або іншої частини роботи. Коли ми оцінюємо користувацьку історію, то присвоюємо певну кількість пунктів кожному елементу. Значення вихідних розмірів нічого не важить. Що важливо, так це відносні розміри. Історія, якій присвоєно два пункти, має бути вдвічі більшою за історію, якій надано один пункт. Вона має також складати дві третини історії, яку оцінюють у три пункти.”
“Аби зрозуміти, у чому користь оцінки історії в безрозмірних пунктах, необхідно ввести нове поняття — швидкість. Швидкість — це показник темпу прогресу команди. Для і визначення підсумовують кількість пунктів, що були присвоєні кожній користувацькій історії, яку команда реалізувала протягом ітерації. Якщо команда реалізує три історії, кожна з яких оцінюється в пʼять пунктів, то її швидкість дорівнює пʼятнадцяти.”
“Розробник програмного забезпечення, якого змушують працювати в багатозадачному режимі, значною мірою втрачає ефективність унаслідок перемикання між двома (або більше) завданнями.”
“У проекті з розробки ПЗ ми можемо оцінювати користувацькі історії в ідеальних днях. При оцінці в ідеальних днях ви припускаєте, що: 1) Оцінювання історії — це єдине завдання, над яким ви працюєте. 2) Усе, що вам необхідне, є під рукою в момент початку роботи. 3) Перерв не буде.”
“Ідеальний час і реально витрачений час — не те саме. Ідеальний час гри в американський футбол становить шістдесят хвилин (чотири пʼятнадцятихвилинні періоди). Проте для завершення матчу зазвичай потрібно близько трьох годин. Причиною такої різниці є різного роду перерви, що можуть виникати під час матчу.”
“Незважаючи на добре відомий факт, що оцінка, надана тим, хто буде виконувати роботу, краща за оцінку, надану кимось іншим [Lederer, Prasad, 1992], найкращими є спільні оцінки членів команди, які будуть здійснювати проект. Це пояснюється двома причинами. По-перше, в Agile-проекті зазвичай невідомо, хто конкретно має вирішувати ту чи іншу задачу… По-друге, навіть якщо ми очікуємо, що виконувати цю роботу буде фахівець із баз даних, інші члени команди можуть мати власні міркування”
“На мою думку, найкращий спосіб оцінки для Agile-команд, — це покер планування [Grenning, 2002). Покер планування обʼєднує експертну оцінку, оцінку за аналогією і розбивку на дрібніші частини в єдиний зручний підхід, що дозволяє швидко отримати надійні результати.”
“На підставі ретельного аналізу літератури з оцінки програмного забезпечення Йоргенсен [Jorgensen, 2004 дійшов висновку, що «оцінювати завдання повинні ті, хто є найкомпетентнішими в їхньому виконанні».”
“результати досліджень свідчать, що усереднення індивідуальних оцінок дає кращі результати [Hoest and Wohlin, 1998], як і колективне обговорення оцінок Uorgensen and Molokken, 2002]. Колективне обговорення є основою покеру планування, а такі обговорення призводять до усереднення індивідуальних оцінок, що надто відрізняються.”
“покер планування працює, тому що це весело.”
“при визначенні швидкості я зазвичай дотримуюся підходу «усе або нічого»: якщо історія реалізована (запрограмована, протестована й прийнята власником продукту), то команда отримує всі пункти, але якщо в історії щось залишилося недоробленим, вона не отримує нічого.”
“Якщо ви скажете людям, куди потрібно дістатися, але не вкажете шляху, то будете вражені результатами. Генерал Джордж Паттон”
“перелік основних аргументів на користь вибору пунктів для оцінки розміру. Серед них такі: 1) Пункти допомагають керувати крос-функціональною поведінкою. 2) Оцінки в пунктах не втрачають актуальності. 3) Пункти — це чистий показник розміру. 4) Оцінка в пунктах зазвичай відбувається швидше. 5) Мої ідеальні дні — це не ваші ідеальні дні.”
“Зверніть увагу на те, що оцінки як у пунктах, так і в ідеальних днях вимагають перегляду при зміні розміру в процесі розробки. Однак коли команда набуває досвіду, перегляду потребують лише оцінки в ідеальних днях.”
“У багатьох проектах значна частка загальних зусиль витрачається на придбання нових знань. Важливо, аби ці зусилля були визнані та вважалися фундаментальним аспектом проекту. Придбання нових знань важливе тому, що на початку проекту ми ніколи не знаємо всього, що нам потрібно знати для завершення проекту. Знання, що їх набуває команда, можна поділити на дві групи: 1) Знання про продукт. 2) Знання про проект.”
“Знання про продукт - це знання про те, що буде розроблятися. Це знання про ті функції, що будуть включені, і про ті, які відсіються. Що більше знань про продукт має команда, то якісніші рішення вона зможе ухвалювати про характер і функції продукту.”
“Знання про проект, на відміну від попереднього, — це знання про те, як продукт буде створюватися. Прикладами є знання про технології, що будуть використовуватися, про кваліфікацію розробників, про те, наскільки злагоджено буде працювати команда тощо.”
“Зворотний бік набуття знань — це зменшення невизначеності.”
“Із проектами повʼязана безліч різних типів ризику, серед яких головні: 1) Ризик зриву графіка («Ми не можемо це виконати до жовтня»). 2) Ризик збільшення витрат («Імовірно, ми не зможемо придбати обладнання за відповідною ціною»). 3) Ризик функціональності («Ми, схоже, не зможемо це виконати»).”
“Насамперед слід розробляти функції з високою цінністю та високим ризиком. Ці функції приносять найбільший прибуток, а робота над ними паралельно усуває значні ризики. Наступні на черзі — функції з високою цінністю та низьким ризиком. Вони приносять такий само прибуток, як і попередні, але є менш ризикованими. Зрештою, ними можна зайнятися пізніше.”
“Існує чотири основні фактори, які необхідно враховувати під час пріоритизації. 1) Фінансова цінність наявності функцій. 2) Витрати на розробку (і, можливо, підтримку) нових функцій. 3) Обсяг і значущість навчання й нового знання, набутого під час розробки функцій. 4) Величина ризику, ліквідованого внаслідок розробки функцій.”
“Приріст прибутку може бути результатом того, що нова система або продукт: 1) Стимулює існуючих клієнтів до придбання додаткових ліцензій. 2) Містить у собі додаткові опціональні додатки, які можна продавати окремо. 3) Містить функції, що дозволяють установлювати більш високу ціну. 4) Стимулює використання консультаційних послуг (наприклад, з інтегрування з додатком стороннього виробника).”
“У пошуках можливостей для підвищення операційної ефективності слід звертати увагу на такі чинники: 1) Усе, що займає багато часу або буде займати багато часу, якщо компанія розшириться. 2) Поліпшення інтеграції або комунікації між відділами. 3) Зниження плинності кадрів. 4) Скорочення часу навчання нових співробітників. 5) Будь-які чутливі до термінів процеси. 6) Обʼєднання декількох процесів. 7)Усе, що підвищує точність і зменшує переробку.”
“Під приростом прибутку мається на увазі додатковий прибуток, який ми можемо отримати від існуючих клієнтів.”
“Збережений прибуток — це те, чого ми більше не втратимо через незадоволення клієнтів нашим продуктом, зростання потреб чи інших причин відмови від WebPayroll.”
“чиста зведена вартість (net present value, або NPV). Для визначення NPV підсумовують зведені вартості кожної статті в потоці майбутніх вартостей.”
“Ставка внутрішньої прибутковості (internal rate of return, ao IRR), яку іноді називають рентабельністю інвестиції (return on investment, або ROI) дозволяє уявити прибуток від проекту у відсотковому вираженні. Якщо NPV — це показник того, скільки грошей можна отримати від проекту (у нинішній зведеній вартості), то IRR - це показник того, наскільки швидко зростають гроші, вкладені в проект. 3 IRR ми отримуємо можливість легше порівнювати проекти”
“Чимало організацій визначають мінімальну привабливу ставку дохідності (minimum attractive rate of return, ao MARR). Фінансуються лише ті проекти або теми, що мають IRR, яка перевищує MARR.”
“Додаткову інформацію щодо економіки проектів створення ПЗ можна знайти у чудовій книжці Стіва Токі «Return on Software: Maximizing the Return on Your Software Investment» (2004).”
“Кано запропонував визначати категорію функції за допомогою двох пи-тань: що користувач буде відчувати за наявності функції в продукті — і що буде відчувати користувач за відсутності цієї функції. Перше з цих питань відоме як функціональна форма, оскільки передбачає наявність функції. Друге питання відоме як дисфункціональна форма, оскільки в цьому разі функція відсутня. Відповідь на кожне з питань обирається за стандартною шкалою з пʼяти пунктів: 1. Мені це подобається. 2. Я очікую, що так буде. 3. Мені байдуже. 4. Я це переживу. 5. Мені це не подобається.”
“Подрібнюйте великі історії за межами даних, підтримуваних історіями.”
“Подрібнюйте великі історії на підставі операцій, що виконуються в межах історії.”
“Спробуйте видалити наскрізні функції (такі, як безпека, реєстрація та обробка помилок) і створити дві версії історії: одну з підтримкою наскрізних функцій, а іншу — без підтримки.”
“При розробці ПЗ ми нерідко забуваємо (або ігноруємо) пораду Керніга-на й лоджера: «Примусь це працювати, а потім підвищуй швидкодію» [Kernighan and Plauger, 1974].”
“Подрібнюйте велику історію, якщо маленькі історії мають різні пріоритети.”
“Не подрібнюйте велику історію на завдання. Замість цього намагайтеся застосувати до всієї історії підхід «трасуючих куль».”
“Уникайте погіршення ситуації внаслідок додавання повʼязаних змін до відповідним чином оціненої функції — за винятком ви-падків, коли ці залежні зміни мають такий само пріоритет.”
“Історію можна подрібнювати за типом даних, які вона підтримує. Історію також можна розбивати на підставі передбачених операцій.”
“Подрібнення історій на підставі CRUD-операцій (створення, читання, редагування й видалення) є вельми розповсюдженим. Історію можна зменшити за допомогою виділення наскрізних функцій - таких, як безпека, реєстрація, обробка помилок тощо. Також це можна зробити шляхом ігнорування цільової продуктивності під час тієї ітерації, у якій реалізується функціональна історія. Цільову продуктивність можна виділити в самостійну історію та реалізувати її пізніше. Багато історій описують дві й більше потреби. Якщо такі потреби мають різні пріоритети, розбивайте історії відповідно до них. Уникайте розбивки історій на завдання з розробки, які є обовʼязковими для реалізації функції. Поділ роботи на обовʼязкові завдання є звичним для нас настільки, що ми починаємо автоматично подрібнювати на них користувацькі історії. Уникайте спокуси збільшення розміру великої історії завдяки включенню до неї повʼязаних змін, що не потрібні для реалізації саме цієї користувацької історії. Нарешті, памʼятайте, що іноді корисно обʼєднувати користувацькі історії, особливо повʼязані з усуненням помилок, які є занадто дрібними самі по собі.”
“Що скоріше продукт буде випущено (і що кращим він виявиться), то швидше організація почне отримувати прибуток від вкладень у проект.”
“Планування релізу — це не прагнення створити план, у якому буде за-значено, які розробники будуть займатися тими чи іншими користувацькими історіями або завданнями, воно також не є переліком послідовності виконання робіт у межах однієї ітерації. Створення плану з таким рівнем деталізації під час планування релізу небезпечне й може ввести в оману. Рішення про те, хто й чим буде займатися, а також про послідовність виконання робіт краще залишити тим, хто буде безпосередньо виконувати ці завдання, і відкласти їх на якомога пізніший термін.”
“Перш ніж розпочати планування релізу, важливо встановити критерії, за якими проект можна оцінити як успішний або невдалий. Для більшості проектів основним критерієм є сума грошей, яку вдалося заощадити або заробити. Як основні індикатори ймовірності досягнення фінансових цілей у більшості проектів використовуються календарний графік, обсяг роботи і ресурси. Це означає, що умови задоволеності власника продукту визначаються поєднанням цільових термінів, обсягу й ресурсів.”
“Проекти можуть бути орієнтованими або на терміни, або на функції. Орієнтований на термін проект — це проект, що має бути завершений до певної дати, при цьому набір його функцій визначається за домовленістю. Орієнтований на функції проект - це той, що має бути завершений за максимально короткий термін, але при цьому реалізація набору функцій вважається більш важливою.”
“План релізу — це план високого рівня, що охоплює більш тривалий пе-ріод, ніж одна ітерація.”
“Agile-команда прагне усувати всі дефекти в тій ітерації, у якій вони були виявлені. Це стає можливим із набуттям досвіду роботи з короткими ітераціями, зокрема, унаслідок застосування автоматичного тестування.”
“всі учасники проекту памʼятають, що одні історії вимагають більше часу, ніж інші, незважаючи на те, що їхні початкові оцінки однакові.”
“Досвід, отриманий під час виконання численних проектів, свідчив, що команди набагато краще підганяють обсяг робіт до тривалості ітерації, а не тривалість ітерації — до обсягу робіт.”
“Стабільний ритм виконання ітерації — це свого роду пульс проекту. Колега Саймон Бейкер, Agile-тренер компанії «Think-box Itd.», описує це так: «Як серцебиття, стабільність якого необхідна для життєдіяльності організму, фіксована тривалість ітерації допомагає задавати ритм розробки (і реалізації). Ритм у моїй практиці - значущий фактор, що дозволяе досягти стійкого темпу» [Baker, 2004].”
“Я вважаю, що саме двотижневі ітерації є ідеальними. Витрати, повʼязані з плануванням і тестуванням, значно краще піддаються управлінню, коли розподіляються за двотижневим періодом. Перший тиждень двотижневої ітерації може сприйматися інакше, ніж другий тиждень, але ця різниця не настільки значна, як у випадку чотиритижневої ітерації. Крім того, більшість організацій можуть (за наявності досвіду) навчитися не змінювати пріоритети протягом двох тижнів, тоді як утриматися від цього впродовж чотирьох тижнів дуже складно.”
“6 × 2 + 1 - Безперервна робота з використанням двотижневих ітерацій може відчутно напружувати команду через постійну необхідність видавати готовий продукт за умови, що термін здачі роботи не виходить за межі наступного тижня. Мій улюблений прийом зниження цієї напруги — макроцикл із шести двотижневих ітерацій, за якими йде однотижнева ітерація. Я позначаю цей цикл формулою «6 × 2 + 1». Під час двотижневих ітерацій команда працює над пріоритетами власника продукту. Для однотижневих ітерації команда підбирає роботу самостійно. Це не означає, що вона використовує цей час для ігор або весь тиждень проводить на пляжі. Члени команди протягом цього тижня зосереджуються на тій роботі, яку вважають пріоритетною для проекту. Програмісти можуть займатися реорганізацією коду, здійснювати яку протягом іншої ітерації, на їхній погляд, ризиковано, або експериментувати з новітніми технологіями. Тестувальник може займатися автоматизацією наявних ручних тестів. Аналітик — досліджувати наступну велику функцію, якій, на його думку, було приділено недостатньо уваги. Можливість отримати тиждень для роботи над тим, що команда колективно пріоритизувала для себе, е потужним надихаючим фактором. Важливо підкреслити, що така однотижнева ітерація в жодному разі не є звалищем недоробок із попередніх ітерацій. Це час, коли команда отримує можливість попрацювати над тим чи іншим технічним боргом, що виник у перших ітераціях під час освоєння Agile-підходу або в ще давніші часи.”
“Ідеальним способом спрогнозувати швидкість є виконання ітерації (або двох чи навіть трьох) з подальшою оцінкою значення потрібного показника на підставі спостережуваної швидкості. Оскільки найкращим способом визначення швидкості є її спостереження, цей підхід слід обирати за замовчуванням.”
“Припустімо, що команда виконала три ітерації із середньою швидкістю 20 протягом усього періоду. Для трьох ітерацій діапазон становить 85-115 %. Це означає, що фактична швидкість до кінця проекту буде, ймовірніше, лежати в діапазоні від 17 до 23.”
“За моїми спостереженнями і на думку моїх колег, більшість працівників, цілком задіяних у проекті, можуть приділяти проекту від чотирьох до шести годин на день. Це відповідає даним, що учасники приділяють роботі над проектом від 55 [Ganssle, 2004] до 70 % [Boehm, 1981) свого часу. Найвищий показник, за даними Кеннеді [Kennedy, 2003], в інженерів компанії «Toyota», де високоефективний процес ощадливого виробництва дозволяє присвячувати роботі над цільовим проектом до 80 % часу.”
“Скільки 6 годин на день члени команди не приділяли проекту, ви навряд чи відмовитеся від можливості збільшити цей показник. Кращий, на мій погляд, спосіб домогтися цього вигадав Франческо Чірілло з «XPLabs». Чірілло вчить команди працювати з високою концентрацією тридцятихви-линними інтервалами |Cirillo, 2005]. Кожен тридцятихвилинний інтервал складається з двох частин: двадцять пʼять хвилин інтенсивної роботи, а далі — пʼятихвилинна перерва. Ці тридцятихвилинні інтервали називають «помідори». Ця назва повʼязана з використанням таймерів у вигляді помідорів, що подають сигнал, коли закінчуються двадцять пять хвилин. Чірілло запропонував свій метод Пьєрджуліано Боссі, і той документально підтвердив його успішність під час роботи з декількома командами [Bossi, 2003; Bossi and Cirillo, 20011. Ці команди зазвичай планували виконувати роботу на десять «помідорів» (пʼять годин) на день. Якщо ви витрачаєте свій час менш продуктивно, ніж хотілося 6, можете спробувати цей підхід.”
“Існує три способи оцінки швидкості. По-перше, можна використовувати середні історичні показники за їх наявності. Водночас, перш ніж застосувати середні історичні показники, необхідно зрозуміти, чи не змінилися суттєво команда, характер проекту, технологія тощо. По-друге, можна відкласти оцінку швидкості доти, доки не будуть виконані кілька ітерацій. Це найкращий варіант. По-третє, можна спрогнозувати швидкість шляхом подрібнення кількох історій на завдання й визначення обсягу робіт, потрібного для ітерації. Цей процес скидається на планування ітерації.”
“є сенс створювати буфер під час складання календарного графіка. Буфер — це припуск на можливу помилку в оцінці. У разі, коли існує значна невизначеність або витрати, пов’ 'язані з помилкою, створення буфера стає дуже корисним. Він допомагає захистити проект від впливу невизначеності. Отже, буферизація календарного графіка проекту є хорошою стратегією управління ризиками. У цьому розділі ми розглянемо два типи буферів: функціональний буфер і буфер календарного графіка.”
“В Agile-проекті функціональний буфер створюється дуже просто. Спочатку клієнт вибирає всю абсолютно обовʼязкову роботу. Оцінки цієї роботи підсумовуються. Дана робота являє собою мінімум, що має ввійти в реліз. Далі клієнт обирає ще 25-40 % робіт ближче до верхньої границі діапазону для проектів із більш високою невизначеністю або меншою стійкістю до ризику невиконання календарного графіка. Оцінки цих робіт додаються до первісної оцінки й утворюють сумарну оцінку проекту. Після цього складається план проекту, що передбачає поставку всього набору функцій, однак при цьому частина роботи визнається є додатковою і виконується тільки в тому разі, якщо дозволяє час. Додаткова робота виконується в останню чергу й виключно після завершення обовʼязкової.”
“перенесення локального запасу часу загалом в буфер проекту дозволяє уникнути впливу закону Паркінсона і синдрому студента. Як ми знаємо з Розділу 2, закон Паркінсона стверджує, що робота завжди розтягується так, щоб зайняти увесь відведений на неї час. Синдром студента [Goldratt, 1997 — це схильність відкладати справи на останній момент, що заважає їхньому успішному завершенню. Прикладом може вважатися початок роботи студента коледжу над курсовим проектом за три дні до терміну його здачі. Усуваючи проблеми, повʼязані із законом Паркінсона й синдромом студента, більш короткий графік, що включає буфер, скоріше буде виконаний, ніж довший графік без буфера.”
“Метод квадратного кореня із суми квадратів є найнадійнішим, коли оцінюються не менше 10 користувацьких історій або функцій. Якщо ж у вашому проекті менше 10 елементів, то, імовірніше, можна обійтися без буфера.”
“На буфер проекту має припадати не менше 20 % загального терміну проекту. Буфер меншого розміру не завжди забезпечує адекватний захист проекту в цілому.”
“невизначеність функцій потрібно компенсувати за допомогою функціонального буфера, а невизначеність календарного графіка — за допомогою часового.”
“Не забувайте також, що в проекті можуть використовуватися й інші буфери, крім функціонального й часового. Інколи має сенс створити бюджетний буфер.”
“Часовий буфер, своєю чергою, створюється шляхом включення в календарний графік додаткового часу з урахуванням невизначеності, властивої розмірам команди. Функціональний буфер можна обчислити шляхом присвоєння кожній користувацькій історії двох оцінок — із 50 та 90 % вірогідністю. Застосування квадратного кореня суми квадратів цих двох оцінок дозволяє визначити відповідний розмір часового буфера.”
“якщо кілька команд працюють над одним проектом, їм потрібно координувати свою роботу… По-перше, команди мають створити загальну базу для оцінок. Ім необхідно домовитися про проведення оцінки в однакових одиницях: пунктах або ідеальних днях. Також вони повинні домовитися про значення цих одиниць шляхом узгодження оцінок невеликого набору історій. По-друге, коли командам доводиться працювати разом, корисно як- найраніше додавати деталі до користувацьких історій. Найкращий спосіб досягти цього - визначення умов задоволеності власника продукту щодо тієї або іншої історії. Це ті речі, що можуть бути продемонстровані після реалізації користувацької історії. По-третє, команди виграють від створення ковзаючого випереджального плану в процесі планування релізу. Ковзаючий випереджальний план — це лише погляд уперед на кілька майбутніх ітерацій (зазвичай на дві або три), що дозволяє командам координувати роботу, обмінюючись інформацією про те, над чим кожна з них почне працювати в найближчому майбутньому. По-четверте, у дуже складних проектах із великим числом між-командних взаємозалежностей у план корисно вбудовувати підтримувальні буфери. Підтримувальний буфер — це певний запас часу, що запобігає затримці поставки результатів однієї з команд, яка призводить до затримки початку робіт в іншій команді.”
“Швидкість - це показник обсягу роботи, яку команда виконує протягом кожної ітерації. Швидкість повинна визначатися на основі правила «все або нічого». Якщо історія реалізована, то команда має право включити її повну оцінку в розрахунок швидкості. Якщо історія частково реалізована протягом ітерації, вона не враховується при визначенні швидкості.”
“Дошка завдань виконує подвійну роль — надає команді зручний механізм організації роботи і забезпечує можливість побачити, скільки роботи залишилося. Дуже важливо, щоб дошка завдань (або щось подібне) враховувала значну гнучкість в організації роботи команди.”
“Деякі команди іноді звертаються до індивідуальної швидкості, тобто до кількості пунктів або ідеальних днів, реалізованих окремим членом команди. Моя порада — не треба відстежувати індивідуальну швидкість. Визначення індивідуальної швидкості підштовхує людей до поведінки, що заважає успішному здійсненню проекту. Припустімо, ви оголошуєте, що маєте намір вимірювати індивідуальну швидкість і відслідковувати її від ітерації до ітерації. Як, на вашу думку, на це відреагують члени команди? Якщо мені доведеться робити вибір між одноосібним завершенням історії й наданням допомоги колезі, який стимул надасть мені вимірювання індивідуальної швидкості?”
“Швидкість команди має значення, проте індивідуальна швидкість — ні.”
“Якщо більшість ваших історій реалізуються одноосібно, вам слід переглянути підхід до їх складання. Це, зазвичай, означає, що вони повинні бути написані на більш високому рівні, так, щоб у роботі над ними могли брати участь кілька людей.”
“Плани оновлюються протягом усього проекту, і про ці оновлення необхідно поінформувати зацікавлені сторони. Без інформування не буде цінного зворотного звʼязку, що може підвищити бажаність й успішність продукту, а також корисність плану.”
“Планування - це спроба оптимальним чином збалансувати три аспекти розробки продукту: функції, ресурси і терміни. Зміна одного із цих аспектів призводить до зміни інших.”
“Дванадцять рекомендацій для Agile оцінки та планування: 1) Залучайте всю команду… оцінка найкраще вдається за участі всієї команди, хоча працювати з оціненими історіями або завданням будуть лише один або два учасники команди. Що більше відповідальності бере на себе вся команда, то успішніше вона діє. 2) Плануйте на різних рівнях. План релізу, план ітерації та щоденний план мають різні часові горизонти і різні рівні точності. Кожен із них має свою мету. 3) Розділіть оцінки розміру й термінів, використовуючи різні одиниці. Найпростіше розмежувати оцінку розміру та оцінку термінів за допомогою таких одиниць виміру, які неможливо сплутати. Оцінка розміру в пунктах і перетворення розміру в термін за допомогою швидкості - відмінний спосіб цього досягти. 4) Виражайте невизначеність у термінах функціональності або в даті. Жоден план не є повністю визначеним. Обовʼязково майте на увазі невизначеність при складанні планів релізу… Використовуйте більші одиниці (ітерації, місяці, квартали) пропорційно зростанню невизначеності. 5) Переплановуйте часто… Користуйтеся будь-якою можливістю переглянути плани, аби проект завжди був спрямований на створення найбільшої цінності для організації. 6) Відстежуйте й повідомляйте про прогрес… Забезпечте регулярне інформування шляхом публікації простих і зрозумілих індикаторів прогресу команди. Задля цієї мети добре підходять діаграми вигорання та інші наочні індикатори прогресу. 7) Визнайте важливість навчання… Набувши нові знання про використання технологій і про роботу команди, коригуйте очікування щодо темпів прогресу й бажаного підходу. 8) Плануйте функції відповідного розміру. Функції, що будуть додані в найближчому майбутньому (у наступні кілька ітерацій), необхідно розбивати на відносно невеликі користувацькі історії - переважно такі, чия реалізація займає один-два дні, у будь-якому разі не більше 10 днів. Нам найкраще вдається оцінювати роботу, що має розміри приблизно одного порядку. Робота з історіями в такому діапазоні розмірів забезпечує оптимальне поєднання витрат і точності. 9) Пріоритизуйте функції. Працюйте з функціями в такій послідовності, що оптимізує загальну цінність проекту. 10) Будуйте оцінки і плани на фактах. 11) Залишайте невеликий резерв. 12) Координуйте роботу команд за допомогою випереджаючого планування. У проекті за участі кількох команд координуйте їхню роботу, використовуючи ковзаюче випереджальне планування. Заглядаючи на- перед і розподіляючи конкретні функції між конкретними ітераціями, можна створювати плани, що враховують взаємозалежність команд.”
“Сума оцінок не обовʼязково має дорівнювати оцінці великої історії.”
Фокус таймер (Focus timer) [promo]
No comments:
Post a Comment