Текст книги "Все о SCRUM. Изучение, разработка, интеграция"

Автор книги: Клод Обри

сообщить о нарушении

Текущая страница: 2 (всего у книги 3 страниц)

1.2 Agile-движение

1.2.1 Аgile-манифест

Термин Аgile, тесно связанный со Scrum, появился в сфере разработки ПО в документе под названием «Agile-манифест».

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

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

✓ Люди и взаимодействие важнее процессов и инструментов.

✓ Работающий продукт важнее исчерпывающей документации.

✓ Сотрудничество с заказчиком важнее согласования условий контракта.

✓ Готовность к изменениям важнее следования первоначальному плану.

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

Помимо четырех основных ценностей, Манифест содержит двенадцать принципов. Ниже я цитирую первый, ключевой:

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

Scrum стоит под знаменем Agile-манифеста. Два его основателя также входят в число 17 подписавших документ.

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

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

1.2.2 Аgile-практики

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

Практики, описываемые как гибкие, или Agile-практики, существовали и до Манифеста, а некоторые – задолго до него.

К примеру, еще в начале 1980-х сообщество разработчиков программного обеспечения рекомендовало совершать короткие циклы разработки (так называемая итеративная разработка).

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

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

1.2.3 Аgile-методика

Scrum и Экстремальное Программирование (XP) существовали и до Манифеста. После его подписания и публикации они стали считаться Agile-методами, в то время как другие попали в список отсталых и утратили популярность. С недавнего времени к семье Agile присоединился Kanban [7]7
  Kanban появился среди Agile-методов совсем недавно; на самом же деле Lean Software, где зародился Kanban, опирался на фундамент, заложенный еще производственной системой заводов Toyota в 1950-х годах. – Прим. авт.


[Закрыть].

Рисунок 1.4 – Быть гибким с Agile-методикой

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


[Закрыть].

1.2.4 Аgile-режим

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

Однако Scrum потерял смысл в этом Agile-режиме разработки программного обеспечения [9]9
  Как и не стоит обращаться к Scrum, чтобы войти в Agile-режим. – Прим. авт.


[Закрыть].

1.2.5 Agility

• За пределами информационных технологий

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

Scrum берет начало в разработке ПО, но сейчас широко используется и за пределами ИТ:

✓ в маркетинге и торговле;

✓ в сфере цифровых технологий;

✓ при разработке оборудования (hardware) и систем, включающих программное обеспечение.

Марк Андриссен, основатель Netscape, произнес известную фразу: софт пожирает мир.

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

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

• Аgile-менеджмент

Управление меняется. Новые подходы[10]10
  Steven Denning, Radical Management. – Прим. авт.


[Закрыть] идут в ногу с Agile-принципами.

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

• Определение Agility

Джим Хайсмит, один из подписантов Манифеста, так определяет Agility по отношению к изменениям:

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

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

Agility – это способность организации приносить максимум ценности, часто и своевременно, и адаптироваться к изменениям в своей среде.

Из этого определения ясно, что гибкость относится не только к команде, но и к организации.

• Agile организация

Принципы освобожденных компаний (liberated companies) также имеют много общего с Agile-движением с точки зрения ценностей и важности человеческого фактора.

Работа Фредерика Лалу[11]11
  Frederic Laloux, Reinventing Organizations. – Прим. авт.


[Закрыть], посвященная успешным новым организациям, выдвигает на первый план принципы бирюзовых организаций (teal organisations), идущих в ногу с Agile.

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

Рисунок 1.5 – Agility – трамплин, чтобы выбраться с галеры на свободу

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

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

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

1.2.6 Вклад системологии

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

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

Это становится ясно на практике. Многие задачи невозможно решить внутри команды. Нужно обращаться к экосистеме, внутри которой развивается команда, в частности, к отношениям с заинтересованными сторонами.

В этом издании мы разработаем системный подход к Scrum.

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

