Довгострокове планування та спритний?

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

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

Мати бачення того, куди повинен піти проект - це ^ТМ Good Good .

Вважаючи, що саме це відбудеться, це не так.

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

- Дуайт Д. Айзенхауер

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

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

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

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

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

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

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

Добре мати план, якщо ви вважаєте його незавершеним, а не тим, що написано каменем.

Головне тут - регулярно (принаймні щомісяця) робити випуски , збирати реальний зворотній зв'язок від користувачів та оновлювати план на основі цих відгуків.

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

Якщо припустити, project-managementі agileви мали на увазі Scrum, це був би не точний шлях.

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

А Sprintможе бути не більше місяця, коли Teamзобов’язується довести Sprint Backlog Itemsстатус до Done.

DoneТут є важливим словом, і кожен з них Scrum Teamповинен мати одне визначення виконаного, тобто там, де не залишилося виконати роботу. Коли Sprint Backlog Itemбуде Готово , це означає , що документація аналізу, архітектури та технічного написано, і що ця функція була ретельно протестована (юніт - тести, інтеграційні тести, функціональні тести ...).

Після того, як Product Backlogє місце, і Елементи мають пріоритет із менш важливими характеристиками донизу, а найважливіші зверху, Команда (розробників) визначає, скільки часу має Product Backlog Itemтривати розробка кожного з урахуванням власного досвіду. Саме тут ви можете визначити, що проект потребує повного року роботи. Вважайте, що тількиProduct Ownerповинен визначати пріоритетні позиції, оскільки саме він відповідає за рентабельність інвестицій, або ще знає, що є найважливішим для кінцевого споживача. Крім того, Команда повинна оцінити час, необхідний для повноцінного розвитку функції, хоча тут і там можуть бути багаторазові фрагменти коду, які могли б відповідати потребам цієї функції, тобто, щоб уникнути подальшої складності та бути впевненим, що предмет не повинен займати довше, ніж вимагає команда. Блокування продукту не повинно бути ідеальним! На цьому етапі процесу достатньо простого перерахування історій користувачів, які ми можемо подумати про розробку системи.

Саме під час Sprint Planning Meetingцього Команда бере на себе зобов'язання щодо того, що буде розроблено для наступного Sprint, отже, створивши Sprint Backlog. Sprint BacklogСкладається з підмножини , грунтуючись на Product Backlog Itemsтому , що Teamкоммітов повинні бути зроблені в кінці спринту. Враховуючи, наприклад, Блокування продукту з 50 предметів, і всі 50 предметів потребує року, тоді команда може захотіти вибрати, скажімо, 5 предметів із Блоку продукту, і створити Блоки спринту з цими 5 предметами. Ці 5 предметів при необхідності можуть бути розширені / підірвані до кількох інших предметів, завдяки чому Команда може змінити свою думку після перегляду та взяти на себе зобов’язання зробити лише 4 Предмети з 5 раніше вибраних предметів із Блоку товарів.

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

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

Саме під час того, Sprint Review Meetingколи Product Ownerпотрібно викликати, Teamдемонструє те, що було зроблено під час спринту, і де йому потрібно розповісти, чому він не зробив, якщо це застосовано, усієї роботи, яку він доклав. Після цього скасований твір повертається у Product Backlogта доступний для наступного Sprint. Впевнені, що ці нерозроблені товари будуть включені до наступного спринту, якщо інше не сказано власником товару, якщо ціль змінилася. Але найголовніше, хоч мета системи змінювалася під час спринту, не перебивайте її, якщо це абсолютно не потрібно. Тільки Власник продукту має повноваження перебивати спринт.

Після Sprint Review Meetingзакінчення, який повинен тривати не більше 4 годин щомісяця спринт (якщо я правильно пам’ятаю), саме час дістатися до Sprint Retrospective Meeting. Sprint RetrospectiveПотрібно для Teamстатися так , що він може обговорювати, в присутності Scrum Master і власник продукту ( по бажанню) , що пішло не так, як Scrum команда може поліпшити свою продуктивність і т.д. , і привести відповідні корективи.

Коли час Sprint Retrospectiveзакінчиться, для нового Sprint Planning Meetingпланується наступний Sprintі створити новий Sprint Backlog.

Пам’ятайте, Teamвідповідальний за підтримку, Daily Scrumяка проводить 15-хвилинну нараду, на якій кожен член команди відповідає на три питання (не в такому конкретному порядку):

1. Що ти робив з моменту останнього щоденного скраму?
2. Що ви плануєте зробити до наступного щоденного Scrum?
3. З якими проблемами чи перешкодами ви стикалися з часу останнього щоденного скраму?

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

Майстер Scrum несе відповідальність за дотримання Правил Scrum з боку інших членів команди Scrum (Майстра Scrum, власника продукту та команди).

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

Якщо вам потрібна додаткова детальна інформація про розробку програмного забезпечення Scrum і Agile, зверніться до Scrum.org та їх посібника з Scrum .

Ну, це цілком відповідь! Я сподіваюся, що це, принаймні, допоможе вам в управлінні вашими проектами.

РЕДАКТИКА №1

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

1. Я думаю, ви повинні мати стільки пусків, скільки зможете. Єдиний реальний зворотній зв'язок / показник прогресу в розробці програмного забезпечення - це код, розгорнутий у виробництві. Отже, який би процес ви не використовували, чим частіше ви розгортаєтеся в прямому ефірі, тим більш гнучким стаєте. Тобто, ви отримуєте реальний відгук від реальних користувачів раніше і можете адаптуватися раніше.

2. Хоча вам не слід робити великий дизайн вперед , я думаю, що добре думати про велику картину щоразу, коли ви збираєтесь відрегулювати та поповнити відставання, як для Scrum (для наступного спринту), так і для Kanban / flow (коли є місце в межах WIP). Якщо врахувати ціле (товар, послугу тощо), то простіше врахувати, які робочі предмети отримають вам більше цінності.

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

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

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

Ти повинен:

1. Майте генеральний план (бажано без доданих термінів), який буде розвиватися по мірі руху.

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

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

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

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

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

Джим

Додамо сюди коротку форму моєї антигізійної ренти.

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

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

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