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

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

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


Чтобы лучше оценить ситуацию:

Итак, ситуация:

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

Кодовая база на тот момент составляла уже сотни тысяч строк, тестов было минимальное количество, автоматизации никакой. В Git-e использовалось две ветки master на продакшене и dev в разработке, естественно было множество проблем при больших сливаниях и т.д. Постепенно скорость внедрения новых фич упала практически до нуля. Руководство просило хоть как-то оценивать сроки, но по сути, любые оценки были пальцем в небо.

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

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

Было понятно, что надо что-то менять.

Начало

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

Внедрение

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

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

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

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

Процесс

Если до этого момента все шло относительно хорошо, то тут начались проблемы. Программисты в целом поддерживали Scrum, но когда дошло дело до планирования — начались возражения вида «Зачем столько времени тратить на болтовню?», «Целый день бестолку сидим в переговорке», но конечно самый шок был у всех, когда я заикнулся о Daily Scrum — «Каждый день болтать — ужасно», «Каждый сам может посмотреть все в джире/битбакете», «Если кому интересно — он спросит».
Было понятно, что вводить что-то надо постепенно, и дело тут не в том, что процесс был навязан «сверху», нет, люди хотели изменений, но такое было выше их сил.

Мы начали с введения спринтов и да, планирования.
Мы объединили бэклоги всех подсистем в один и постарались расставить приоритеты. Наши первые user-story представляли из себя старые таски, они могли быть чисто техническими и тд. Оценивали в story points, за основу взяли шкалу степеней двойки, но конечно изначально оценки разнились в разы. Первые спринты у нас длились неделю, некоторые не одобряли такие короткие спринты, и такую частую «болтовню», но те, кто меня поддерживали, понимали, даже на неделю мы пока не могли запланировать все точно, о больших спринтах пока не могло быть и речи.

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

Еще несколько недель мы продолжали работать в таком режиме, я старался обратить внимание на то, что спринт это именно итерация, а не просто отрезок на пути. В конце концов было найдено более менее хорошее решение. Мы разделили ретроспективу и планирование и разнесли их на разные дни, во вторник ретро, в среду планирование, между этими встречами, программисты решали разные RND задачи, те, которые было еще рано как-то оценивать, посколько было не ясно, что делать. Но самое главное, между ретро и планированием было запрещено работать над задачами прошедшего спринта. Это тоже сначала не понравилось, потому что незаконченный код оставался и забывался, однако эта мера принесла свои плоды. Команда начала понимать, что незаконченные в спринте задачи — реально не закончены, они могут быть забыты, оставлены на неопределенный срок и т.д.

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

Другой большой бедой стало то, что несмотря на две недели изучения, люди все-таки плохо знали «чужие» проекты.
Во-первых, на планировании задачу по проекту А человек, который его разрабатывал оценивал в 4 балла, а остальные в 16 и 32. Приходилось долгое время объяснять, что оценка должна учитывать то, что задача может оказаться у человека, который раньше с этим проектом не работал.
Во-вторых, разработчики стали активно пользоваться тем, что Scrum предлагает членам команды самим выбирать себе задачи.Таким образом, программист обычно старался взять себе задачу по «своему» проекту, чтобы не заморачиваться с чужим кодом. На несколько недель, нам пришлось в вести правило, что тебе запрещено брать задачу из «своего» проекта, если на доске есть другие. Было недовольство, но, надо сказать, оно быстро сошло на нет, как только люди достаточно изучили весь код.

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

Развитие

Медленно, но верно, мы двигались в сторону правильного и хорошего процесса, который помогал нам работать.
Через пару месяцев мы ввели Daily Scrum (стендап), назначили его на 12:00, потому что к этому времени обычно все уже были на работе (у нас очень гибкий график). Долгое время на стендапе каждый просто называл задачи над которыми работал, и это было не очень полезно, но прошел какой-то период адаптации и команда стала реально обмениваться полезной актуальной информацией о проблемах и прогрессе.
Спринты стали двухнедельными, мы научились лучше оценивать задачи и смогли себе это позволить. Оценки на планировании стали совпадать в большинстве случаев, а когда они не совпадали мы могли все обсудить и, чаще всего, придти к общему мнению.
Процент чисто технических задач в бэклоге стал постепенно падать. И все чаще задача представляла из себя именно User Story.

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

Мы стали использовать Git Flow, настроили Jenkins чтобы прогонять автотесты при каждом коммите, стали мерить покрытие кода и стараться его улучшать. Количество хотфиксов, которые в начале могли занимать пол спринта, стало сокращаться. Качество продукта, а главное настроение наших пользователей существенно улучшилось. Мы проанализировали где у нас слабые места в процессе разработки и придумали как поступить с долгими Code Review.

Наши дни

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

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

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

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