Почему спринты отнимают радость от создания программного обеспечения

Спринт — это бег с максимальной скоростью на короткую дистанцию. А что происходит после завершения спринта? Вам нужно перевести дух и отдохнуть (возможно, даже немного поблевать, если вы не в форме).

Представьте, что бегун на 100 метров делает 26 спринтов, один за другим, без перерывов.

А потом начинает еще один…

Именно так чувствует себя большинство команд разработчиков!

Но спринты — это agile!

<Напыщенная речь>

Остановитесь на этом. Давайте развеем миф о том, что «спринты лежат в основе scrum и agile-методологий». Спринты НЕ лежат в основе Agile!

Вот манифест:

Подумайте о своем последнем спринте. Чувствуете ли вы, что эти пункты — «Личности и взаимодействие важнее процессов и инструментов» и «Реагирование на изменения важнее следования плану» — сработали хорошо?

Или вы чувствуете, что все заботились о том, чтобы придерживаться процесса и это было превыше всего?

Я до сих пор не понимаю, в чем проблема.

Расскажите мне, слышали ли вы хотя бы одно из этих предложений:

• В спринте осталось всего 2 дня, так что давайте возьмем этот случайный баг вместо важной функции из следующего спринта, которая займет 4 дня.
• Давайте сделаем последний рывок, чтобы завершить цели спринта, мы же обязались ее выполнить!
• Если мы закончим спринт на 100%, это значит, что мы недостаточно выложились, 80-85% — отличный результат.
• Наша цель на спринт — «добиться прогресса в работе над функцией X»!
• ПМ: «Мы договорились, что в каждом спринте будет только 15% на технический долг, вам придется перенести это на следующий спринт».
• У нашей команды отличная скорость, вот что важно. Функции опаздывают, потому что продукт не очень хорошо их определил.
• Почему график оттока не снижается? Давайте начнем релизить вещи как можно быстрее.

А теперь остановитесь на минуту. Если бы вам пришлось задуматься об идеальном способе организации работы вашей команды, честно ли вы думаете, что выбрали бы текущий способ?

Считаете ли вы, что он приносит наибольшую пользу вашим клиентам? Думаете ли вы, что ваши инженеры действительно наслаждаются процессом, чувствуя, что они вносят свой вклад в творческий процесс?

Какова альтернатива?

На прошлой неделе я разговаривал с техническим директором очень маленького стартапа. В нем только он и 2 разработчика. Когда я спросил, как они организуют работу, он сказал:

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

Сдержите свои возражения («Нам нужно что-то пообещать клиентам! Этого нельзя делать в зрелой компании с тысячами клиентов!»).

Позвольте мне рассказать вам о Basecamp. 24-летняя компания, приносящая десятки миллионов прибыли в год. Никаких дорожных карт, никаких целей.

Я читал книгу, которую написали их генеральный директор и технический директор в книге «Не обязательно быть сумасшедшим на работе».

Для краткого ознакомления с их альтернативой спринтам прочитайте эту статью:

Если вас это заинтересует, они написали бесплатное руководство о том, как они работают, под названием «Shape Up». Фрид упоминает в своем подкасте с Ленни Рачицки, что он не советует идти напролом и менять все в своей работе — это наверняка приведет к провалу. Он предлагает начать с PoC для одного проекта и посмотреть, как все пойдет дальше.

Истории 10 успешных компаний разного размера, внедривших Shape Up, смотрите в эпизоде Shapers & Builders.

А если я не могу изменить то, как работает моя компания?

«Антон, это все хорошо и интересно, но не мне решать, как работает моя команда». Я вас понимаю. Вероятно, так думают 99% из вас, кто работает в крупных компаниях, с существующими привычками и процессами.

Тем не менее, есть много вещей, которые мы можем сделать:

• Всегда оставляйте пространство для дыхания в спринте. Я постоянно борюсь с аргументом «давайте включим это в спринт, а в худшем случае перенесем на следующий» с аргументом «давайте не будем брать это в спринт, в лучшем случае мы сможем добавить это, если у нас будет время».
• «Добиться прогресса в X» — глупая цель спринта. Не форсируйте это.
• Если кто-то закончил свои задачи, можно позволить ему работать над тем, над чем он хочет.
• Боритесь за спринты типа “качество/перерыв”. Это периоды в 2-3 недели, в течение которых люди могут что-то исправить. Даже раз в год это лучше, чем ничего.
• Думайте критически. Не соглашайтесь с практикой, в которую вы не верите, только потому, что вы к ней привыкли.
  • Ваша команда не хочет ежедневных стендап-митингов? Пропустите их!
  • Вы чувствуете, что ретро повторяются и вам нужно время, чтобы решить проблемы? Пропустите парочку из них!

</Напыщенная речь>

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

Я просто думаю, что мир программного обеспечения станет лучше, если инженерные менеджеры будут думать сами за себя и придумывать системы, которые работают в их конкретном контексте — отрасли, компании, команды.

Источник