Планування і відстеження итеративной розробки за допомогою microsoft project, agilerussia

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

Зрештою, хто ви, менеджер по розробці, як не експерт з планування, нехай навіть гнучкому? Множити оцінки на 2 може калькулятор. Не довіряти розробникам, а також смикати їх з будь-якого приводу може будь-хто, кому за чесну зарплату нічим зайняти себе в робочий час. "Головняк" обіцянок термінів, виданих після багатозначної паузи, витраченої на роздивляння стелі, і смиренної готовності до неминучого викликом на килим до керівництва в разі зривів термінів можна повісити на дівчину без нервів з посадою адміністратора проекту.

Завершую ліричний вступ. Отже, рамки даної замітки: як планувати і відслідковувати ітерації в Scrum за допомогою TFS і Project - прогнозування термінів всього проекту зараз не розглядаємо.

Що на вході?

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

Робочі елементи, які плануються на ітерацію, зберігаються в TFS чи іншої ALM, по можливості має інтеграцію з Project.

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

На які питання буде відповідь по завершенню?

Чи встигнемо ми зробити все завдання, що запланували?

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

На які питання потрібно регулярно отримувати відповіді?

Ми все ще встигаємо зробити все заплановане до кінця ітерації? Якщо так, то що конкретно і які у нас є варіанти неминучого перепланування?

А, можливо, ми запланували мало роботи, і має сенс взяти в роботу додаткові завдання? Якщо так, то скільки роботи можна взяти, щоб встигнути її зробити?

Які інструменти потрібні?

Що візьмемо в якості прикладу?

Знаю, що сектанти від Agile скажуть: і не потрібно враховувати всі ці дрібниці, адже планування всього цього, тим більше автоматизованими інструментами, схоже на розстріл виробів з гармати. Таким чином, основна теза: це складно, а тому безглуздо. А хочете побачити, як легко все ці чинники може врахувати в калькуляції Project, надавши нам чітку картину прогнозу ітерації і поточного її стану в перебігу всієї ітерації?

Отже, що я зроблю?

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

автоматичне планування

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

- то вибираємо пункт Параметри в меню Файл. у вікні Параметри Project переходимо на закладку Розклад. потім в спадному спіскеПараметри планування для цього проекту вибираємо пункт Усі нові проекти. а в списку Нові завдання пункт Автоматичне планування. після чого натискаємо кнопку OK.

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

Це досить важливий момент. Ручне планування і відстеження завдань менеджером всередині ітерації дуже трудомістким і практично безглуздо. Крім того, з цим завданням чудово справляється сама команда, обговорюючи поточний статус завдань на щоденному Scrum-зборах. оточивши дошку завдань. Ми використовуємо для цього віртуальну дошку TFS Workbench. щоранку кожен з нас розповідає іншим про статус своїх завдань, вказуючи на відповідні їм "папірці" (sticky notes) на дошці завдань, при необхідності змінюючи їх статус (взяв в роботу, завершив) і оцінку залишилися трудовитрат, відображаючи прогрес або вказуючи новою оцінкою факт недооцінки.

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

Визначаємо параметри ітерації

Тепер нам потрібно визначити параметри ітерації, які Project буде використовувати для розрахунку проекту.

Дата початку ітерації

Доступні людино-години

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

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

На панелі інструментів переходимо на основну ятати Завдання і натискаємо першу кнопку Діаграма Ганта. після чого в випадаючому списку вибираємо уявлення Лист ресурсов.

Ось як це виглядає.

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

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

Я на проекті виконую функції ролей Product Manager і Program Manager (термінологія методології Microsoft Solution Framework 3.1. По якій насправді ми "живемо", а по Scrum лише "розробляємо"), тому на ітерації я "байдикують" як всі курки з анекдоту , часто розповідаємо Scrum-тренерами. Звичайно, це не правило, іноді я беру деякі роботи на себе, але конкретно в даній ітерації на момент планування потреби в мені як виконавця не було. Тому стовпці Макс. одиниць навпроти себе я вказав 0%. Крім того, це допомагає Project відловлювати спроби призначити на мене якісь завдання ітерації помилково і виводити відповідне попередження.

Тепер перейдемо до більш складному випадку.

Ballmer Steve у нас керує групою розробки, а тому залучається до технічного співбесіди розробників, активним пошуком яких ми зараз займаємося. За статистикою, спеціально зібраній минулого ітерації, він відволікався на спілкування з претендентами в середньому на 10%. Тому грунтуючись на статистиці HR про те, що кількість бажаючих або вирішили змінити нарешті роботу на початку весни може тільки зростати, і принципі "вчорашньої погоди", мені потрібно закласти доступність ресурсу Ballmer Steve на 90%.

Але я ж ще хотів закласти в розрахунок фокус-фактор. Зазвичай тренери рекомендують фокус-фактором зменшувати кількість доступних для планування папуг, зазначених в story points. Але для цього їх потрібно спочатку порахувати, а якось ліниво: адже вище я вже передав всі дані, нехай Project сам вважає. Тому я придумав закладати показник продуктивності просто в доступність всіх ресурсів. Та ж яєчня, тільки вид ззаду. За підсумками минулого ітерації фокус-фактор склав 45%, але при плануванні цієї ітерації ми вирішили стандартним чином спробувати змусити себе трохи краще фокусуватися на цілях ітерації, а тому заклали фокус-фактор в 50%. Таким чином, Ballmer Steve, якого ніхто не відволікає, особливо я, доступний на ітерації на 90%, але все з них за прогнозом "вчорашньої погоди" з невеликою доданою оптимистичностью він буде "доступний" тільки на 50%. Разом, отримуємо 45%.

З точки зору вкладу в роботу по даній ітерації Gates Bill просто стахановец, відповідно, повністю "доступний" з урахуванням фокус-фактора на 50%.

Завантажуємо робочі елементи

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

Проте, краще завантажувати завдання безпосередньо з самого Project. В цьому випадку закладені "доступності" ресурсів будуть автоматично проставлені в стовпець Назви ресурсів за всіма завантаженим завданням, інакше доведеться проставляти вручну. Подробиці див. В статті Створення плану Microsoft Project з робочих елементів Team Foundation.

Все, я передав Project для калькуляції всі необхідні в цьому конкретному прикладі дані, тепер його пора прийти на допомогу. Переходимо на закладку Ресурс. тиснемо кнопку Параметри вирівнювання і у вікні, вказуємо параметри розрахунку. Тиснемо кнопку OK. і натискаємо на панелі інструментів, мабуть, саму магічну кнопку в Project - Вирівняти все. При цьому Project обчислює такі дати завдань, при яких дотримуються всі задані раніше параметри, взаємозв'язку завдань в TFS, а також бажання швидше все встигнути при нормальному завантаженні всіх ресурсів. Ось навіть Project за замовчуванням шанує трудовий кодекс.

Project справляється з розрахунком в частки секунди, після чого знову починаються мої муки. Зазвичай все-таки на ітерацію планується "на око" більшу кількість роботи, чим зможе осилити команда в нормальному темпі роботи. Хоча буває і зворотне. Відповідно, дата завершення всього проекту спливає за дату закінчення ітерації або встає як укопана за кілька днів до неї. Переходимо на закладку Форма т панелі інструментів і встановлюємо переключательСуммарная завдання проекту. після чого відобразиться коренева завдання, по столбцуОкончаніе якої можна відразу бачити розраховану дату закінчення всіх робіт. Як наслідок, мучимося над питанням, що можна викинути з перевантаженої або додати в недовантажених ітерацію.

Крім того, буває, що при плануванні відразу ж прогнозується, хто і які завдання буде виконувати. Всі розуміють, що протягом ітерації найпріоритетніше завдання може схопити будь звільнився член команди. Тим не менш, є "улюблені" і "нелюбимі" завдання, є експерти та інші варіанти індивідуальних бажань або небажань забрати конкретні завдання. Звичайно, ідеальним варіантом було б призначати всі завдання на один і той же ресурс, наприклад, керівника групи розробки: в момент планування це означає призначення завдань команді, а не конкретним виконавцям - протягом ітерації члени команди розбирають завдання самостійно або на прохання керівника групи розробки. В цьому випадку ресурсу Ballmer Steve я просто б проставив "доступність", рівну сумарній доступності всіх членів команди. Але так зробити виходить не завжди, в результаті, доводиться враховувати в тому числі і індивідуальне навантаження кожного ресурсу. На панелі інструментів переходимо на основну ятати Завдання і натискаємо першу кнопку Діаграма Ганта. після чого в випадаючому списку вибираємо уявлення Графік ресурсів.

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

Ось, власне, і все.

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

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

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