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

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

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

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

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

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

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

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

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

Ось так я це зробив:

Візьміть свої основні етапи WBS і перетворіть кожен із них на корисну функцію

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

Розмір футболки - це зусилля щодо особливостей

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

Розбийте особливість на історії

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

Невеликий -> 40 балів

Це буде основою порівняння з іншими ознаками

Пов’язати зусилля з точки зору історії в усі функції

Порівняйте свою маленьку функцію з іншими функціями. Наприклад,

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

Середня особливість Y - це, мабуть, 80 очок історії. Продовжуйте це до тих пір, поки у вас немає точок історії, які оцінюються на високому рівні для всіх функцій.

Оцініть швидкість своєї команди

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

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

Знайдіть свою заплановану дату завершення

Якщо ваша команда з макетного планування спринту відчуває себе комфортно, передаючи 25 очок історії у спринті, а ваш загальний відставання схожий на 300 очок історії за золотою версією проекту Cadillac, то, схоже, ваша команда в ідеалі займе 12 спринтів або 24 тижні, щоб завершити все.

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

Це не проблема з "управлінням". Абсолютна вимога перед тим, як розпочати, мати можливість оцінити вартість та вигоду будь-якого потенційного проекту. В іншому випадку, як би хтось знав, що варто робити (чи робити)?

Тоді чому Agile?

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

Деякі ключові моменти з точки зору оцінки часу:

• Зміни вимог протягом проекту неминучі; Agile враховує це, а не робить вигляд, що змін не буде.
• Детальні технічні характеристики часто містять недоліки в дизайні, які не розкриваються до вступу в проект. Це може означати більші зміни в традиційному проекті, ніж у Agile.
• Оцінка часу, що базується на тому, "наскільки велика річ, на мою думку, це весь цей проект?" ймовірно, буде настільки ж точним, як і складання прогнозованого часу для багатьох детальних вимог.
• Головне, що призводить до хороших оцінок, - це цикл оцінювання, вимірювання та огляду - який можна застосувати до будь-якого послідовного процесу.
• Оцінка "збережена робота" буде визначатися первинними вимогами до проекту, а не деталями, тому я сумніваюся, що Agile сильно зашкодить можливості оцінити це.

Оновлення:

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

Це, безумовно, одна з найскладніших частин введення Agile

"Керівництву ще потрібні оцінки часу"

Мій підхід:

• Накладка 300%. Стара приказка на 300% корисна, коли ви знаходитесь в ситуації, коли бути справді спритним на рівні управління не відбудеться. Можливо, це не "спритний підхід", але є компромісом для цієї ситуації. Ви зможете зайти кілька разів вперед, але на це не розраховуйте!

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

• Переконайтеся, що ви співпрацюєте над виконаними функціями та якістю з управлінням, щоб вони насправді приймали ці рішення

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

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

• Оновлюйте своє резюме та пов’язаний профільIn. Якщо ви не можете отримати підтримку керівництва, зробивши свою справу декілька разів, рухайтеся далі. Деякі організації не перелічать ваші аргументи, тому перейдіть до тих, які є. Називав це зайнятістю дарвінізмом;)

Я думаю, ви робите помилкові припущення щодо розвитку Agile. Гнучкість та зміни вимог буквально вкладаються в маніфест "Agile" .

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

Гнучкі (читайте: мінливі) вимоги вітаються в Agile. Зрозуміло, якщо ви запитаєте більшість розробників, вони додадуть застереження, що зміни повинні бути розумними. Попросити команду побудувати 3D-гру, а потім змінити вимоги бути "системою управління ядерним реактором" - це небагато. Але додавання, вилучення або зміна вимог в рамках проекту є цілком чудовим.

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

Простота - мистецтво максимізувати обсяг незаробленої роботи - є суттєвим.

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

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

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

Це абсолютно сумісно з Agile (або будь-якою іншою) філософією розвитку, і ваше керівництво абсолютно повинно використовувати це.

Так, спритність має деякі переваги.

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

Але все ж потрібно дати досить точні попередні оцінки.

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

І зараз я це чую.

Я чув це раніше. Я майже впевнений, що говорив це раніше:

О - Але Хау! НАКІЛЬКЕ простий смертний чоловік, такий як я, дивиться моїми очима на долю таких речей! Речі, які тільки боги можуть божественні та спрямовані. Речі, про які смертні чоловіки можуть лише мріяти в найглибших нетрях і забути до дня! О, тиранічні управлінські типи, ХОЧУ такі вимоги можуть бути задоволені !?

Використовуйте свої минулі виступи як керівництво та будьте чесними .

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

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

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

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

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

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

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

Ваш заявлений випадок - просто не спритна проблема:

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

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