Команда - это группа профессиональных работников, занимающиеся различной трудовой деятельностью. Смысл командной работы состоит в производстве высоких результатов за счет кооперирования между сотрудниками высокой квалификации и производства совокупного результата, который должен превосходить сумму результатов членов команды.
Безусловно, есть категории асов, предпочитающих работать в одиночку, но в сегодняшнем высокотехнологичном мире одиночная работа стала уделом немногих. Только при наличии команды можно рассчитывать на производство качественного программного продукта в заданные сроки. Именно время - это то превосходство, которое может предоставить командная работа для компании за счет более быстрого вывода информационной системы на рынок. На командной работе базируется методология Scrum.
Топ-менеджмент большинства организаций полагает, что, отдавая предпочтение отдельным специалистам, проще осуществлять контроль и управление коллективом в целом. Когда есть необходимость в хороших исполнителях, руководство нацелено на то, чтобы в фирме собрать самых опытных работников. Вопросы качества и хороших результатов становятся решенными априори после того, как нужный работник найден. Не так все просто.
Ресурс отдельного, хоть и профессионального исполнителя ограничен многими факторами, которые определяют необходимый результат. Но когда мы начинаем говорить о командной работе, то начинают работать совсем другие принципы. Командный ресурс состоит из ресурсов исполнителей, к которому добавляется синергетический эффект, приводящий общий механизм в движение. Эту материю сложно пощупать, но она работает и отделяет успешные команды от сборища заурядных исполнителей.
Характеристиками эффективных команд являются следующие:
Каким образом удается создать группу людей с целью достижения высоких результатов? Будет ли она самоорганизованной и создавать атмосферу взаимного обучения и информирования? Чтобы найти ответы на эти волнующие вопросы, один из основателей Scrum Д. Сазерленд потратил уйму времени. Как добиться результата, чтобы люди соединились в одно целое, думали о непрерывном усовершенствовании? Точно не методом террора и жесткого контроля, ведь каждый должен прийти к пониманию, что это ему действительно необходимо. Давление даст только отрицательные результаты. Вероятнее всего, есть набор несложных правил, помогающих достичь требуемого результата.
Все зафиксированные правила укладываются в единый лозунг: "Одна команда - от старта до финиша". Главное требование к команде, которая должна создавать необходимый продукт, - многофункциональность. Это выражается в наличии всех специалистов, необходимых знаний и практики для успешного выполнения заданий.
Стандартная организационная структура включает в себя отдельные подразделения управления, анализа, разработки, тестирования, внедрения и т. д. Они укомплектованы сотрудниками данных специализаций. Подобная структура полностью соответствует классическому подходу к разработке программного обеспечения. Но на сегодня необходимы команды, которые будут состоять из всех необходимых сотрудников и, оперативно реагируя на внешние вызовы, отражать их в конечном продукте. Именно по такому принципу и построены Scrum-команды. Все члены подобных команд должны иметь определенные задачи и функции в работе, выполняемые в рабочих интервалах, за которые должен быть сформирован очередной вид рабочего продукта (спринты). Функциональные отделы не выпускают отдельно продукт, а команда, в противовес функциональной организации, все делает сообща. Это во многом дублирует принципы процессного подхода, что еще раз подчеркивает, что Scrum является эффективной процессной методологией.
Но команда - более сложный организационный элемент, нежели отдельный сотрудник. Команда возникает, живет, развивается и заканчивает функционирование по своим принципам, которые необходимо знать. Понимание этих принципов поможет оптимально ею управлять и прогнозировать результаты, которые может предоставлять команда на различных этапах своего жизненного цикла.
Эксперты, занятые вопросами создания эффективной организационной среды, сходятся во мнении, что методика Scrum помогает компаниям достигнуть желаемых результатов производства программного обеспечения за счет внедрения инкрементного подхода производства. Во главе этого лежит базисный принцип разработки информационной системы или сервиса в виде создания минимально необходимой функциональности для конкретной временной даты и предоставления этой версии в пользование клиенту. После чего выполняется использование созданного артефакта, и команда приступает к следующей итерации работы над продуктом, который развивается на основе полученных результатов. И так далее, итерационно, шаг за шагом продукт приходит к тому виду, применение которого оптимально для заданных рабочих условий компании.
Существует простая методика, которая может позволить проверить "правильность" мышления команды. Нужно в разговоре с любым сотрудником, включенным в Scrum-команду, задать вопрос о состоянии их группы. Оптимальным будет, если член команды ответит о разрабатываемом продукте, а не будет рассуждать об их текущей специализации. В случае, когда сотрудник не связывает себя с общим продуктом, речь идет о недопонимании целей Scrum или же о прочей "проблемной" причине. Если же есть тенденция, что вся команда находится в "кризисном" состоянии, тогда необходимо диагностировать ее состояние и принимать соответствующие меры.
Чтобы группа людей превратилась в сплоченную и эффективную команду, необходимо пройти несколько этапов.
Наиболее распространенной моделью, описывающей стадии командообразования, является модель Такмана (рис 5.1).
(рис 5.1) Этапы командообразования
В своем развитии все команды обязательно проходят несколько этапов.
Этот этап во многом является отправной точкой для создания команды и постановки целей на разработку или развитие продукта. Как правило, на этом этапе выполняются создание или обновление состава, постановка целей деятельности всего состава команды в целом и отдельных ее членов, не очень понимающих те задачи, выполнение которых поставлено перед ними для достижения общего результата.
На этом этапе все члены команды отчетливо осознают свои и общие цели, задающие вектор движения коллектива. В период бурления часто возможны конфликты и противостояние между отдельными членами команды, формирование мелких группировок, поэтому особенно возрастает роль Scrum-мастера (SM) как модератора (его обязанности мы обсудим чуть позже). Этап бурления - самое время для определения формальных и неформальных лидеров Scrum-команды.
На этапе нормализации происходит "притирание" членов команды друг к другу. Закрепляются лидеры команды, и она начинает демонстрировать стабильные результаты деятельности. Основная задача Scrum-мастера на этом этапе - помощь команде для перехода на следующий этап.
Функционирование - это этап, на котором команда переходит к самоуправляемости. На этом этапе команда способна оптимизировать свою производительность, существующие неформальные связи между членами команды закрепляются окончательно. Этот период наибольшей эффективности и производительности.
Цели, поставленные перед командой, достигнуты, мотивация большинства участников в этот период убывает. Профессиональный Scrum-мастер должен четко отслеживать рубеж между этапом функционирования и расформирования, и предпринимает шаги, которые не позволят команде сильно понизить их производительность. В качестве примера подобных шагов можно привести изменение состава команды, смену целей, предоставление нового продукта, над развитием которого должна трудиться команда, и т. д.
Чтобы работать эффективно, команда должна как можно дольше находиться на этапе функционирования. Соответственно, главной задачей команды (и, в частности, Scrum-мастера) является максимально быстрый переход между этапами, предваряющими стадию функционирования, и замедление этапов, которые идут после. Но надо отдавать себе отчет в том, что команда также подвержена влиянию организации, ее управленческим процессам, которые протекают в компании, и возможны временные и "сезонные" отклонения, определяемые, скажем, аттестациями, выплатами премий и пр.
Команду нужно держать в тонусе, но необходимо тщательно отслеживать состояние наиболее "заслуженных" работников в целях предотвращения возможных выгораний и срывов.
Организация командной работы - это очень важная часть деятельности Scrum-мастера, который своей работой должен обеспечить комфортное рабочее состояние всем ее членам.
Scrum-команда должна состоять из мотивированных профессиональных сотрудников. Это факт, на котором построена оптимальность данной гибкой методологии. Члены команды отвечают за разработку программного продукта высокого качества. Они должны обладать множеством различных навыков, необходимых для создания эффективного программного обеспечения:
Члены команды участвуют в планировании работ на временной интервал, который в Scrum принято называть "спринт". Команда может включать опытных разработчиков и новичков, которые в процессе работы должны совершенствоваться при обмене знаниями. Члены команды отвечают за следующие задачи в проекте:
Основной движущей силой команды является ее участник, которого принято называть разработчик (Development member) - специалист, представляющий собой "ядро" Scrum. От его навыков, умения, квалификации, опыта будет зависеть дальнейшее развитие продукта и Scrum-команды. Как правило, команда, работающая над продуктом, состоит из 4-15 человек. Помимо владения теоретическими знаниями каждый член команды должен уметь практически применить следующие навыки:
Разработчика Scrum-команды целесообразно сравнивать со швейцарским ножом, который виртуозно может решить любую поставленную перед ним задачу. Но неправильно думать, что за счет универсализации теряется спецификация, выражаемая в создании качественного и используемого кода программного продукта. Универсализация приветствуется и всячески "взращивается" в членах команды, но разрабатывать инкремент программного продукта - это основная задача разработчиков Scrum-команды.
Scrum-мастер - движущая сила Scrum-процесса. Он призван помогать команде в освоении гибкой методологии. Его роль является определяющей при внедрении Scrum. Для того чтобы Scrum получился успешным, Scrum-мастер должен обладать следующими качествами:
Scrum-мастер призван помогать команде в использовании Scrum. Его функции сопоставимы с функциями тренера, который помогает спортсменам соблюдать спортивный режим и поддерживать физическую форму. Scrum-мастер создает мотивации и в то же время следит за тем, чтобы члены команды не увиливали от выполнения "тяжелых физических упражнений". Однако его полномочия ограничены. Он не может заставить сотрудника выполнять то или иное упражнение, которое тот не желает выполнять. Вместе с тем он напоминает о целях и о том, как необходимо их достигать. Scrum-мастер обладает властью в той мере, в какой этой властью наделила его команда.
Scrum-мастер может сказать команде: "Итак, к окончанию каждого спринта мы должны создавать программный продукт, потенциально готовый к установке. На этот раз нам не удастся создать такой продукт. Что мы можем сделать для того, чтобы подобная ситуация не повторилась в следующем спринте?". Это пример проявления власти Scrum-мастера над процессом. Если команде не удалось к окончанию текущего спринта изготовить программный продукт, потенциально готовый к установке, значит, произошел какой-то сбой в работе команды. Но поскольку власть Scrum-мастера распространяется только на процесс, то он не имеет права сказать: "Поскольку нам не удалось к окончанию текущего спринта изготовить программный продукт, потенциально готовый к отправке заказчику, я хочу, чтобы он просмотрел весь код до того, как он будет окончательно принят". Возможно, было бы не так уж плохо, если бы кто-то просмотрел весь код, но Scrum-мастер не имеет права принять такое решение, поскольку оно выходит за пределы его полномочий и вторгается в сферу ответственности команды. Scrum-мастер должен лишь контролировать соблюдение процесса командой, его роль может оказаться более трудной, чем роль типичного руководителя проекта, так как руководители проектов зачастую могут сказать: "Делайте так, потому что я так решил".
При назначении SM не рекомендуется совершать следующих ошибок:
Проводя параллель с функциональным или процессным подходом к организации процессов, можно сказать, что обязанности Scrum-мастера соответствуют роли функционального менеджера/администратора, но не владельца процесса.
Роль владельца продукта является основной при использовании методологии Scrum. Ожидания и определение этой роли очень размыты. С одной стороны, на нее возлагается масса надежд, но обязанности четко не определены.
Для того чтобы быть успешным, сотрудник, выполняющий эту роль, должен сочетать в себе навыки таких должностей, как менеджер продукта, менеджер проекта, бизнес-аналитик, и при этом быть природным лидером, способным мотивировать и вдохновить окружающую его команду на свершения.
Бизнес-аналитик - сотрудник, который знает, как получить требования от пользователей и как подготовить требования к команде, чтобы она исполняла их максимально быстро.
Менеджер продукта - сотрудник, который знает, чего хотят бизнес и пользователи.
Менеджер проекта - сотрудник, который знает, как планировать и отслеживать исполнение проекта.
Лидер - сотрудник, который знает, как направить общие усилия в одну сторону, на чем сфокусироваться и как мотивировать команду на достижение этой цели."Готового" для конкретной организации идеального владельца продукта, как ни прискорбно это констатировать, не существует. Владельца продукта необходимо воспитать в соответствии с целями, задачами и условиями, в которых функционирует организация, более того, успех создаваемого продукта зависит именно от того, кто исполняет эту роль и какова его позиция в организации. Этот сотрудник должен занимать достаточно важное место в организационной структуре компании. Это поможет отстоять обоснованную точку зрения в дискуссиях руководства и донести до них те выгоды, которые сулит развитие программного продукта.
Владелец продукта (Product Owner) - сотрудник, который указывает Scrum-команде ее цель и не позволяет отклоняться от нее. Указание цели происходит за счет:
На нем лежит ответственность за то, как члены команды поймут задачи, необходимые для реализации. Для эффективного выполнения роли PO необходимо иметь следующие качества:
Подытоживая разговор о владельце продукта, стоит отметить, что эта роль - новая для современной бизнес-среды. Предстоит осознать множество критичных факторов, как технического, так и социального порядка, относящихся к разработке эффективных программных продуктов, для того чтобы требования к этой роли выкристаллизовались.
Самый серьезный вызов для внедрения гибкого подхода - уметь перестроиться с привычных "рельсов" течения рабочих процессов. Каждый член Scrum-команды должен осознавать, что результат (инкремент) и эффективность команды будут напрямую зависеть от результатов его деятельности, синхронизированных с результатами деятельности остальных членов команды. Scrum поощряет развитие универсализма каждого из членов команды, но при этом должна сохраняться специализация. Для того чтобы продукт был качественным, члены команды должны быть (или стремиться к тому, чтобы стать) экспертами в профильных областях деятельности. Самоорганизация и высокий профессионализм необходимы для того, чтобы:
После того как задания на ближайший спринт определены, команда должна самоорганизоваться для его выполнения. То, как именно будет достигнут результат, целиком зависит от членов команды и результатов их работы. Самоорганизация возможна при соблюдении определенных условий. Важно, чтобы среди членов команды были сотрудники, разные не только по профессиональной специализации, но и по своим командным ролям. К примеру, можно привести следующие роли, которые скорее соответствуют личностным качествам сотрудников:
Каждая подобная роль занимает свою "зону" в команде. Чем больше свободных зон, тем ниже уровень самоорганизации команды, и для ее развития необходимо внедрение в команды сотрудников, соответствующих подобным ролям. Зрелость и развитость команды можно оценить, только понаблюдав за тем, как совершенно разные люди уживаются между собой и достигают консенсуса в коллективном обсуждении критичных вопросов и задач. Следующим важным этапом в процессе самоорганизации является проведение ретроспектив.
По окончании спринта команда собирается и совместно обсуждает, что прошло хорошо, а что не так, как планировали или хотелось бы. Ретроспективы дают возможность проанализировать и при необходимости подправить правила, по которым команда работала раньше. Тему ретроспективы мы более подробно обсудим в следующих главах.
Только после того, как будет достигнута атмосфера общего доверия, сотрудники в команде захотят слушать и понимать друг друга. Самоорганизация отдельных членов команды необходима для достижения эффективности коллективного труда, как совокупность достигнутых результатов каждого.
Кроме обозначенных основных ролей, в зависимости от типа разрабатываемого продукта или условий, в которых функционирует организация, для команды могут потребоваться сотрудники со следующими профильными навыками и квалификацией:
При внедрении в команду новых ролей важно помнить, чтобы все сотрудники разделяли общие ценности и правила инкрементности и итеративности работ, а также связанные с ними принципы работы в Scrum-команде. Смысл Scrum состоит в том, что член команды должен выйти за пределы своей специализации.
Если того требуют общие интересы, люди должны быть готовы работать, не ограничиваясь лишь своей узкой специализацией.
После того как будет достигнута самоорганизация всех членов команды, следующей ступенькой на пути совершенствования командной работы и, как следствие, самого процесса Scrum, является достижение состояния самоорганизующегося коллектива.
Основной вопрос, который необходимо решить для эффективного внедрения в управленческую практику компании, заключается в том, что может дать самоорганизация компании, ведь то, что все организовались и заняты, может в итоге ни к чему не привести. Если цель самоорганизации команды должна последовательно привести к успеху продукта, то помимо перечисленных условий важна мотивация - сотрудники должны быть мотивированы самоорганизовываться.
Культура компании, в которой разрабатывается программный продукт, неизбежно влияет на самоорганизацию: может способствовать ее распространению, а может и нет. Если инициатива в организации хотя бы не наказуема, то самоорганизация команды возможна.
Директивное вмешательство определяется типом управления организацией.
Если директивное вмешательство состоит в задании цели и задач реализации информационной системы, то важно, чтобы это делалось непротиворечиво и последовательно. Вмешательство, направленное на прояснение ожиданий, доступных ресурсов и того, что можно и чего нельзя делать, поощряет и способствует формированию самоорганизованности Scrum-команд.
Если директивное вмешательство определяет операционное управление, то распространение в такой управленческой культуре высоких самоорганизованных Scrum-команд достаточно затруднительно.
Чтобы организация смогла встать на рельсы самоорганизованности, помимо необходимости наличия определенной управленческой культуры важно, чтобы гибкие методологии разработки и принцип командной работы опоясывали и проходили "красной нитью" через всю организацию. Подобная организационная структура в последнее время начала внедряться в деятельность немногих компаний по всему миру. Но это только начало. Эта "мета"-методология называется холократия.
Холократия по своей сути - это способ децентрализации управления, который позволяет выстроить процессы таким образом, чтобы сотрудник мог влиять на жизнь компании и обладал полной властью в рамках своей роли. Эта технология управляется не менеджментом, а общей целью компании, процессом, ожиданиями и метриками, определенными управленческой командой, состоящей из выделенных представителей отдельных команд. В Scrum принципы холократии на сегодняшний день наибольшее распространение получили при организации деятельности отдельных команд и при организации взаимодействия между несколькими командами.
В теории это выглядит перспективно, но вопросов пока больше, чем ответов:
Только самые отчаянные инноваторы могут решиться на внедрения подобного типа управленческой структуры, но есть успешные примеры и в России, и не только в сфере информационных технологий.
Но, несмотря на блестящую идею о самоорганизованности, важно понимать, что такое самоорганизующаяся команда, а также что не входит в ее полномочия.
На определенном этапе, когда команда может объективно оценивать вклад участников в формирование конечного продукта и процесс Scrum, ей можно доверить самостоятельное формирование состава команды в рамках заданных ресурсов.
Команда должна определять максимально эффективный способ, с помощью которого будет достигать результата. Эффективность в подобных случаях измеряется сроком, составом и ценой работ. При этом команда должна быть способной адаптироваться к ограничениям и условиям окружающей среды.
Самоорганизованность и способность адаптироваться под изменчивые условия свойственны многим природным колониям живых существ. Возьмите, к примеру, пчел или муравьев. В том случае, когда человек в своих стремлениях создать что-то эффективное наиболее точно копирует природные аналоги, получаются оптимальные решения.
В решениях, из которых складывается конечный результат, принимает участие каждый член команды, разделяя ответственность и вознаграждения. Самоорганизованность команды - это действенный этап в работе по Scrum. Для его достижения и последующего удержания требуется управленческое участие, неподдельный интерес к производимым результатам и желание к постоянному развитию.
Scrum - действенная методология, в основе которой лежат принципы командной работы, состоящей из сотрудников, каждый из которых должен выполнять определенную основную роль:
Эти сотрудники работают совместно, чтобы создать рабочий инкремент программного продукта. Разработка проходит относительно короткими интервалами, которые принято называть "спринт". Инкремент должен удовлетворять заданным критериям и требованиям, обозначенным владельцем продукта, перед началом каждого спринта. Сотрудники, выполняющие различные роли, скомпонованы в единую команду. В зависимости от личных и профессиональных качеств каждого из сотрудников в развитие Scrum привносятся определенные качества. От того, насколько они зрелые, зависит совокупная профессиональная зрелость команды в целом и производимого ими продукта.
Сотрудники, играющие роли, которые являются основными для функционирования Scrum, по мере работы проходят становление и развитие как команда. Каждый из этапов этого становления характеризуется определенными характеристиками. Для того чтобы на каждом этапе деятельность команды удовлетворяла владельца продукта, Scrum-мастер должен отслеживать состояние этих характеристик и при необходимости корректировать ход гибкого процесса.
Наивысшая степень развития сотрудника - состояние самоорганизованности. В этом состоянии сотрудник полностью отвечает за производимые им результаты и готов к постоянным изменениям в целях осознания и последующего совершенствования.
Наивысшая степень развития команды - состояние самоорганизованности. Для достижения этого состояния каждый из членов команды должен быть самоорганизованным, команда в целом должна разделять общие цели, постоянно отслеживать отклонения от заданного рабочего процесса, искать способы для последующего развития и совершенствования как командного взаимодействия, так и отдельных ее индивидов.
В следующей главе мы поговорим о наиболее сложном и критичном этапе деятельности в процессах разработки программного обеспечения, который определяет ожидания заинтересованных пользователей от создаваемой информационной системы и закладывает прочный фундамент дальнейшего взаимодействия между заказчиками и разработчиками программного продукта, - этапе планирования работ.
В Scrum этот этап достаточно сильно отличается от классических подходов к планированию и имеет свои детали, которыми также нужно эффективно управлять для получения оптимального рабочего продукта.
Для получения официальных документов о завершении программы дополнительного профессионального образования (удостоверения о повышении квалификации, дипломов о профессиональной переподготовке и MBA) необходимо предоставить:
Внимание! Вы можете не заказывать доставку бумажной версии официального документы, а скачать его в электронном виде и распечатать самостоятельно. Информация о выданном документе в течение 1 месяца загружается в Федеральную информационную систему «Федеральный реестр сведений о документах об образовании и (или) о квалификации, документах об обучении» - ФИС ФРДО.
Доступ на новый сайт осуществляется с использованием адреса электронной почты, который был указан вами при регистрации на "старом". Мы постарались перенести все ваши данные с прежнего ресурса, однако не исключена вероятность потери части информации.
При возникновении проблемы со входом, воспользуйтесь функцией сброса пароля
Если вы обнаружите несоответствия, пожалуйста, сообщите нам.