В чем выгода использования agile методологии в цифровой трансформации

Основы Agile-трансформации

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

Чтобы достичь успеха в сегодняшней рыночной ситуации, компании должны быстро поставлять клиентам качественный инкремент продукта (product increment – «ощутимый результат работы одного спринта» (например, новая функция продукта, прототип приложения и т.д.) — te-st.ru/2017/07/04/12-terms-of-scrum).

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

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

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

Agile-трансформация – это работа по реорганизации компании, в результате которой она сможет работать по принципам Agile.

В чем смысл Agile-трансформации?

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

Смысл Agile-трансформации – как раз в устранении препятствий, которые мешают выполнению всех этих действий.

Стратегия трансформации

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

Во-первых, следует учитывать ценностные установки вашей компании в контексте планирования. Что для вас более ценно – предсказуемость поставки или способность адаптироваться к изменениям? Для большинства компаний ценным является и то, и другое, и это приводит к негативным последствиям.

Чем более вы настраиваете систему на предсказуемость, тем сложнее ее изменить. И, наоборот, чем больше вы придаете системе адаптивности, тем она менее предсказуема.

Второе, о чем стоит серьезно подумать, — это в чем заключается ценность вашего продукта для клиента с точки зрения планирования. Стараетесь ли вы понять, что нужно вашему клиенту (мы называем это открытой экосистемой – emergent ecosystem), или же вы сосредоточены только на выполнении взятых на себя обязательств (мы называем это замкнутой экосистемой — convergent ecosystem)?

Наша система координат

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

Путь к адаптивно-открытой компании часто идет через сектор предсказуемости (predictability) и замкнутости (convergence), затем через адаптивно-замкнутый сектор (convergence-adaptability) и только потом достигает адаптивно-открытой части матрицы (adaptability — emergence).

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

10 шагов к Agile-трансформации

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

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

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

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

Шаг 3. Нарисуйте дорожную карту трансформации
С какой команды, ресурса или группы начать трансформацию? Какое подразделение продолжит этот процесс? А кто его поддержит затем? Мы должны рассказать компании о том, что мы собираемся делать, сколько времени это займет, и что мы рассчитываем получить взамен вложенных инвестиций. Мы называем группы, которые проходят трансформацию, экспедициями, а промежуточные результаты, которых они достигают – базовыми лагерями (basecamps).

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

Шаг 5. Проводите промежуточную проверку результатов каждые 30 дней
Наподобие цикличности спринта, вам нужно периодически оценивать продвижение трансформации, проводить ретроспективы и корректировать процесс.

Шаг 6. Адаптируйтесь и учитесь
Пересмотрите видение конечного состояния, основываясь на том, как эволюционировало ваше понимание успеха в процессе Agile-трансформации.

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

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

Шаг 9. Управляйте коммуникациями
Регулярные и прозрачные коммуникации по поводу успехов и трудностей, с которыми сталкиваются лидеры трансформации, создадут позитивную атмосферу и придадут вам энергии. Такие встречи часто проходят в формате общего собрания, круглого стола с руководством и других видов информационных встреч.

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

Дорожная карта Agile-трансформации

Для успешной трансформации большой и сложной компании абсолютно необходима дорожная карта Agile-трансформации. Подход «как-нибудь-разберетесь-на-ходу» тут просто не сработает. По нашему опыту, успешные трансформации проходят по вот такой дорожной карте:

С чего начать: сформируйте видение конечного состояния

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

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

Трансформация начинается: пилотный проект и запуск

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

Поддержание непрерывности изменений

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

Автор: Тим Зак, прирожденный айтишник, уже более 10 лет решает маркетинговые задачи с помощью технологий. Компетенции Тима охватывают стратегическое планирование, UX, аналитику, автоматизацию маркетинга, контент-маркетинг и поисковый маркетинг. Одним из его преимуществ является опыт работы в различных отраслях.

Источник

1.2 ПРЕИМУЩЕСТВА AGILE

Уже на второй месяц реализации проекта команда поняла, что нужно разделить работу на более короткие периоды (спринты), чтобы медперсонал видел результаты. Они начали работать недельными интервалами. Сделанное тут же показывали не только главврачу, но и всем сотрудникам того блока, в котором шла автоматизация. Кроме небольших еженедельных успехов пользователям демонстрировали крупные «прорывы», и это стало решающим фактором для успеха всего проекта. Одной из таких побед стала генерация автоматического выписного эпикриза. Это было важно, потому что после завершения рабочего дня врачи часто вынуждены были заполнять выписные эпикризы и тратили до получаса на эпикриз каждого пациента. После внедрения новой системы эпикриз на каждого пациента формировался автоматически за 5 секунд! Это был переломный момент.

