Давайте проведем небольшой мысленный эксперимент.

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

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

Но сначала нужно ввести понятие спринтов.

Сравнение процесса на вашем рабочем месте

Последняя фраза, конечно, была шуткой. Будет ли кто-нибудь в здравом уме внедрять такой процесс в небольшую часть программного обеспечения, разработанного вне работы?

… Но подождите, разве индустрия обычно не говорит нам идти небольшими итеративными шагами? Чем отличается разработка чего-то для соседа от создания первой версии «минимально жизнеспособного продукта»?

Это заставляет меня задаться вопросом, почему мы вообще заморачиваемся всеми этими досками задач, записывая задачи, которые все делают в нашей повседневной работе?

Возможно это как-то связано с тем, что в проекте участвует больше людей.

Давайте пересмотрим историю соседей, на этот раз с большим количеством людей.

«Функция соседа», новая версия

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

Прогресс становится нечетким

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

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

Что-то подсказывает вам, что это был ужасный способ сделать правильный софт.

Мобильное программирование спешит на помощь

Я большой поклонник совместной работы в режиме реального времени, потому что это устраняет много ненужного микроуправления и недопонимания. Это также дает более ценные и качественные результаты.

Попробуем сейчас.

«Черта соседа», совместное издание.

После того, как сосед объяснит различные функции, о которых она думала, а также подчеркнет «убойную функцию», которую она хочет больше всего, вы приглашаете группу собираться раз в неделю. Просьба об обязательствах немедленно заставляет некоторых участников колебаться, ссылаясь на жизненные приоритеты и так далее. Остались вы и двое других, банда из четырех человек, включая соседа с запросом (она владелец продукта, если это, кстати, не очевидно).

Родится настоящая команда.

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

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

Но это не заканчивается дома.

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

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

Все дело в потоке

Вуди Зуилл — крестный отец группового программирования, но в основном он ссылается не на групповое программирование как на панацею, а на важность потока.

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

Все остальное просто склонно деградировать до напряженной работы.

Так что в следующий раз, когда вы начнете проект, вспомните историю соседей. Насколько вам нужны Jira, дорожные карты и параллельная работа над задачами, которые досаждают нашим рабочим сообществам? Вы предлагаете работать над отдельными задачами, чтобы сделать отличный продукт, или это просто потому, что вам нужно немного свободного времени, чтобы написать что-то в своем собственном темпе?

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

Краткое содержание

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

Затем забудьте все, что, как вы думали, вы знали, потому что все, что пришло в результате проверки и получения этой обратной связи, попадет на вершину вашего невыполненного задания и станет новым невыполненным заданием.

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

Я надеюсь, что это вдохновит вас попробовать что-то новое в вашей повседневной работе или, возможно, в вашем следующем личном проекте (хотя вы никогда не сойдете с ума, чтобы использовать методы работы в своем личном проекте, верно?)

Спасибо за прочтение.