Site icon AppTractor

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Мы работаем по 6-недельным циклам. По окончании цикла мы на одну-две недели отрываемся от запланированных проектов, чтобы все могли самостоятельно побродить, починить вещи, заняться любимыми проектами, которые мы хотели сделать, и вообще отдохнуть перед началом следующего шестинедельного цикла.

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

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

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

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

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

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

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

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

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

Источник

Exit mobile version