что такое capacity в agile
«Гибкая разработка»: кратко о методологиях Agile
Разработка программного обеспечения — это труд, который требует своевременного принятия правильных решений. CTO, архитекторы, тимлиды и сами разработчики регулярно делают выбор в пользу тех или иных инструментов, платформ и фреймворков.
Но все принимаемые решения нужно как-то «синхронизировать». Один из резидентов Hacker News отметил, что ему приходилось наблюдать за тем, как пяти сотням разработчиков в одной крупной компании разрешили самостоятельно принимать некоторые решения в «отрыве» от команды. По его словам, это был хаос. И хотя команда начала работать быстрее, она двигалась в никуда, потому что позднее возникали проблемы на этапах поддержки ПО.
Чтобы избежать подобных ситуаций, используется семейство процессов гибкой разработки. Их внедрение позволяет руководству компании повысить заинтересованность и мотивацию сотрудников, а также ускорить доставку продукта заказчику. В последнее время эта тема приобретает все большую популярность, потому что на некоторые методологии Agile обращают внимание общественности главы крупнейших корпораций.
Поэтому мы решили начать серию постов о «гибких» методологиях, чтобы еще раз рассмотреть их особенности, сравнить варианты и помочь вашим компаниям оптимизировать процессы. Сегодня мы говорим о Scrum, канбан и экстремальном программировании.
Scrum
Scrum — это фреймворк гибкой разработки ПО, который считается методологией «по умолчанию». Для многих является синонимом Agile. По статистике за 2016 год, предоставленной VersionOne, Scrum используют 58% «гибких» компаний. При этом её поддерживают многие SaaS-платформы. Например, решение ServiceNow, частью которого является инструмент Agile Development.
Методология была разработана в конце 80-х — начале 90-х годов. Процесс управления состоит из фиксированных коротких итераций — спринтов (sprints).
Используя методологию Scrum, представитель заказчика плотно работает с командой разработки, расставляя приоритеты в списке требований к продукту (Product Backlog). Этот список состоит из баг-фиксов, функциональных и нефункциональных требований — из всего, что нужно сделать для реализации рабочего приложения.
Функциональные элементы, добавляемые в бэклог, называют историями. Каждая задача оценивается в определенное количество очков. Очки являются абстрактной метрикой и для её оценки могут использоваться самые разные шкалы (например, ряд Фибоначчи или степени двойки).
На основании списка требований заказчика команда определяет функции, которые хочет реализовать, и начинает свой спринт. Обычно он длится 30 дней. В конце подсчитывается общее количество очков, набранных командой за спринт (скорость). Это позволяет более четко планировать следующие спринты.
За последние десять лет программисты Кен Швабер (Ken Schwaber), Майк Бидл (Mike Beedle) и Джефф Сазерленд (Jeff Sutherland) приложили множество усилий для развития Scrum. Кен Швабер — наиболее активный сторонник фреймворка, и его сайт — хорошее место, чтобы начать свое знакомство с методологией. Он также выпустил книгу.
Scrum за все время существования приобрел огромную популярность и используется командами разработчиков даже в крупных компаниях. Однако сообщество за это время выявило и определенные её недостатки.
Например, среди них отмечают чрезмерную ориентированность на набор очков. При планировании, команда отбирает истории, которые она сможет завершить к концу спринта, руководствуясь скоростью предыдущего этапа. Основная цель этих очков — сделать планирование более надежным и предоставить четкую перспективу.
Однако здесь скрывается проблема: поскольку работа разработчиков оценивается в баллах, они будут стараться заработать их побольше и оптимизировать под это свою деятельность. Что не приводит к улучшению кодовой базы, не делает её проще.
Другая проблема — длительные митапы. Причем совещания проводятся синхронно со всеми участниками разработки, что становится проблемой для специалистов, работающих удаленно. Людям приходится встраивать многочасовые совещания в свое расписание для обмена информацией, которую можно передавать иным способом.
Что касается неизменности историй во время спринта, то в больших масштабах это также приводит к проблемам. У программистов нет возможности перераспределить работу при обнаружении новых особенностей. Scrum не позволяет перестраивать корабль прямо во время плавания, поэтому приходится ждать окончания сессии, чтобы внести изменения.
Extreme Programming
Особенность Scrum заключается в том, что этот фреймворк уделяет мало внимания практикам разработки. Поэтому некоторые agile-компании (порядка 10%) комбинируют его с экстремальным программированием (XP).
Экстремальное программирование привлекло к себе внимание в конце 90-х. Концепция зародилась в сообществе Smalltalk, а её авторами считаются разработчики Кент Бек (Kent Beck) и Уорд Каннингем (Ward Cunningham), которые хотели сформировать новые практики в разработке ПО, сделанные для людей.
Первым проектом, созданным по методологии Extreme Programming, стала система контроля платежей Chrysler Comprehensive Compensation (C3) в середине девяностых. Сам термин «экстремальное программирование» появился в 1997 году.
Концепция строится на основании двенадцати приёмов:
Однако Extreme Programming делает сильный упор на тестирование, что отличает её от Scrum. Методология гласит, что разработчик не может сказать, что код написан правильно до тех пор, пока не пройдут все модульные тесты. Поэтому часто XP идет рука об руку с техникой разработки Test Driven Development (TDD), когда сперва пишется тест, а затем логика для его прохождения.
Но такая «тестоориентированность» одновременно и недостаток подхода. Чтобы адаптировать XP, нужно инвестировать в создание инфраструктуры автоматизированных тестов и непрерывного развертывания ПО.
При этом, если в случае Scrum компания может послать менеджеров проектов на двухдневные курсы, то в случае с экстремальным программированием приходится тренировать всю команду разработчиков. Что гораздо более затратно. Нужно менять культуру в организации, объединяя несколько отделов: XP требует, чтобы тестировщики, UI-дизайнеры, программисты, архитекторы и пользователи работали сообща.
/ Flickr / U.S. Army / CC
Канбан
Scrum по-прежнему остается эффективной методологией, которая пользуется популярностью. Особенно в комбинации с экстремальным программированием. Вместе их процент использования среди Agile-команд достигает 68%.
Однако сегодня многие команды рассматривают иные варианты и обращают внимание на другие методологии. Одной из них стал канбан. CTO ConvertKit Грант Аммонс (Grant Ammons) говорит, что компании сперва адаптируют Scrum, который учит их необходимым дисциплинам для разработки ПО, а затем ищут более удобную альтернативу и обращаются к канбану.
Канбан — это техника для управления разработкой, где процесс разработки рассматривается как конвейер с запросами на реализацию функций, с которого сходит улучшенное программное обеспечение.
Канбан зародился как часть системы производства Тойоты «точно вовремя», поэтому методология исключает излишнее накопление задач. Например, если тестировщики проверяют пять функций за неделю, а разработчики и аналитики реализуют десять, то «общая пропускная способность конвейера» ограничивается до пяти функций. Это нужно, чтобы избежать накопления работы у QA-команды, иначе они могут начать «срезать углы» и случайно пропустить на рынок некачественный продукт.
В этом случае также можно провести перераспределение ресурсов: когда программисты и аналитики выполнили свою норму, они могут помочь с тестированием и написанием автоматизированных тестов. В будущем это позволяет повысить пропускную способность конвейера.
И канбан легко выявляет такие узкие места. В своей простейшей реализации — это большая доска с расчерченными столбцами, в которых размещаются стикеры-карточки. Столбики — это этапы процесса разработки, а стикеры — рабочие задачи. Цифры вверху каждого столбика показывают, сколько карточек разрешено в нем «копить».
Однако, как отмечают в сообществе HN, у такого подхода тоже есть определённые недостатки. В том же Scrum короткие спринты положительно сказываются на мотивации разработчиков. Программисты знают, что работа над продуктом закончится, когда весь список требований на 30 дней будет выполнен. В случае с канбаном — это постоянный и нескончаемый поток заданий. Однако есть выход — краткое обсуждение списков задач на неделю (или две).
Также ввиду своей специфики, канбан плохо подходит для долгосрочного планирования и неудобен в работе для крупных команд разработки (больше пяти человек).
Напоследок отметим, что использование Agile-методологий накладывает серьезные требования на опыт членов команды и их способность эффективно взаимодействовать друг с другом. При этом каждая более или менее распространенная методология имеет свои сильные и слабые стороны, а также области применения. По этой причине появляются новые фреймворки и дорабатываются «старые».
Как рассказать что такое Agile на заводе? Топ 5 самых популярных Agile-практик
Если оторваться от Хабра, заглянуть в реальную российскую компанию старше 30 лет и больше чем с тысячью сотрудников и произнести слово Agile, то реакция будет как минимум настороженная. Люди там уже слышали истории похожие на «Как рассказать бабушке» или «Как рассказать дедушке» и посмотрели все выступления Грефа, получили с десяток предложений внедрить гибкость за неделю, кто-то из сотрудников даже поработал год со Scrum, но остается один вопрос:
«Что с этим нам делать то, у нас из программирования только сайт?»
В итоге примерно для 100% компаний Agile смахивает на шарлатанство.
Но вот парадокс — в мире 77% компаний*, использующих Agile в проектах, занимаются совсем не разработкой программного обеспечения.
Под катом практика того, как Agile становится понятным в крупных компаниях и проектных командах без разработки. Мы делаем систему управления проектами, но когда общаемся с относительно крупным клиентом напрямую, большую часть времени обсуждаем гибкую методологию и подходы к автоматизации управления проектами. Этим опытом хочется поделиться.
Вместо определения. Что сказать про Agile, когда собрались разные люди из разных отделов
Agile — это не метод разработки программного обеспечения. Википедийные определения плохо годятся для понимания, если ты не разработчик.
Это принципы организации проектной деятельности и применим он в любой области. На практике самое чувствительное отличие для людей — это уход от иерархии и исчезновение одного центра генерации точно описанных задач. Это командная работа с ролями, ответственностью за общий результат и плоской структурой взаимодействий.
Команда в игре «Что? Где? Когда?» существует по принципам Agile. Взаимодействиям отдана ключевая роль. Капитан выполняет роль заказчика продукта (верного ответа), 2-3 эрудита перебирают массивы информации, кто-то следит за временем, есть человек, который анализирует, задает вопросы и побуждает общение, любой может высказаться и привести к результату или все провалить, за пределами игры есть разбор полетов (ретроспектива).
Противовес Agile — это конвейерный (каскадный) метод с жесткой иерархией и точными задачами поставленными как можно ближе к SMART. По этим принципам в «Что? Где? Когда?» капитан должен был бы раздавать точные задачи — кому в каком направлении думать и пытаться собрать это в ответ. Каждый участник должен был бы соблюдать приличия и высказываться когда дойдет очередь. В случае провала нужно было бы кому-нибудь понизить мотивацию или уволить и принимать это решение будет капитан.
Главной причиной появления и развития Agile является то, что все больше проектов не имеют 100% понимания, что должно быть в конце. Расписать точные задачи попросту невозможно. И решили, что свободные взаимодействия важнее инструкций, а готовность к изменениям важнее планов.
Гибкие методологии — это ответ на неопределенность; до конца неизвестно, что нужно сделать и что должно получиться в результате. Казалось бы, а что непонятного в разработке, например, сайта или в строительстве дома или в приготовлении гамбургера в Макдональдсе? Эти проекты поставлены на поток, где неопределенность?
Но. Даже если вы веб-студия и для вас это тысячный сайт, для клиента это первый раз. И его желания останутся неопределенностью до самого конца. Многие студии делают 3-4 варианта главной страницы и закладывают неделю на непредвиденные доработки. У всех, кого я знаю, работа разбита на итерации, после каждого есть демонстрация и обсуждение. Общение с заказчиком важнее подписанного контракта.
В строительстве дома есть план-проект, расчет материалов и трудозатрат. Но почему-то сроки всегда затягиваются. Бывает, что фундамент плывет, или стяжка пересыхает, начинает что-нибудь трескаться или брус влажноват или кирпич слишком пористый или цемент привезли не той марки или клиент передумал и решил, что теперь это будет баня. Прораб — это человек оркестр, решает все, что всплывет, постоянно отступая от плана ради результата. Нормальный дом гораздо важнее описания.
Хорошо, в изготовлении гамбургера в Макдональдсе нет никакой неопределенности. Процесс отработан за 70 лет и воспроизведен в 125 странах. Да, это конвейер, куда лучше не влезать с гибкостью. Agile не применим в хорошо отлаженных годами процессах. Правда, открытие нового ресторана по очень точной франшизе — это всегда уникальный проект. Где к месту будет итеративный подход, сокращение итераций, распределение ролей, открытое взаимодействие, визуализация проекта на Agile-доске, ретроспектива, ежедневные планерки.
Итого ключевые ценности Agile (манифест):
Что такое команды с ролями?
В привычной команде есть две роли: Начальник и Подчиненный, один умный другой дурак. В Agile принципиально важны три: Заказчик продукта, Методист, Участник команды.
В упрощенной форме:
Заказчик — рассказывает какой продукт нужен, для чего он нужен, устраивает обсуждения вокруг запросов с рынка, принимает решения по приоритетам.
Методист — следит за тем, чтобы заказчик не превратился в начальника. Ну и еще за выполнением остальных практик, например, чтобы все задачи были с оценкой или чтобы оценки задач не превышали 80% от имеющегося времени, если есть такая договоренность.
Команда — оценивает, распределяет и реализует задачи. Всегда демонстрирует версию продукта, а не отдельные выполненные кусочки.
Если совсем упростить, то в Agile обязателен человек, который следит за тем, чтобы команда получала максимальное количество информации о требуемом продукте во всех деталях с разных сторон и принимала активное участие в обсуждении как реализовывать.
Не получала поставленную задачу как директиву свыше, а описание и понимание того, что должно быть сделано для пользователя, когда продукт будет разработан.
Со стороны гибкая команда от привычной отличается именно наличием или отсутствием так называемого повествовательного диалога (narrative collaboration).
Если идет обсуждение вопроса «Как реализовать продукт?» на всех уровнях, значит команда гибкая. Если ищут кто виноват, что не выполнен список конкретных задач, значит все как обычно.
Главный вопрос: «Как управлять ресурсами когда все так гибко?»
Все эти рассказы про ответственные команды и истории появления метода воспринимаются как полная фигня, если нет ответа на вопросы:
«А как точнее управлять ресурсами?», «Как раньше понять, что в проекте ресурсов стало не хватать для окончания?», «Мы всегда ставили и распределяли задачи по исполнителям и могли прогнозировать результат, а что теперь?». Что бы рассказать про Agile, можно раскрыть только этот вопрос.
Надо отметить, что вообще весь Agile сконструирован именно для решения вопроса с ресурсами «Как эффективно управлять ресурсами в проекте с непредсказуемостью» Методология бы не родилась, если главной задачей был бы комфорт и свобода людей в команде.
Есть несколько важных принципов и методов, явно направленных именно на прогнозирование ресурсов:
1. Наглядность необходимых ресурсов. Agile-доски неразрывно связаны с методологией. Это когда задачи распределены по колонкам, а колонки определяют этап находящихся в них задач. Это самый наглядный инструмент визуализации состояния проекта. В идеале, любому стороннему человеку должно быть понятно на какой стадии находится проект и сколько осталось до конца. Если всем вдруг станет очевидно, что не хватает ресурсов или надо сменить приоритеты, это произойдет само собой.
Вопросы предсказуемости результатов и управления приоритетами решаются именно за счет наглядности.
2. Приоритеты и бэклог. При планировании учитывается, что не все задачи удастся закрыть за выделенный отрезок времени. Всегда есть список того, что надо сделать обязательно и того, что сделать хорошо бы (это и есть бэклог). Приоритеты проставляет команда в обсуждении с внутренним заказчиком продукта. Если так случается, что остается время, решаются задачи второй степени важности, если не успевают закрыть даже задачи с отметкой Обязательно (Critical) команда напрягается дополнительно.
3. Короткие итерации (спринты). Этот подход, как никакой другой позволяет компаниям пробовать что-то из Agile. Руководство согласно на промежуточный результат через пару недель без того, чтобы влезать и всем проставлять задачи. Согласиться на такой режим работы на полгода было бы невозможно.
Спринт (итерация) — это отрезок времени в несколько недель. У нас чаще всего это 2 недели. Самое важное в спринте — это определение того, какой промежуточный результат должен быть получен. Этим результатом хорошо называть итерацию, например, «Выпуск досок с правами» или «Выпустить сайт на тест». Если работа идет по отрезкам времени, но каждый отрезок не приводит к какому-то конкретному результату, то это уже не итерационный подход.
4. Оценка задач в размерах футболок. Люди не слишком любят давать точные оценки задачам, но оценивать примерно, по шкале большая, средняя, маленькая для большинства нормально. Ниже самые популярные в мире способы оценки задач без высокой точности. С процентами по частоте использования.
Мы используем третий, но оценки бывают только 1h, 2h, 4h, 8h.
Смысл подхода в том, чтобы уйти от попытки ловить кого-то на неточных оценках своих работ. Они и так с самого начала примерны. Фокус на то, что бы за спринт каждый стремился набрать максимальное кол-во балов, которые примерно связаны со временем.
5. Burndown chart (график сгорания)
Очень простая вещь — это график с двумя линиями; первая — сколько времени сгорело и это всегда прямая, на второй — сколько задач в пересчете на ресурсы закрыто и тут возможны колебания. Фактически это графический ответ на вопрос идет ли команда по плану или отстает.
Здесь изложены только общие подходы без деталей, возможно, стоит написать отдельный материал с подробностями управления ресурсом. Но если резюмировать здесь в две строчки, то получится:
Топ 5 самых популярных Agile-практик понятных всем
Еще раз подчеркну, Agile на базовом уровне применения — это просто. Нет никаких сверхсложных приемов, которые надо долго изучать. Ниже для примера приведено 5 самых популярных практик (по данным все того же опроса от VersionOne)
Все они применимы в проектах из любой области и достаточно просты для мгновенного использования. Все объединены общей идеей итерационного подхода.
1. Итерационное планирование — спринты (90% команд используют)
Работать небольшими забегами с промежуточным результатом — хорошая практика. Спринт — это несколько недель. Слишком короткие или слишком длинные отрезки — плохо. Одинаковый интервал на все случаи жизни тоже не годится. У спринта должна быть максимально точная цель, исходя из этого и определяется длительность.
Самый частый ошибкой является то, что команды привыкают просто расписывать задачи раз в две недели, теряются процессы постановки промежуточных целей и подведение итогов в конце. Работа сваливается в обычный поток задач с обновлением раз в спринт. Проблему должен решать методист.
2. Ежедневные планерки (88% команд используют)
Задача — чтобы каждый день команда подтверждала единое направление движение всех участников.
По классическому описанию каждый в команде раскрывает три вопроса:
Что сделано к этому моменту из спринта?
Что планируется на сегодня?
Какие проблемы возникли или что мешает?
По нашей практике это быстро надоедает командам и становится рутиной или формальной отчетностью. Что помогает:
Менять время планерки — 6 мес. утром, 6 мес. вечером.
Каждый раз менять ведущего планерки, не должно быть лица перед которым отчитываются. Отличный вариант если ведущий разыгрывается жребием.
Заказчик продукта, делиться историями о клиентах в начале планерки.
Обсуждать общие темы и только потом переходить к вопросам.
Не пускать на планерки никого кроме участников команды.
3. Ретроспективы (83% команд используют)
Совещание в конце итерации. Обсуждение, что получилось, а что не очень. Самая важная цель — сделать выводы о том, как меняться.
Заказчику продукта — о том, как лучше показывать ожидания пользователей, методисту — о том, как побуждать диалог и выполнять договоренности выбранных подходов, команде — о том, как при оценках учитывать новые открывающиеся факторы.
Как правило, ретроспективы проходят весело — итерация-то закончилась, можно выдохнуть и обсудить итоги. Хорошая практика что-нибудь пить или есть в перерывах этого процесса.
4. Итерационные показы (81% команд используют)
Это демонстрация от команды раз в несколько итераций результатов проекта, как правило, в виде выступления. Главный смысл в том, чтобы была «сессия» и ничего страшного, если это станет похоже на отчетность перед руководством.
Главная трудность в том, чтобы собрался кто-то кроме команды, да еще и понимал смысл происходящего. По нашей практике приживается только при очень крутом руководстве.
5. Короткие итерации (71% команд используют)
Смысл в том, что нужно постоянно стараться сокращать цикл получения маленьких промежуточных результатов. Если этого не делать, циклы будут естественным образом расти или будет постоянными, независимо от промежуточных целей. Чем короче цикл, тем меньше ошибок при итерационном планировании.
Это задача методиста, стоит вспоминать про это хотя бы раз в полгода.
Как понять ведется ли проект по Agile-методологии или еще нет?
Диаграмма того, сколько компаний меняют Agile под себя выглядит так:
Гибкость подхода распространяется и на сам подход. Это первое, что стоит узнать команде, если им предстоит стать гибче. Нельзя быть на 100% Agile, выполняя все предписания. Никто строго не соблюдает правила в чистом виде, на практике у каждой компании есть свои модификации.
Самые популярные методы из Agile внедряются легко, дают результаты и не перевернут компанию с ног на голову. Именно по этой причине 98% использующих что-то из Agile говорят об успешности подходов.
Если начать, например, с утренних планерок, то ничего страшного в команде не произойдет, но простой ежедневный диалог людей внутри проекта делает процесс гибче.
Комбинация гибкости и жесткости всегда индивидуальна и зависит от множества факторов: руководителя, сложности проекта, размера команды, бюджета и тд. Но если осмысленно внедрен хоть один подход, то эта компания работает по Agile-методологии и будет не лишним гордо сообщать об этом внутри коллектива.
P.S. Опрос: Agile в России 2017
В статье приводится несколько фактов о распространении Agile в мире, взятых из опроса от компании VersionOne.
Проблема в том, что эти данные имеют мало общего с нашей действительностью.
Мы в YouGile проводим большой опрос о гибкой методологии в России.
Результаты обязательно будут опубликованы на Хабрахабр.
Как мы познакомились с Agile & Scrum
Введение
Не в коем случае не хочу утверждать, что это гайд по тому, как вводить Scrum, — это лишь опыт введения и адаптирования Scrum’а под нужды одной компании. Данный опыт может быть интересен/полезен, как новичкам: основные наводки, этапы, циклы и т.п., так и профессионалам: обсудить что пошло не так, чего делать не стоило и т.п. Подчеркну, то что у нас вышло — это лишь нечто напоминающее Scrum.
Предыстория, с чего все началось, как пришли к тому что нужен Scrum
Я работаю руководителем IT-отдела (менеджером проектов) в одной маленькой/средней томской фирме. Численность работников в IT-отделе на начало деятельности: 5 человек, на данный момент: 24 человека.
На начальном этапе я был геймдизайнером, но постепенно перекочевал в стан проект менеджеров. Примерно, это случилось летом 2014 года, данное время и будем считать начальной точкой.
Как и большинство начинающих управленцев, я ринулся изучать материалы: искать в интернете, смотреть записи конференция, читать книги, общаться со старшими собратьями из других фирм, приобрел кучу знаний, как я считал на тот момент (это естественно было ошибкой). И я, амбициозный и одухотворенный новыми целями и задачами, ринулся в бой.
Я считаю основной проблемой начинающего управленца: отсутствие или неправильная коммуникация с работниками. Причин этой проблемы может быть много: отсутствие опыта, недоверие со стороны работников, незнание основных технических/бизнес процессов и т.п. Но мне повезло в данном вопросе. Изначально я тесно работал с разработчикам, являясь геймдизайнером, а до этого я немного поработал программистом при полном отсутствии менеджмента, поэтому у меня было некое видение чего же не хватает.
Как все было до Scrum
Изначально у нас был развернут старенький Redmine без всяких плагинов и настроек, можно считать его практически чистым, TeamCity (бесплатный) для обеспечения хоть какого-то билдинга, SVN, куда же без репозитория. В Общем все работало.
Задачи ставились в redmine, по мере выполнения проставлялись часы а иногда и проценты выполнения, но зачастую не было ни сроков ни каких-то планов, очень везло, если был хотя бы обговоренный dead-line.
И тут настало мое время. Руководство дало мне добро на применение всего, что душе угодно (принесет больше прибыли). Как я уже писал выше — это лето 2014.
На тот момент с Agile мы были еще слабо знакомы, университетский курс и пару статей. Поэтому у нас еще не возникало мыслей о какой-то гибкости, и мы начали действовать по старинке (возможно, мысли возникали, но отсутствие опыта и что-то еще не давало им пробиться дальше). Изначально мы зафиксировали наши основные задачи на досках, которые у нас висят практически в каждом кабинете. Выглядело, это примерно так:
Естественно все было перенесено и в электронный вид: по некоторым задачам зафиксировано в redmine в виде feature или epic, по некоторым в старом добром Excel, также поставили важность и приблизительные сроки выполнения задач. Потом мы приступили к декомпозированию и оценке задач с каждым работником, который будет выполнять задачи. Получился набор feature с sub-tasks и оценкой сроков выполнения задач. Получился своеобразный backlog, но с ним дальше нужно как-то работать, сам по себе он не дает результатов.
Диаграммы Гантта
За некоторое время до этого я сталкивался с Диаграммами Гантта (ленточные диаграммы) в фирме, в которой работал программистом. Сделал пару диаграмм по нашим проектам, наброски показал руководству, и эта методика им понравилась. И я приступил к изучению инструментов, которые позволили бы мне в наилучшем виде сделать эти самые диаграммы.
Мной были опробованы:
В итоге, потыкавшись с некоторыми программами и время от времени их меняя, мы несколько месяцев вели проекты с активным использованием диаграмм Гантта. Руководству это все нравилось, они видели четкие и утвержденные планы, и, вроде как, все устраивало, за исключением небольшого НО (большого).
Это НО, Руководство и не только: маркетологи, отдел продаж и т.п. постоянно продавливали какую-либо разработку в план в самые неподходящие моменты. Это приводило к тому, что нужно было полностью перестраивать план и смещать задачи разработчиков, с придумыванием новых задач на время простоя, если такое появлялось. Когда в команде было мало человек, то особых проблем не возникало, сдвинуть пару человек ничего особо страшного, но когда от завершения одной задачи стало зависеть более двух человек, а иногда пропихивания приводили к тому, что задачи вообще исчезали, то перестраивать планы стало проблематично.
Вот тут то и возникла потребность в чем-то ином.
Какие потребности были
Собрав feedback от руководства и главных действующих лиц компании, был сформирован некий список того, что же хотелось увидеть:
Что рассматривал еще
Почему Scrum удовлетворяет потребности
Как донес до всех
Основные концепции разработчики и так понимали из статей, так что с ними проблем практически не возникло, все восприняли с энтузиазмом. Основной проблемой было руководство, но так как оно в процессах практически не участвует, то нам и карты в руки.
Как изучил? Что смотрел? Какие ресурсы? Какие книги?
Общение с профессионалами
Мы общались с менеджерами из других фирм, узнавали, что и как у них. Смотрели какие отклонения от нормы они делали, смотрели, как и что может быть применено у нас. Сказать честно: особо ничего не почерпнули. Основной вывод: все действуют, как им заблагорассудится (какой Agile удобен для них).
Чтение статей
Нами было пересмотрено кучу статей, какие именно фигурировали, вспомнить уже никто не может. Но их было множество. Времени на это было выделено предостаточно. Естественно все упирается в Agile Манифест, большинство статей и сайтов ссылаются на него, так что мы не стали исключением, и брали его, как первоисточник. (ссылка есть в источниках и ссылках)
Чтение книг
Начало внедрения
Документ с основными мероприятиями
Расписали основные мероприятия и сформировали небольшой список с описанием действий, раздали всем работникам для ознакомления. На тот момент он был, естественно, далек от совершенства. (ссылка есть в источниках и ссылках)
Карты
Естественно нужно было где-то достать карты для Poker-planning. пересмотрели в интернете ряд магазинов, стоимость колоды для четырех человек варьировалась от 1000 рублей до 2000 рублей. Денег просить у руководства мне особо не хотелось, и поэтому я их сделал сам. Обычная бумага А4, черно-белый принтер, ножницы, — вот что вышло:
Множество раз пытался их переделать, цветной принтер, картон и многое другое, но эти старые добрые карты (не в полном составе) служат до сих пор.
Интересный факт. Надеюсь я ничего не перепутал. Один из немногих на тот момент магазин по продаже колод карт, который мне мне понравился — planningpoker.ru. Подумал тогда, какие же прикольные карты. Позже, спустя несколько лет на конференции директор фирмы, которая организовала этот магазин, подарил мне одну из таких колод совершенно случайно. (ссылка есть в источниках и ссылках)
Доска
Следующий важный этап, это подготовка Scrum-desk, взял обычные ватманы, пару А3 и А4, маркеры, скотч и др. И получилось довольно таки неплохо:
Что получилось в результате подготовки
Первый опыт, первый sprint
Backlog
Первый backlog мы строили в MS Excel, разбили все, как нужно на колонки:
Естественно, присутствует еще ряд колонок, которые не вошли на рисунок, но это другая история. Подчеркну, у нас получились именно задачи (feature), а не пользовательские желания (user-story), как это принято в Agile. Первый sprint было принято решение сделать двухнедельным. Расставили приоритеты, отсортировали, пометили зеленым, что хотелось бы взять на sprint, расставили story-points. Хм, что такое story-point?!
Как довел до сведения разработчиков. Story-point — день
На систему оценки в story-points — идеальные человеко дни, перейти достаточно сложно и непонятно для разработчиков. Как мы объясняли story-point — это идеальный восьмичасовой рабочий день разработчика, когда у него есть все под рукой, ничто не отвлекает его от работы (уже заметны проблемы, есть все и не мешает хм. ), он находится в изолированном от других помещении, где есть свежий воздух, еда, чай/кофе, туалет и он продуктивно выполняет поставленную задачу, решение которой ему полностью ясно. Некоторые вещи еще добавлялись при объяснении новичкам, но они особо не имеют значение.
Распределение ролей
В нашей компании практически нет cross-разработчиков? есть отдельные тестировщики и мы разрабатываем под различные платформы. Соответственно, мы слабо ложимся на одно из понятий Scrum, как унификация работников. Мы им пренебрегли и в первом sprint’е у нас участвовали разные разработчики в одной команде.
Планирование
Были распечатаны все features из backlog’а, которые должны были пойти в sprint, и мы начали оценку.
Какие действия на планировании sprint’a нами предпринимались:
Составили Scrum-list (в MS Word):
(ссылка есть в источниках и ссылках)
Зачем нужен лист?
Для того чтобы другие команды и вовлеченные в проект люди представляли какие задачи в данный момент выполняет та или иная команда. А также для того, чтобы видеть какой результат будет через определенный промежуток времени.
Ежедневные планерки
На первую планерку все явились, как по часам, что не радует (в дальнейшем было все не так радужно). Собрались, начали обсуждать поочередно у кого как что идет, вопросов и проблем ни у кого не было. Перешли к Scrum-desk.
Доска задач в бумажном виде
Начали двигать стикеры и тут уже столкнулись с проблемой, так как стикеры были приклеены к ватману на скотч, отдирать их и переклеивать составляло некоторую проблему. С этим с горем пополам справились (в дальнейшем приобрели сноровку и это не составляло проблему). Стали проставлять сожженные story-points, и тут возник некий вопрос: не у кого из разработчиков не было проблем и вопросов, а story-points сожгли то не достаточно. Причина, как обычно банальна: у кого-то просто некоторое время ушло на раскачку и он просто не все время делал свою задачу, кто-то вел подготовительные работы, которые в sprint не были никак заложены и в том же духе. В итоге у нас вышло нечто похожее:
Изначально стикеры просто лепились на доску, но со временем стали их закреплять дополнительно на скотч, было пару прецедентов когда все слетало. Позже появилось еще пару столбцов типа: in testing, code review и т.п.
Зачем нужна burn-down?
Burn-down нужна для того чтобы можно было отслеживать прогресс выполнения sprint’а у команды, а также для того чтобы в визуальном виде можно было видеть отклонения от выполняемого плана по времени. Основная цель burn-down: показать команде (так как у нас самоорганизующиеся команды), что нужно принять оперативные меры, если произошло отклонение.
Как строить burn-down?
Множество инструментов позволяют строить burn-down диаграммы в электронном виде, мы воспользовались MS Excel, а также строили на ватмане.
Изначально (позже появлялись дополнительные столбцы) наша таблица содержала:
Как видно по диаграмме — первый sprint прошел практически удачно, небольшие отклонения от идеального исполнения. НО, как гласит правило: Если по окончанию sprint’a есть не сожженные story-points, то sprint провален. На это правило, на тот момент, мы закрыли глаза и радовались успешному завершению sprint’a!
Демонстрация
Пришло время продемонстрировать руководству результаты sprint’a. “Команда” (менеджер) подготовила свою презентацию, в дальнейшем каждый член команды делал свою часть. Изначально не было стандарта презентации. Собралось много зрителей: руководство, часть отдела продаж и маркетинга.
Презентацию делали в MS Powerpoint:
В первой презентации было всего четыре слайда, по этой причине разработчикам тяжело было демонстрировать, так как не было слайдов того о чем рассказывать, но в дальнейшем мы исправились.
Где и как проходила демонстрация
Так как у нас, на тот момент, не было conference-room презентация проходила в кабинете разработчиков, достали проектор и светили на стену.
Изначально выступил менеджер (я) рассказал для чего все тут собрались, рассказал основные цели и задачи sprint’a, и начали выступать по очереди разработчики, завершилось все выступлением менеджера с демонстрацией burn-down диаграммы и вопросами со стороны публики.
Основные задачи менеджера на демо:
Разработчики на первой демо
На первой демонстрации, как в прочем еще sprint’ов десять, разработчики рассказывали для себя: применение сложной терминологии, углубление в предметную область, демонстрация результатов не для обычных людей. На начальных sprint’aх, иногда и сейчас, приходилось перефразировать, резюмировать демонстрацию разработчиков, для того чтобы заинтересованные люди могли понять о чем идет речь.
Публика на демо
Со стороны публики было много отвлеченных вопросов, которые косвенно относились к демонстрируемому sprint’у, на которые они очень хотят получить ответ, — это очень затягивает демонстрации и по сей день. Первая демонстрация длилась часа полтора.
Ретроспектива
Первый sprint прошел удачно и для разработчиков. Отзывы были только положительные.
Какие улучшения были обсуждены на первой ретроспективе:
Feedback от руководства
Все понравилось, требуется больше слайдов в презентацие. Руководство захотело привязывать премиальную часть ЗП разработчиков к результатам демонстрации sprint’a: заинтересованные лица проставляют субъективные оценки каждому разработчику с проставлением критериев этой оценки, оценка менеджера — среднее арифметическое из всех оценок. Данная система не особо прижилась, но это уже совсем другой рассказ.
Как все пошло
После первого sprint’a уже много воды утекло, было предпринято множестве действий по оптимизации процессов, некоторые имели какой-то profit, многие нет.
Какие меры предприняли
Объединение команд, почему случилось
Изначально у нас было две команды разного профиля разработки, у каждой был собственный Scrum c блэкджеком и Scrum-desk. Но так как у нас всегда, и сейчас, есть просадки с менеджментом (я фактически один), то у меня не хватало времени на организацию процессов по планированию/ведению/демонстрации на две команды. По этой причине нами было принято решение объединить команды в одну.
Да, — это помогло выиграть некоторое время, но, Нет, — это не дало положительных результатов. Такое продлилось четыре sprint’a, но так как у команд был совершенно разный профиль разработки, разработчикам было совершенно незачем работать вместе.
Разделение команд
Со временем работников становилось больше и становилось больше направлений разработки, появлялись то мобилки, то еще что-нибудь. Как я говорил в пункте с объединением команд, людям совсем не за чем работать вместе, если между ними нет прямой связи в разработке проектов. Соответственно, мы разделили команды по разным направлениям. Да, — это дало продуктивный результат для каждой отдельной команды, но каждая команда, сожрала уйму времени менеджера.
Варьирование времени sprint’ов
Попробовали различные вариации:
Перешли на доску с маркерами
Отказались от ватманов, некрасиво смотрится, разработчикам не нравилось это на обоях.
И решает проблему с отрыванием скотча от бумаги. Но, появилась новая проблема — клей на доске. Также пропала burn-down диаграмма в бумажном виде, так как я стал выводить изображение диаграммы на телевизор в кабинете разработчиков.
Следующий этап: стали писать ежедневные таблицы митингов маркерами на доске:
Таблица содержит: число, столбец сжигания задач не из плана, столбец сжигания задач из плана.
Перешли на облачное решение: google doc
Стали вести burn-down диаграммы в google таблицах. С течением времени стали добавляться еще значения в таблицу:
Так как при длительном sprint’e у нас появилась тенденция: не укладываться в sprint (запасы пробовали брать, ни к чему хорошему не привело), ввели новое значение — off-plan, которое показывает график с учетом сжигания не запланированных задач.
Далее пошли еще дальше, ввели еще три значения: Real, Off-plan (error) и Off-plan (extra):
Перешли в google презентации
Удобное решение, можно работать всем одновременно:
Сейчас у нас гораздо больше слайдов, чем было вначале, но получается более четкая презентация и занимает меньше времени.
Попробовали плагин для Redmine
Поставили плагин для Redmine, его название — Backlog’s. Дает возможность организовывать работу с backlog’ом продукта и sprint’ами через Redmine:
У данного плагина есть электронная доска задач, которая полностью повторяет функционал той, которая у нас была вначале в реальном виде. Все столбцы подхватываются из Redmine, — это значение статуса задачи. Sprint замещает значение и функционал «версии» в Redmine. Достаточно удобный плагин, мы его используем и сейчас.
Ввели регалиеметр
Отражает суммарно сожженные story-points каждого работника за все sprint’ы. Стимулирует работников работать более продуктивно, каждый работник способен брать на sprint определенное количество story-ponts. Видя, что другие ребята работают продуктивнее него, работник предпринимает попытки, чтобы достигнуть более хороших результатов. У нас среднее количество story-points на двухнедельный sprint — это семь.
Какие улучшения дали нововведения
В первую очередь все нововведения направлены на улучшение производительности и на сокращение времени на планирование и сопутствующие работы. Переход в облако и на полностью электронную работу значительно сократил время на работы по планированию.
Что же происходит сейчас?
На данный момент существует проблема: количество работников велико для одного менеджера и мы не успеваем проводить все работы по планированию. Что делать с этим мы знаем. Пытаемся действовать по наработанной схеме.
Дало ли результаты?
Придуманная и внедренная система дает следующие результаты:
Что планируем делать дальше
В данный момент у нас, опять, активно внедряется 1С Битрикс, руководство хочет чтобы все работники были в одной системе. Планируем изучать новый инструментарий и смотреть, как нашу работу можно перенести в CRM. На данный момент есть кое-что на примете: доска для Битрикса — scrumban.ru. (ссылка есть в источниках и ссылках)
Есть планы при помощи MS Project применять метод освоенного объема в параллели ко всей нашей системе.
Заключение
В заключении хочу повториться, что это не в коем случае не гайд, а лишь опыт одной небольшой фирмы. Надеюсь что после прочтения статьи у вас останутся лишь позитивные мысли и вы вынесете для себя нечто полезное, а может быть и опыт, как делать нельзя.