Наверное вы уже что-то слышали об Agile. Может даже пытались применять у себя в проектах. Ну или хотя бы ради интереса посмотрели парочку видео на ютубе. Однако так и не поняли как сделать работу над проектом проще и эффективнее?
Это Андрей и он тоже не понял.
У Андрея своя Web-студия. Он работает 24/7, прикладывает колоссальные усилия, но студию уже 2 года как прогресс покинул. Мелкие проекты тянутся полгода, оплата поступает не всегда вовремя, у коллектива не горят глаза. Андрей твердо решил что так продолжаться не может.
Давайте, поможем Андрею и его команде разобраться в терминах и войти в прекрасный мир Agile методологии.
Что же мы имеем в виду под Agile? Многое о нем говорит перевод слова, с английского - гибкий, способный адаптироваться под различные ситуации, быстрый. Отсюда происходит и второе название - гибкие методологии.
Это не конкретный принцип действия, а скорее совокупность различных методов, общие принципы которых задокументировали еще в 2001 году.
В документ вошли 4 идеи:
● Люди и взаимодействие важнее процессов и инструментов;
● Работающий продукт важнее исчерпывающей документации;
● Сотрудничество с заказчиком важнее согласования условий контракта;
● Готовность к изменениям важнее следования первоначальному плану.
«Да, нашли тут дурака! Документаций нам не надо, контракта мы не придерживаемся, на инструменты наплевать! Так и создается из визитки интернет магазин с бюджетом в 5 тысяч. Знаем, плавали» - разочарованно подумал Андрей.
Наш герой, как и многие, изначально понимает Agile манифест некорректно, полностью откидывая правую часть предложения. Однако это неправильное восприятие сути.
«Мы признаем ценность того, что находится справа, но для нас более ценно то, что слева. Это не взаимоисключающие вещи, просто акцент делается на людях, взаимодействиях, сотрудничестве и работающем продукте» - объясняет Agile манифест.
Тут Андрей понимает, что по сути, Agile это своего рода философия, которую ему нужно не внедрить, а лишь принять.
И правда, Agile это лишь система ценностей, на основе которой развивается целый комплекс практик по управлению проектами.
Окей, с теорией разобрались, но что же Андрей получает на практике?
Пошаговую разработку продукта из небольших подзадач, а не одной большой задачи. На каждом этапе Андрею нужно спланировать определенный объем задач, проанализировать требования, спроектировать, разработать и протестировать “кусочек” проекта, задокументировать процесс, согласовать с заказчиком.
– Слишком сложно! — опять пробурчит Андрей.
– Минимизирует риски! — ответим мы.
И обоснуем. По окончанию каждого этапа мы имеем какой-то готовый функционал. Готовую версию подпродукта. Его можно просмотреть, оценить, протестировать, сделать выводы в каком направлении двигаться дальше, согласовать все на промежуточном этапе! А дальше скорректировать недочеты, подвести итоги и приступить к следующему.
«Хорошо, я допускаю, что это может сработать, но мне нужна конкретная методика по управлению проектами» — резонно замечает Андрей.
Давайте расскажем ему об одной из самых распространенных методик Agile.
Scrum
В центре SCRUM находится команда, у каждого есть четкая роль. Условно, команда делится на 3 вида ролей:
1. Product Owner (владелец продукта) - человек, понимающий каким продукт должен получится на выходе. Он собирает и приоритезирует требования. Общается с клиентом или клиентами. Рассказывает о ним команде. Вот кстати интересный факт: Product owner это не всегда клиент. Это запросто может быть человек в команде разработки.
2. SCRUM Мастер - это “сердце команды”, задача этой роли в том, чтобы создать для команды максимально комфортные условия работы, мотивировать и помогать. Роли мастера и владельца продукта ни в коем случае не должны пересекаться.
3. Непосредственно команда, которая выполняет проект: дизайнер, Front-end, Back-end.
“А кто головой отвечать будет??!” - восклицает Андрей.
В SCRUM нет распределяющей шляпы, которая говорит кто что делает и несет за это всю ответственность, как обычно принято. С точки зрения технологий Agile, команда является самоорганизующийся. Лидеры появляются в зависимости от той задачи, которую в данный момент решаем. А зависит это от итерации на которой находимся.
Андрею нужно изначально разбить время на отрезки, собрать команду, желательно до 7 человек на конкретный проект, все содержание проекта разделить на части, примерно равные по размеру. А что, как и когда делать, каждый решает для себя сам, при поддержке Scrum мастера и на условиях выдвинутых Владельцем продукта.
Как пользоваться Scrum
1. Формирование бэклога
Это список требований (задач), которые нужны для реализации проекта, включает в себя как технические, так и функциональные требования. Product Owner отвечает за бэклог, наполняет его и расставляет приоритеты. Именно такой подход к делу решает одну из основных задач Андрея, ведь часто для его команды все задачи одинаково приоритетны, что приводит за собой “застой” в разработке проекта.
Задачи в бэклоге обычно формируются на языке пользователя и включают в себя все требования заказчика.
2. Спринт планирование
На этом этапе Андрею с командой из всех пунктов бэклога на основании их приоритета, нужно выделить один объем задач на конкретный спринт. Обычно спринт равен недели, но допустимо выбрать и другой. Кстати, спринты на протяжении всей работы над конкретным продуктом имеют одинаковую продолжительность. Нужно это для еженедельного повышения продуктивности команды. Чтобы было что замерить и с чем сравнить.
Допустим, разработка главной страницы сайта. Андрею нужно создать доску задач и разбить ее на колонки:
To Do - задачи, которые нужно сделать;
WIP - задачи в процессе выполнения;
Done - выполненные задачи;
Изначально каждую пользовательскую задачу следует разбить на подзадачи и распределить по сотрудникам. Планирование спринта определяет чем Андрей и его команда будут заниматься в ближайшее.
Собрание с планированием задач и публикацией полученных в результате спринта рабочих метрика проводится перед каждым спринтом. На этих встречах команда определяет сколько часов у них ушло на прошлой недели, правильно ли были распределены задачи по часам и сколько времени уйдет на следующие задачи. Выделяются задачи на следующую неделю, просчитываются затраты и другое-другое-другое. В общем, планируется следующая рабочая неделя.
Когда задачи на неделю спланированы, посчитаны и распределены — они переносятся в колонку To DO и блокируются. Это значит, что в течении рабочей недели команда работает по заранее согласованному плану.
Когда колонки сформированы - Андрей получает ясную картинку, четко понимает на каком этапе находится, что нужно делать и сколько это будет стоить. А затем идет с этой информацией к клиенту. Ясные сроки и ясные средства. Так же ясно это понимает и вся команда. Здорово, правда?
Для визуализации задач удобнее всего использовать дополнительные программы. Андрею вот приглянулся WEEEK.
3. Ежедневные Скрам-встречи — митапы
Они просто должны быть. Каждый день. Но не более 15 минут. Поэтому их часто проводят стоя на ногах, чтобы не задержаться на удобном диване невзначай.
Проводить такие встречи нужно в начале рабочего дня. В процессе команда не решает вопросы и проблемы, просто каждый отвечает на три вопроса SCRUM Мастера: что сделал вчера, что планирует сделать сегодня и с какими проблемами столкнулся. Так команда видит, что все идет по плану. А если не по плану, то мастер может оперативно это исправить.
За время собрания успеваем перенести сделанные задачи в колонку Done , а те, которые планируются на сегодня из To Do перемещаем в WIP.
Вывод: задача команды за один спринта все задачи из колонки To Do перенести в колонку Done. Если не все задачи успели дойти до этой колонки, то задачи переносятся на следующий спринт, а на следующем планировании проводится корректировка рабочих часов на задачи.
– Ох, ну зачем каждое утро, то? – недоволен Андрей.
– Чтобы понимать, где находимся – отвечаем мы.
4. Ретроспективы.
Не смотря на то, что команды являются самоорганизующимися, кто-то должен отслеживать, что все идет по плану. Ретроспективы проводятся после каждого спринта. На них рассказываются и обсуждаются текущие продуктивные показатели команды и результаты спринта. Часто они игнорируются, но без них очень сложно понять, что в команде все работает именно так как нужно и ничего не нужно корректировать.
5. Демонстрация и релиз
Спринты должны быть распределены так, чтобы спустя какое-то количество спринтов получить логически законченную часть продукта или полностью готовый продукт. Стандартно — один релиз это 4 спринта.
Так, спустя 4 недели Андрей уже имеет “осязаемую” часть, а может даже и весь продукт. Может показать его клиенту и обсудить возможные правки, собрать новые требования, и даже получить процент оплаты :)
Что делать Андрею и его команде дальше?
С собранными требованиями после демонстрации вернуться к этапу бэклога и повторить цикл. Профит.
Протестировав, Андрей понял, что при соблюдении правил, результат работы получается качественным и в короткие сроки. А использовать WEEEK намного удобнее вместо, хоть и ламповой, но громоздкой пробковой доски и стикеров.
Что еще нужно знать?
Многие из тех, кто пытался внедрить Scrum потерпели фиаско. Scrum — гибкий и одновременно относительно жестко регламентированный фреймворк.
Он четко объясняет правила, которые необходимо соблюдать, чтобы все работало. Но гибок в том, что для каждой команды и проекта Scrum будет разный. У кого-то между спринтами будет регулярный полуспринт на правки. У кого-то будут релизы каждую неделю. У кого-то спринты по 2 недели. А у кого-то дополнительная строка под внеплановые задачи. Никто не знает как удобно работать вам и вашей команде. Нужно пробовать, тестировать и внедрять.
Scrum чек-лист
1. Собираем команду, распределяем роли.
2. Формируем бэклог, разбиваем его на части по приоритету.
3. Одному спринту отводим определенный объем задач.Оформляем и наполняем колонки To Do.
4. Каждое утро проводим митап, по его результатам переносим задачи в нужную колонку.
5. В конце спринта проводим ретроспективы.
6. Общаемся с клиентом, показываем что сделали, собираем новые требования, правки.
7. После нескольких спринтов, проводим релиз, заливаем готовую часть продукта или функцию.
8. Колесо Сансары дало оборот.
Подписаться