Про SCRUM. Мухи и котлеты, или истина все же где-то рядом?

В последнее время можно все чаще услышать о загадочном и красивом термине с гордым названием SCRUM.

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

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

Была произведена внезапная инспекция ближайшего книжного лабаза, в результате которой на личной полке появилась книжка с говорящим названием «SCRUM с Team Foundation Server 2010. Профессиональный подход». Авторы: Стив Резник, Бьйорк Аарон, Майкл де ла Маза. /Приятно, когда простые русские парни пишут книжки для простых русских парней!/

Как понятно из названия, рассказывается не только о самом процессе и методологии SCRUM, но и о навороченном инструменте продвижения и реализации этой самой методы – TFS 2010 (TFS, на самом деле, много для чего можно использовать).

Возможности TFS – отдельная тема (Артем, ау!!! I'm looking forward to see the improved version of your presentation!). Здесь же хотелось бы остановиться на основных родовых признаках процесса SCRUM. И дать свои комментарии и впечатления по поводу.

Итак, что же декларируется в SCRUM-методологии:

1) Тесное (я бы сказал, неразрывное) взаимодействие разработчиков ПО с бизнесом и пользователями.

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

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

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

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

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

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

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

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

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

Однако утверждать, что такой подход — исключительное достоинство SCRUM, не совсем верно. В любом «живом» проекте периодически возникают вопросы и сомнения, несмотря на самые подробные (казалось бы) FSD и BRD. Поэтому в правильно организованном проекте всегда налажен хороший контакт с пользователями/бизнесом, и пользователи достаточно правильно мотивированы, чтобы оперативно и вдумчиво реагировать на все уточняющие вопросы разработчиков, а не делать формальные отписки и отговорки.

2) Каждый спринт – это фактически полноценный проект.

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

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

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

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

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

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

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

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

Все сказанное можно в большой степени отнести к любой качественной и опытной команде в независимости от применяемой проектной методологии и процессов (SRUM, MSF, OpenUP, Waterfall и др.).

3) Нацеленность на функционал.

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

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

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

4) Минимум проектной и сопроводительной документации.

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

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

Бэклог – таблица/список/набор записей на засаленных листочках (нужное подчеркнуть) с так называемыми сценариями использования (user stories). Эти сценарии-истории оформляются в довольно произвольной форме в терминах и выражениях, максимально понятных пользователям и заказчику. Это могут быть короткие, весьма расплывчатые заметки, сноски, а могут быть достаточно подробные и детальные описания отдельных элементов и функционала будущей системы.
А дальше — задача Владельца продукта вербально донести все это до разработчиков на понятном для них языке. И при необходимости — детализовать эти требования до необходимого уровня в процессе регулярных сессий-встреч (иногда по отдельности с разработчиками или пользователями, иногда совместно, когда присутствуют все заинтересованные стороны). Все эта детализация происходит на этапе планирования и подготовки к старту очередного спринта.

Ну и самое главное – Владелец продукта составляет (как правило — параллельно с ведущейся разработкой) подробные планы тестирования и сценарии тестирования для каждого из  приближающихся спринтов. С детальным определением, что пойдет на вход каждой функции, и что должно получиться на выходе. С максимальным перечислением возможных комбинаций значений параметров и вариантов реакции системы. Фактически, речь идет об отложенном документировании. Процесс документирования получается разнесенным во времени и по дистанции проекта.
А то, что сценарии тестирования есть не что иное, как документирование системы (причем достаточно скрупулезное), лично у меня не вызывает никаких сомнений.

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

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

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

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

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

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

В качестве примера из наших трудовых будней можно привести старт проекта РНО. Когда Паша и Володя потратили несколько дней на разработку тестового приложения, подтверждающего правильность выбранной ими архитектуры разработки. 
Речь идет о возможности «подружить» Ваадин с механизмом удаленного вызова веб-сервисов.
До того момента в среди специалистов в конторе бытовало устоявшееся мнение, что это нереально и «так не бывает». Паша и Володя это мнение опровергли на практическом работающем примере. По сути, (если оперировать терминологией SCRUM) был применен классический спайк. Хотя, понятно, никто в тот момент не заморачивался ни на какие скрумы и спайки:)

Другими словами, беру на себя смелость утверждать о применимости гибридной модели. Тем более что, если проанализировать многие реальные проекты, то выяснится, что этот самый гибридный подход там зачастую по факту и применялся. Возможно, при этом не звучали слова «SCRUM» или “MSF”, но сути дела это не меняет.

5) Универсальность членов SCRUM-команды (команды разработчиков).

Команда, отвечающая за разработку и поставку ПО не имеет такого четкого разделения ролей, как это принято при более традиционных подходах. Т.е там нет выделенных ролей аналитиков, разработчиков, архитекторов, специалистов по СУБД и оптимизации.

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

6) Сплоченность команды. Общая, не дозированная по ролям, ответственность за результат.

В SCRUM-процессе определяются три роли. Владелец продукта, Руководитель команды, и собственно, Команда разработчиков.

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

