Помоги проекту - поделись книгой:
Scrum – бесплатный метод, и его описание предоставлено в этом гайде. Роли, артефакты, правила и мероприятия Scrum не подлежат изменению, и, хотя возможно использование только отдельных его частей, конечный результат уже не будет Scrum. Scrum существует только в своей целостности и может быть контейнером для дополнительных техник, методологий и практик.
Статья X. Благодарности
Раздел 10.01. Люди
Среди тысяч людей, способствовавших развитию Scrum, мы хотим выделить тех, кто на протяжении первого десятилетия существования метода внес в его разработку наиболее весомый вклад. В первую очередь это, конечно же, Джефф Сазерленд и Джефф Маккенна, а также Кен Швабер, Майк Смит и Крис Мартин. В последующие годы много людей способствовали развитию Scrum, и без их содействия он не был бы настолько усовершенствован. Дэвид Старр использовал все свои редакторские навыки при создании этой версии Scrum-гайда.
Раздел 10.02. История
Кен Швабер и Джефф Сазерленд впервые представили Scrum на конференции OOPSLA (Object-Oriented Programming Systems, Languages and Applications) в 1995 году. Данное руководство основывается на опыте, приобретенном Кеном и Джеффом на протяжении многих лет применения Scrum.
История развития Scrum уже может считаться длительной. Отмечая те компании, в которых Scrum был впервые использован и усовершенствован, мы не можем не вспомнить о корпорациях Individual, Inc., Fidelity Investments и IDX (сегодня GE Medical).
Scrum-гайд описывает метод в том виде, в котором он был разработан и поддерживался в течение более 20 лет Джеффом Сазерлендом и Кеном Швабером. В других источниках вы можете найти образцы, процессы, справку и полезные инструменты, которые дополняют фреймворк Scrum. Это позволяет достичь продуктивности, ценности, проявить креативность и в итоге испытать гордость.
Приложение 3. Сценарий достижения гибкости организации
Используется с 2005 года
1.1. Введение
Давление со стороны глобальной экономики требует от современного бизнеса в большей степени полагаться на способность создавать программное обеспечение в качестве ключевого конкурентного преимущества. Программное обеспечение – для управления процессами производства и доставки до потребителя или для повышения эффективности ежедневных рутинных действий – затрагивает практически все аспекты современного бизнеса.
В то же время многие руководители предприятий считают, что их методы разработки программного обеспечения мало изменились с 1980-х годов. Повсеместно распространены предиктивные, основанные на планировании, каскадные методы разработки, несмотря на горы доказательств того, что эти процессы часто не в состоянии предоставить своевременно реальную ценность и поэтому препятствуют развитию способности компаний реагировать на быстро меняющиеся требования клиентов и условий рынка. И ситуация только ухудшается.
Современные IT-организации должны эффективно координировать распределенные по всему миру команды разработки программного обеспечения, встраивая ранее разработанные приложения в более гибкие, сервис-ориентированные архитектуры. Очевидно, что мы нуждаемся в новом подходе к управлению и разработке программного обеспечения, чтобы оставаться конкурентоспособными.
Для решения этих проблем был создан ряд более гибких и адаптивных методов разработки, которые позволяют организациям быстрее поставлять программное обеспечение высокой ценности. Scrum – один из таких проверенных методов, применяемых на многих предприятиях по разработке программного обеспечения.
В этом документе подробно объясняется, как высшие руководители могут внедрить Scrum на уровне предприятия, включая масштабирование среди большого количества различных применений и создание команд, а также рассказывается о вызовах, с которыми придется столкнуться, и наградах, которые можно получить. Документ предоставляет сценарий по адаптации Scrum на предприятиях, для которых создание качественного программного обеспечения и его количество – ключ к успеху в конкурентной борьбе на рынке.
Это «набор» идей по реализации Scrum в рамках предприятия, и это скорее сценарий, чем руководство, потому что каждая организация уникальна. Реализация Scrum в одной организации будет отличаться от реализации в другой. Типы препятствий, вещи, нуждающиеся в изменении, трудность в реализации этих изменений и люди, которые будут проводить эти изменения, везде разные, поэтому графики, приоритеты и усилия в каждой организации также будут разными.
1.2. Обзор Scrum и гибкой разработки программного обеспечения
На первый взгляд Scrum – очень простой процесс: это техника управления разработкой программного обеспечения, которая имеет относительно небольшой набор взаимосвязанных методов и правил, не слишком предписывающего характера, которым можно быстро научиться и получить возможность почти сразу повысить производительность.
Scrum естественным образом фокусирует всю организацию на создании успешных продуктов. Он обеспечивает создание через регулярные промежутки времени полезных функций, таких как требования, архитектура, дизайн, даже при использовании нестабильных технологий. Вы можете применять Scrum в начале проекта или в середине, он поможет сэкономить усилия при разработке.
Scrum эффективен, потому что оптимизирует атмосферу разработки, устраняет организационную надстройку и непосредственно синхронизирует рыночные требования со скоростью доставки необходимых функций. Scrum, основанный на современной теории контроля, производит лучшее из возможного программного обеспечения при помощи доступных ресурсов, приемлемого уровня качества и в требуемые сроки. В своей основе Scrum – итеративно-инкрементальный процесс разработки любого продукта или управления любой деятельностью. Он производит потенциально готовый к выпуску набор функциональности к концу каждой итерации.
Отличительные черты Scrum:
• инструмент, который может быть использован для достижения гибкости;
• гибкий процесс для контроля и управления разработкой;
• упаковка для существующих инженерных практик и методов;
• командный метод разработки систем в условиях, когда требования меняются быстро;
• контролирует хаос в условиях конфликта интересов и потребностей;
• улучшает коммуникации и обеспечивает максимальное сотрудничество;
• обнаруживает и устраняет все препятствия, стоящие на пути разработки и выпуска продукции;
• представляет собой способ добиться максимальной производительности;
• масштабируется от отдельных проектов до целых организаций и может управлять разработкой множества взаимозависимых продуктов и проектов с командой из более чем тысячи участников;
• позволяет каждому получать удовольствие от своей работы, вклада в общее дело и осознания, что сделал максимум возможного.
Подробное описание методов Scrum выходит за рамки этого документа (см. Швабер, 2004, и Швабер, 2002). В двух словах метод можно описать созданием бэклога продукта, где все требуемые функции организованы в список по их приоритетности (рис. А3.1).
Рис. А3.1. Модель эмпирического процесса для Scrum
Владелец продукта отвечает за утверждение изменений в бэклоге продукта. Реализация происходит после 30-дневных итераций, называемых спринтами, которые фокусируются в верхних пунктах списка в бэклоге продукта. Цель каждого спринта – поставка потенциально готового к выпуску инкремента продукта. В течение спринта контрольные точки разработки обсуждаются на совещаниях, называемых Scrum-митингами. На них сообщается прогресс и деятельность каждого члена команды и определяются проблемы, которые могут блокировать этот прогресс. Это позволяет Scrum-мастеру контролировать прогресс в отношении общих обязательств спринта и давать советы по корректировке процесса разработки для обеспечения успешного завершения спринта. Процесс разработки показан на рис. А3.1.
1.2.1. Принципы Scrum
Помимо освоения механизмов работы Scrum, для руководителей важно понимать, что Scrum руководствуется несколькими основными принципами:
• верой, что эффективная разработка программного обеспечения лучше осуществляется через эмпирический процесс, а не через процесс планирования;
• убеждением, что после устранения организационных препятствий самоорганизованная и самоуправляемая команда естественным образом будет создавать лучшее программное обеспечение, чем было бы в противном случае;
• допущением, что вы можете получить наиболее ценное программное обеспечение в отведенное время и в рамках выделенного бюджета и все же вы не можете окончательно спрогнозировать точную функциональность, которую команда будет в состоянии предоставить.
Scrum заявляет, что признание этих ключевых принципов освобождает организацию от многих ограничений, препятствующих эффективной разработке программного обеспечения. Тем не менее высшее руководство должно признавать, что применение этих ключевых принципов предполагает значительные изменения в организации, которая сделала выбор по их внедрению. Так как эти принципы составляют основу Scrum, каждый заслуживает некоторого дополнительного обсуждения.
1.2.1.1. Эмпирический процесс против процесса планирования. Scrum основан на убеждении, что сегодня большинство систем разработки имеют неправильную философскую основу, а именно что через все более и более эффективное планирование мы можем достичь более предсказуемых и более качественных результатов. Scrum определяет процесс разработки приложений как непредсказуемый и необычайно сложный (подумайте о сотнях тысяч созданных вручную строк программного кода). Ценность такого процесса может быть измерена только эмпирически. В конце концов каждое ваше приложение, разработанное другой командой в другом месте и при других обстоятельствах, будет отличаться от созданного вашей командой и в вашем контексте, поэтому готового рецепта, основанного на процессе пошагового планирования, не может быть.
Scrum определяет процесс разработки систем как свободный комплекс мероприятий, который сочетает в себе известные, эффективные инструменты и методы под управлением команды разработчиков в тесном сотрудничестве с владельцем/потребителем продукта. Так как многие из этих видов деятельности неточные, применяются средства контроля, такие как постоянный осмотр и демонстрация, чтобы управлять рисками в реальном времени и предоставлять эмпирическое подтверждение состояния проекта в любой момент времени.
Рекламный слоган Scrum прост:
или
1.2.1.2. Устранить препятствия, чтобы команда могла делать свою работу. С годами организационные процессы и методы разработки программного обеспечения в каждой компании, как правило, накапливаются до тех пор, пока создание программного обеспечения не становится довольно сложной задачей. Когда Scrum начинает применяться, эти «организационные препятствия» на пути выпуска эффективного программного обеспечения становятся очевидными, потому что влияют на способность команды соответствовать быстрому, итеративному, пошаговому характеру Scrum. Удаление или изменение этих процессов и методов работы может выявить необходимость начала крупного проекта изменений на предприятии под контролем и управлением высшего руководства (более подробно эта тема раскрывается далее).
Более того, в Scrum команда – главное звено. В конце концов члены команды – те, кто реально проектирует, разрабатывает и предоставляет программное обеспечение, поэтому оптимизация производительности команды за счет устранения препятствий оптимизирует коммерческую производительность всего предприятия по доставке ценного продукта клиентам. Управляющий персонал делает свою работу, когда устраняет препятствия. Команда делает свою работу, когда выполняет свои обязательства, описанные в каждом бэклоге спринта.
Другими словами, в Scrum команда одновременно наделена и полномочиями, и обязанностями по доставке продукта. Команда хорошо делает свою работу, когда она самоорганизованна, самоуправляема и самостоятельно добивается выполнения целей спринта. Для многих организаций это переворачивает все с ног на голову. Иерархический, директивный стиль управления при применении Scrum естественным образом устраняется. Владелец продукта теперь только устанавливает набор задач и приоритеты, а члены команды решают, как этого добиться, и никто не должен указывать, как им это делать в процессе работы.
1.2.1.3. Лучший, хотя и не такой предсказуемый, результат против фальшивой уверенности. Scrum начинается с допущения, что создание программного обеспечения – сложный бизнес, существующий в изменчивом специализированном техническом пространстве, и никто не в состоянии надежно предсказать или точно спланировать, что команда сможет произвести, когда она сможет это сделать и какими в итоге будут качество и стоимость. Scrum считает, что только команды могут оценить эти вопросы, просчитать стоимость, договориться о ближайшем плане работы в зависимости от различных рисков и потом скорректировать этот план в процессе работы. Соглашение состоит в том, что команда предоставит лучшее из возможного в данных обстоятельствах программное обеспечение. Следование любому другому подходу, основанному на пошаговом выполнении плана, не способствует «улучшению» и только мешает команде отзываться на сложности реального мира и на его непредсказуемость.
Исторически сложилось, что пренебрежение этой философией создает ряд организационных проблем:
• руководство на самом деле считает, что может предсказать стоимость, срок выпуска и функциональность, которые будут предоставлены на основании планирования;
• разработчики и руководители проектов вынуждены жить во лжи: они притворяются, что могут планировать, прогнозировать и выполнять планы; они движутся своим путем, но делают вид, что идут по другому пути; в конце концов они, по существу, работают без контроля;
• к моменту релиза система часто оказывается неподходящей или требует существенного изменения; ключевая причина – то, что долгий процесс разработки и высокая стоимость повторной работы ограничивают нашу видимость полезности того, что команда на самом деле разрабатывает.
Признание этих реалий не происходит без проблем. Например, какой менеджер захочет сказать своему руководству, что он точно не знает, что ему предоставит команда разработки к определенной дате. Но у такого подхода имеются и преимущества: организация получит то, в чем действительно нуждается, – способность создавать лучшие продукты для конечных пользователей и делать это быстро и четко, обеспечивая себе конкурентное преимущество для ведения бизнеса.
1.2.2. Scrum и гибкость разработки программного обеспечения
Scrum используется начиная с середины 1990-х годов и в настоящее время применяется в тысячах проектов по всему миру. Наряду с ним за этот период получили признание несколько новых итеративных методологий. Как и Scrum, каждый метод представляет собой комбинацию старых и новых идей, но все они подчеркивают, что необходимо следующее:
• тесное взаимодействие между командой разработки и бизнес-экспертами;
• общение лицом к лицу (это более эффективно, чем документальная переписка);
• частое предоставление готового к развертыванию, представляющего ценность для бизнеса программного обеспечения;
• прозрачность целей, прогресса и артефактов;
• создание крепких, самоорганизованных команд;
• создание способов программирования и команды разработки, позволяющих обеспечивать непрерывную адаптацию к изменяющимся требованиям.
В 2001 году многочисленные основатели и последователи таких методологий, включая лидеров, использующих Scrum, встретились, чтобы понять, что у них всех есть общего.
Они выбрали слово «гибкий» в качестве объединяющего термина и создали Манифест гибкой разработки программного обеспечения, в котором заявили общие ценности.
• люди и взаимодействие важнее процессов и инструментов;
• работающее программное обеспечение важнее исчерпывающей документации;
• сотрудничество с заказчиком важнее согласования условий контракта;
• готовность к изменениям важнее следования первоначальному плану.
Манифест инициировал тысячи новых гибких проектов. Результаты и опыт этих проектов дали дальнейшее развитие практическим способам применения многочисленных форм гибких подходов к разработке программного обеспечения. Как и в любой деятельности, некоторые из них оказались успешными, а другие потерпели неудачу. Но самым поразительным было то, что и бизнесмены, и технический персонал относились к работе в этих проектах с любовью. Это был именно тот способ разработки программного обеспечения, о котором они мечтали, и конечные пользователи и клиенты также были с ними согласны. Успешные проекты порождали больше последователей, и, как и при успешном спринте, этот гибкий цикл продолжается по настоящее время.
1.3. Подготовка к Scrum
После того как высшее руководство предприятия получает общее представление о деловых и культурных преимуществах Scrum и гибких способов разработки, оно часто хочет сделать следующий шаг и оценить, как этот метод разработки может улучшить их организацию.
В течение первых 15 лет жизни Scrum его применение в большинстве случаев происходило в организациях снизу вверх. Другими словами, команда, работающая над проектом, пробовала Scrum и добивалась впечатляющих результатов. Затем его пробовала другая команда, и очень скоро Scrum-проекты появлялись по всей организации. В последнее время, однако, многие организации стремятся внедрить Scrum сверху, в рамках процесса развития компании и работы по улучшению производительности и ускорению реагирования на рыночные условия.
Поскольку Scrum – это в основном расширение прав и возможностей команды разработки в принятии самостоятельных решений, его внедрение сверху требует вдумчивого рассмотрения и подготовки, которую мы опишем в этом разделе.
1.3.1. Скрамить сразу и процесс разработки программного обеспечения, и организацию
Многие организации в течение долгих лет вынуждены были преодолевать различные препятствия и терпеть недостатки. Scrum быстро их выявляет и требует их устранения. К счастью, повышение производительности и ценности, полученные в результате Scrum-проектов, делают усилия по внедрению стоящими, но это все еще усилия.
Чтобы применить Scrum, организация должна выполнить два типа работы. Во-первых, проекты, где команды разработки учатся создавать программное обеспечение с использованием Scrum. Во-вторых, устранение препятствий на пути оптимизации создания и выпуска программного обеспечения, с которыми могут столкнуться Scrum-команды. Первая работа улучшает поставку программного обеспечения, а вторая убирает помехи на пути повышения прибыльности и производительности.
Оба типа работ представляют собой вызов и требуют значительных усилий сверх обычного процесса разработки программного обеспечения. Полная реализация Scrum на предприятии может занять до пяти лет. Независимо от интенсивности усилий и желаний руководства этот график не может быть ускорен, поскольку ядро проекта – организационное изменение.
Ежедневные и ежемесячные циклы инспекции и адаптации при использовании Scrum делают все видимым: технические методы разработки, технологический процесс и организационные помехи. Проекты, использующие Scrum, регулярно выявляют препятствия, которые должны быть записаны, которым должна быть дана оценка, присвоен приоритет и в отношении которых следует принять соответствующие меры.
Скорость внедрения Scrum напрямую связана со следующим:
• степенью необходимых изменений внутри организации;
• срочностью в улучшении разработки и выпуска программного обеспечения в пределах организации;
• эффективностью руководства в рамках организации.
1.3.2. Роль высших руководителей как организационных Scrum-мастеров в процессе непрерывного улучшения
Scrum-мастер отвечает за исполнение Scrum-командой принципов и принятие ценностей Scrum. Scrum-мастер предостерегает команду от взятия на себя чрезмерных обязательств, которые невозможно будет выполнить во время спринта. Кроме того, Scrum-мастер постоянно работает над устранением препятствий на пути команды к успешной реализации целей спринта.
Руководитель – это Scrum-мастер изменений в организации.
На уровне предприятия эта работа ложится на плечи высшего руководителя, чья работа заключается в том, чтобы, находясь вне команды, устранять организационные барьеры, которые могут помешать успеху гибкой модели развития.
Цель Scrum-мастера в организации – заметить, идентифицировать и провести работу, чтобы вызвать изменение, которое устранит препятствие. То есть высший руководитель как Scrum-мастер в организации в первую очередь – действующая сила изменений, а список препятствий – это его бэклог продукта. Консультант по внедрению Scrum на предприятии выступает здесь как владелец продукта и устанавливает приоритетность устранения препятствий. Этот бэклог продукта из препятствий прорабатывается в организации с помощью команд, использующих Scrum-процесс, с описанием устраненных препятствий. Бэклог организационных изменений начинается на этапе пилотных проектов и продолжается до тех пор, пока не определены необходимые изменения в ходе оценочно-адаптационного цикла Scrum.
Scrum-мастер в организации периодически встречается со всеми Scrum-мастерами, владельцами продуктов и консультантом по внедрению для дальнейшей разработки бэклога продукта изменений в организации. Команды формируются, и это приводит к изменениям в организации во время спринта. В обзоре спринта изменениям дается оценка и формируются показатели, которые могут отражать прогресс в реализации изменений. Таким образом, высший руководитель вовлечен в процесс продолжающихся организационных изменений, направленных на повышение производительности и качества команд разработчиков программного обеспечения.
1.3.3. Предупреждение: изменение – трудная работа
Поделиться книгой: