Crashing
Crashing — вторая техника Schedule Compression. В отличие от Fast-Tracking, требует доп. бюджет.
Закон Брукса
«Adding manpower to a late software project makes it later» — Фред Брукс, 1975. Crashing имеет жёсткие пределы:
- Время на onboarding новых людей.
- Накладные расходы на коммуникацию (n × (n-1) / 2 каналов связи).
- Невозможно распараллелить «9 беременных женщин не родят ребёнка за 1 месяц».
Когда работает
- Задача легко делится на параллельные части.
- Новые ресурсы достаточно квалифицированы.
- Время на onboarding меньше, чем выигрыш.
Cost-Time Tradeoff
Для каждой задачи определяется crash cost per day. Crashing применяется к задачам с минимальным crash cost ratio (стоимость / выигрыш в днях).
Когда применять и когда нет
Применять
- Нужно срочно сжать сроки
- Есть бюджет на доп. ресурсы
- Задача допускает распараллеливание
Не применять
- Творческая задача (написание плана, дизайн) — не масштабируется на людей
- Бюджет ограничен — Fast-Tracking лучше
Примеры применения
Задача QA-тестирование (5 дней с 2 QA). Можно crash до 3 дней с 4 QA (доп. 2 QA × 3 дня × 50К ₽/день = 300К ₽). Если эта задача на критическом пути и проект задерживается — может стоить.
Часто задаваемые вопросы
«Adding manpower to a late software project makes it later». Закон Фреда Брукса (1975): добавление людей в опоздавший софт-проект делает его ещё более опоздавшим. Из-за времени на onboarding и роста числа коммуникационных каналов.
Ограниченно. В Agile нет фиксированного scope, поэтому «сжимать график» некорректно. Можно сократить scope (выкинуть низкоприоритетные истории) — это эффективнее crashing.