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

Не пытайтесь делать спринты такой длины

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

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

1. Заинтересованные лица теряют внимание и забывают о проекте.

2. Так как количество требований увеличивается, общая сложность возрастает, и процесс разработки перестает быть линейным. Чтобы управлять увеличившейся сложностью и помнить предыдущие решения, команде разработки требуется вести больше документации и средств проектирования.

3. Объем информации для обзора и изучения, а затем для принятия решений разрушает эффективность коротких Scrum-мероприятий.

В пределах проекта применяйте спринты одной длины

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

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

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

Примеры проектов Scrum-PRN

В Fidelity Investments применили Scrum в 1997 году, чтобы предоставлять интернет-услуги для своих пользователей. Чарльз Шваб и клиенты E-Trade уже управляли своим капиталом онлайн, а пользователи Fidelity – еще нет. В то время Fidelity представляла собой жесткую каскадную организацию. Многочисленные попытки по предоставлению интернет-услуг заканчивались неудачей. В отчаянии компания обратилась к Scrum. За несколько месяцев первый вариант сайта Fidelity.com был разработан и запущен, и в течение 18 месяцев инвесторы были счастливы работать с Fidelity.com, который стал не хуже решений конкурентов. Успех был достигнут, и Scrum выведен из оборота компании. Следующие семь раз, когда Fidelity критически нуждалась в разработке программного обеспечения, она создавала Scrum-проекты. Однако компания не воспользовалась всеми преимуществами, которые могла бы получить, приняв во внимание предыдущий опыт. Каждый Scrum-проект мог быть более эффективным, чем предыдущий. Тем не менее Fidelity сделала выбор – использовать Scrum только в чрезвычайных ситуациях, PRN.

Шаг на следующую ступень в организации – переход Scrum с уровня проекта на уровень студии разработки программного обеспечения. Как только студия создана, у организации появляется постоянная база для быстрого запуска Scrum-проектов по разработке программного обеспечения.

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

Студию разработки программного обеспечения иногда также называют фабрикой разработки[6], хотя фабрика предполагает выполнение повторяющейся, стандартизированной, простой работы, в то время как разработка программного обеспечения отнюдь не такая работа.

Студия – научающаяся организация

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

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

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

Менеджер студии

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

• иметь за плечами несколько лет опыта работы Scrum-мастером, менеджером в Scrum-среде;

• понимать процесс разработки программного обеспечения;