В водопадной парадигме количество работы со временем может увеличиваться.
Источников такого прироста чаще всего два:
- Обнаруженная ценность. Она же пресловутый Scope creep. Когда на старте мы (или заказчики) не знали, что нам это нужно. Но нам это нужно. И заказчики в ходе проекта постоянно вспоминают, что они хотели что-то ещё. Это абсолютно нормально, нельзя заранее предусмотреть всё, даже имея бесконечное время на анализ. Просто так мир и люди устроены. А значит срок спланировать точно в начале проекта мы не сможем.
- Накопление ошибок и сложности интеграции. В водопадной модели дефекты обнаруживаются после разработки, в процессе уже тестирования. И заранее знать сколько их там, и что мы обнаружим когда перельёмся на прод — невозможно. Очень хочется сказать, что мы прошли этапы анализа и разработки, и проект закончен на 2/3, но поговорка «не так страшны первые 90% проекта, как вторые 90% проекта» содержит слишком много правды.
На картинке из книги Vasco Duarte “NoEstimates” пример такой ситуации в проекте, использующем Rational Unified Process. Как вы видите, количество дефектов растёт в течение всей фазы разработки и большей части фазы тестирования. И точно спрогнозировать время проекта в такой ситуации крайне сложно, ведь вся эта работа таит в себе множество нюансов и скрытых связей. Начиная чинить баги, мы можем плодить новые или ломать уже работающий функционал. Эта проблема вшита в водопадную модель.
Потому в Скраме и есть требование подготовки функционала, потенциально готового к релизу, и жёсткого соблюдения Definition of Done. Готовый к релизу инкремент должен быть протестирован, а дефекты устранены. И только после этого можно засчитать прогресс.
“Работающий продукт — основной показатель прогресса.” – Agile Manifesto
Источников такого прироста чаще всего два:
- Обнаруженная ценность. Она же пресловутый Scope creep. Когда на старте мы (или заказчики) не знали, что нам это нужно. Но нам это нужно. И заказчики в ходе проекта постоянно вспоминают, что они хотели что-то ещё. Это абсолютно нормально, нельзя заранее предусмотреть всё, даже имея бесконечное время на анализ. Просто так мир и люди устроены. А значит срок спланировать точно в начале проекта мы не сможем.
- Накопление ошибок и сложности интеграции. В водопадной модели дефекты обнаруживаются после разработки, в процессе уже тестирования. И заранее знать сколько их там, и что мы обнаружим когда перельёмся на прод — невозможно. Очень хочется сказать, что мы прошли этапы анализа и разработки, и проект закончен на 2/3, но поговорка «не так страшны первые 90% проекта, как вторые 90% проекта» содержит слишком много правды.
На картинке из книги Vasco Duarte “NoEstimates” пример такой ситуации в проекте, использующем Rational Unified Process. Как вы видите, количество дефектов растёт в течение всей фазы разработки и большей части фазы тестирования. И точно спрогнозировать время проекта в такой ситуации крайне сложно, ведь вся эта работа таит в себе множество нюансов и скрытых связей. Начиная чинить баги, мы можем плодить новые или ломать уже работающий функционал. Эта проблема вшита в водопадную модель.
Потому в Скраме и есть требование подготовки функционала, потенциально готового к релизу, и жёсткого соблюдения Definition of Done. Готовый к релизу инкремент должен быть протестирован, а дефекты устранены. И только после этого можно засчитать прогресс.
“Работающий продукт — основной показатель прогресса.” – Agile Manifesto