Agile появился в виде манифеста и набора из двенадцати принципов более двадцати лет назад. Они были сформулированы ведущими разработчиками как философия или майндсет, после чего были проверены временем и остаются актуальными спустя все эти годы поскольку предоставляют свободу реализации и возможность совершенствования практик разработки и управления процессами.
Как понять, что у Вас есть Agile?
Тут все просто. Если на проектных совещаниях вы часто слышите слова «скрам», «спринт», «канбан-доска», то, похоже, у вас есть артефакты Agile. Но не факт, что есть Agile как целостный подход к разработке. Про четыре ценности Agile и манифест вы наверняка уже где-то слышали, а действительно ли на ваших проектах эти ценности поддерживаются? Сейчас мы в этом убедимся.
Люди и взаимодействие важнее процессов и инструментов
Часто вы слышите, к примеру, что ваш Руководитель проекта пожертвовал чем-либо или даже кем-либо в команде в угоду старому процессу или все той же Джире? Приходится ли вам на митингах или в переписке сталкиваться с фразами:
«Мы не должны этого делать, потому что так не прописано в …»
«Не начинайте это делать, это очередная хотелка, завтра о ней забудут»
«Он нам не подходит, потому что он не умеет в …»
Agile манифест утверждает, что, выбирая между взаимодействием в команде и с заказчиком, именно само взаимодействие должно цениться выше формальных процессов. Несовершенные инструменты взаимодействия и прочие артефакты с одной стороны тяжело заменить, но, с другой стороны, их поддержание обойдется дороже в долгосрочной перспективе.
Работающий продукт важнее исчерпывающей документации
Часто ли вам встречается недоделанный продукт, не работающий должным образом или просто с большим количеством дефектов? И основная линия зашиты разработчика такого продукта: “ну делали же по Agile”. Не поддавайтесь. Перед вами не продукт Agile или Scrum-фреймворка. Работающий продукт в Agile всегда важнее.
Разработчики не могут сдать недоделанный функционал и доводить его на проде до пригодного состояния. В Agile и конкретно в Scrum создаются маленькие итерации полностью работоспособного функционала. Действуя подобным образом, владелец продукта получает гораздо меньше дефектов (бывает, что в отдельно взятой итерации их и не находят).
Сотрудничество с заказчиком важнее согласования условий контракта
Как часто вам кажется, что исполнитель использует оппортунистические практики чтобы изменить сроки проекта или оправдать низкое качество поставляемого продукта?
В Agile манифесте прямо заявлено, что продукт должен быть сделан так, как того потребует заказчик — в ущерб тому, что прописано в договоре. И тогда я считаю правильным поставить вопрос: на чьей стороне оппортунизм в этом случае? Для целей статьи я расширил понятие сотрудничества до «делайте то, что требует заказчик», так как это наиболее простой способ реализации сотрудничества. Но никто не мешает развивать сотрудничество еще шире — с Agile у заказчика есть возможность сделать больше, чем указано в договоре. При этом важно не забывать, что и договор, в свою очередь, должен быть составлен так, чтобы удовлетворять изменяющимся потребностям проекта, среды, заказчика, политической ситуации и так далее.
Готовность к изменениям важнее следования первоначальному плану
Часто вы слышите, к примеру, что продукт не доделали и не могут сдать, потому что требования за время проекта уже сто раз менялись, все переделывали сто один раз и, похоже, снова будем переделывать?
Это тоже вид оппортунизма. Agile показывает готовность к изменениям изначально. Верно и обратное: если требования вашего проекта выбиты в камне и ни при каких обстоятельствах не изменятся — его будет быстрее сделать одним махом, без каких-либо итераций. Но есть один нюанс. Делая его итеративно — вы как заказчик сможете раньше получить прибыль от готового функционала.
Что будет мешать Agile в вашем бизнесе?
Негибкая среда
Речь про общее положение дел в отрасли и состояние рынка. Возможно, у вас не получится сходу применить итеративный продукт в вашей среде, но всегда можно попробовать внедрить элементы гибкой культуры, майндсета, Scrum-фреймворка.
Негибкая команда
Сейчас это все менее и менее актуально и все больше и больше ребят успели уже поработать в Scrum-команде (пусть даже и в неправильной), и мы сможем выстроить долгосрочные отношения в высокоорганизованной кросс функциональной команде. Если вам досталась другая команда — необходимо разбираться (возможно, с помощью приглашенного -Scrum-мастера), что пошло не так во время формирования команды, и делать выводы как ее изменить вплоть до полного расформирования и повторного набора. В вашей команде вам пригодится набор ценностей Scrum-фреймворка: Фокус, Смелость, Открытость, Приверженность и Уважение. Они определяют взаимодействие в команде и с заказчиком, и без них хороший продукт вряд ли получится.
Негибкий контракт
Вам попался контракт, который предполагает конкретные сроки, конкретное качество и конкретные работы к этим срокам. Где тут гибкость? Что в контракте прописано в случае изменений? Чтобы не попасть в водоворот постоянные дополнений к контракту, желательно сразу формулировать гибкий контракт с учетом потенциальных изменений в продукте.
Негибкие требования
Требования указаны слишком подробно, либо, наоборот, слишком абстрактно. Что делать в этом случае? Исходите из цели. Вкратце, имейте в виду следующие вопросы:
- Цель – для чего мы разрабатываем этот продукт
- Целевая аудитория — для кого это будет полезно
- Действия — что именно требуется предпринять, чтобы достичь цели
С пониманием этого разработчик уже разберется как ему реализовать ваше требование.
А как должно быть по Agile?
Итерация и Инкремент
Для понимания того, как именно должен быть организован гибкий подход к разработке, прежде всего надо осознать, что такое «итерация».
В этой статье вы уже несколько раз видели слово Итерация. Это ключевое понятие в Scrum подходе. Работая с неопределенностью, Scrum предполагает, что команда будет разбивать весь перечень работ на короткие итерации (=взаимодействия), скажем, двухнедельные спринты, и за время этого спринта появится полезный рабочий инкремент продукта. Именно этот важный момент часто упускают из виду, поэтому я бы хотел заострить на нем ваше внимание. За время спринта должен появиться полезный рабочий инкремент продукта -конкретный шаг на пути к достижению цели продукта. В этой простой фразе заложено довольно много: команда планирует ряд задач на спринт, эти задачи должны принести пользу для продукта и компании (и для пользователей конечно же), команда доводит их до конца (до состояния готовности) и все это происходит за ритмичную итерацию, которая снова повторится спустя две недели, но уже с другим инкрементом.
В конце спринта проводится демо для ключевых заказчиков, где принимается решение выкладывать ли ли сделанный функционал на продуктивную среду или нет, и какие доработки требуется сделать, чтобы его можно было загрузить. На этом этапе также появляется еще один важный элемент: обратная связь, которую необходимо учесть в начале следующей итерации при ее планировании. Детали — как именно провести планирование, демо, ретроспективу — вы можете узнать у подрядчика вроде Ауриги:. Scrum-фреймворк их формат не регламентирует, только обозначает их наличие в цикле итераций.
Неопределенность
Неопределенность в Scrum снимается итеративностью и инкрементным подходом к разработке. С определенностью можно сказать, что вам точно стоит попробовать сделать ваш проект с высокой неопределенностью по гибкой методике.
Непрерывное совершенствование
Непрерывность – один из непременных признаков того, что ваш подход к разработке продукта соответствует правильным Agile практикам. Хочу продемонстрировать это на примере реальных случаев из практики.
Один из моих клиентов на вводной встрече сказал, что скрам-мастера поработали с командой и ушли примерно год назад. Последнее ретро было полгода назад. Вы уже, наверное, догадались в чем проблема, правда? Скрам-мастер должен присутствовать в команде как отдельная роль – на всем протяжении проекта. Это может быть профессиональный коуч со стороны, либо добавочная роль аналитика или девопса. Ключевое слово — всегда. И ретро мы проводим тоже на постоянной основе, поскольку всегда есть что обсудить и всегда есть что усовершенствовать в текущем рабочем процессе. Нельзя думать про команду и скрам-мастера в ключе «сделал и забыл» – это живой изменяющийся организм, а ваша основная задача быть готовым к изменениям.
Еще один пример со вводной встречи и на этот раз на тему командообразования. Проблемы командообразования и взаимодействия в команде очень часто существенным образом влияют на молодые команды. Пути их решения проложены в этом абзаце. Владелец продукта заявляет: “У нас сформировались три команды”. Я недоумеваю: «Как это сформировались? Сами по себе?» Уточнил. Оказывается, их сформировал сам менеджмент= по принципу «каждая команда занимается своим функционалом»: одна продукт, вторая бэкенд, а третья — диджитал. Как вам такое, Илон Маск? Лично у меня вопросов уже не было. Отодвигаем нашего визави, засучиваем рукава, берем заказчика и узнаем, где наш продукт, где его границы (если продуктов несколько — есть смысл разбить команды по продуктам или по сервисам, которые компания предоставляет клиентам). Если продукт один, а команда уже 25 человек — то это многовато для одной команды, и для удобства взаимодействия можно бы ее разбить на группы до 3-9 человек по принципу общего сервиса, общего функционала, общего заказчика, общей технологической базы (в широком смысле), как-то еще чтобы всем стало проще.
Что получается по деньгам?
Работая по Scrum, вы получите рабочий результат раньше, а денег потратите — только на несколько первых итераций. И уже тогда вы переоцените свои приоритеты, поймете, на чем стоит сосредоточится, а что – убрать из требований, возможно даже, что вам придут в голову новые, более интересные идеи по продукту. Также возможен вариант, когда вы осознаете, что этот проект нежизнеспособен и самым разумным будет остановить его финансирование. Однако, может оказаться, что, продукт, напротив, очень многообещающий – и тогда вы оперативно сможете удвоить и утроить усилия над сулящим выгоду проектом.
Хочу предупредить, что делать один и тот же проект итерациями дороже чем делать его же целиком за один присест. Однако возврат на инвестиции он будет отдавать раньше. Нелегкий выбор, который вам предстоит отдать на обсчет при старте вашего нового проекта.
Заключение
Теперь вы знаете почему ваш Agile не такой Agile каким он задумывался.
Agile это нечто сродни мировоззрению, это майндсет, философия. Scrum — это готовый фреймворк который декларативно утверждает какие процессы и артефакты нужны чтобы реализовать итеративную разработку по Agile. Однако он не отвечает на вопросы как это реализовать в вашей оргструктуре, команде и в вашей среде. Если с этим есть трудности — а они всегда есть — вам необходима помощь специалиста по работе с гибкими методиками.
Хотелось бы в заключение отметить, что Agile – вовсе не конечная станция, а просто остановка на пути. После того, как вы – самостоятельно или с помощью подрядчика, освоите Agile и в вашей компании появится настоящий гибкий подход к разработке, перед вами откроется много дверей и коридоров, на которых написаны слова SAFe, OKR, Kanban, Lean и много-много других. Поверьте, будет интересно. Приходите в Ауригу, я расскажу.