Руководитель команды – это такой массовик-затейник, аниматор, вдохновитель, переговорщик. Балабол-собеседник, короче (молчать, поручик!!!).

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

Он проводит ежедневные утренние собрания-летучки (минут на 15-20), где проговаривается все, что накипело и касается текущего спринта, планов на каждый конкретный день.

Ну а Команда разработчиков отвечает за выполнение, реализацию, спринта. Ее задача – выполнить контракт с бизнесом на заданном спринтом отрезке времени.

Удача или провал спринта – это консолидированная ответственность.

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

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

Т.е. команда в SCRUM – это такой своеобразный кулак, монолит, в хорошем смысле слова.

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

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

Понятно, что велик соблазн действовать по сценарию «Я свою часть работы сделал, весь такой Дартаньян и вообще пушистик по жизни. Вот были бы все такими же, так вообще – проекты сдавали бы в два раза быстрее и качественнее.»

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

Дабы не быть голословным, есть у нас такой вялотекущий чудо-проект, А-Лизинг называется. Заказчик там настолько, мягко говоря, своеобразный, что периодически возникает непреодолимое желание отправить его в пеший кругосветный эротический круиз. Чисто по-человечески подобное желание можно понять. Но, с другой стороны, работа у нас такая. Надо стремиться соблюдать необходимый баланс и соблюдать компромисс — не давать окончательно садиться на шею, но и дело совсем не стопорить. Лично у меня не всегда получается, бывает подаю коллегам плохой пример, вот Катя не даст соврать. Надо работать и расти над собой.

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

Однако что-то мне подсказывает, что истина, как водится, — где-то посередине, и в реальной жизни может быть творческий симбиоз подходов, задекларированных в SCRUM (Agile) и более традиционных методологиях.

Как уже отмечалось в ИМХЕ выше, многие декларации и намерения SCRUM на поверку используются (в той или иной степени) в тех же Rational UP, MSF и OpenUP.

А действительно классический и весь из себя традиционный Водопад (Waterfall) в чистом виде уже давно мало кто применяет. Во всяком случае, в сфере разработки и поставки ПО.

Аминь.

P.S.

Нельзя не отметить: по законам диалектики заявленные преимущества SCRUM могут стать его же потенциальными слабыми местами.

Например, Владелец продукта. Его роль в процессе переоценить трудно. Он определяет лицо конечного продукта, его начинку, качество тестирования, взаимоотношения с Заказчиком. Случись чего (болезнь, знакомство с кирпичем, семейные обстоятельства, ссора с Заказчиком, да мало ли), и судьба проекта — сразу под большим вопросом. То же самое — в команде разработчиков. SCRUM предполагает, что чем дальше в лес, тем третий лишний: сплоченность команды, взаимопонимание ее участников неуклонно растет, от каждого в отдельности очень много зависит. В идеале разработчики должны понимать друг друга с полунамека, без лишних слов. Соответственно, в SCRUM критически важно сохранить состав до конца проекта.

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

P.P.S. Хотелось бы добить высказыванием с Хабра, может быть слегка эмоциональным, но довольно точно передающим актуальные  тенденции ИТ-индустрии:

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

Попробую раскрыть, что я имел под этим ввиду — недостаточно найти классную идею, умных разработчиков, пронырливого маркетолога и богатого инвестора. Это добра сейчас навалом. Ключевая идея в том, что все, точнее даже так, ВСЕ БЛЕ*ТЬ, должны работать прозрачно друг для друга и понимать, зачем они друг другу нужны.

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

Отсюда на самом деле вытекает известная фраза — «В любой непонятной ситуации — эволюционируй». А именно: учи новые практики, автоматизируй процессы, меняй культуру и так далее. Лень это делать — давай досвидания, тебя скоро попросят с этого рынка. Все это я бы хотел обсудить в комментах...

http://habrahabr.ru/company/scrumtrek/blog/184320/

    Предыдущие статьи из категории: Навеяло

  • Сергей Вильянов. Карьерный тупик
  • С изумлением наблюдаю за одной карьерной историей. Вот есть некий человек, который долго-долго сидит на определенной позиции. Именно сидит — уверенно, […]

  • Мы и гномы
  • ... Если представить нашего врага как дракона, который похитил у нас нашу Родину, то мы только-только ранили его. Он еще […]

  • О Легенде номер 17
  • Посмотрел “Легенду номер 17”. Впервые за долгое время фильм, описывающий события советской эпохи, не вызвал чувство омерзения и гадливости (не […]

  • Удивляются одаренности сотрудников Альфа-банка
  • Все же ребята из “Альфа-банка” совершенно отмороженные дебилы. Я недавно писал о том, как какая-то киса взяла у них кредит […]

  • Схема спасения банков
  • Схема спасения банков Кипра за счет средств частных инвесторов станет моделью для будущих пакетов помощи в рамках еврозоны, заявил министр […]

Вы можете оставить комментарий, или Трекбэк с вашего сайта.

Оставить комментарий

Вы должны Войти, чтобы оставить комментарий.