Существует множество направлений системологии: холизм, кибернетика, теория систем и т. д.

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

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

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

1.3 Скрам сегодня

Какова ситуация в отношении Scrum сегодня?

1.3.1 Scrum-мания

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

В опросах три четверти респондентов утверждают, что используют Scrum или его варианты.

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

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

1.3.2 Критика Scrum

Вполне логично, что при нынешней популярности Scrum написано много статей, критикующих его и предлагающих другие подходы.

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

Другие понимают Scrum лишь частично:

✓ Пользователи, долгое время находившиеся под гнетом директора по информационным технологиям (CIO), которые обнаруживают, что Scrum приветствует изменения, и думают: теперь можно постоянно все менять.

✓ Менеджеры, которые уверены, что Agilе-команда – на то и Agile, что может выполнять больше работы за меньшее время.

Реальность может их разочаровать. Мы постараемся дать ответ на эту критику и разочарования.

1.3.3 Scrum лично для вас

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

✓ Если вы разрабатываете приложения из категории несложных по модели Cynefin вероятно, Scrum для вас – не лучший выбор.

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

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

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

Мы за изменения, но против постоянных прерываний процесса!

1.3.4 Контекстуализированный Scrum

Концепция Shu Ha Ri была создана Алистером Кокберном (подписал Манифест и предложил использовать слово agile). Это модель развития, взятая из айкидо. Shu соответствует фазе обучения, когда ученик повторяет за учителем, не пытаясь что-либо изменить.

✓ Ha – вторая фаза обучения. Ученик берет на себя инициативу и ответственность за то, что делает.

✓ Ri – последняя фаза обучения и овладение техникой: ученик сам становится учителем и может создать новые, более высокие формы и принципы.

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

В противном случае существует риск исказить концепцию Scrum.

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

Например, во время разработки ПО дополнительно пригодятся инженерные практики из Экстремального Программирования.

Мы поговорим об этом в главе «Контекстуализация Scrum».

1.4 Scrum – живой организм

1.4.1 Scrum меняется

Иногда люди думают начать работать в формате Scrum, но источники, к которым они обращаются, не особо достоверны. И новички сталкиваются с трудностями: они когда-то прочитали книгу или статью, посещали тренинг – но знания с тех пор не обновляли.

Некоторые практики, когда-то связанные со Scrum, уже устарели: Scrum постоянно развивается.

Scrum 1995 года, описанный в статье Швабера, не имеет практически ничего общего с Scrum 3.0. Если на то пошло, первое издание этой книги, написанное в 2009 году, сильно отличается от того, которое вы сейчас держите в руках.

Несмотря на простоту (или, возможно, из-за нее), Scrum по-прежнему часто неправильно понимают. Осенью 2016 года я выступил на нескольких конференциях с темой под названием «Scrum? Срам!» (см. главу 22) о борьбе с основными ошибками при применении Scrum. Среди пяти выявленных причин ошибок и недопонимания на первом месте стояло незнание того, чем на самом деле является Scrum. Все это приводит к его искажению.

1.4.2 Превосходство Scrum

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

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

Мы рассмотрим их в основном во второй части этой книги с точки зрения системологии.

1.4.3 Языковой аспект

Знакомство с новой культурой начинается с новых слов. И Scrum имеет свой язык.

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

Словарь значительно расширился за десять лет и продолжает развиваться.

• Не переведенные термины

Такие слова, как, например, спринт, уже давно нашли место во французском словаре. И в английском, и во французском они означают одно и то же.

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

В этом списке следующие слова: бэклог, Scrum-мастер, эпик. Я объясняю, почему эти термины не переведены, в соответствующих главах [12]12
  Тем не менее, калькированный перевод этих слов на французский есть в Квебеке – Прим. авт.


[Закрыть].

• Переведенные термины

