МенеджментПідрозділ
Методології
Як команда вирішує, що будувати далі, у якому порядку і звідки знає, що щось завершено. Девʼять методологій — від двох, за якими більшість справді працює, до чотирьох, що існують, бо однієї команди стало замало. Кожна сторінка описує те, що фреймворк справді визначає — кожну церемонію, роль і артефакт, — а не переказує його, і прямо каже, де він перестає працювати.
Що всередині
Усі сторінки цієї групи — і про що кожна з них.
- AgileЧотири цінності й дванадцять принципів, на яких стоїть усе інше, — і те, чого вони ніколи не казали.МаніфестПринципи
- ScrumКожна подія, роль і артефакт зі Scrum Guide — включно з чотирма, які більшість команд тихо пропускає.Спринт3 ролі
- KanbanПотік замість ітерацій: ліміти WIP, сім каденцій, класи обслуговування й діаграма накопиченого потоку.Ліміти WIPПотік
- ScrumbanЩо дає збереження церемоній Scrum і потоку Kanban — і які поєднання не дають ні того, ні того.ГібридВитягування
- WaterfallМодель, яку всі згадують як помилку, описана точно, — і випадки, де вона й досі є правильною відповіддю.ФазиФіксований обсяг
- SAFeМасштаб на 50–200+ людей: чотири конфігурації, ART, PI-планування, IP-ітерація й усі десять принципів.ART50–200+
- LeSSМасштаб через прибирання, а не додавання: LeSS Basic для 2–8 команд, LeSS Huge далі, й усі десять принципів.2–8 командДескейлінг
- NexusВід трьох до девʼяти Scrum-команд на один продукт і Integration Team, чия робота — залежності між ними.3–9 командІнтеграція
- Scrum@ScaleДва цикли, що масштабуються вбік: Scrum of Scrums і Executive Action Team, — і де вони перетинаються.Два циклиГоризонтально
З чого почати
- Уперше з усім цимСпершу Agile — заради цінностей, потім Scrum — заради механіки: більшість команд працюють якоюсь його версією.
- Ваші спринти постійно переповнюютьсяПрочитайте Kanban. Спринт не завершується через незавершену роботу, а не через точність оцінок.
- Кілька команд, один продуктПочніть із Nexus для трьох–девʼяти команд; SAFe і LeSS відповідають на те саме питання на дуже різних масштабах.
Інше в цьому розділі
- МенеджментУправління IT-проєктом — це набір рішень, які перетворюють намір на випущений продукт: що будувати, як розрізати це на роботу, яку справді можна завершити, як команда організовує себе тиждень за тижнем і як результат доходить до користувачів. У розділі 21 тема у пʼяти групах — продуктовий менеджмент, декомпозиція, методології, реліз-процес і формальні фреймворки, — і кожна сторінка дає компроміс за вибором, а не переказ для сертифікаційного іспиту.
- ДекомпозиціяЯк перетворити щось надто велике, щоб почати, на частини, достатньо малі, щоб завершити, — і не загубити дорогою причину кожної частини. Чотири теми про дві традиції, що рідко зустрічаються: декомпозиція робіт із проєктного менеджменту й користувацькі історії з продуктового. Вони відповідають на різні питання, і розуміння, у якій ви зараз, знімає більшість суперечок про потрібну деталізацію плану.
- ФреймворкиДва зводи практик проєктного менеджменту, які ви зустрінете в тендерній документації, вимогах до сертифікації чи процесному посібнику клієнта. Вони не конкуренти: один є зводом знань про те, про що думати, другий — методом, що приписує, хто що вирішує. Обидві сторінки описують, що справді каже чинне видання, а порівняння між ними — це та суперечка, яку зазвичай ведуть без нього.
Було корисно?
Поділіться з тим, хто працює над тією ж задачею.