Вместо предисловия:
- Чистосердечное признание: когда я в статье (в данном случае в тесте) вижу такие слова как product owner, бэклог, технический проект, бизнес процесс, agile - чувствую себя колхозником. Я конечно понимаю смысл этих слов, мне нравятся новые слова, легко найти их смысл в интернете, но в нашей франчайзи такое не используют вообще… В связи с этим у меня вопрос. Вы действительно используете в своей организации эти слова и эти методики? =) И как? Повышает эффективность?
- Большинству франчайзи будет достаточно выучить одного переводчика с агильского
(Из дискуссии на форуме Инфостарта)
К некоторому моему удивлению, на Инфостарте не затихают дискуссии про то, Agile - это правда работающий подход, или это про чувство собственной важности? Способ более эффективно работать или оправдание собственной некомпетентности? Ну и соответственно, традиционно ломаются копья про то, нужен ли Agile в 1С, или это всё глупости…
В очередной раз расскажу свои пять копеек по этому вопросу. Про то, что такое Agile подход, когда он работает, а когда нет, я уже много раз писала. Можно почитать подробности в публикациях: Почему Agile превращается в Тяп-ляп. Кто виноват и что делать? , Что такое Agile mindset или, говоря по-русски, пронырливый образ мысли и так далее.
Тех, кому интересно эту тему рассмотреть более подробно - приглашаю ко мне на курс по Agile, который стартует 25 марта 2021. А за неделю до него, 17 марта мы поговорим про метод, близкий к Agile (но строго говоря к нему не относящийся) - про Канбан.
Что мы будем понимать под Agile?
(Несколько абзацев для тех, кто в танке. Ну, и для того, чтобы сверить часы - а то бывает, что любой бардак называют словом "Agile")
Agile - это подход к управлению проектами, предполагающий выполнение работы маленькими кусочками, с уточнением содержания по мере получения обратной связи от заказчика. За счет движения “короткими перебежками” и короткой “петли обратной связи” можно получить результат, который в большей степени оказывается полезным заказчику. Для работы по “гибким методологиям” существует большое число инструментов, техник и методов. Например,бэклог продукта, Канбан-доски, дорожные карты продукта вместо диаграмм Ганта, карты пользовательских историй, покер планирования и многое другое.
При этом важно помнить, что Agile - это подход, который стоит применять для проектов, связанных с высокой неопределенностью требований (не очень понятно на старте, что мы хотим получить в результате), и высокой технической неопределенностью (не очень понятно на старте, как мы будем это делать). Если всё понятно как делать, внедрение стандартное, все требования в начале уже известны - необходимости городить Agile нет.
Потому что работать по Agile совсем не так просто, как полагают те, кто бодро делает заявления в стиле “Мы не документируем - у нас Agile”!..
Работа по Agile требует более высокой компетентности и самоорганизованности членов команды, требует от представителей заказчика готовности быть в контакте с командой проекта и регулярно обсуждать проблемы и запросы, требует определенного уровня доверия и готовности к сотрудничеству.
Не все попытки внедрить Agile оказываются успешными. Но - если получается - то, черт возьми - оно работает и оказывается продуктивным!!! Просто надо помнить, что чудес не бывает, и Agile трансформация, как правило, занимает несколько лет.
"Фишки" Agile, полезные в проектах 1С
А здесь я хочу рассказать про то, какие фишки и инструменты Agile по моему опыту и по моим представлениям самые полезные. Ожидаю, что читатели статьи про многое из упомянутого ниже воскликнут: “ё-моё, а мы тоже это используем, а ни про какой ваш “Ажаль” слыхом не слыхивали!”. Это логично (мало того, нелогичным было бы обратное). Потому что если инструмент полезный и работающий, очевидно, что многие разные умные люди независимо приходят к его использованию. Просто называют разными словами. Следует ли из этого, что Agile - бессмысленный? Нет, конечно. Плюсы разных фреймворков и методов Agile в том, что они представляют собой не просто хаотичный набор инструментов, а некоторую технологию, которой можно обучаться, которую можно внедрить, и применять на практике. Впрочем, мы немного отвлеклись. Итак, самые полезные на мой взгляд, фишки Agile:
Регулярные встречи.
Самые распространенные встречи Agile:
- Ежедневные летучки (стенд-ап совещания или ежедневный Скрам) - ежедневные встречи до 15 минут (в классическом варианте - стоя, чтобы не засиживаться), где обсуждаются текущие вопросы
- Регулярные демонстрации заказчикам и будущим пользователям результатов продукта
- Ретроспективы - сбор извлеченных уроков и обсуждение, что можно улучшить.
Во многих командах нет практики регулярных встреч, особенно встреч с команды разработки с бизнес-заказчиками. А те, у кого такая практика есть, могут подтвердить, что оно улучшает взаимопонимание.
Ё-моё, в этом есть некоторая магия, это удивительно - но это работает, когда мы заставляем людей встречаться!.. Казалось бы, зачем нужна летучка - ведь итак каждый член команды может подойти к тимлиду и сказать “у меня есть проблема”... Но - не подходят, блин!.. По тысяче разных причин… И каждый знает свои планы и обязанности, зачем уточнять их на летучке? Но когда знаешь, что на следующем стенд-ап совещании нужно будет рассказать команде, что ты сделал за вчерашний день - это мобилизует доделать кусок… Есть Agile-подход, используемый для обучения - называется EduScrum. Изначально его придумали для проектной работы в школах, но сейчас применяется много где - в том числе, насколько я понимаю, в Корпоративном Университете Сбербанка. Но расскажу я сейчас про школьников. Так вот, суть метода в том, что участников делят по командам, каждая команда получает исследовательское задание (например, по естественным наукам: выясните, сколько меди в этом телефоне), сама распределяет задания, определяет направления движения и сдает работу. Так вот, в командах участвуют нормальные школьники, и многие из них, естественно, совершенно не прочь пофилонить. И в отсутствие надзора строгого учителя и страха двойки команда может забить на эти ваши дурацкие исследования, и просто приятно провести время на уроке. А потом наступает время общей встречи, и каждая команда рассказывает, что она сделала. Тем, кто валял дурака сказать, естественно, нечего. И учитель на этом месте настаивает, чтобы представитель команды вышел и так и сказал - мы ничего не сделали. Так вот, удивительным образом, после того как на фоне других команд команда лентяев разок-другой признается “мы ничего не сделали”, они волшебным образом - без всякого страха двоек и требований от учителя - начинают что-то делать, так как им самим становится некомфортно. В общем, встречи и здесь работают, да.
Короткая петля обратной связи.
Это такое специальное “эджайльское” словосочетание. Для тех, кому требуется “перевод с агильского”, поясню - в сложных проектах нам трудно быть до конца уверенными, что наши представления о том, как надо что-то делать - верные. Поэтому мы проверяем наши предположения, пробуем, а потом смотрим, что получилось и корректируем. Этот принцип применяется повсеместно: мы что-то моделируем, делаем прототипы. Мы даем заказчикам “поиграться”, “покрутить в руках” какие-то функции, чтобы они убедились, удобно ли им. Мы предлагаем пройти по шагам описанный бизнес-процесс от начала и до конца, чтобы убедиться, что таки по нему можно работать. Мы выпускаем один модуль в ОПЭ, чтобы на его примере понять, что нужно переделать в других модулях. И так далее…
Честно скажем, эту идею - собирать обратную связь и на ней учиться - придумали задолго до Agile. Внимательные наблюдатели легко узнают в ней уже набивший оскомину (но от этого не ставший хуже работать) цикл Деминга-Шухарта: Plan-Do-Check-Act. Особенность Agile - что мы пытаемся сделать этот цикл как можно короче. Один из лозунгов - Ошибайся чаще, ошибайся безопасно (fail fast fail safe в оригинале. Или, как его иногда пародируют: fail fast - be agile).
Я уверена, что все внедренцы, читающие эту статью в тот или иной момент сталкивались с ситуациями (или сталкиваются с ними постоянно), когда первоначальная версия реализации того или иного функционала оказывалась нежизнеспособной. И вместо того, чтобы говорить “ничего не знаю, так было написано в ТЗ, а мы не при чем” или “как жаль, что у нас такой некомпетентный специалист задачу делал, давайте его оштрафуем или уволим”, Agile признает, что такое случается сплошь и рядом и предлагает минимизировать убытки. Как раз при помощи той самой короткой петли обратной связи.
Канбан-доски.
Это инструмент, который я настоятельно рекомендую всем, кто еще не использует. Если про Канбан-метод еще можно ломать копья, нужен он или нет (кстати, на момент написания статьи я планирую через неделю провести вебинар про Канбан-метод - присоединяйтесь), то про Канбан-доски таких вопросов не возникает.
Чтобы все задачи были зафиксированы, и “работа не проваливалась в трещины”. Чтобы можно было всю информацию о задаче привязывать к одной сущности. Чтобы доска делилась не на три абстрактные колонки “Надо сделать - В работе - Готово”, а на ней был подробно расписан бизнес-процесс, от постановки до тестирования.
На этом, пожалуй, пока остановлюсь.
И, чтобы статья не искажала действительность, добавлю еще несколько пунктов про то, когда Agile не идет на пользу:
Когда Agile не идет на пользу:
- Когда нет физической возможности. Мы можем рассуждать, что Agile в данной ситуации полезен. Но если бизнес-заказчик не готов к гибкости по срокам и бюджету и настаивает на детальном ТЗ на старте, а представители заказчика не готовы к тесному сотрудничеству с командой разработки - наши рассуждения врядли смогут изменить ситуацию.
- Когда коробочное внедрение, все просто и понятно. Agile дороже и сложнее, чем работа "по Водопаду". Так зачем огород городить, если и так понятно, что делать - бери лопату и копай!
- Не надо усложнять сущности без надобности! Не надо!
- Не буду-не буду Оккам!!! Только бритву убери...
(Анекдот)
Когда пытаются лень и некомпетентность оправдывать Agile. Если в команде нет дисциплины и компетентности, то, честно скажем, никакой подход не спасет. Может показаться, что при помощи Agile удобнее скрывать лень и некомпетентность, но на мой взгляд все обстоит строго наоборот. Да, в работе по Водопаду команда на старте демонстрирует способность нарисовать красивый план. Но дальше работа происходит "в черном ящике" и до самого конца нельзя убедиться в работоспособности решения. А при работе по Agile команда каждую итерацию (спринт) выныривает из черного ящика и предлагает попробовать на практике промежуточный результат. На эту тему есть красивый образ про дельфина, который регулярно выпрыгивает на поверхность, и подводную лодку, про которую пока она не всплыла вообще ничего достоверно не известно - как у нее дела и куда она приплывет на самом деле? Риски в случае с дельфинами, согласитесь, куда меньше. - Когда нет открытости. Когда одна сторона пытается “наколоть” другую.
— Александр, такой вопрос: как нам повысить уровень доверия в отношениях с заказчиком?
— А что сейчас не так с уровнем доверия?
— Ну, у нас есть команда, есть менеджер. И мы хотим, чтобы заказчик доверял команде и общался только с менеджером. А он лезет напрямую к инженерам...— А чем это плохо? Человек сразу получает ответы на свои вопросы, быстрые коммуникации и все такое.
— Понимаете... Мы ему джуниор-инженеров продаем как синьор-инженеров... И нам не хотелось бы, чтобы он обнаружил этот факт. (Из книги Александра Орлова "Джедайские техники конструктивного общения")
- Agile не всегда подходит, когда сильный руководитель, а команда состоит из начинающих разработчиков и аналитиков. Пресловутая самоорганизация команды она рождается из той идеи, что задачи решаемые на Agile проектах слишком сложны для того, чтобы их мог решить один человек, поэтому нужно подключать коллективный разум. А если коллективный разум пока не накопил опыта, и способен предложить только фантастические и нереализуемые идеи - тут выигрыш от совместных обсуждений и самоорганизации будет куда меньше, а потерь времени и наступания на грабли - куда больше. И еще раз напомню в этом месте, что Agile работает в команде мотивированных профессионалов.
Это были общие рассуждения, основанные на моем опыте и опыте моего окружения. А теперь - вопрос к сообществу.
Ответьте, пожалуйста, на вопросы опроса
Коллеги, интересен ваш реальный опыт про применение Agile в проектах 1С. Ответьте, пожалуйста, на вопросы опроса. В качестве благодарности за участие в опросе - пришлем промокод на скидку в 25% на курс по Agile.
На вводном открытом вебинаре 25 марта - подведем итоги. Мне вот тоже любопытно будет познакомиться с результатами.