Другие термины Scrum используются в переводе. Некоторым такое использование важно, но, к сожалению, как мне кажется, это никак не закреплено правилами. В повседневной речи, а иногда даже в письменном виде можно встретить: definition of done, sprint planning meeting, sprint review, impediment. Я трепетно защищаю использование французского языка, поэтому, соответственно: критерии завершенности, встреча по планированию спринта, обзор спринта, препятствие.

Иногда появляются смешанные термины, например, приемочный тестинг, а не приемочное тестирование.

Словарь развивается с помощью терминов, которые приобретают все большее значение. Я имею в виду, в частности, такие слова как stakeholder или backlog refinement, для которых рекомендую использовать заинтересованные стороны и доработка бэклога. В этой редакции книги больше не говорю feature – теперь это функциональность.

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

Мы не используем ни скраммер, ни скрамист, когда говорим о приверженцах Scrum. Однако таких много.

Чтобы идти дальше

Книги [13]13
  Здесь и в последующих главах названия книг, не переведенных на русский язык, и имена их авторов приводятся на языке оригинала. – Прим. ред.


[Закрыть]

‣ Steven Denning, Radical Management, Jossey & Bass, 2010

2
Разделение процесса на спринты

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

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

Рисунок 2.1 – В традиционном цикле стадии различаются

2.1 Изменение парадигмы

Течение цикла зависит от используемой модели (или процесса). Во Франции по-прежнему распространена V-модель, но компании, особенно крупные, обычно берут ее за основу для дальнейшей адаптации к их контексту и создания уже своей собственной модели.

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

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

Этому есть причины:

✓ Модель разработана методологами-теоретиками и оказывается слишком удалена от реальности и неприменима на практике.

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

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

Все это давно известно.

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

В то же время возникла противоположная идея индустриализации процессов, и пришлось подождать, пока она провалится на практике.

Scrum и Аgile-методы взяли предшественников за точку отсчета и пошли дальше с моделью цикла разработки, основанной на последовательном повторении одной стадии. В Scrum эта стадия называется спринт.

Спринт с точки зрения времени – повторяющаяся стадия фиксированной продолжительности.

Рисунок 2.2 – Повторение спринта

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

Еще одно фундаментальное отличие заключается в том, что Scrum – это не более чем фреймворк. Он не определяет наполнение каждого спринта: за это отвечает команда.

2.2 Итеративный и инкрементальный подход

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

2.2.1 Инкрементальная разработка

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

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

Пока я писал эту книгу, использовал инкрементальный подход: сделал изначальный план (в виде карты мыслей), а затем писал главу за главой, не ориентируясь на порядок в плане.

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

Рисунок 2.3 – Густав Эйфель, инженер, практиковавший инкрементальный подход

2.2.2 Итеративная разработка

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

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

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

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

2.2.3 Итеративный и инкрементальный подход

Scrum объединяет оба подхода с концепцией спринта:

✓ в конце спринта появляется инкремент продукта;

✓ обратная связь на этот инкремент позволяет скорректировать цель следующего спринта.

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

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

2.2.4 Научный двухфазный подход

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

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

Lean Startup популяризировал эту концепцию тестирования гипотез и коротких спринтов для получения информации о новом продукте. Мы все постоянно слышим термин MVP (Минимальный жизнеспособный продукт, Minimum Viable Product), который, на мой взгляд, плохо отражает его суть. Ведь речь идет не о продукте, пусть даже с минимальным количеством функций, но о результате, который позволяет проверить предположения, и, следовательно, узнать новую информацию.

Если гипотеза не подтверждается, команда переключается на другую функцию продукта.

Достижение MVP соответствует окончанию стадии иследования и началу стадии эксплуатации.

С точки зрения жизненного цикла продукта, Lean Startup используется на стадии исследования, а Scrum – на стадии эксплуатации.

Рисунок 2.4 – Две стадии разработки продукта

Концепция Lean Startup предполагает малозатратный по ресурсам этап проверки гипотезы несколькими конечными пользователями.

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

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