Рефакторинг в Agile-разработке
В проекте разработки приложения полный объем проекта не учитывался при разработке приложения. Таким образом, частый рефакторинг кода с учетом изменений отрицательно влияет на сроки реализации проекта, что стало необходимым во время спринта. Как лучше всего это контролировать, чтобы минимизировать риск превышения согласованной даты реализации проекта, если заинтересованные стороны не хотят идти на компромисс?
Ответы
TL; DR
Частью любой структуры управления проектами, но особенно гибких структур, таких как Scrum, является необходимость постоянного управления ожиданиями заинтересованных сторон. Люди хотят того, чего хотят, и тогда, когда они этого хотят, но большая часть управления проектами объясняет людям, что они на самом деле могут иметь в рамках различных ограничений, влияющих на проект. По мере развития проекта должно быть понимание того, что в настоящее время выполнимо в рамках текущих ограничений, особенно когда то, что выполнимо, отличается от того, что изначально планировалось.
Ожидаются доработки
Рефакторинг изменяет реализацию без изменения внешнего поведения. По всей видимости, на самом деле вы не занимаетесь рефакторингом; вы выплачиваете технический долг или выполняете доработку и интеграцию, что по сути не одно и то же.
Такие фреймворки, как Scrum, рассматривают различные типы работы (включая рефакторинг и доработку) как приемлемый компромисс для эмпирического контроля и проектирования. Это обрабатывается в процессе оценки и (правильно) проявляется как замедление скорости по мере увеличения технического долга, сложности или темпа изменений. Это ожидаемо и желательно в итеративной структуре, потому что каждый цикл проверки и адаптации дает возможность изменить область действия, приоритизацию или подход.
Переделка - это цена эмпирического контроля. Вы не можете избежать этого в сложных проектах, таких как разработка программного обеспечения. Scrum просто делает доработку видимой для команды и заинтересованных сторон как стоимость внесения необходимых или желаемых изменений.
Исправлено - все невозможно
«Железный треугольник» утверждает, что вы можете скорректировать проект, контролируя бюджет, объем или график, с качеством неявным четвертым измерением, на которое влияют три других ползунка. На следующем рисунке это показано.
Agile-фреймворки, такие как Scrum, обычно рассматривают объем, и особенно объем проекта , как основной слайдер, задавая следующие вопросы:
Какой объем мы можем уместить во временные рамки одного спринта или уложиться в наш гибкий план выпуска ?
В настоящее время ваш проект пытается исправить как объем, так и график. Это оставляет только бюджет в качестве доступного слайдера. Если вы попытаетесь заблокировать и это, либо ваш проект потерпит неудачу, либо пострадает качество, либо и то, и другое. Вы просто не можете надежно установить фиксированную цену, фиксированный объем и фиксированный график в рамках любой структуры проекта при сохранении качества; Скрам просто делает его более очевидным и делает более заметными компромиссы.
Смысл Scrum не в том, чтобы волшебным образом заставить железный треугольник исчезнуть. Вместо этого он вынуждает проект (а также заинтересованные стороны и спонсоров) прийти к соглашению с присущими ему компромиссами. Scrum позволяет заинтересованным сторонам определять, «достаточно ли хорошо» что-то для отправки в конце каждого спринта, а владелец продукта получает возможность настроить объем и приоритеты во время уточнения бэклога и планирования спринта. Заинтересованные стороны должны использовать эти события как способ гарантировать, что они получат максимальную выгоду в рамках плана выпуска; это никогда не является гарантией возврата денег, что проект будет на 100% завершен или пригоден для использования в конце фиксированной серии спринтов.
Уменьшить невозвратные затраты
Еще один аспект гибкой разработки - это возможность «рано потерпеть неудачу». Когда проект может потерпеть неудачу по какой-либо причине, гибкие фреймворки, такие как Scrum, дают владельцу продукта возможность сэкономить, отменив спринт и спланировав новый на основе изменившихся ожиданий, или позволив заинтересованным сторонам отменить оставшуюся часть проекта, если он не будет служить их целям. Последнее не приведет к успеху проекта, но снизит невозвратные затраты, связанные с проектом.
Никто не может гарантировать успеха проекта. Лучшее, что вы можете сделать, - это контролировать его и как можно скорее убить обреченный проект, когда успех уже не вариант.
Что вы можете сделать сейчас
Во-первых, признайте, что вы находитесь на пути марша смерти. Если вы не согласитесь с этой правдой, все остальное не будет иметь значения.
Затем выясните, в чем проблема: дизайн, технический долг, необоснованные ожидания или что-то еще. Не имеет значения, какова первопричина или причины; вам просто нужно сделать их видимыми, чтобы команда и заинтересованные стороны могли совместно их решать.
И, наконец, общаться текущее состояние ясно. Если вы приближаетесь к полнофункциональной версии на несколько циклов позже первоначально запланированной даты выпуска, обсудите, может ли проект скорректировать вершину «времени». Если вы не можете или не хотите корректировать график, вы все равно можете уложиться в установленный срок, увеличив затраты или сократив объем. Будут ли заинтересованные стороны жертвовать своевременной доставкой на сокращение трудоемкой функции? Вы не узнаете, пока не спросите.
Если проект не может или не хочет делать что-либо из вышеперечисленного, готовьтесь к провалу. Обновите свое резюме и надейтесь, что вы извлекли ценные уроки, которые сможете использовать в своем следующем проекте или следующей работе. Прежде всего, надейтесь на то, что вы научились рано и часто сообщать о предположениях, проблемах, требованиях к структуре и компромиссах, а также осознали важность постоянного управления ожиданиями заинтересованных сторон.
Производите ли вы развертываемое приращение продукта каждый спринт? В таком случае согласованные сроки поставки уже соблюдаются, и это лучший способ минимизировать риск и вселить в клиента уверенность в том, что вы делаете. Заинтересованные стороны (через владельца продукта) должны решить, что и когда они хотят, поэтому наиболее важно, чтобы они продолжали видеть, как вы приносите пользу, и чтобы вы получали их отзывы об улучшениях, изменениях и исправлениях, необходимых для продукта. Здесь важно получить их отзывы. По понятным причинам заказчики могут быть обеспокоены тем, что сроки не увеличиваются без новых функциональных возможностей, но как только вы начнете включать последние улучшения, которые они считают приоритетными, они с большей вероятностью оценят необходимость гибкости.