Вы, наверное, уже слышали о методологии (или если вам будет угодно, философии) Agile и о том, что это единственный способ эффективно разрабатывать программное обеспечение. Но как же так получается, что выдающиеся компании и продукты создаются без Agile? Почему в SpaceX нет scrum-мастеров, а в Apple нет специалистов по Agile-коучингу? Молодые успешные стартапы не кичатся тем, что у них свой уникальный подход к гибким методологиям разработки, который дает им уникальное преимущество в скорости разработки. С другой стороны, компаниям среднего уровня и крупным аутсорсерам продают Agile-трансформацию, а некоторые региональные банки кичатся своими Agile-методологиями. Мы, те, кто приносит ценность пользователям, уже поняли, что Agile не является серебряной пулей. Но чем же он является?
Agile — это секулярная религия.
- Есть манифест наших великих предков. (вспомните несколько пунктов из него? Вот и с заповедями так же…)
- Есть обязательные ритуалы, которые нужно выполнять.
- Есть жрецы.
- Существуют различные церкви, которые сертифицируют жрецов (например, ICAgile, Scrum Alliance и т.д.).
Нет только научных доказательств существования божества, ни доказательств эффективности предложенных методик. Когда я пришел к этой мысли, задумался, вдруг я ошибаюсь и пошел гуглить научные работы, но все они были на уровне школьного реферата "Как я провел лето". Ну ладно, наука есть наука, но на практике божество помогает нам. Главное правильно молиться.
Религия начинается из благих побуждений
Как и у любой религии, у Аджайла есть благие побуждения. Ребята, которые его придумали, столкнулись с тем, что методы управления проектами, взятые из производства и строительства, не подходят для софтверных проектов. Именно поэтому они (точнее их последователи) взяли Канбан у Тойоты и придумали Pi-диаграмму, которое представляет собой переложенную на новый лад диаграмму Ганта. Вообще, идеологический разрыв между традиционным менеджментом производства/строительства и менеджментом проектов по разработке ПО связан с тем, что у софтверных проектов большой уровень неопределенности. Именно поэтому мы всегда успеваем построить все здания вовремя, а производства гарантированно отдают качественный продукт в рамках бюджета и сроков.
Чтобы эффективно создавать продукт с точки зрения Agile, необходимо мыслить итерациями и ориентироваться на ценность для клиентов. Старайтесь доставлять продукт пользователю как можно раньше и глубоко вовлекать заказчика в процесс производства продукта.
Вспомните свой кнопочный Айфон, который положил начало этому уникальному продукту (продажи которого за год в 4 раза больше продаж всей Икеи). А приложение вашего банка, где можно только смотреть баланс, это же было так здорово? Ой, оказывается что у продукта может быть достаточно масштабный набор качеств на старте, чтобы он был востребован. А еще у продукта есть бюджет, потому что денег физически не бывает бесконечно, даже у Apple (только у Федерального Резерва, но там не занимаются разработкой ПО). А так же у продукта обычно есть примерная дата релиза.
Ну что ты нагоняешь — конечно аджайл умеет работать со сроками и бюджетами, надо всего лишь грамотно запланировать скоуп задач которые точно должны попасть в релиз, оценить их в стори поинтах и положить их на диаграмму в соответствии с тем сколько стори поинтов обычно закрывает команда.
А еще нужно ставить людей и взаимодействие впереди инструментов. Поэтому, если ты умеешь доставлять ценность, но недостаточно соблюдаешь ритуалы, в рамках аджайл-трансформации мы тебя уволим.
Ну что ты снова — никто никого не уволит, лучше расскажи главное — Agile учит людей персональной ответственности и мотивирует развивать продукт
Да, терапия принятия ответственности требует не менее 10 сессий (в реальной жизни — минимум полгода), чтобы изменить отношение человека к ответственности, и проводится специалистом, который учился годы с полного согласия и желания пациента. Однако Scrum мастер и ритуалы Agile быстро научат людей принимать ответственность! Кроме того, они мотивируют, поскольку мы знаем, что даже наличие акций не всегда способствует мотивации работать на благо компании. А в данном случае человек сам оценил задачу и сам выбрал метод ее решения и теперь уж точно он кровью и плотью связан с компанией и ее целями.
Но если все так почему так много людей на это покупаются?
Религия не требует рационального объяснения. Она просто дает людям в нее погруженных чувствовать себя лучше веря в свои идеалы и отправляя свои ритуалы. Ни один священник не вылечил молитвой рак, но продолжает говорить о том, как провидение поможет исцелиться. Все мы знаем, что провидение и химиотерапия эффективнее чем провидение, но вот эффективнее ли химиотерапия с провидением, чем без него? Здесь у нас есть сомнения, хотя без сомнения вера как источник психологического ресурса может быть полезной. В общем, Аджайл это способ для тревожных людей справляться с тревогой проводя рандомные ритуалы.
Некоторым сотрудникам-активистам очень нравится получать власть, следуя ритуалам. Вчера вы были просто менеджером проекта или тестировщиком, ставили задачи или тестировали то, что написали другие. А теперь вы ведете недельное планирование, пишете юзер стори, обсуждаете их с командой. Ваша работа становится более значимой, и вы получаете больше внимания. Ведь внимание это все что вам нужно?
Лично мне никогда не требовалось НАСТОЛЬКО много внимания, поэтому я хочу просто ставить задачи и чтобы они были выполнены. Однако я осознаю, что мой стиль управления токсичный, потому что я не даю переносить задачу из спринта в спринт с умным видом people-focused лидера.
Большинство людей заняты своими прямыми обязанностями и воспринимают новые порядки как еще одну задачу, которую нужно выполнить, чтобы не уволили. Это типичная социальная динамика политиков и конформистов. Ну серьезно, вы хотите, чтобы люди брали ответственность за свою работу, так как будто это их бизнес и их задачи, а не ваши? И вы хотите достичь этого за счет того, что они будут иметь скрам-мастера и ежедневные встречи? Макиавелли позавидовал бы вашему лидерскому видению.
Люди ходят на работу, чтобы работать работу за деньги. Их может мотивировать продукт, видение и харизма менеджеров, бонусы и опционы на акции, но не покер-планирование и юзерстори. Больше всего людей мотивирует четкий объем задач и видение будущего, если они не являются специалистами, работающими с неопределенностью за особую компенсацию (в стартапах это обычно фаундеры, а в корпорациях — выдающиеся менеджеры).
Но ведь Аджайл это в первую очередь модель коммуникации, а вопрос коммуникации все равно встанет с ростом коллектива
В данной модели церковные деятели отвечают за менеджмент, и каждому менеджеру приписывается “agile-священник”. К недовольным такому соседству отправляют инквизицию. Цель заключается в служении закону божьему (аджайлу), а не в том чтобы делать продукт.
Люди найдут способ общаться между собой, если:
- Вы не ставите сертифицированного переводчика между ними и бизнесом.
- Вы подбираете людей, которые могут общаться друг с другом, а не только хорошие сотрудники.
- Вы не мешаете им общаться, возводя фиксированные процессы общения.
- Вы направляете общение, используя правильные площадки (не создаете одну общую группу в Телеграмме на 100 человек, например).
- Вы держите команды маленькими
- Вы увольняете тех, кто не умеет общаться.
Но ведь аджайл ставит впереди всего пользователей и продукт
Да, и регламентирует путь, который поможет придти к этому продукту. Единственный верный путь, в океане ереси. Стоит сказать, что вообще любая методология выступает за все хорошее и против всего плохого.
Командам нужен фасилитатор чтобы коммуницировать эффективно.
Фасилитатор это независимый человек. Не из компании. Человек работающий в компании уже не может быть фасилитатором, потому что у него есть интересы в этой компании. Но я бы задумался зачем нужен фасилитатор в команде. У вас бракоразводный процесс? Корпоративный конфликт? Кто-то взял кого-то в заложники? Если люди не могут делать свою ежедневную работу без фасилитации — единственная фасилитация которая нужна это фасилитация переговоров об увольнении.
А как же самоорганизация?
Я понимаю, что большинство топ-менеджеров и даже фаундеров часто готовы отдать судьбу своего бизнеса в руки бога, лишь бы не заниматься операционкой, но можно просто уйти на пенсию, нанять тех, кто хочет заниматься операционкой, а самим посвятить остаток жизни хождению в церковь. От этого будет больше толку, чем от аджайл-трансформации. Так получилось, что не все люди способны к самоорганизации, как не все люди умеют писать код, и не все умеют делать дизайн. Поэтому кто-то должен заниматься организацией. Если бы ваши сотрудники могли бы эффективно самоорганизоваться они бы на вас не работали, а открыли бы свой бизнес.
Причем здесь смерть?
Все больше и больше голосов выступают с мыслями, похожими на мои. Все меньше людей связывают производительность в разработке софта с методологией Agile. Высокопроизводительные команды используют некоторые элементы, но далеки от методологии целиком. Если десять лет назад, многие заявляли, что настоящий Agile просто никто не внедрял, то теперь эти иллюзии у все большего числа моих коллег развеяны. Да, до сих пор издаются книги, проводятся тренинги, трансформации, но голосов активно проповедующих эту религию становится меньше. И это означает скорую смерть и переосмысление.
А как нам тогда жить, скажи отец?
Это каждый пусть решает сам. Но есть несколько общих рекомендаций.
- Для начала подумать зачем вы или ваши коллеги внедряете какие-то ритуалы? Для того чтобы уменьшить свою тревогу или потому что это реально помогает?
- Закрывать потребности в религии, если она у вас есть, настоящей религией.
- Нанимать хороших менеджеров, увольнять плохих.
- Делегировать проекты вместо задач.
- Дать свободу принятия решений тем, кому она нужна для дела, и дать понятную структуру тем, кому свобода и ответственность не нужна.
- Воспринимать проекты как ставки.
- Помнить, что проекты нельзя завершить, можно только прекратить.
- Периодически спрашивать у менеджеров как идут дела.
- Вместо один-на-один встреч ходить с коллегами на ланч.
- Вместо оценок 360 полагаться на интуицию.
- Учиться быть хорошим человеком и затем уже хорошим менеджером.
- Делать вещи.
Подписывайтесь на мой телеграм-канал @dailykuznetsov. Я публикую в нем короткие заметки о том, как веду международный бизнес, а также о цифровых продуктах и финансах.
"Делегировать проекты вместо задач" - правильная мысль
Да, это называется Scrum. Сюрприз!!!
есть немного разное понимание проекта. В моем мире — любая фича это проект. В скраме обычно выбирается набор задач из бэклога, которые войдут в спринт, планируются/оцениваются, и идут в разработку. Да, в идеале, каждый спринт должен завершаться, с новым функционалом который приносит ценность и можно было бы это обозначить как проект. На практике, это просто итеративный производственный процесс где бэклог переходит в фичи. К тому же — в процессе планирования участвует менеджер, иногда продакт-овнер, скрам-мастер. Кто в итоге планирует — команда или они, на практике сложно отличить (очевидно что человек способный к лидерству способен заставить команду делать как он хочет, так чтобы команда думала что она это хочет делать именно так). Можно ли считать это делегированием команде?
Еще раз повторюсь, вы не знает предмет, как и те, кто городит оргструктуры и процессы вокруг вас.
Scrum-команда работает над продуктом, а не над проектом. Отличие проекта от продукта - в жизненном цикле, очень упрощая проект конечен и органичен, продукт бесконечен и не ограничен. Аналог проекта - спринт, в рамках которого создается продакт-инкремент, который аналог скоупа проекта, с той разницей, что в спринте, вероятнее всего, происходят улучшения фич , реализованных в прошлых спринтах, так как в отличие от проекта, в спринт никто не должен пытаться впихнуть все фичи продукта в их полном объеме. Если это происходит, то чем тут виноват скрам?
Основной прикол коротких проектов-спринтов - перестать делать то, что уже всем понятно для продукта не нужно. Как Scrum-команда определяет, что это делать больше не нужно? Так по итогам ревью и анализа метрик использования продукта. Если ваш продукт-оунер и тим-лид не умеют в метрики, значит у вас нет итеративной и инкрементальной разработки. Если ваш продукт-оунер не знает, что нужно пользователям и не умеет это определять, и вы берете задачи из бэк-лога наугад или потому-то что так сказал биздев, то почему в этом виноват Scrum и Agile, а не вы сами?
В Scrum команде полностью делегирована ответственность за продукт. Но требования к продукту появляются от пользователей и стэйклохдеров, а не выдумываются командой на пустом месте. И, конечно, пользователи и стейкхолдеры должны влиять на приоритизацию задач в бэк-логе в момент планирования спринта, продукт же делается для них и по их заданию. Однако, в отличие от классических методологий, требования не декомпозируются до финальных задач, потому что никто не знает в начале работы на продуктом или спринтом всех деталей большинства требований, а то и вообще нужны ли эти требования. В этом и есть свобода команды - свобода выбора финальной реализации и изменения требований.
Суть же Scrum очень проста - послушали пользователя, записали на бумажку, то как его поняли, запилили как сумели - показали пользователю, внесли коррективы, уточнили понимание всех сторон, запилили новую версию или перешли к новым фичам. А если вы совсем экстраверт, а пользователь совсем хам, то скрам-мастер просто научит вас разговаривать друг с другом и слышать и уважать друг-друга. Нет ничего проще Scrum )))
"Scrum-команда работает над продуктом, а не над проектом." — за исключением ранних стадий, над продуктом работают несколько команд.
"В Scrum команде полностью делегирована ответственность за продукт." — ответственность обычно у того, кто рискует (деньгами, карьерой), делегировать ответственность не делегировав риск невозможно.
"Суть же Scrum очень проста - послушали пользователя, записали на бумажку, то как его поняли, запилили как сумели - показали пользователю," — кнопочный айфон часто показывали пользователю, как и многие другие продукты (gpt, ракеты spacex, впрочем назовите любой продукт, которым пользуетесь). Более того, пользователь, или даже внутренние стейкхолдеры способны дать вменяемый фидбек по прототипу, mvp етц.
1. Для сложных продуктов есть разбиение на вертикальные подпродукты (или чит с созданием внутреннего продукта, когда какая-то общая для всех часть функционала выделяется в продукт для других команд), Scrum of Scrums и SAFE. Если же вы про ситуацию, когда у вас есть команда фронта, команда бэка, команда поддержки, команда дизайнеров и бедные менеджеры "ставят туда задачки", то это просто не Scrum, тут хотя бы до проектного управления и матричной структуры дорасти, да.
2. Продукт Оунер должен быть одним из ключевых стейкхолдеров, а мотивация разработчиков должна быть подвязана на результаты, показываемые разрабатываемым продуктом. А, разрабы говорят, что от них ничего не зависит, они просто хотят зашипить код и получить лавэ? Ну тогда какой-то же вам Agile? Работайте, как на заводском конвейере тогда, просто закрывая задачки, не понимая откуда они пришли и зачем они нужны.
3. Вы путаете требования и реализацию. Судя по всему у вас отсутствуют базовые навыки проведения интервью и работы с потребностями пользователей. Ну и опять тогда причем тут Agile?
самое важное здесь, что кроссфункциональные команды это утопическое царствие небесное для очень многих бизнесов, особенно если они с самого начала не нанимали и не создавали всю разработку в таком виде.
Например, если вы делаете продукт со сложным клиентом, такой как трейдинговая платформа, у вас рано или поздно он вырастет в набор самостоятельных продуктов — хранилище котировок, торговый терминал, обработка заявок и гейты к поставщикам ликвидности и биржам, административные интерфейсы и так далее. Можно заменить эту аналогию на любой продукт где клиент и сервер достаточно масштабные, созданы на разных технологических стеках, то есть почти всегда.
Каждый из этих продуктов будет состоять из разных специалистов, иногда даже с разным стеком технологий (очевидно клиент и сервер могут быть созданы на разном стэке, но даже бэкендовые сервисы могут иметь разные технологии — go для high performance и python, например, для того, что не требует высокой производительности)
Go программист в такой ситуации не может написать клиентскую часть, а разработчик клиента не может писать бэкенд. При этом каждый из продуктов делается силами нескольких людей. И все — нет кроссфункциональных команд. Это пытаются решить разными способами в agile, лучший из которых это фичекоманды.
Да, настоящие адепты скажут мне — что всегда можно сделать кроссфункциональные команды, что я говорю ересь — распределить 4 фронтедера по командам и вот вам 4 кроссфункциональные команды, но в реальной жизни это так не работает, люди объединяются вокруг сервиса и вокруг технологического стэка. Четыре человека из разных команд коммитящие во фронт без согласования сотворят дичь. Придется иметь отдельного архитектора который синхронизирует их работу. И в итоге мы просто получим параллельную структуру (фронтендеры/члены кроссфункциональных команд) с параллельным менеджментом (архитектор фронтенда/менеджер команды).
Фичекоманды как идея мне нравится. В такой ситуации продуктовый менеджер выделяется на фичу и работает с командой которая готова эту фичу сделать. И когда мы начинаем дальше крутить эту идею в голове — мы приходим к Shape Up
Ну объединятся вокруг технологий и кода, а не продукта самая порочная идея, из которой и растут все проблемы.
Ваш код никому не нужен, нужен ваш продукт.
А все проблемы, которые вы описываете характерны в первую очередь для монолитов
Тот же фронтенд не всегда можно эффективно распилить на микрофронтенды. Что тогда делать?
Как я сказал, всегда есть чит с внутренним продуктом. Пилите фреймворки и внутренние слои, оставляя продуктовой команде только косметику и свою бизнес-логику.
Но если совсем край, можете создать бутылочное горлышко из команды фронта и умирать в нем всеми проектами )
Если организовать внутренний продукт, то получится, что бизнес-команды будут находиться от него в зависимости. То есть, например, не смогут взять себе задачи в спринт, пока не будет реализована поддержка в "ядре" фронтенда. Или, что ещё хуже, возьмут задачи, но не смогут их реализовать из-за каких-то недоработок, которые придётся эскалировать команде ядра.
У вас в любом сложном продукте будет ситуация борьбы за приоритеты, но только так у вас есть ответственная команда со своим видением и отсутствие необходимости делать одно и тоже несколько раз в несвязанных командах. Альтернатива же - собирать все хотелки в начале года (откуда они в этот момент известны-то?), оценивать, приоретизировать, выбивать ресуры и получать реализация через год, когда уже все уволились, кто это просил.
Жаль, что не все стейкхолдеры это понимают
вы сравниваете две полярности — чистый божественный аджайл и адский вотерфол. На практике никто за пределами аджайла не собирает все требования в начале года, более того, в большинстве проектов требования уточняются постоянно, планы пересматриваются регулярно. Я понимаю что сравнивая с ситуацией собрать все требования в начале года и запланировать, любая методология будет выглядеть победителем, примерно как если не стрелять себе в колено это отличная мера для здоровья коленей.
отлично — внутренние продукты. С внутренними заказчиками. И приоритизация между ними, синхронизация продуктовых планов. И вот мы приходим к старому доброму Ганту.
проблема в том, что продукт и технологии часто связаны. В примере выше — торговый терминал это огромный продукт. Его могут пилить даже несколько команд. И у них свой сет технологий. У бэкендеров свой. И в такой ситуации, когда есть сложные технологии, не веб-приложение для трекинга задачек, и не vc.ru а технически более изощренный продукт, делать кроссфункциональные команды которые несут ценность пользователям не получается.
Понятно что это все разбивается на внутренние продукты, внутренних пользователей, метрики и kpi но в целом это не сильно ближе к принципам декларируемым аджайлом чем то как работает какой-нибудь Крок, только более модно.
Ну если не получается у вас, Agile чем виноват? У меня вот получается.
При этом как у вас получается работать в проектных водопадах со сложным продуктом я тоже прекрасно знаю - никак )
Общее видение давно развалилось, команда core-части посылает всех нахер и пилит только то, что просят один-два топа, слабые команды запускают микрофичи годами, новое получается запустить, только если оно вообще практически ничего не хочет от существующего, а проектная команда прям физически изолирована от остальной компании. Перефразируя Толстого, все несчастные разрабы в России несчастливы одинаково
Не могу судить за всех разрабов, я был по большей части счастлив как разраб, но мне попадались плохие менеджеры. Дай им молоток или дай микроскоп получится одинаковый результат (читай, методология им ничем бы не помогла). Так же я был свидетелем пары agile трансформаций, которые все сделали только хуже, внедрение методологию в среду слабых руководителей не приводит ни к их замене на более сильных, не к улучшению их работы и работы в целом (тоже сюрприз).
Я сторонник гибкости и в первую очередь, здравого смысла, в разработке и точно не призываю планировать на пять лет вперед. Но аджайл в массах ушел от идей гибкости, примерно как церковь ушла от идеи бога.
1. SAFE это чистый кровавый энтерпрайз, как и прочие попытки масштабирования Agile
2. "а мотивация разработчиков должна быть подвязана на результаты" — должна конечно, но в реальной жизни у людей есть разные мотивации, и вот эта идея, что кто-то кому-то что-то должен, не работает за пределами идеального мира религиозно-озабоченных людей.
3. Я плачу продактам не для того, чтобы они спрашивали у пользователей, что им нужно. А для того чтобы они делали то, что пользователь купит. Нужен пользователю blackberry с лучшим экраном и большей батарейков. А купит он Айфон. Интервью это один из инструментов проверки гипотез, заказчик и пользователь не знают что им нужно.
Вы даже до максимы "пользователю не нужно сверло на 3/4, ему нужна дырка на 3/4", которая сама спорна, потому что пользователю нужны не дырки для горшков или полок, а уют и порядок, а еще кого-то пытаетесь критиковать. Короче, вы сам источник всех своих проблем. Удачи вам в нелегкой борьбе с собой!
"вы сам источник всех своих проблем. Удачи вам в нелегкой борьбе с собой!" — так можно сказать про любого человека )
Кроме того по вашему описанию, у меня складывается впечатление, что речь идет о так называемом "сопровождении продукта" - ситуации, когда в устоявшийся продукт или систему запрещено вносить изменения и "продуктовая команда" работает не над продуктом с его пользователями, а с заявками на его изменение, большинство из которых она вынуждена отклонять, потому что они уходят далеко за зону ее ответственности и представляют собой масштабные проекты уровня организации, инициация которых требует одобрения высшего менеджмента. Ну это просто "кровавый энтерпрайз", гибкие методы сюда никак не всунешь. Радуйтесь, если у вас там есть канбан-доска, это уже существенный прорыв. Но вечные битвы за "приоритезацию тасков" вам обеспечены. Но Agile тут снова не при чем )
А если у вас нет пользователей, которым можно показывать версии продукта, а стейклохдеры говорят, что обладают всей полнотой требований, то просто не используйте Scrum )
Соберите требования, оцените сверху и разбейте их на этапы-проекты, в рамках каждого проекта произведите детальную декомпозицию, уточните сроки и пилите себе спокойно продукт законченными кусками фич в рамках проектов, не переживая, что продукт еще не может быть использован вообще.
В рамках проектной деятельности полно способов повышения видимости и получения обратной связи - вехи, опытная эксплуатация, эскизное проектирование... Если вам нужно работать по ЕСПД - работайте. Вряд ли только у кого-то хватит на это денег и терпения )
Ну конечно, работать с неполнотой требований можно только по scrum. Ведь за пределами разработки ПО всегда есть вся полнота требований, от оборонного заказа до частных яхт. И только в разработке ПО, так получилось, что требования бывают неполными, и только скрам это решение проблемы.
Вы писали когда-нибудь "Обоснование выбора программных средств" на 200 страниц, а потом "Обоснование выбора проектных решений" на пять томов перед разработкой системы? Я писал. )
Отличие Scrum от традиционного подхода в том, что в нем требования уточняются в процессе проекта и через разработку. Когда как в традиционном подходе требования уточняются и фиксируются в рамках нескольких этапов проектирования, предваряющих разработку в рамках проекта.
Блин, вы рассуждаете о предмете, не имея базовых понятий о нем, которые рассказываются на 4-5 курсе института )
Какое у вас образование вообще, если не секрет?
Вы писали когда-нибудь "Обоснование выбора программных средств" на 200 страниц, а потом "Обоснование выбора проектных решений" на пять томов перед разработкой системы? — это же не вопрос скрам или не скрам, это вопрос принятых верхнеуровневых стандартов в документообороте. При этом, внутри могут быть скрам-команды вполне, но наружу вам придется отдавать тома документации все равно.
У меня три класса церковно-приходской школы, а что?
Ну про отсутствие базового образования в computer science и результирующую кашу в голове сильно заметно. Стандарты документирования хех
нет конечно. В скраме делегируются задачи.
Только в вашем варианте псевдоScrum, где над задачами работают не продуктовые, а функциональные команды.
да и в продуктовых, вы планируете что? спринт. В спринт идут что — таски. Таски делегируются от кого — от продуктового менеджера. Программисты и дизайнеры — делают таски, а не проекты.
А в проекте что делает бэк-эндер? )))
Какую чушь вы несете, божечки.