Почему «мы делаем по Agile» — это не ответ, а уклонение от вопроса 🎭
В PMBOK есть скучный пример, который на самом деле объясняет всё. Проект общественного центра: нужно запустить услуги для пожилых. Команда не пытается спроектировать сразу всё — она делает доставку питания, разворачивает, смотрит реакцию, потом добавляет перевозку, потом выездные мероприятия. Каждая услуга живёт сама по себе.
А рядом в том же центре — обучение волонтёров народной дружины: базовый модуль, логистика, патрулирование. Модули можно писать параллельно, но программа не работает, пока не собраны все три. Половина обучения — это не половина пользы, это ноль.
Вот и весь критерий, который люди годами обсуждают на конференциях. Вопрос не «мы agile или waterfall», а: имеет ли смысл кусок продукта отдельно от целого? Если да — итерации дают вам обратную связь раньше, чем вы успели ошибиться дорого. Если нет — итерации превращаются в ритуал: стендапы есть, демо есть, а показать до самого конца нечего.
Эрик Ларсон добавляет неожиданное: выбор подхода — это тоже командное решение, и его портит отсутствие спора. Сжатые сроки, желание не ссориться — и все молча кивают на «давайте по скраму». Ларсон советует назначать адвоката дьявола: пусть кто-то 15 минут доказывает, почему выбранный путь неверен. Именно тогда всплывает главное — что требования-то у нас зацементированы регламентом, и гибкость нам нужна ровно нулевая.
💡 Адаптивный подход оправдан там, где требования плывут И продукт можно поставлять кусками. Одного условия мало: плывущие требования без инкрементальной поставки — это не Agile, это хаос с ретроспективами.
❓ А в вашем последнем проекте частичная поставка приносила пользу — или ценность появлялась только в день релиза?
📚 Источники: PMI — «PMBOK Guide (7th Edition)», Эрик Ларсон — «Управление проектами. Практическое руководство»
