Записаться

5.1. Команда

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

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

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

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

Характеристиками эффективных команд являются следующие:

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

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

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

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

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

5.2. Этапы командообразования

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

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

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

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

Наиболее распространенной моделью, описывающей стадии командообразования, является модель Такмана (рис. 5.1).

Рис. 5.1. Этапы командообразования

В своем развитии все команды обязательно проходят несколько этапов.

Формирование

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

Бурление

На этом этапе все члены команды отчетливо осознают свои и общие цели, задающие вектор движения коллектива. В период бурления часто возможны конфликты и противостояние между отдельными членами команды, формирование мелких группировок, поэтому особенно возрастает роль Scrum-мастера (SM) как модератора (его обязанности мы обсудим чуть позже). Этап бурления - самое время для определения формальных и неформальных лидеров Scrum-команды.

Нормализация

На этапе нормализации происходит "притирание" членов команды друг к другу. Закрепляются лидеры команды, и она начинает демонстрировать стабильные результаты деятельности. Основная задача Scrum-мастера на этом этапе - помощь команде для перехода на следующий этап.

Функционирование

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

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

Расформирование

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

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

Команду нужно держать в тонусе, но необходимо тщательно отслеживать состояние наиболее "заслуженных" работников в целях предотвращения возможных выгораний и срывов.

Организация командной работы - это очень важная часть деятельности Scrum-мастера, который своей работой должен обеспечить комфортное рабочее состояние всем ее членам.

5.3. Разработчик

Scrum-команда должна состоять из мотивированных профессиональных сотрудников. Это факт, на котором построена оптимальность данной гибкой методологии. Члены команды отвечают за разработку программного продукта высокого качества. Они должны обладать множеством различных навыков, необходимых для создания эффективного программного обеспечения:

• Бизнес и системный анализ.
• Проектирование архитектуры программного продукта.
• Программирование.
• Тестирование.
• Настройка баз данных.
• Разработка эргономичных пользовательских интерфейсов.

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

• обязательное выполнение элементов работ, включенных в текущий спринт:
  • акцент на взаимосвязанных задачах спринта;
• совершенствование личной и командной работы.

Основной движущей силой команды является ее участник, которого принято называть разработчик (Development member) - специалист, представляющий собой "ядро" Scrum. От его навыков, умения, квалификации, опыта будет зависеть дальнейшее развитие продукта и Scrum-команды. Как правило, команда, работающая над продуктом, состоит из 4-15 человек. Помимо владения теоретическими знаниями каждый член команды должен уметь практически применить следующие навыки:

• общаться с пользователями для понимания целей производимых разработок;
• собирать "правильные" требования, которые в дальнейшем можно сопоставить с ожиданиями ключевых пользователей;
• планировать дальнейшую работу над продуктом в виде его инкрементного развития;
• документировать в минимальном объеме требования;
• выполнять синтез разрозненных и противоречивых требований в единое комплексное рабочее решение;
• создавать удобный, читаемый, понятный, однозначный код ИС в целях его дальнейшего развития;
• проводить полный цикл разных видов тестирования;
• выполнять установку программного обеспечения;
• поддерживать пользователей и отвечать на любые, даже глупые, вопросы.

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

5.4. Scrum-мастер

Scrum-мастер - движущая сила Scrum-процесса. Он призван помогать команде в освоении гибкой методологии. Его роль является определяющей при внедрении Scrum. Для того чтобы Scrum получился успешным, Scrum-мастер должен обладать следующими качествами:

• быть ответственным;
• отдавать должное команде, а не личным достижениям;
• всегда быть готовым к диалогу;
• выкладываться по максимуму;
• обладать умением влиять на других;
• обладать развитым профессиональным кругозором;
• разбираться в профессиональных и технических вопросах.

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

Scrum-мастер может сказать команде: "Итак, к окончанию каждого спринта мы должны создавать программный продукт, потенциально готовый к установке. На этот раз нам не удастся создать такой продукт. Что мы можем сделать для того, чтобы подобная ситуация не повторилась в следующем спринте?". Это пример проявления власти Scrum-мастера над процессом. Если команде не удалось к окончанию текущего спринта изготовить программный продукт, потенциально готовый к установке, значит, произошел какой-то сбой в работе команды. Но поскольку власть Scrum-мастера распространяется только на процесс, то он не имеет права сказать: "Поскольку нам не удалось к окончанию текущего спринта изготовить программный продукт, потенциально готовый к отправке заказчику, я хочу, чтобы он просмотрел весь код до того, как он будет окончательно принят". Возможно, было бы не так уж плохо, если бы кто-то просмотрел весь код, но Scrum-мастер не имеет права принять такое решение, поскольку оно выходит за пределы его полномочий и вторгается в сферу ответственности команды. Scrum-мастер должен лишь контролировать соблюдение процесса командой, его роль может оказаться более трудной, чем роль типичного руководителя проекта, так как руководители проектов зачастую могут сказать: "Делайте так, потому что я так решил".