Еще один пример масштабной победы из практики компании «Софт-М» касается очереди в стационар, когда удалось сократить время ожидания для пациентов с трех месяцев до 10 дней во всех подразделениях.

Достигнутые победы были важны и для поддержания мотивации внутри команды. Как убедились участники проекта, они действительно делали нечто нужное и значимое. Примечательно, что слова «Agile» команда тогда не знала, хотя и использовала элементы гибких подходов (короткие итерации, доску с задачами проекта и каждого сотрудника, регулярные демонстрации продукта), которые начинали постепенно проникать в практику управления проектами. Так, фактически они работали по Agile, с успехом преодолели сопротивление пользователей и создали информационную систему, которая с тех пор успешно внедряется во многих медицинских учреждениях по всей стране.

Уже на второй месяц реализации проекта команда поняла, что нужно разделить работу на более короткие периоды (спринты), чтобы медперсонал видел результаты. Они начали работать недельными интервалами. Сделанное тут же показывали не только главврачу, но и всем сотрудникам того блока, в котором шла автоматизация. Кроме небольших еженедельных успехов пользователям демонстрировали крупные «прорывы», и это стало решающим фактором для успеха всего проекта. Одной из таких побед стала генерация автоматического выписного эпикриза. Это было важно, потому что после завершения рабочего дня врачи часто вынуждены были заполнять выписные эпикризы и тратили до получаса на эпикриз каждого пациента. После внедрения новой системы эпикриз на каждого пациента формировался автоматически за 5 секунд! Это был переломный момент.

Еще один пример масштабной победы из практики компании «Софт-М» касается очереди в стационар, когда удалось сократить время ожидания для пациентов с трех месяцев до 10 дней во всех подразделениях.

Достигнутые победы были важны и для поддержания мотивации внутри команды. Как убедились участники проекта, они действительно делали нечто нужное и значимое. Примечательно, что слова «Agile» команда тогда не знала, хотя и использовала элементы гибких подходов (короткие итерации, доску с задачами проекта и каждого сотрудника, регулярные демонстрации продукта), которые начинали постепенно проникать в практику управления проектами. Так, фактически они работали по Agile, с успехом преодолели сопротивление пользователей и создали информационную систему, которая с тех пор успешно внедряется во многих медицинских учреждениях по всей стране.

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

Источник

Agile-разработка: преимущества и «подводные камни»

Вопросы, рассмотренные в материале:

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

История возникновения Agile-разработки

Немногие знают, что целенаправленно заниматься созданием программного обеспечения и управлять проектами начали еще в 1970-х годах. Так, в 1970 году в Америке программист Уинстон Ройс написал работу, которая получила название «Управление развитием крупных программных систем». В своих трудах Ройс раскритиковал последовательный принцип разработки программного обеспечения, указывая на то, что процесс разработки ПО не следует отождествлять с работой сборочной линии на заводе, где новые детали поочередно добавляются в общую конструкцию.

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

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

Перечислим несколько ключевых открытий:

После этого в 2001 году на американском курорте произошла встреча ведущих разработчиков программного обеспечения. В качестве итогов обсуждения методов разработки был напечатан «Манифест о гибкой разработке ПО Agile» (в переводе с английского слово «agile» означает «подвижный», «быстрый» или «гибкий»). Данный документ и стал базовым руководством в деле дальнейшей разработки программного обеспечения.

Топ-3 статей, которые будут полезны каждому руководителю:

Идеи и принципы Agile-разработки

«Манифест о гибкой разработке ПО Agile» позволяет понять, что такое Agile-разработка и включает в себя четыре ключевых установки и 12 принципов эффективного управления проектами. Именно поэтому все системы управления по методологии Agile основываются на одинаковых установках и принципах (несмотря на то, что вариации их использования могут быть разными).

Приведем основные установки методологии разработки Agile:

Далее перейдем к принципам гибкой Agile-разработки:

Особенности применения Agile-разработки

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

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

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

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

Разработка по методологии Agile чаще всего начинается с разделения всего объема работ на небольшие составные части. Это значительно упрощает рабочий процесс и позволяет каждой группе сфокусироваться на порученной ей задаче.

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

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

Все время, отведенное на разработку проекта, делится на несколько спринтов, к примеру, на 10. Все спринты имеют одинаковую продолжительность (допустим, 7 дней). И на протяжении каждого периода участники должны ежедневно встречаться друг с другом для обсуждения прошедших и предстоящих работ.

При этом длительность одной встречи не должна быть больше четверти часа. Во время таких встреч каждый специалист должен ответить себе на три основных вопроса:

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

Сегодня данная методология наиболее распространена в IT-сфере (Agile-разработка сайтов и ПО), однако рассматриваемый подход постепенно завоевывает и другие области: обучение, маркетинг, бизнес. Гибкая система управления проектами начинает все чаще применяться в частных компаниях и государственных организациях.

