В «Syberry» мы не гонимся за конкретной методологией и не являемся апологетами Agile, RAD или вариации Waterfall. Конкретная методология выбирается исходя из специфики проекта и требований заказчика. Но с нами приключился интересный опыт перевода одного из наших проектов с итеративного процесса на Agile, и мы хотим им поделиться.

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

Читать далее

Спасти «Титаник». Или рядового Райана (смотря какой фильм вам больше нравится)

Начнём с того, что для одной компании из США некий подрядчик занимался разработкой и поддержкой Energy Management Solution. Это система ERP-класса, являющаяся основой бизнеса клиента. Подрядчик благополучно зафейлил свою работу, чуть не утопив «Титаник», т. е. компанию заказчика. Клиент решил сменить вендора и инициировал поиски нового, способного оказывать качественный сервис, отвечать за сроки и держать обещания.

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

Немного об Energy Management Solution

Главная задача системы — обеспечение конечных клиентов (это в основном крупные компании) информацией об объёмах, структуре использования и стоимости потребляемых ресурсов (электроэнергии, воды, газа и т. п.). Система позволяет импортировать, экспортировать, смотреть статистику и цены, делать регрессионный анализ, сравнивать затраты по периодам, составлять отчёты и все остальные bells and whistles. Пользуются системой как сотрудники заказчика (менеджеры/операторы), так и сотрудники клиентов заказчика.

Какие задачи перед нами стояли

Здесь всё красиво укладывается всего в три пункта (на первый взгляд):

• поддержка клиентов (пользователей со стороны заказчика и конечных пользователей системы);
• обеспечение стабильности работы системы (в основном, импорта и экспорта данных);
• переработка системы, разработка новых фич.

Он сказал «Поехали!» и залип

Мы изучили систему, переняли знания и опыт от предыдущего вендора, включая его ошибки, собрали команду и… хочется сказать «Погнали!», но нет. Мы немного залипли.

При детальном рассмотрении задачи оказались совершенно разнородными: нужно было фиксить мелкие баги, стабилизировать систему, пилить новые фичи — причём несколько сразу, как маленькие — до недели разработки, так и большие — вплоть до 4 месяцев и более. И всё это на фоне подозрительного отношения сотрудников заказчика к новому подрядчику, т. е. к нам. Понятно, что сказывался негативный опыт работы с предыдущим разработчиком. Вдруг эти тоже те ещё «спасатели»?

Раскладываем по полочкам свой тернистый путь

Что мы сделали такого, чтобы всем сразу стало легче:

• разделили команды разработки и поддержки;
• выстроили процессы поддержки (порядок обработки запросов клиентов, SLA времени доступности и реакции и т. д.) и согласовали это с клиентом;
• приоритизировали бэклог.

Что мы сделали, но лучше б не делали:

• попытались параллельно доставлять фиксы и фичи;
• старались быстрее передавать новый функционал клиенту, иногда в ущерб качественному тестированию и документированию;
• пусть и временно, но всё же сильно сократили объём проводимого код-ревью;
• писали всё новое на основе всего старого.

И что вышло? В гонке «вооружений» мы уделили мало внимания переработке кода и архитектуры, и это привело нас в точку накопления технического долга. Здесь уместно сказать «Упс…». И сейчас нам всё равно нужно перерабатывать код и архитектуру некоторых значимых частей проекта, но мы с этим справимся. Кто не натирает мозоли, тот не узнает дороги.

Что бы стоило сделать сразу (ретроспективная оценка):

1. посадить технического писателя и бизнес-аналитика описывать существующие процессы (суперсложная задача, потому что у клиента на это катастрофически не хватало времени, а иногда даже знаний о том, как именно организована бизнес-логика работы тех или иных модулей системы и какие имеются зависимости);
2. проводить внутрикомандные демки по каждой доставленной фиче (это могло бы помочь быстрее делить знания между разработчиками, тестировщиками и другими участниками проекта);
3. начать внедрять гибкие подходы (более строго следовать Agile, Scrum’у или Kanban’у — мы, конечно, старались, но делали это частично, будем честны).

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

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

Привет, Agile-манифест!

Как в нашем случае работали четыре главных ценности манифеста:

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

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

Плюшка: внутренние митинги с командой позволяют быстро и незатратно делиться ценными сведениями по проекту (главное — не дать им скатиться в базар).

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

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

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

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

В нашем кабинете есть доска, на которой мы отображаем текущее состояние задач (in testing, in analysis и т. д.). Кроме этого у нас есть напоминания о дедлайнах, а также блок визуализации ценностей клиента и основных его проблем. Глядя на неё, команда чётко понимает, что нужно иметь ввиду при работе над каждой задачей.

В команде проекта на данный момент 15 человек, и мы решили разделить её внутри на Feature-teams (группа разработчиков, работающих над одной крупной задачей). Мы много митингуем. Смеётесь? Вот зря. Дейли-митинги, ретромитинги, митинги по командам — всё это дает отличное понимание того, на каком свете проект в любой момент времени, и помогает ориентироваться, куда мы идём и как туда попадём.

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

Когда мы решили внедрить Kanban, команда была настроена скептически. «Что??? Стикеры? Зачем? Ерунда какая!». Гораздо спокойнее в процессе работы пилить и чтоб никто не трогал — каждый трудится исключительно под свою ответственность. Но такой подход чреват возрастающим уровнем стресса: чем ближе к релизу, тем больше срывов.

Буквально за пару недель Kanban всем «зашёл». Участники проекта включились в игру, всем стало интересно переклеивать задачи, копить у себя в колонке «Done» побольше стикеров. Сейчас мы не представляем, как раньше обходились без этого. Теперь на доске можно увидеть и такое:

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

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

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

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

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

С точки зрения PM’а, это настоящий ужас. Из-за узкой специализации людей нельзя было переключать между задачами.

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

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

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

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

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

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

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

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

Грабли: ретро-митинг должен быть более объёмным, чем просто обсуждение проблем, иначе он может превратиться в способ демотивации команды.

Ошибка в том, что мы пытались за короткий период времени, от ретро до ретро, решить все проблемы, и это, увы, не удалось. Теперь мы обсуждаем идеи команды в другом формате: выбираем наиболее важные (голосуем, используя dot-voting), причём только 3 штуки (чтобы гарантированно успеть до следующего ретро), вместе придумываем, что можно сделать, чтобы решить вопрос. Раздаём «лайки» за заслуги (помощь коллеге, деливери важной фичи, фикс, давно бесящего всех, сложного бага и т. п.) и дополняем всё это игрой (agile-сообщество богато на такие вещи и щедро делится с желающими, также можно использовать тимбилдинговые или бизнес-игры).

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

Мы только-только внедрили новый вид ретроспективы, но команда уже оценила его эффективное отличие от старой версии.

К чему мы всё это рассказали

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

На нашем пути теперь стоят новые задачи:

1. Разработка и внедрение системы автоматического распознавания первичных документов, чтобы исключить ручной труд узких специалистов из далекой Индии.
2. Оптимизация системы с помощью внедрения новых технологий (например, мы уже попробовали использовать OLAP-кубы для пре-агрегации данных, изучаем механизмы прогноза потребления и стоимости).
3. Интеграция с различными сторонним системами и модный нынче Machine Learning.

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

Фото: компания Syberry

Эта публикация подготовлена в партнёрстве с компанией ООО «Сайберри СиАйЭс».

Что такое партнёрский материал?

Место солидарности беларусского ИТ-комьюнити

Далучайся!