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

С чего начать: Scrum или Kanban? Что лучше: одно-, двух- или четырехнедельные итерации спринта? Итерации или спринты? Должны ли мы использовать Jira, Trello, VersionOne или Monday.com? Должны ли мы описывать работу в пользовательских историях или в заданиях, которые необходимо выполнить? Наш технический долг вышел из-под контроля — сработает ли закалка спринта? Можем ли мы использовать скорость для измерения улучшения?

Мне задавали (или задавали себе) некоторые из этих и других вопросов раньше. Я уверен, что вы сталкивались с одними и теми же историями снова и снова (обычно в LinkedIn!), и мне потребовалось много времени, чтобы понять, что все это на самом деле не имеет значения. .

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

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

Это не совсем так. Эти ответы не помогут.

Видите ли, все эти и подобные им вопросы сосредоточены на структуре. Они сосредоточены на инструментах торговли. Ответы на эти вопросы кажутся привлекательными, потому что у них есть реальные ответы, с которыми могут помочь другие люди. Другие люди (или даже вы сами) могут сказать: «Это сработало» или «У меня был отличный опыт с этим».

Ответы на эти вопросы кажутся привлекательными, потому что у них есть реальные ответы, с которыми могут помочь другие люди.

«Если я реализую эти ответы», — думаете вы. «Я буду создавать отличное программное обеспечение», и если вы не создаете отличное программное обеспечение, то вы думаете, что, вероятно, неправильно используете Scrum (или канбан, или пользовательские истории, или что-то еще).

Некоторые ответы на вопросы будут когда-нибудь полезны. Они просто бесполезны сейчас.

Эти вопросы и ответы на них сосредоточены на том, «как делать». Они полностью упускают из виду «что делать».

— Но мы знаем, что делать!

Вы не *знаете*. Во всяком случае, еще нет. Вы думаете, что знаете, но вы *на самом деле не знаете*.

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

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

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

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

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

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

«Но как нам улучшить наш процесс?»

Постепенно. Что бы вы ни выбрали в первую очередь, или что вы делали в первую очередь, просто исправьте это постепенно. Никто во всем мире не «делает Scrum» так, как Scrum был задуман. Это невозможно. Каждая компания, каждая команда, каждый сотрудник части программного обеспечения, ситуация и инфраструктура доставки различны. Просто выберите одну из своих проблем и исправьте ее. Затем выберите следующий и исправьте его. Вы не замените старую систему отопления, снеся дом и построив замок.

Итак, перестаньте беспокоиться о том, верна ли ваша структура, или будет ли вы более успешными, используя канбан вместо Scrum или #noEstimates вместо Story Points, и начните беспокоиться о том, удовлетворяете ли вы потребности своих пользователей.

Так вы добьетесь большего успеха.