Так, методы разработки Agile используют: правительство Новой Зеландии, компания Return Path (программное обеспечение), компания Oreo (занимается производством сладостей), компания Aviasales (крупный продавец авиабилетов), крупнейшая российская финансовая организация «Сбербанк».

Эти и многие другие предприятия довольно успешно применяют в своей работе самые разные методы, основанные на Agile.

Преимущества и недостатки Agile-разработки

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

Во-первых, Agile-управление обладает максимальной гибкостью. И если традиционная разработка предусматривает конкретные этапы работы, Agile без труда подстраивается под потребителя конечного продукта и любые запросы клиента.

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

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

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

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

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

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

Как внедрить Agile-разработку

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

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

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

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

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

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

2 метода управления, альтернативные Agile-разработке

1. Scrum.

Эта платформа, разработанная в 1986 году, считается наиболее структурированным членом семейства Agile. Scrum включает в себя как элементы традиционного подхода, так и гибкие идеи проектного управления.

Использование Scrum подразумевает деление проекта на части, которые могут использоваться заказчиком для получения ценности. Такие части называются заделами продуктов (product backlog) или, как привыкли говорить в российской практике, беклогами. Беклог разделяется на эпики (блоки функциональности) и беклоги релизов. После разделения беклога продукта на беклоги релизов и эпики, они приоретизируются совметно с представителями заказчика.

Наиболее важные части проекта первыми отбираются для выполнения в спринте (аналогичные используемым в Agile временные промежутки, длительность которых варьируется от 2 до 4 недель). По окончании спринта заказчик получает готовую часть проекта и может начинать использовать ее в своих целях.

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

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

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

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

Механизм действия Scrum-методологии основан на проведении пяти основных встреч:

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

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

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

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

Так, в ходе каждого спринта члены рабочей команды добавляют новые тестовые функции на сайт и избавляются о тех, которые пригодились клиентам меньше всего. Разработчики Netflix уверяют, что главное достоинство Scrum в возможности совершения «быстрых ошибок»: вместо долгой и изнуряющей подготовки крупного релиза небольшие поставки по Scrum осуществляются каждые 14 дней. Такие поставки легко отслеживать и исправлять ошибки в случае необходимости.

Scrum-методология предъявляет очень высокие требования к участникам проектной команды. Рабочая группа должна быть небольшой (от 5 до 9 членов) и кросс-функциональной – т. е. все участники команды должны обладать познаниями в нескольких актуальных для разработки проекта сферах. К примеру, разработчик программного обеспечения должен также разбираться в тестировании и бизнес-аналитике. Такой подход позволяет задействовать всех членов команды независимо от специфики текущих работ, а также дает возможность сотрудникам подменять друг друга и оказывать взаимопомощь.

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

И последнее. Методология Scrum может не подойти для разработки некоторых продуктов, к примеру, промышленного станка или строительного объекта.

2. Kanban.

Данный подход был разработан инженером компании Toyota Тайичи Оно в 1953 году. По своей сути Kanban напоминает производственный процесс, который начинается с кусочка металла и заканчивается готовой деталью. То есть разработка проекта осуществляется поэтапно: инкремент продукта передается вперед до тех пор, пока не получится необходимый заказчику элемент.

Стоит отметить, что создателю Kanban нравился принцип организации работы супермаркетов и их кредо: «держи на полках только то, что нужно клиенту». Поэтому данная методология позволяет оставлять некоторые поставленные задачи незавершенными (в случае, если они неактуальны в данный момент времени и есть другие срочные задачи).

Работа по методологии Kanban гораздо лояльнее, чем по Scrum – здесь отсутствует распределение ролей, да и время спринтов не ограничивается жесткими рамками. Согласно установкам Kanban, член рабочей команды даже может выполнять несколько задач одновременно (что абсолютно недопустимо в Scrum). Кроме того, в основах Kanbab отсутствует информация о необходимости встреч по поводу обсуждения статуса проекта, т. е. их проведение вовсе не является обязательным.

Работа в Kanban начинается с определения этапов потока операций (workflow). Они выглядят как столбцы, а задачи обозначаются специальными карточками. Карточка, подобно заводской детали, перемещается по этапам как по конвейеру, и процесс ее завершения возрастает пропорционально количеству пройденных этапов. В итоге получается готовый элемент продукта, соответствующий все требованиям заказчика. Панель со столбцами и карточками может быть как настоящей, так и электронной, – Kanban никак не ограничивает свободу действий в данном вопросе.

Методология Kanban в вашей организации может быть настолько гибкой, насколько вы сами этого захотите, однако у нее тоже есть 4 базовых установки:

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

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

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

Источник