Картошка с укропом

Рассказы о разном

Ещё один Agile

| Comments

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

О чём проект

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

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

Как было

Начну, пожалуй, с того, что опишу процесс поставки функциональности до того момента, как меня вбросили в эту “мясорубку”.

Когда я пришел, только-только закончилась разработка версии 0.11, которая длилась около 6 недель (могу ошибиться в точной цифре). Но во время “реструктуризации” людьми, которые были знакомы с проектом, было принято решение отойти от набирания фичей в версию. Бизнес выдвигал требования к продукту с очень большой скоростью, требования так же быстро менялись, и нужно было отвечать этому возможностью быстро реализовать ту или иную функциональность. Работая по версиям, мы могли доставить новые требования только через месяц. Это редко устраивало владельцев продукта.

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

Стоит заметить, что никто не собирался разрабатывать версию 0.11 так долго. Всё планировалось закончить за 2-3 недели. Но постоянные изменения, которые не терпели отлагательств и не могли быть отложены ещё на месяц, включались в релиз. Это влекло за собой увеличение времени разработки всего релиза.

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

Приоритезированный Backlog

Начали активно покрывать тестами контрольную карту и поставили перед собой задачу выкладываться на production один раз в неделю. В Jira тогда было сложно разобраться, что к чему и какой приоритет у какой задачи. Да, каждой задаче была присвоена категория приоритета (от trivial до blocker), но когда у тебя 200 major задач, то не понятно, какая задача из списка приоритетней. И в этом списке, конечно же, будут более приоритетные задачи (потому что они более полезные, выгодные) и менее приоритетные.

После пары дней копания в этом пекле ко мне на глаза попал плагин к Jira - Greenhopper. Я его и раньше видел, но сейчас это была уже новая версия, избавленная от тех проблем, которые были в первой версии. Это было просто открытие, и в тот же день я сделал доску. В первом столбце (Backlog) разместились все задачи в порядке убывания приоритета. Задачи с приоритетом Critical и Blocker размещались в отдельных свимлэйнах в самом верху доски. Про колонки, которые были, расскажу позже.

Все новые задачи создавались без приоритета и попадали на самое дно бэклога. Один раз в неделю я вместе с владельцем продукта (Product Owner) размещали задачи в том месте бэклога, которое больше всего отвечало её приоритету.

Всё было хорошо, пока мы не столкнулись с тем, что задачи застревают в нашей “трубе”.

Засор трубы и прочистка

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

  • Backlog - всё понятно;
  • BA in Progress - сюда попадали задачи для бизнес-анализа. Макеты, спецификации, дизайн;
  • BA in Review - здесь жила задача, которую “проверяли” на соответствие всего;
  • Behating и Behating Review - написание автоматических тестов и ревью их разными членами команды;
  • Ready For Dev - тут складывались все задачи, у которых готов дизайн, бизнес-анализ;
  • Assigned - задача назначена разработчику;
  • In Progress, Ready for QA, QA in Progress, Deployment - всё понятно из названия и ничего особенного тут не происходило. Проблем с этими колонками за всё время не было.

Так вот, получалось, что после прохождения первых четырёх колонок задача застревала в Ready for Dev, потому что бизнес-аналитики и QA, которые писали приёмочные тесты, пропускали задачи через себя скорее, чем это делали разработчики. Через какое-то время в Ready for Dev скопилось около 30-ти задач, и это уже было похоже на второй бэклог. Задача, которая попала в Ready for Dev, будет сделана “непонятно когда”, потому что там есть другие. Непонятен был сквозной приоритет, очень много ньюансов приходилось держать в уме.

Но на помощь пришли лимиты. Мы поставили лимиты на все колонки до In Progress в зависимости от количества человек, имеющих влияние на задачи в этих колонках. И очень жестко ограничили количество в “буфере” Ready for Dev. Теперь там могло быть не более 7-ми задач.

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

Да, были некоторые неудобства вначале. Но потом все запомнили это правило.

Что же нам это дало? Это помогло вернуть понимание, что задача взятая в работу будет выдана на production через прогнозируемое количество времени и не застрянет где-нибудь посредине.

Конечно, застревающие задачи были. В Greenhopper количество дней, проведённых в колонке, отмечается точками внизу задачи и потому легко раз в день окинуть взглядом доску, понять, какие задачи лежат в своих статусах слишком долго, и дать этим задачам “волшебный пендель”.

А чтобы взять новую задачу в работу, нужно передать дальше предыдущую.

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

Общие собрания

Ежедневные по утрам

Ещё одним важным пунктом процесса можно назвать собрания (митинги, как их часто называют). Когда я пришел на проект, в команде было 11 человек. Утром мы все собирались и говорили о том, кто что делает, с какими проблемами столкнулся и как будет решать. Стандартный такой утренний stand up. Но когда через какое-то время в команде стало уже 20 человек, это было уже не так эффективно и пришлось это поменять. Теперь на доске были выписаны все critical задачи и весь утренний разговор был построен вокруг них. Через какое-то время список сэволюционировал в табличку - когда будет на production, что за функциональность, кто замешан в разработке. Как только дата подвергалась сомнению, она изменялась, выяснялись причины и оповещались все заинтересованные лица (заказчики фичи), если это было необходимо. Либо мы фокусировались на задаче и пытались всеми правдами и неправдами выпустить её в тот срок, что был заложен изначально - уходили в production с какими-то багами или выкидывали что-то из функциональности. Так как команда была выкоквалифицированая, то и сроки были зачастую правильные.

На протяжении дня

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

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

Один раз в неделю

Проект уезжал на production два раза в неделю, во вторник и четверг. Кажду пятницу, вечером мы собирались всей командой и я показывал, что мы сделали за эту неделю и что, в результате, попало на production. Презентация эта длилась не более получаса. Как это нам помогало? Всё просто - каждый член команды знает о том, что было сделано и для чего. Даже если потом будут вопросы, все будут знать, кто разрабатывал ту или иную функциональность и какую проблему она решает. Это также помогало людям, разрабатывавшим большие куски системы (по 2-3 недели), понимать что происходит на проекте.

Прибзительно один раз в месяц

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

Спонтанные желания собраться

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

Лучше меньше да побыстрее

А ещё мы делали всё с упором на минималистичность. Слышали про MMF (minimum marketable feature)? Так вот, мы старались следовать этому. Наши новые фичи должны были иметь необходимый минимум функциональности, который решит проблему. Никаких комбайнов, никаких “было бы хорошо сделать ещё вот это”. Почему? Потому что сделав что-то за 2 дня, мы уже на 3-й получим обратную связь и сможем добавить то, чего действительно не хватает. А если бы мы делали всё по принципу “было бы хорошо сделать ещё вот это”, то доставили бы это на production через недели две, а потом бы выяснилось, что всё равно “этим невозможно пользоваться” и нужно добавить то, чего действительно нехватает. Это Agile, не надо этого бояться.

Выводы

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

Заключительное слово

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

Comments