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

Члены команды могут применять новые для них методы работы

Самоорганизация

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

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

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

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

Вот вам еще один пример. Вице-президент компании РТС по разработке программного обеспечения Сильвин Муссад работал непосредственно с Джейн Вачутка. В его подчинении находилось более 300 девелоперов ПО. Он и его менеджеры изначально считали, что необходимо распределить процесс разработки среди 50 команд. Они так и поступили и создали лучшие команды, которые только смогли. Но при этом команды оказались не очень продуктивными.

Лидеры команд сообщили Сильвину, что каждой команде была назначена цель, реализация которой в значительной степени зависит от работы других команд. Как результат 75 % времени тратилось на разрешение зависимости между командами. Иногда единственный человек, который мог сделать необходимую работу, находился в другой команде. Сильвин попросил лидеров команд обдумать более эффективный способ организации. В результате приняли решение, что во время каждой итерации лидеры станут оценивать предстоящий объем задач и определять наличие в каждой команде разработчиков, лучше всего подходящих для выполнения специфического набора заданных требований.

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

Кросс-функциональность

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

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

ВЫВОДЫ

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

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

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

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

Практика – искусство возможностей

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

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

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