Джефф Сазерленд - Софт за 30 дней. Как Scrum делает невозможное возможным

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

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

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

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

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

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

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

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

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

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