SCRUM Гибкая разработка ПО ЛЮДИ
Преодоление сопротивления В этой главе отмечено, что в переменах присутствует как технический (модификация в физический методах выполнения работы), так и социальный аспект (то, как люди представляют себе возможное влияние перемен на отношения в организации). Рассказано, почему появляется сопротивление, основанное на социальном аспекте, нельзя ли его предупредить, как лучше подготовить людей к изменениям и как эффективнее преодолеть сопротивление. Сопротивление не должно переходить в борьбу, нужно создать у людей ощущение неотвратимости перехода к Scrum и бессмысленность сопротивления.
Возникновение сопротивления Так как переход к Scrum вызывает сильные изменения в работе компании, что не может не вызвать сопротивления среди сотрудников, ведь каждый из них реагирует на изменения по разному. Кто будет сопротивлятся Условно можно поделить всех сотрудников на консерваторов (которые будут сопротивляться больше всего), прагматиков и новаторов. Делается упор на то, то необходимо превратить прагматиков в сторонников Scrum и приводятся меры, которые должны этому поспособствовать. Заблуждения и фобии Многие заблуждения и фобии вполне предсказуемы и типичны для большинства организаций, некоторые же будут специфичны именно для выбранной организации. Их можно разделить на заблуждения, связанные с отрицательным опытом работы по методу «водопада» и фобии, связанные с гибкой методологией разработки. Заблуждения первой группы легко развеять рациональными доводами, второй группы носят более личный и эмоциональный характер.
Информация о переменах Одна из основных причин возникновения сопротивления - недостаточная информированность. Послания лидеров Работники предпочитают слышать разъяснения о необходимости перемен от человека, занимающего более высокую должность в организации. Следует не только честно рассказать людям о том, что их ожидает, но и внимательно выслушать и понять возражения. Мнение коллег Однако, существуют понятия, идеальными источниками которых являются коллеги по работе. То есть необходимо, чтобы люди, которые осознали необходимость перемен помогли осознать их своим коллегам. Лидерам необходимо давать своим подчиненным дополнительные возможности для таких обсуждений.
Тонкости индивидуального сопротивления Люди сопротивляются Scrum по разным причинам, но их можно разделить на две категории: 1) людям не хочется менять существующий порядок вещей; 2) людям не нравится методология Scrum как таковая. Классификация «как люди сопротивляются» имеет также два пункта: 1) активно; 2) пассивно. Далее будут рассмотрены некоторые способы, позволяющие преодолеть сопротивление различных категорий лиц. Активные Пассивные Скептики Консерваторы Саботажники Последовате ли Скептики Предпочитаю Не нравится т статус - кво Scrum • Позволить времени сделать свое дело. • Попросить поделиться историями людей, использующих Scrum. • Выберите из числа скептиков наиболее яркого представителя. • Используйте скептика в качестве внедрения Scrum.
Тонкости индивидуального сопротивления • • • • Саботажнки Стремитесь достичь успеха Лишите саботажников даже малейших надежд Устраните саботажников Консерваторы Предоставьте консерватору стимулы к переменам Вызовите неудовлетворенность существующим порядком вещей Выявите и развейте страхи людей. Последователи Измените состав команды Похвалите правильное поведение Сами статньте примером правильного поведения Выявите подлинное препятствие
Новые роли Одна из причин сопротивления внедрения Scrum является непонимание людьми новых ролей, которые им приходится выполнять при реализации Scrum - проекта. До тех пор, пока люди не поймут, то означают эти новые роли и какие из специалистов обладают квалификацией, необходимой для успешного их исполнения, будет нелегко подыскать подходящих людей.
Роль Scrum - мастера Scrum - мастер призван помогать команде в использовании Scrum. Он не имеет власти над членами команды, он должен контролилровать соблюдение процесса командой. Качества хорошего Scrum - мастера Чувство ответственности, скромность, готовность к сотрудничеству, полная самоотдача, умение влиять на других людей, наличие обширных познаний. Технические лидеры в качестве Scrum - мастеров Первый риск: технический лидер привык руководить подчиненными, но Scrum - мастер не принимает решения вместо своей команды. Второй риск: у технических лидеров зачастую нет необходимых навыков взаимодействия с людьми (Scrum - мастер должен быть скорее посредником и помощником, а не руководителем).
Роль Scrum - мастера: собственные или приглашенные В долгосрочной перспективе нежелательно пользоваться услугами Scrum - мастеров, приглашенных со стороны. Однако, в начале внедрения выгодно пригласить в качества Scrum - мастера какого - либо стороннего консультанта, который будет выступать в роли наставника потенциальных Scrum - мастеров. Ротация Scrum - мастеров Стоит избегать ротации людей на этой ответственной должности. Однако, для обучения персонала это допустимый вариант. Преодоление типичных проблем Роль Scrum - мастера достается человеку, не пригодному для ее успешного исполнения. Объяснить такому человеку, что он не подходит для данной роли, и что интересы команды важнее всего. Сменить его на подходящего. Scrum - мастер одновременно является программистом, тестером или другим специалистом. Довольно рискованный подход, но довольно типичный. Желательно выйти из этой ситуации, назначая одного Scrum - мастера на несколько проектов. Scrum - мастер принимает решения вместо своей команды. Необходимо напомнить ему о его задаче.
Владелец продукта заботится о том, чтобы его команда двигалась к цели и не отклонялась от нее. Обязанности владельца продукта • Формирование представления о будущем продукте и донесение его до членов команды. • Определение границ в зависимости от ограничений для соответствующей компании. Каждой команде нужен только один владелец продукта Владельцу необходимо решать сложные задачи, относящиеся к разным аспектам деятельности команды. Так что он не может распылять внимание на несколько команд. Наличие двух владельцев может вызвать двойной взгляд на одну проблему. Команда владельцев продукта. Допустимое решение чтобы упростить работу владельца, однако, для каждой команды должен быть назначен свой владелец. Качества хорошего владельца продукта Доступность, знание бизнеса, коммуникабельность, решительность, наличие вполне определенных властных полномочий.
Владелец продукта Scrum - мастер как владелец продукта Такая модель может быть успешной. Однако, Scrum - мастер должен защищать интересы команду, а владелец - интересы продукта. Соединение этих ролей в одну приводит к проблемам. Преодоление типичных проблем Владелец продукта делегирует право принятия решений другому, а затем отменяет принятые решения. Владелец должен безоговорочно делегировать принятие решений и не намерен пересматривать принятые решения. Отменять неугодные решения можно лишь после окончания спринта. Владелец продукта слишком рьяно понукает команду. Scrum - мастера должны урегулировать это с владельцами. Владелец продукта предлагает снизить качество. Это решение должно приниматься на как можно более высоком уровне руководства и должно быть гласным. Владелец проживает в другом городе. В этом нет ничего страшного, при условии, что владелец хорошо справляется с поставленной перед ним задачей.
Изменившиеся роли В этой главе описаны основные коррективы, которые должны вносить в свою деятельность люди при переходе от исполнения своих традиционных ролей к работе по методологии Scrum. Внимание сосредоточено не на описании роли, а на ее изменении.
Изменившиеся роли Аналитики В Scrum - команде целью аналитика является анализ, выполняемый к нужному моменту. Аналитик должен опережать свою команду лишь на самую малость, в то же время снабжая ее полезной информацией о текущих и ближнесрочных функциональных возможностях программного обеспечения. Руководители проектов В Scrum - проектах отсутствует роль руководителя, а многие их его обязанностей возлагаются на Scrum - команду. Бывшие руководители становятся Scrum мастерами, владельцами продукта или одним из членов команды. Почему изменяется название должности Название было изменено на Scrum - мастер, чтобы напомнить, что теперь компания работает по новой методологии.
Изменившиеся роли Архитекторы Главной обязанностью архитектора является выстраивание последовательности работ в спринты. Это может помочь команде быстрее добывать нужные знания, минимизировать совокупную стоимость разработки, избегать рисков или выявлять их. Архитектор, не занимающийся кодированием Архитекторам вовсе не постоянно заниматься кодированием, хотя некоторые из них захотят к этому вернуться. Однако, некоторые из архитекторов перестали программировать по причине нежелания заниматься практическим программированием. Функциональные менеджеры Обычно сохраняют за собой функцию распределения людей по проектам. Лидерская роль функционального менеджера Менеджерам стоит сочетать глубокое понимание конкретной работы и управление по принципу «снизу вверх» (построитель организации обучающего типа). Обязанности, связанные с управлением кадрами Менеджеры обязаны периодически проводить аттестацию, следить за повышением квалификации, профессиональным ростом работников своего отдела; могут принимать на работу и увольнять людей.
Изменившиеся роли Программисты Одна из самых впечатляющих перемен - то, что программисты должны стать активными участниками процесса выяснения требований к будущему продукту, должны общаться с клиентами, пользователями, другими членами команды. Также изменятся способы выполнения ими своей работы. Администратор базы данных Многое из того, что говорилось программистов применимо и к этим специалистам. Также им придется научиться постепенно делать то, то традиционно рассматривалось как подготовительная работа к реализации проекта.
Изменившиеся роли Тестеры Также, как и программистам им придется перейти в более интерактивную среду (выявлять требования в ходе общения). Работать тестерам придется итеративно. Для Scrum - команд также свойственно автоматизированное тестирование. Проектировщики пользовательского интерфейса Проектировщики должны опережать разработчиков на один спринт. И, хотя проектирование и разработка могут двигаться параллельными путями, проектировщики должны помнить, что являются с разработчиками одним целым. Также им необходимо обдумывать будущие ходы в разработке интерфейса.
Скачать презентацию SCRUM Гибкая разработка ПО ЛЮДИ Преодоление сопротивления
scrum.люди.ppt