При назначении SM не рекомендуется совершать следующих ошибок:

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

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

5.5. Владелец продукта

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

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

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

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

Менеджер проекта - сотрудник, который знает, как планировать и отслеживать исполнение проекта.

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

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

Владелец продукта (Product Owner) - сотрудник, который указывает Scrum-команде ее цель и не позволяет отклоняться от нее. Указание цели происходит за счет:

• четкого определения выполняемых задач;
• установки приоритетов выполнения задач;
• повышения ценности работы, выполняемой командой;
• обеспечения видимости, прозрачности, понятности выполняемых задач, формирования понятных и непротиворечивых требований к ним.

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

• быть доступным для вопросов от членов команды;
• досконально знать профильное направление бизнеса;
• быть коммуникабельным;
• быть решительным;
• иметь определенные властные полномочия в организации.

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

5.6. Самоорганизация членов команды

Самый серьезный вызов для внедрения гибкого подхода - уметь перестроиться с привычных "рельсов" течения рабочих процессов. Каждый член Scrum-команды должен осознавать, что результат (инкремент) и эффективность команды будут напрямую зависеть от результатов его деятельности, синхронизированных с результатами деятельности остальных членов команды. Scrum поощряет развитие универсализма каждого из членов команды, но при этом должна сохраняться специализация. Для того чтобы продукт был качественным, члены команды должны быть (или стремиться к тому, чтобы стать) экспертами в профильных областях деятельности. Самоорганизация и высокий профессионализм необходимы для того, чтобы:

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

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

• критик;
• координатор;
• генератор идей;
• исполнитель;
• прочие.

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

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

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

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

5.7. Прочие члены команды

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

• Аналитики. Разделяют роль владельца продукта. Нужны для крупных продуктов и рассредоточенных команд. Действуют на стратегическую и тактическую перспективу. Их акцент смещается с документирования в сторону вербального общения.
• Руководители проектов. Разделяют роль Scrum-мастера. Нужны для организации работ и ресурсного обеспечения команды.
• Архитекторы. Разделяют роль технического лидера владельца продукта. Определяют качество технической работы команды. Задают тренд развития команды и создаваемого продукта.
• Функциональные менеджеры. Роль не изменяется, но часть обязанностей, связанных с участием в разработке программного продукта, переходит к команде. Должны трансформироваться во владельцев процессов.
• Программисты. Трансформируются в разработчиков.
• Администраторы базы данных. Как правило, их не переводят в Scrum-команды из-за очень узкой, но необходимой для поддержки и развития продукта профессиональной специализации.
• Тестировщики. Трансформируются в разработчиков/аналитиков. Им необходимо учиться действовать не в режиме выявления, а в режиме упреждения проблемы.
• Проектировщики пользовательского интерфейса. Их роль аналогична роли аналитиков, но с акцентом на продукты, в которых требуется usability.

При внедрении в команду новых ролей важно помнить, чтобы все сотрудники разделяли общие ценности и правила инкрементности и итеративности работ, а также связанные с ними принципы работы в Scrum-команде. Смысл Scrum состоит в том, что член команды должен выйти за пределы своей специализации.

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

5.8. Самоорганизующийся коллектив

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

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

Культура компании, в которой разрабатывается программный продукт, неизбежно влияет на самоорганизацию: может способствовать ее распространению, а может и нет. Если инициатива в организации хотя бы не наказуема, то самоорганизация команды возможна.

Директивное вмешательство определяется типом управления организацией.

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

Если директивное вмешательство определяет операционное управление, то распространение в такой управленческой культуре высоких самоорганизованных Scrum-команд достаточно затруднительно.

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

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

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

В теории это выглядит перспективно, но вопросов пока больше, чем ответов:

• Как осуществить переход к такому принципу управления? (в частности, крупным и иерархическим организациям, в которых любая управленческая ломка может закончиться глубоким кризисом).
• Где взять достаточное количество мотивированных и квалифицированных сотрудников?
• Как осуществлять мотивацию отдельных команд?
• И прочее.

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

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

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

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

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

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

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

5.9. Краткие выводы

Scrum - действенная методология, в основе которой лежат принципы командной работы, состоящей из сотрудников, каждый из которых должен выполнять определенную основную роль:

• владелец продукта;
• Scrum-мастер;
• члены команды разработки.

Эти сотрудники работают совместно, чтобы создать рабочий инкремент программного продукта. Разработка проходит относительно короткими интервалами, которые принято называть "спринт". Инкремент должен удовлетворять заданным критериям и требованиям, обозначенным владельцем продукта, перед началом каждого спринта. Сотрудники, выполняющие различные роли, скомпонованы в единую команду. В зависимости от личных и профессиональных качеств каждого из сотрудников в развитие Scrum привносятся определенные качества. От того, насколько они зрелые, зависит совокупная профессиональная зрелость команды в целом и производимого ими продукта.

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

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

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

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

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