Чи встановлено фіксовану дату доставки елементів «спритний» спосіб роботи?

Нам постійно кажуть, що ми будемо по-спритно працювати над новим проектом вищим керівництвом. Вони створили стенд-ап, спринт-планування, ретроспективи тощо тощо. Однак тепер вони придумали план, в якому детально описуються всі роботи, які вони хочуть, щоб ми здійснили дати з кожним елементом і знову показали дати з тим, що буде показано в кожному один. Цей план виходить на ІІ квартал 2017 року.

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

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

Це справедливе судження чи я занадто реагую на цей план !?

Існує різниця між дотриманням терміну та виконанням усіх вимог. Це як старе прислів’я "швидко, добре чи дешево, вибери два".

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

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

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

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

Давайте розглянемо різні пункти тут:

Нам постійно кажуть, що ми будемо по-спритно працювати над новим проектом вищим керівництвом.

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

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

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

ніхто не був оцінений командою розробників.

Так як же керівництво знає , що цей план є життєздатним на всіх ? У Agile робота - це переговори. Бізнес каже: нам би цього хотілося. Інженерія каже: добре, якщо припустити, що XYZ триватиме 3 тижні. У тому, що ви описуєте, немає співпраці з клієнтами. Ніяких осіб та взаємодій.

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

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

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

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

Ваш опис збігається з тим, що я вважаю вантажним культом спритним. Основна увага приділяється конкретним процесам і церемоніям, а не основним концепціям управління проектами на основі доказів. Можливо, вам пощастить ділових людей зрозуміти, якщо ви пов’язуєте це з Lean або TPS . Справжня проблема, яку вам потрібно вирішити, - це управління минулим від їхнього страху перед невідомим. Правильна відповідь керівникам - "ми не можемо сказати тобі, коли все буде зроблено, але як тільки ми почнемо надавати цінність, ми можемо будувати прогнози на основі нашого досвіду". Розробники схильні говорити такі речі, як "робиться, коли це зроблено" і "я не знаю, коли це буде зроблено". Менеджери не скажуть подібним чином керівникам, це робить їх схожими на nincompoops.

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

Якщо ви можете змусити команду розробників представити єдиний фронт, ви дійсно повинні відштовхуватися і триматися за якістю. Мій досвід полягає в тому, що керівники проектів вважають, що вихід програмного забезпечення лінійний. Тобто, кожен період X виробляє Y 'відсоток повний'. Тобто, якщо ви не «на 50% завершені» на півдорозі дозволеного часу, клаксони починають звучати. Насправді, якщо ви все робите правильно, перша функція, як правило, займає набагато більше часу, ніж 50-та функція (подібного розміру.) Якщо ви зможете пройти цей початковий кризовий період небезпеки ("що відбувається?", "Я не хочу" не бачите нічого, що буде зроблено! ") Ви, ймовірно, будете в порядку.

Ласкаво просимо в справжній бізнес.

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

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

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

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

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

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

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

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

Agile не заважає вам планувати основні етапи (наприклад, ми випустимо V 1.0 за 3 місяці), але те, що входить у кожен етап, неможливо виправити.

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

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

КОЖНИЙ відповідний бізнес-проект має обмеження:

• Час
• Ресурси
• Очікуваний мінімальний набір функцій

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

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

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

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

Як хтось уже вказував перед маніфестом:

Індивіди та взаємодії над процесом

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

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

Це пункт, де він може піти двома шляхами.

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

2. Вони все ще можуть захотіти дотримуватися власної версії проти колективної думки команди.

Якщо результат №2, то це не є спритним.

Якщо ви закінчитеся з №1, то я б сказав, що команда стоїть на правильному шляху, адже Agile - це не лише про те, як «реагувати на зміни» Devs - це ще й про те, щоб бізнес міг реагувати на зміни.

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

Якою б не була ваша відповідь, ви будете помилятися. Це воно.

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

До речі, якщо ви (як команда) приймаєте ці дати, ви там помиляєтесь.

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

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

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

Його не aglie планування немає.

Але якщо ви задумали, ви не знаєте плану і просто працюєте спринт за спринтом. Це може бути аглі працює.

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

Якщо ви працювали по-спритному, тоді план B - це, сподіваємось, демонстрація останнього спринту