4 анти-паттерна Scrum, которые приводят к техническому долгу, и что вам следует делать вместо этого
Позвольте мне сразу уточнить одну вещь: Scrum сам по себе не вызывает технического долга. Однако немногие компании делают Scrum правильно. В результате многие реализации Scrum приводят к значительному техническому долгу.
Все четыре антипаттерна, порождающих технический долг, описанные в этой статье, широко распространены, что основано на моем личном опыте работы и консультирования во многих компаниях.
Почему некоторые реализации Scrum непреднамеренно создают огромную техническую задолженность, а другие - нет? Что мы можем сделать, чтобы этого не произошло?
Прежде чем мы углубимся в это, давайте сначала определим технический долг. Затем я подробно остановлюсь на том, почему определенные реализации Scrum приводят к возникновению технического долга, и что мы можем с этим сделать.
Что такое технический долг?
Лучшее объяснение технического долга, с которым я столкнулся, было сделано Хенриком Книбергом в его статье Хороший и плохой технический долг (и как помогает TDD):
«Думайте о техническом долге как о чем-то в своем коде, которое замедляет вас в долгосрочной перспективе. Трудночитаемый код, отсутствие автоматизации тестирования, дублирование, запутанные зависимости и т. Д. »- Хенрик Книберг
Однако он также утверждает, что стремление к нулевому техническому долгу также замедлит вас. Удивительно и нелогично, правда?
Вот как это объясняет Книберг:
«Подумайте о своем компьютере и столе, когда вы что-то создаете. У вас, вероятно, есть повсюду разные вещи: старые кофейные чашки, ручки и заметки, а на вашем компьютере открыты десятки окон. Беспорядок, не так ли?
Представьте, что вам нужно постоянно содержать рабочее место в чистоте - каждый раз, когда вы нарезаете овощ, вам нужно чистить и заменять нож. После каждого мазка нужно чистить и заменять кисть. После каждого музыкального дубля вы должны отключить инструмент и положить его обратно в футляр. Это замедлит вас и полностью убьет вашу креативность, поток и продуктивность.
Фактически, «беспорядок» - это то, что позволяет вам поддерживать ваше состояние потока - все ваши рабочие материалы всегда под рукой ».
Что бы мы ни делали, мы всегда будем устраивать беспорядок. Это так же неизбежно, как попытка уйти от второго закона термодинамики. «Свежий» беспорядок неизбежен для сохранения потока и эффективности работы. Это «старый» беспорядок, который снова и снова преследует нас в виде технического долга.
Важно помнить следующее: мы всегда будем создавать беспорядок. Это и хорошо, и плохо, в зависимости от того, когда мы решим заняться этим.
Теперь, когда мы обсудили, что такое технический долг, давайте обсудим различные анти-паттерны Scrum, которые порождают технический долг, и то, что мы должны делать вместо этого.
Антипаттерн 1: оценки разработчиков исключают исправление технического долга из оценок
Что обычно бывает
Вы находитесь в стадии доработки, и команда Scrum дает оценку. За исключением того, что они не принимают во внимание время, необходимое для устранения технической задолженности. В результате технический долг вашего продукта со временем увеличивается, потому что они никогда не дают себе времени на его устранение.
Технический долг - это то, что команда обрабатывает позже, визуализируя его в бэклоге продукта. Затем команде нужно убедить product owner-а не удалять его и сделать его приоритетным. Под постоянным давлением со стороны заинтересованных сторон владелец продукта лишает его приоритета или даже закрывает его, поскольку есть более важные вещи, над которыми нужно работать.
Неужели так должно быть?
Что мы должны делать вместо этого
Как владелец продукта, я ожидаю, что разработчики дадут оценки, которые включают исправление технического долга. Я прямо прошу их включить технический долг. Во время доработки я буквально говорю команде Scrum следующее:
«Когда вы готовите, уборка на кухне - это часть работы. Повар никогда не спрашивает разрешения убрать кухню. Он идет вместе с работой. Если вы не будете убирать кухню в какой-то момент, вы больше не сможете готовить из-за скопившегося беспорядка. Вам не нужно мое разрешение, чтобы исправить технический долг. Дайте вашу оценку, которая включает исправление любого применимого технического долга. Мне даже не нужно знать ».
Обычно я не задаю вопросов. Иногда я поступаю так, потому что то, что я ожидал, будет легким, оказывается трудным. Тогда я хочу понять, почему, потому что, возможно, мы сможем уменьшить масштабы, чтобы что-то выпустить быстрее. Мне также нужно знать о значительном техническом долге. Возможно, наша техническая реализация слишком сложна, в то время как в начальной версии мы можем справиться с меньшим объемом трафика.
Технический долг - это не то, что мы ставим в приоритет отдельно в отставании по продукту, если только мы не находимся в такой ужасной ситуации, в которой мы должны.
Суть Scrum - это способность регулярно приносить пользу. Если технический долг мешает вам создавать приращение продукта каждый спринт, значит, вы не способны выполнять Scrum. Следовательно, контроль вашего технического долга жизненно важен для успеха в Scrum.
Антипаттерн 2: мы должны завершить все в нашем спринте
Что обычно бывает
В конце спринта вся команда испытывает стресс. Все беспокоятся, что мы не сможем закончить все на нашей тарелке. Наши заинтересованные стороны и владелец продукта будут разочарованы и рассержены. Что показывать на обзоре спринта? Каждый прилагает дополнительные усилия, чтобы закончить как можно больше. Тем не менее, мы все еще терпим поражение.
Это происходит потому, что наши оценки всегда будут ошибочными. Независимо от того, что мы делаем, оценки основаны на ограниченной информации: заранее известном. Следовательно, ваши оценки неизбежно окажутся неверными. Такова природа сложной работы: вы не знаете того, чего не знаете.
В результате у нас часто будут спринты, в которых мы обречены на провал с самого начала. За исключением того, что мы осознаем это только где-то во время спринта, часто ближе к концу, когда наши степени свободы ограничены. Независимо от того, насколько усердно мы работаем, мы не сможем выполнить все элементы невыполненной работы за спринт. Период.
За исключением того, что есть команды, которые все еще могут довести все до конца в спринте. Как они это делают?
Они достигают этого, срезая углы и создавая технический долг. Наши заинтересованные стороны и владелец продукта заметят незавершенные элементы бэклога, но они заметят технический долг и более низкое качество только тогда, когда будет слишком поздно - как лягушка, которая медленно нагревается, пока вода не закипит.
Что мы должны делать вместо этого
Гибкий способ работы требует гибкости. Нам нужно иметь возможность корректировать наши планы и действия на лету, в том числе в зависимости от того, приносят ли они ожидаемые результаты.
Предпосылкой для такой гибкости является наличие четкой всеобъемлющей цели. Чего мы пытаемся достичь и почему? Что сейчас важнее всего?
Когда у вас мало времени, вы вынуждены делать выбор. Когда целью является выполнение всего в спринте, тогда нет свободы принимать решения. Все одинаково важно.
Когда вы занимаетесь Scrum, вам нужно как минимум три вещи:
- Четкая и всеобъемлющая цель каждого спринта, называемая S print Goal. Цель спринта должна объяснять, чего мы пытаемся достичь и почему.
- Гибкость в плане спринта
- Гибкость в масштабе спринта
- Гибкость в отношении объема отдельных элементов бэклога спринта
Помните, что после запуска спринта исправлено следующее:
- Время - Продолжительность спринта.
- Качество - определение «сделано»
- Ресурсы. Добавление людей во время спринта часто невозможно и обычно замедляет работу.
Когда эти оценки не соответствуют действительности, ваши планы неточны. Чтобы реагировать без ущерба для качества, необходима гибкость в масштабах.
Антипаттерн 3: мы должны увеличить скорость
Что обычно бывает
Многие команды Scrum оцениваются по их скорости. Основное убеждение заключается в следующем:
Более высокая скорость = больше усилий, затрачиваемых на предоставление функций = больше ценности
В результате команда сокращает углы или искусственно завышает числа для увеличения скорости. Результатом является заблуждение, которое делает заинтересованные стороны и руководство счастливыми, не достигая при этом ничего, кроме как подрывая ваши усилия по предоставлению как можно большей ценности.
Что мы должны делать вместо этого
Ваш клиент не обращает внимания на затраченные вами усилия. Им наплевать, сколько работы вы вложили. Их волнует только то, насколько результат вашей работы помогает им в достижении их целей.
В этой статье ~ 2300 слов. Можете ли вы судить о его качестве по количеству слов? Представьте, что я пишу статьи объемом 8000 слов за один месяц и 3000 за другой. В каком месяце я работал лучше?
Слова имеют значение только в той степени, в которой они находят отклик у вашего читателя. Больше слов не значит больше ценности. Точно так же выполнение большего количества элементов невыполненной работы спринта с точки зрения усилий неважно.
Ваши усилия показывают только то, насколько они важны для вашего клиента.
Антипаттерн 4: Слабое, отсутствующее или несогласованное определение готовности
Что обычно бывает
Многие команды Scrum имеют слабое, отсутствующее или несогласованное определение готовности. Определение готовности - это контрольный список качества, которому должна следовать команда Scrum. Это делает очевидным то, что когда что-то «сделано», это означает именно это.
Когда у Scrum-команды слабое определение готовности, например, за исключением приличного уровня тестирования, это означает, что вы будете производить технический долг каждый раз, когда работа будет завершена. Некоторые команды даже не определяют определение «Готово», а другие записывают его, но никогда не используют его в качестве контрольного списка, прежде чем переместить элемент в «Готово». Оба случая дают один и тот же результат: технический долг.
Но, безусловно, наиболее распространенной проблемой является вера в то, что каждой команде Scrum разрешено устанавливать собственное определение готовности. Эта воспринимаемая свобода полностью ложна. Если несколько команд Scrum работают над одним и тем же продуктом или организация установила стандарт качества для команд, то все команды Scrum должны, по крайней мере, следовать одному и тому же определению готовности. Цель этого общего определения «Готово» - сделать их совместную работу потенциально выпускаемой.
Что мы должны делать вместо этого
- Если организация устанавливает стандарт качества, то все команды Scrum должны, как минимум, следовать этому стандарту. Отдельные команды Scrum могут изменить свое определение готовности, сделав его более строгим, при условии, что стандарт организации является базовым.
- Если одна или несколько Scrum-команд работают над одним и тем же продуктом, тогда все команды, работающие над этим идентичным продуктом, должны как минимум определить определение готовности, которому они все должны следовать. То же самое относится к определению готовности, установленному на организационном уровне - отдельные команды могут применять более строгие критерии.
Даже если вы не станете жертвой этих антипаттернов, технический долг неизбежен.
Технический долг воспринимается как нечто грязное. Однако работали ли вы когда-нибудь над системой без каких-либо технических долгов? Вы когда-нибудь работали над системой, разработчики которой говорили: «Ух ты, разве этот код не потрясающий и с которым приятно работать!»
За десять лет создания программных продуктов я ни разу не слышал, чтобы ни один разработчик спонтанно произносил эти слова вслух. Жалобы на техническое качество системы кажутся универсальными, независимо от ее состояния. Однако есть разница между периодическими жалобами и постоянными жалобами типа «мы не можем работать над этим продуктом» .
Техническую задолженность нельзя предотвратить любой ценой. Это то, чего нельзя полностью предотвратить. Основная проблема в том, что программное обеспечение создается в определенном контексте. Тот, кто проверяет код, не имеет одинакового контекста и может иметь в своем распоряжении другую (и лучшую) информацию. При просмотре кода через их призму сделанные выборы кажутся неоптимальными, хотя в то время они могли считаться оптимальными.
Может случиться и обратное. Некоторые варианты позже будут сочтены неоптимальными, но на самом деле они оптимальны. Те, кто судит об этом сейчас, не имеют достаточного контекста, чтобы понять, почему этот выбор имел смысл в то время. Иногда разработчики могут даже усугубить ситуацию, отменив этот выбор, потому что они недостаточно понимают предметную область или то, что делает продукт. К сожалению, люди, которые это сделали, часто уже покинули компанию.
Сторонники Скрама будут утверждать, что эти команды, создающие технический долг, не занимаются Скрамом. Это просто повод не смотреться в зеркало и не видеть, что мы можем сделать лучше. Распространено непонимание Scrum. Слишком легко указывать пальцем, не видя, что мы можем извлечь из этого.
Scrum дает самоуправляемой команде огромные возможности для контроля своего технического долга. Разработчики несут ответственность за выполнение работы, а также за оценки (если применимо). Если исправление технического долга является частью работы, то это подпадает под их юрисдикцию. Они решают, как будет выполняться работа. Если непредвиденное поднимает свою уродливую голову и увеличивает сложность, тогда самоуправляемая команда Scrum имеет гибкость в отношении объема, чтобы достичь цели спринта.
Есть одно предостережение по поводу вышеизложенного: владелец продукта несет ответственность за максимизацию получаемой ценности. Излишняя инженерия или устранение слишком большого технического долга в краткосрочной перспективе может привести к снижению стоимости. Следовательно, между владельцем продукта и разработчиками необходима здоровая напряженность, чтобы принять наилучшие компромиссные решения.
Владелец продукта должен поговорить со своей командой о техническом подходе, чтобы понять, какие компромиссные решения были приняты. Стоимость обслуживания и время вывода на рынок являются важными факторами, влияющими на получение ценности.
Чрезмерная техническая задолженность в Scrum-командах должна быть редкостью. Однако многие команды Scrum становятся жертвами этих антипаттернов, и поэтому это довольно распространенное явление. Технический долг никогда нельзя полностью устранить, но вам нужно контролировать его, чтобы он находился на приемлемом уровне.
Быть гибким и предсказуемым, а также реагировать на изменения становится невозможным при наличии достаточного технического долга. Работая в таких условиях, нельзя быть гибким. Когда вы используете дисциплинированный Agile-фреймворк, такой как Scrum, управление техническим долгом - это комплексная сделка. Без скрама и регулярного предоставления ценности не будет.
