Джефф Сазерленд - Софт за 30 дней. Как Scrum делает невозможное возможным

В предиктивных проектах по разработке программного обеспечения организация оценивает требования и намечает дату выпуска и стоимость, затем следует обеспечить соответствие реальности планам. В Scrum-проектах команда разработки поставляет столько инкрементов функционала, сколько сможет, с учетом продуктовых приоритетов. И вы можете управлять этим процессом путем приоритезации потребностей, и каждый инкремент продукта будет работоспособен и будет соответствовать необходимому уровню качества.

Качество традиционно было переменной в сфере разработки программного обеспечения. Системы заканчивались с минимальной просрочкой срока выпуска, если качество понижалось. Однако ухудшение качества на самом деле снижает продуктивность, увеличивает стоимость и становится причиной еще б о льших просрочек. Команды отягощаются дополнительной работой по исправлению обнаруженных дефектов и ошибок, с той только разницей, что причина задержки и увеличение стоимости становятся невидимыми для вас. Сегодня качество перестает быть переменной.

Продолжаем наш пример. Вы ожидаете, что к концу десятого месяца сможете использовать весь функционал программного обеспечения. Однако в конце концов узнаете, что накопилось 48 единиц недоделанной работы, и вас это, конечно, не радует. Что делать? Просить разработчиков закончить недоделанные задачи, чтобы увеличить процент законченного для каждой строчки бэклога продукта как можно быстрее? Но мы ошибаемся, если требуем закончить работу как можно быстрее. Обычно на это уходит еще шесть месячных спринтов (48 единиц, деленные на предполагаемую скорость восемь единиц). Оставшаяся несделанная работа отражена на рис. 7.9 как пробел между работой, которая была заявлена как законченная, и аккумулированной незавершенной работой.

Рис. 7.9. Накопление технического долга по мере выполнения работы

В конечном счете команда разработки завершает часть недоделанных задач, и менеджмент признает, что продукт начинает работать. Однако вскоре пользователи принимаются жаловаться, что продукт не соответствует их ожиданиям. С этого момента незаконченная работа замораживается. Это технический долг, который ограничивает людей в эффективном использовании продукта. Начинаются звонков клиентов в службу поддержки и исправление ошибок, которое съедает наше внимание и прибыль. Хуже всего, что это может заставить пользователей искать лучшие альтернативы. Мы не получаем выгоды, которых ожидали. Технический долг прогрессивно уменьшает долговечность продукта, его предполагаемый жизненный цикл.

Предположим, команда разработки состоит из трех программистов и двух инженеров по качеству. Они применяют традиционные, предиктивные, методы. У них имеется контроль качества, чтобы посмотреть, все ли работает. Любые ошибки или дефекты обнаруживаются и возвращаются программистам на исправление. Пока это происходит, другие программисты могут написать много нового программного обеспечения поверх дефектного. Усилия по устранению изначальной проблемы теперь занимают больше времени, а усилия по исправлению сборок программного обеспечения еще больше увеличивают эти временн ы е затраты. Очень важно обнаруживать и исправлять проблемы, как только они появляются. Затем разработчики могут продолжить без усложнения проблемы и отложенных проблем при сборке.

Технический долг затуманивает прозрачность и делает решения сомнительными. Мы измеряем наш прогресс путем сравнения законченных, готовых к использованию фрагментов функциональных возможностей программного обеспечения с оставшимися необходимыми фрагментами. Мы не берем в расчет незаконченную работу. Тем не менее очень много разработчиков программного обеспечения производят незаконченные инкременты. Обычно, когда членов команды спрашивают, почему они частично закончили некоторое количество требований бэклога продукта, вместо того чтобы выбрать меньшее количество и закончить полностью, они говорят: «У нас не было времени». Мы должны обратиться к нашему Scrum-мастеру, чтобы убедиться, что такого не произойдет.

Программное обеспечение за 30 дней обеспечивает предсказуемость, контроль рисков и оптимальную ценность. Краеугольный камень этих возможностей – постоянная прозрачность. Как минимум каждые 30 дней вы можете увидеть то, что покупаете. Многие разработчики борются со старыми привычками и недостаточными профессиональными навыками, чтобы создать эту прозрачность. Есть множество разработчиков, которые переступили эту пропасть. Вам следует выбирать разработчиков и инвестировать в них, пока они не смогут надежно создавать программный продукт, или найти других специалистов, которые смогут это сделать для вас.