Enbisys meetup november 2017 — Evolution of Scrum in Enterprise project

Автор Nikita Stoianov
Enbisys meetup november 2017 — Evolution of Scrum in Enterprise project

Всем привет.

Меня Алексея. Я работаю в компании. НДС Сегодня я хотел бы поговорить о организации процесса разработки в энтерпрайз проектах я расскажу как мы начали использовать скраб подход в нашем проекте о том как он нас менялся со временем.

Ну и почему мы в конечном счете пришли в начале пару слов о самом проекте.

Мы работаем над крупные медицинской энтерпрайз системой система существует в 2005 года мы пришли в 2009 году нам досталась кучу унаследованного кода. Система состоит из порядка 15 приложение которое строится 70 модулей большая база данных сотни таблица больше 1000000 строк кода в 2010 году мы начали использовать скрам. И как я уже сказал этот процесс у нас менялся со временем. Ну условно в рамках этой причине мы делим его на две фазы, а особенности энтерпрайз системы с точки зрения процесса разработки ну во-первых у нас есть план каждые три месяца мы уходим в релиз у нас крупные. Эпики которые занимают от месяца до полугода, а иногда даже больше и мы не можем позволить себе уйти в продакшн с незаконченным эпиком, но медицинская система и мы не можем выкатывать функциональность по частям процессы должны работать полноценно. Ну и общая сложность сложность предметной области сложность кода ведет к низкой предсказуемости большим риском. А до 2010 года у нас был. Хаос и анархия в организации процесса. Ну 2010 года мы решили перейти на скрам и мы пришли в начале использовать классический вариант. То есть у нас есть блок который заполняет продукт оунер 2 недельные спринты есть planning meeting на котором мы обсуждаем даём оценки этих Store планируем спринт запускаем этот спринт у нас с разработки ежедневный стендапы проверка состояния давно и по окончанию спринта у нас происходит ретро и этот процесс продолжается и через каждые три месяца мы уходим в релиз. Ну очень быстро мы поняли, что у нас слишком много мы пытаемся впихнуть в planning. То есть я обсуждение истории есть заполнение спринта и так далее. У нас поэтому у нас появилась ещё одна фаза — это груминге на которых мы обсуждаем Store происходит. Она каждую неделю. Мы также даем эстимейты оценки история, а после этого мы поняли, что для груминга — это слишком много поэтому. Пошли к одной фазе на которой мы определяем состав userstory. Дело в том, что ну изначально. Это задача product owner и product owner не всегда может хорошо определить, что он может дать общее описание, что мы хотим. Но определение выделения. История — это задача в которой так или иначе в нашем случае должна участвовать команда поэтому мы, но опять же использовать всю команду. Это неэффективно нерационально поэтому product owner и тимлид собираются вместе и описанию Epica выделяют Store, а какие у нас возникли проблемы с использованием этого подхода. Ну во-первых — это непредсказуемые задачи которые портят постоянно портят на — это Buddy задача связаны с выходом в продакшн изменение требований неверной оценке история, но и. Последний пункт довольно получалось так, что по окончании груминга. Мы понимали, что мы не готовы оценить эти задачи мы не готовы создать Store и получилось так что. Когда мы планируем спринт у нас просто недостаточно стоит, а ну вот по поводу Burn Down Chart у нас иногда они были достаточно красивые на самом деле мне составило большого труда найти такой красивый burndown среди 150 с лишним. Ну иногда они были вот такие непонятно, что тут происходит. Яна какие-то такие похожие на кардиограмму не очень здорово человека. Ну, а иногда и совсем всё плохо у нас получалось, а дальше, но есть ещё одна проблема более глобальная — это несоответствие понимание процесса с точки зрения команды и понимание процесса точки зрения компании. Ну или скажем менеджмента компании. Дело в том, что спринт — это не тоже самое, что релиз как я уже говорил раньше мы не можем позволить себе Continuous Delivery и о компании есть Release Plan каждые три месяца компания хочет выпустить определённо функциональность в следующем релизе, но компания не понимает, что такое спринты, что такое — это чуждо менеджмента и, что получалось в результате, а мама спрашивает. Сможем ли мы выпустить этот happeak эту функциональность следующем релизе. А Мы отмечаем, но нам надо всё — это разбить no-store всё — это оценить Story Point и, тогда мы всё — это посчитаем и, тогда он скажет, но иногда product owner тратил неделю на описание всего Epica потом ещё тратить массу времени на оценку его ждать или нет мы не можем. Ну хорошо либо можем. Но потом всё равно. Всё всё идёт не так и всё — это и всё — это не получается. А ну и несколько лет мучились пытались как-то исправить эти проблемы. Но в конечном счете пришли к выводу, что проблема наверное всё-таки не внося проблема в процессе мы задали себе простой вопрос зачем нам нужна спринты если они не воспринимаются никем команды и если мы не можем обеспечить хороший качественный контроль над ходом спринта и, тогда мы подумали про. Канбан словах карбоната потоковые процессы разработки когда задачи поступают в общий список разработчики берут задачи из этого списка. Я сейчас хочу углубляться в детали в можно ознакомиться с литературой но. Для нас. Для нас переход на. Канбан означал три основных пункта — это принтов мы уходим от Splinter Store добавляются походу процесса в любой момент и мы осуществляем контроль через скорость выполнения Store. Давайте посмотрим, что у нас получилось.

0 комментариев
0

Читайте также