Я работаю в аналогичном магазине. Как отмечали другие, то, что вы описываете, может быть гибким, но не бесполезным. Я также добавил бы, что имеет ли смысл возвращать журналы и спринты, зависит от того, будет ли это новая работа или техническое обслуживание и постоянная поддержка. Если первое, то подход с водопадом будет иметь больше смысла для команды из одного человека. Если нет, с точки зрения премьер-министра, то, что они делают, кажется хорошим подходом, если в их портфеле несколько проектов.
Для ловких энтузиастов простое упоминание об использовании водопада является кощунством. Но люди должны использовать здравый смысл.
Позвольте мне привести пример из недавнего моего проекта. Я возглавлял команду из 3 разработчиков на агрессивной 5-месячной шкале времени, чтобы перепроектировать два главных веб-сайта. У нас были ежедневные фуршеты. Но это был водопадный проект, потому что это была небольшая команда, ограниченный жизненный цикл, и все разработчики были краткосрочными подрядчиками, приверженными проекту только до запуска. Проект следовал за очень традиционным жизненным циклом водопада. Абсолютно ничего плохого в этом нет. За исключением того, что мы работали «гибким» образом, мы проводили постоянные встречи и сохраняли лучшие практики гибкой разработки. Наша небольшая команда была освобождена от еженедельных встреч по планированию спринта. Почему? Потому что у нас не было еженедельных развертываний. И наша команда не зависела и не влияла на работу, выполняемую любой другой командой. На самом деле мы работали практически автономно. После запуска веб-сайтов мы перешли к быстрому процессу непрерывного обслуживания и поддержки. Другие разработчики сейчас работают в других местах. Все улучшения планируются в соответствии с периодическими развертываниями.
Дело в том, что лучше использовать процессы, которые наиболее разумны для размера, сложности и зрелости каждого проекта. Если вы проводите много исследований, то сложно сделать оценку на следующие пять месяцев, поэтому гибкая версия, вероятно, лучше, чем водопад.
Отчасти проблема в том, что некоторые люди думают, что вы сможете заранее спланировать следующие пять спринтов. Это было со мной раньше. Вы не должны планировать более двух спринтов, потому что если вы это делаете, то вы побеждаете всю цель иметь спринты. Предполагается, что спринт - это обязательство предоставить реалистичное количество улучшений в течение заданного промежутка времени. Вы не должны совершать то, в чем вы не уверены. Планирование спринта по своей природе является краткосрочным планированием, но это своего рода точка. Если у вас есть долгосрочный график, подумайте о том, чтобы разбить вещи на более мелкие результаты. Или настройку встреч контрольных точек в зависимости от того, где вы находитесь в SDLC.
Планирование спринта должно быть реалистичным обязательством относительно того, что гарантированно будет выполнено в течение определенного периода времени. Если вы обнаружите, что планирование не учитывает неизвестные переменные, возможно, вам следует начать давать диапазоны или пессимистические оценки. Или, как другие предложили, используйте сюжетные очки. Спринты также не должны быть забронированы полностью, чтобы учесть проскальзывание и другие важные задачи, которые возникают.