Перейти к содержимому

Процессы

В этом разделе собраны материалы о гибкой разработке, составе команд, продуктовых ставках, ограничениях проектов и измерении эффективности ИТ-процессов.

  • Agile-манифест - Русскоязычный текст Agile Manifesto: четыре ценности и 12 принципов гибкой разработки.

  • Типы команд веб-разработки - Четыре формата команды веб-разработки - соло, диада, триада, спецназ - и bus factor как ключевой критерий устойчивости при выборе состава.

  • Фреймворк GIST — планирование через цели, банк идей, короткие проверочные этапы и задачи.

  • Матрица Impact–Effort — первичная сортировка продуктовых идей по ожидаемому влиянию и усилиям с оговорками о границах метода.

  • Dual-Track Agile — Параллельная работа над тем, что стоит создавать, и выпуском надёжного продукта: Discovery, Delivery, риски и связь с непрерывным исследованием.

  • ФФФ — управление проектом с фиксированными сроком и бюджетом и адаптируемым объёмом.

  • Модель Кеневина — Контексты принятия решений, выбор между анализом и пробами, примеры из разработки и ограничения модели.

  • Итерации и транзакции — Итерационный и транзакционный подходы: издержки, выбор формата по контексту и признаки выгодного перехода к итерациям.

  • Обзор — Социально-психологические процессы в командах разработки: составляющие динамики, особенности IT, диагностика и практики.
  • Модель Такмана — Этапы развития команды: Forming, Storming, Norming, Performing, Adjourning — и управление каждым этапом.
  • Project Aristotle — Исследование Google о пяти динамиках эффективных команд: психологическая безопасность, надёжность, структура, смысл и влияние.
  • Project Oxygen — Исследование Google о 8–10 ключевых поведениях отличных менеджеров: от коучинга до делегирования без микроменеджмента.
  • Бригадный формат разработки — Бригада из 3–4 человек под руководством бригадира-тимлида: состав, проектный офис, ритм работы и зоны ответственности.

Используйте материалы раздела, если нужно:

  • выбрать методологию работы под масштаб и специфику проекта;
  • оценить bus factor и риски текущего состава команды;
  • согласовать с заказчиком принципы гибкой разработки;
  • выбрать метрики процесса и проверить результат улучшений.