Channel: OnAgile Learning Hub 💎
Продолжаем разбираться, чем фреймворки отличаются от методологий
В прошлый раз мы обсудили, в чём разница между этими двумя понятиями, определились с тем, что же такое Scrum и как его воспринимать, чтобы он приносил результат. А сегодня сравним уже знакомый вам Scrum с другим популярным подходом — SAFe.
⚙️ Как мы уже выяснили, Scrum — это классический фреймворк:
• 3 роли
• 5 событий
• 3 артефакта
• Умещается в руководство на 19 страниц
• Минимум правил, а как их применять — решайте сами
⚙️ SAFe (Scaled Agile Framework) начинался как фреймворк для масштабирования, но со временем эволюционировал в нечто близкое к методологии:
• Десятки ролей и должностей
• Многоуровневая структура (Essential, Large Solution, Portfolio, Full)
• Подробные руководства по внедрению
• Сотни страниц документации с детальными описаниями практик, метрик и процессов
• Готовые решения для большинства типовых ситуаций
❤️ Как это выглядит на практике
Scrum даёт основу, на которой можно построить рабочий процесс, а благодаря высокой адаптивности команда сама определяет, как именно это сделать. SAFe же, напротив, предлагает готовые решения на любой случай жизни — в нём их больше, чем в обычном фреймворке.
Небольшим командам, как правило, хватает простоты и гибкости Scrum. А вот в больших компаниях нужна конкретика и продуманная структура.
❤️ А что говорит опыт других компаний
С одной стороны, наличие готовых решений — это удобно. Но важно помнить, что все они появились из чужого опыта, из других продуктов и у других команд. И то, что сработало у одних, может оказаться бесполезным для других или даже навредить им.
Вспомните Rational Unified Process (RUP) и Microsoft Solution Framework (MSF). Многие пробовали идти по пути универсальных методологий, которые оказались слишком сложным для внедрения. Это привело к тому, что их часто неправильно применяли, и в итоге от них отказались ещё в 2005 году.
Всё циклично, и история любит повторяться.
Как вы считаете — стоит ли использовать детализированные методологии или лучше придерживаться простых и гибких фреймворков, не перегружая процесс лишними правилами?
В прошлый раз мы обсудили, в чём разница между этими двумя понятиями, определились с тем, что же такое Scrum и как его воспринимать, чтобы он приносил результат. А сегодня сравним уже знакомый вам Scrum с другим популярным подходом — SAFe.
• 3 роли
• 5 событий
• 3 артефакта
• Умещается в руководство на 19 страниц
• Минимум правил, а как их применять — решайте сами
• Десятки ролей и должностей
• Многоуровневая структура (Essential, Large Solution, Portfolio, Full)
• Подробные руководства по внедрению
• Сотни страниц документации с детальными описаниями практик, метрик и процессов
• Готовые решения для большинства типовых ситуаций
Scrum даёт основу, на которой можно построить рабочий процесс, а благодаря высокой адаптивности команда сама определяет, как именно это сделать. SAFe же, напротив, предлагает готовые решения на любой случай жизни — в нём их больше, чем в обычном фреймворке.
Небольшим командам, как правило, хватает простоты и гибкости Scrum. А вот в больших компаниях нужна конкретика и продуманная структура.
С одной стороны, наличие готовых решений — это удобно. Но важно помнить, что все они появились из чужого опыта, из других продуктов и у других команд. И то, что сработало у одних, может оказаться бесполезным для других или даже навредить им.
Суть Agile как раз в том, чтобы искать свои, оригинальные подходы, а не копировать чужие.
Вспомните Rational Unified Process (RUP) и Microsoft Solution Framework (MSF). Многие пробовали идти по пути универсальных методологий, которые оказались слишком сложным для внедрения. Это привело к тому, что их часто неправильно применяли, и в итоге от них отказались ещё в 2005 году.
Всё циклично, и история любит повторяться.
Как вы считаете — стоит ли использовать детализированные методологии или лучше придерживаться простых и гибких фреймворков, не перегружая процесс лишними правилами?
Please open Telegram to view this post
VIEW IN TELEGRAM
👍4❤2
• 28 - 30 апреля
• 19 - 21 мая
🔹 Профессиональный сертификационный тренинг по Agile и Scrum
Я хочу понять, как начать внедрять гибкие подходы Agile, Scrum и Kanban в своей компании и научиться планировать в условиях неопределенности.
• 26 - 28 мая
🔹 Cертифицированный Скрам-мастер и фасилитатор
Я хочу научиться проводить командные встречи, организовывать ретроспективы даже в сложных ситуациях и создавать атмосферу доверия и тесного сотрудничества внутри своей команды.
• 09 - 11 апреля
• 25 - 27 июня
🔹Сертифицированный Владелец продукта в Agile
Я хочу научиться создавать востребованные продукты, которые действительно решают задачи клиентов, и привить себе навык продуктового мышления.
• 18 - 20 июня
🔹 Сертифицированный Delivery и Project менеджер в Agile
Я хочу ощутить ценность применения Agile и Scrum для своих проектов и овладеть самыми актуальными инструментами управления.
После прохождения каждого курса вы получите именной сертификат от международного консорциума ICAgile.
• 23 - 25 июля
🔹 Масштабирование Agile на основе SAFe, LeSS и Fligth Levels
Я хочу научиться управлять несколькими кросс-функциональными командами и синхронизировать их работу.
📍Сейчас самое время успеть воспользоваться выгодными условиями для тех, кто регистрируется заранее.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍2🔥2🥰1
Это подход к организации работы, когда департаменты формируются не по функциям — например, маркетинг, продажи и разработка — а вокруг конкретного бизнес-направления или линейки продуктов.
То есть внутри каждой такой вертикали есть все специалисты, которые нужны для запуска и развития продукта — свои разработчики, аналитики, маркетологи и прочие. И все они работают, как одна команда.
Например, после перехода на Agile в Сбере выделились несколько value streams — потоков ценности, внутри которых сформировались кросс-функциональные трайбы, скводы и центры компетенций. У каждой из таких «вертикалей» есть ресурсы и сотрудники, которые ведут продукты от начала и до конца.
Модель бизнес-вертикалей действительно чаще всего встречается в крупных компаниях — там, где есть много разных продуктов. Но на самом деле этот подход может быть полезен компаниям среднего размера, особенно если у них уже есть несколько продуктов, или если они планируют активно расти.
Допустим, у вас компания, которая выпускает бытовую химию. В этом случае вертикалями могут быть хозтовары, косметика или другие направления в зависимости от ассортимента, каналов сбыта и целевой аудитории. Каждая из вертикалей будет работать как мини-компаниия внутри одной большой со своей командой, продуктами, прибылью и задачами.
Это перекликается с Agile-подходом и идеей кросс-функциональных команд.
Внутри геосервисов «Яндекс.Карт» и «Яндекс.Навигатора» работают отдельные продуктовые команды, которые полностью отвечают, например, за поиск заведений или алгоритмы маршрутизации. Аналогично устроены и другие сервисы Яндекса — будь то облако, поисковая система или другие направления.
Каждая вертикаль самостоятельно отвечает за свои метрики — за доход, рост и долю рынка.
Что вы думаете о модели бизнес-вертикалей?
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥4👍2
Продолжая тему прошлого поста — пример того, как устроена бизнес-вертикаль в компании Avito.
— У нас пять вертикальных команд. Они разрабатывают основные направления бизнеса, вы можете знать их как категории на Авито: товары, авто, работа, недвижимость и услуги.
Вертикали в Avito различаются друг от друга по типу объявлений и по способам монетизации. Соответственно, у каждой из них есть свои отдельные инструменты, заточенные под задачи конкретного продуктового направления.
Каждая вертикаль отвечает за свой поток ценности
Кросс-функциональные продуктовые команды устроены так, что в них есть свои разработчики, аналитики, продуктовые менеджеры, дизайнеры, маркетологи и другие специалисты. Они глубоко погружены и хорошо понимают специфику именно этой категории объявлений — как люди выбирают и покупают машину, квартиру, или как ищут работу. И за счёт этого могут самостоятельно влиять на их пользовательский опыт.
Когда мы помогаем клиентам в переходе на Agile-модель работы, разделение на продуктовые вертикали или value streams — это из этапов преобразования организационной структуры, которая будет способствовать более быстрой поставке результата.
С его помощью мы стараемся упростить иерархию и сделать процесс взаимодействия и принятия решений максимально быстрым.
Посмотрите интересную статью про Роли и Оргструктуру в LeSS.
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥3
На одном из тренингов участник задал нам вопрос:
Стоит ненадолго остановиться и подумать, а как вообще составлять требования, если сами заказчики не понимают, чего хотят? Давайте порассуждаем, как это устроено в гибких организациях.
Требования не должны быть высечены в камне
Во-первых, они не должны быть слишком объёмными. Подход, в котором всё до мелочей расписано и собрано в один большой документ, чтобы потом ему строго следовать — не самый удачный.
Во-вторых, в результате такого подхода появляется огромный, неподъёмный документ, с которым потом приходится разбираться разработчикам и тестировщикам. Они остаются один на один с этими требованиями, без возможности уточнить что-либо у заказчика и получить фидбэк по ходу работы. Их задача — на основе этих правил создать работающий продукт.
Такая модель разработки усложняет весь процесс
Большие требования долго реализуются, тестируются и также долго исправляются. Можно потратить много времени и ресурсов, но получить совсем не то, что действительно нужно пользователю.
Конечно, и в Agile можно ошибиться и сделать что-то не то. Но ошибка в этом случае будет менее критичной, потому что на неё тратится гораздо меньше времени. И остаются ресурсы, чтобы быстро её исправить — и время, и бюджет.
Поэтому, отвечая на этот вопрос, можно сказать следующее:
Да, большинство из нас привыкли, что требования должны быть полными, ясными и исчерпывающими — и это действительно важный фундамент, с точки зрения понимания, как работают каскадные процессы разработки. Но когда мы переходим к продуктовой разработке, где важно быстро выводить решения на рынок, конкурировать и привлекать новых пользователей — этот фундаментальный подход перестаёт быть эффективным.
В таких условиях нужен другой, более гибкий подход к формулировке требований и работе с ними.
— Если в процессе обсуждения выясняется, что заказчики сами не до конца понимают, чего именно они хотят? Означает ли это, что требования вообще не нужны? Или они не должны быть полными, исчерпывающими и ясными — как нас обычно учат?
Стоит ненадолго остановиться и подумать, а как вообще составлять требования, если сами заказчики не понимают, чего хотят? Давайте порассуждаем, как это устроено в гибких организациях.
Требования не должны быть высечены в камне
Во-первых, они не должны быть слишком объёмными. Подход, в котором всё до мелочей расписано и собрано в один большой документ, чтобы потом ему строго следовать — не самый удачный.
Во-вторых, в результате такого подхода появляется огромный, неподъёмный документ, с которым потом приходится разбираться разработчикам и тестировщикам. Они остаются один на один с этими требованиями, без возможности уточнить что-либо у заказчика и получить фидбэк по ходу работы. Их задача — на основе этих правил создать работающий продукт.
Такая модель разработки усложняет весь процесс
Большие требования долго реализуются, тестируются и также долго исправляются. Можно потратить много времени и ресурсов, но получить совсем не то, что действительно нужно пользователю.
Конечно, и в Agile можно ошибиться и сделать что-то не то. Но ошибка в этом случае будет менее критичной, потому что на неё тратится гораздо меньше времени. И остаются ресурсы, чтобы быстро её исправить — и время, и бюджет.
Поэтому, отвечая на этот вопрос, можно сказать следующее:
Да, большинство из нас привыкли, что требования должны быть полными, ясными и исчерпывающими — и это действительно важный фундамент, с точки зрения понимания, как работают каскадные процессы разработки. Но когда мы переходим к продуктовой разработке, где важно быстро выводить решения на рынок, конкурировать и привлекать новых пользователей — этот фундаментальный подход перестаёт быть эффективным.
В таких условиях нужен другой, более гибкий подход к формулировке требований и работе с ними.
👍4
В апреле 1970 года космический корабль «Аполлон-13» отправился к Луне — это должна была стать третья в истории пилотируемая посадка на её поверхность. Внутри были трое астронавтов.
Но всё пошло не по плану, когда прямо во время полёта в одном из кислородных баллонов произошёл взрыв
Это привело к серьёзной утечке кислорода и отключению важного оборудования. Наземному центру управления в Хьюстоне пришлось немедленно изменить свой курс, и вместо высадки на Луну срочно придумывать, как спасти экипаж в условиях крайне ограниченных ресурсов и времени.
Сегодня «Аполлон-13» — это классический пример того, что даже при самом тщательном планировании и проработке требований, невозможно предусмотреть всё заранее. Что-то всё равно придётся дорабатывать и начинать сначала, чтобы всё-таки высадиться на Луну.
Вся подготовка к запуску была расписана по шагам в чек-листах, основанных на опыте предыдущих полётов — как заправить ракету, как проводить проверки систем и как организовать быт астронавтов на борту. Тестирование скафандров, ремней и оборудования проводилось также строго, как все остальные проверки.
Это была та часть миссии, где всё оставалось предсказуемо
Что касается планирования самого полёта, то здесь нужно было заранее учитывать массу факторов и привлекать к работе опытных специалистов, ведь каждый полёт уникален — когда именно стартовать, как рассчитать траекторию до Луны и обратно, и какие манёвры предстоит выполнить. Всё это ещё предстояло определить.
То же самое касается проектирования систем жизнеобеспечения и двигателей — это огромный пласт инженерной работы, в которой необходимы экспертные знания и точные расчёты. Нельзя было просто взять и скопировать готовые решение — нужны были адаптации.
Тем не менее, эта часть миссии тоже оставалась предсказуемой, пусть для неё и не сущестовало стандартных решений. В следующем посте мы расскажем, что же произошло в момент самой аварии.
Но всё пошло не по плану, когда прямо во время полёта в одном из кислородных баллонов произошёл взрыв
Это привело к серьёзной утечке кислорода и отключению важного оборудования. Наземному центру управления в Хьюстоне пришлось немедленно изменить свой курс, и вместо высадки на Луну срочно придумывать, как спасти экипаж в условиях крайне ограниченных ресурсов и времени.
Сегодня «Аполлон-13» — это классический пример того, что даже при самом тщательном планировании и проработке требований, невозможно предусмотреть всё заранее. Что-то всё равно придётся дорабатывать и начинать сначала, чтобы всё-таки высадиться на Луну.
Вся подготовка к запуску была расписана по шагам в чек-листах, основанных на опыте предыдущих полётов — как заправить ракету, как проводить проверки систем и как организовать быт астронавтов на борту. Тестирование скафандров, ремней и оборудования проводилось также строго, как все остальные проверки.
Это была та часть миссии, где всё оставалось предсказуемо
Что касается планирования самого полёта, то здесь нужно было заранее учитывать массу факторов и привлекать к работе опытных специалистов, ведь каждый полёт уникален — когда именно стартовать, как рассчитать траекторию до Луны и обратно, и какие манёвры предстоит выполнить. Всё это ещё предстояло определить.
То же самое касается проектирования систем жизнеобеспечения и двигателей — это огромный пласт инженерной работы, в которой необходимы экспертные знания и точные расчёты. Нельзя было просто взять и скопировать готовые решение — нужны были адаптации.
Тем не менее, эта часть миссии тоже оставалась предсказуемой, пусть для неё и не сущестовало стандартных решений. В следующем посте мы расскажем, что же произошло в момент самой аварии.
🔥4❤2👍2
Продолжаем рассказывать о миссии «Аполлон-13»
Ещё до аварии команде на борту и в Центре управления приходилось иметь в виду, что некоторые риски невозможно просчитать заранее — например, как скажется космическая радиация, как поведёт себя оборудование в невесомости, и какие технические сбои могут произойти в ходе полёта.
Другим важным моментом были сами астронавты — им предстояло провести много времени в замкнутом пространстве.
В момент взрыва на борту «Аполлона-13» оборудование частично вышло из строя, кислород резко начал заканчиваться, и узнать обо всех повреждениях было практически невозможно.
Именно тогда прозвучала легендарная фраза:
Когда астронавты сообщили о проблемах, дежурные в Центре управления полётами в Хьюстоне не понимали какой именно резервуар повреждён.
Все расчёты и графики полёта пришлось отложить. Основная задача была — не дойти до Луны, а просто выжить. Не было времени на долгие обсуждения, инженеры на Земле и астронавты на борту из подручных материалов собрали фильтр для углекислого газа, который буквально спас экипаж.
В NASA существовал план на случай аварийных ситуаций — сначала стабилизировать обстановку, чтобы экипаж мог дышать, а уже потом думать, как вернуть корабль домой.
Команда тоже была очень хорошо натренирована на нештатные случаи — одни параллельно собирали данные и пытались понять, что случилось, а другие выполняли действия на случай сбоя в электропитании, поскольку топливные элементы «Аполлона» получали энергию, используя кислород из этих же баков.
Проблема была в том, что штатные инструкции не покрывали весь масштаб повреждения. Как только стало понятно, что целый резервуар кислорода утерян, было принято решение перевести экипаж в лунный модуль и использовать его как спасательную шлюпку.
Инженеры из NASA нашли способ подключить квадратные фильтры от командного модуля к круглым отверстиям лунного модуля — с помощью пластиковых пакетов, скотча и шлангов. Этот момент вошёл в историю в качестве примера того, как «соединить квадратное с круглым».
ЦУП рассчитал манёвр, который позволил использовать гравитацию Луны, чтобы развернуть корабль и вернуться на Землю. В итоге астронавты благополучно приземлились 17 апреля 1970 года в Тихом океане.
Предлагаем вам по случаю прошедшего Дня Космонавтики прочитать полную историю миссии «Аполлон-13». А в следующем посте мы разберём, чему она может нас научить с точки зрения подходов к принятию решений.
Ещё до аварии команде на борту и в Центре управления приходилось иметь в виду, что некоторые риски невозможно просчитать заранее — например, как скажется космическая радиация, как поведёт себя оборудование в невесомости, и какие технические сбои могут произойти в ходе полёта.
Другим важным моментом были сами астронавты — им предстояло провести много времени в замкнутом пространстве.
В момент взрыва на борту «Аполлона-13» оборудование частично вышло из строя, кислород резко начал заканчиваться, и узнать обо всех повреждениях было практически невозможно.
Именно тогда прозвучала легендарная фраза:
— Houston, we have a problem.
Когда астронавты сообщили о проблемах, дежурные в Центре управления полётами в Хьюстоне не понимали какой именно резервуар повреждён.
Все расчёты и графики полёта пришлось отложить. Основная задача была — не дойти до Луны, а просто выжить. Не было времени на долгие обсуждения, инженеры на Земле и астронавты на борту из подручных материалов собрали фильтр для углекислого газа, который буквально спас экипаж.
В NASA существовал план на случай аварийных ситуаций — сначала стабилизировать обстановку, чтобы экипаж мог дышать, а уже потом думать, как вернуть корабль домой.
Команда тоже была очень хорошо натренирована на нештатные случаи — одни параллельно собирали данные и пытались понять, что случилось, а другие выполняли действия на случай сбоя в электропитании, поскольку топливные элементы «Аполлона» получали энергию, используя кислород из этих же баков.
Проблема была в том, что штатные инструкции не покрывали весь масштаб повреждения. Как только стало понятно, что целый резервуар кислорода утерян, было принято решение перевести экипаж в лунный модуль и использовать его как спасательную шлюпку.
Инженеры из NASA нашли способ подключить квадратные фильтры от командного модуля к круглым отверстиям лунного модуля — с помощью пластиковых пакетов, скотча и шлангов. Этот момент вошёл в историю в качестве примера того, как «соединить квадратное с круглым».
ЦУП рассчитал манёвр, который позволил использовать гравитацию Луны, чтобы развернуть корабль и вернуться на Землю. В итоге астронавты благополучно приземлились 17 апреля 1970 года в Тихом океане.
Предлагаем вам по случаю прошедшего Дня Космонавтики прочитать полную историю миссии «Аполлон-13». А в следующем посте мы разберём, чему она может нас научить с точки зрения подходов к принятию решений.
🔥6❤2
Модель Киневин (Cynefin framework)
В прошлых постах мы рассказали, как развивалась история миссии «Аполлон-13», и сколько разных факторов пришлось учесть NASA при выполнении полёта, особенно в ситуации, когда на борту произошла авария.
Сегодня мы поговорим о модели Киневин, которая как раз и помогает разобраться, как принимать решения в зависимости от ситуации, в которой вы находитесь.
Простая (Simple)
«Наблюдать— Классифицировать — Реагировать»
В этой среде легко прослеживаются причинно-следственные связи и для всего существуют готовые решения. Здесь лучше всего работают стандартизованные процессы — с инструкциями и чек-листами, которые помогают не допускать ошибок.
Сложная (Complicated)
«Наблюдать — Анализировать — Реагировать»
Ситуация уже не совсем простая, но всё ещё вполне предсказуемая. Здесь больше подойдут классические методы управления проектами. Но если есть вероятность, что условия начнут меняться, то можно добавить элементы из гибких подходов. Например, разбить работу на итерации, чтобы проще было вносить изменения в проект и влиять на результат.
Запутанная (Complex)
«Провести эксперимент — Наблюдать — Реагировать»
Это среда, в которой сложно сразу определить все взаимосвязи — приходится пробовать, наблюдать за результатами и быстро адаптироваться. В таких условиях лучше всего работают Agile-практики, короткие итерации и регулярные циклы инспекции и адаптации — например, спринты и ретроспективы.
Хаотическая (Chaotic)
«Действовать — Наблюдать — Реагировать»
Нет времени на долгий анализ и планирование, потому что всё меняется слишком быстро или уже вышло из-под контроля. В первую очередь нужно стабилизировать ситуацию и среагировать, чтобы вернуться хотя бы к запутанной или сложной среде. А уже потом, когда обстановка станет более предсказуемой, заниматься аналитикой и планированием.
Показательный момент хаотической среды в миссии «Аполлон-13» — это взрыв кислородного баллона. Высадка на Луну больше не имела смысла, когда главной задачей стало — срочно обеспечить возможность дышать. Астронавты, чтобы выжить, собрали самодельный углекислотный фильтр из того, что было под рукой и спаслись. И только после этого начали анализировать аварию и продумывать следующие шаги по возвращению домой.
Подробней о модели Киневин и о том, как она работает на примере реальных рабочих ситуациях, мы рассказываем на нашем курсе Certified Agile Professional.
В прошлых постах мы рассказали, как развивалась история миссии «Аполлон-13», и сколько разных факторов пришлось учесть NASA при выполнении полёта, особенно в ситуации, когда на борту произошла авария.
Сегодня мы поговорим о модели Киневин, которая как раз и помогает разобраться, как принимать решения в зависимости от ситуации, в которой вы находитесь.
Простая (Simple)
«Наблюдать— Классифицировать — Реагировать»
В этой среде легко прослеживаются причинно-следственные связи и для всего существуют готовые решения. Здесь лучше всего работают стандартизованные процессы — с инструкциями и чек-листами, которые помогают не допускать ошибок.
Сложная (Complicated)
«Наблюдать — Анализировать — Реагировать»
Ситуация уже не совсем простая, но всё ещё вполне предсказуемая. Здесь больше подойдут классические методы управления проектами. Но если есть вероятность, что условия начнут меняться, то можно добавить элементы из гибких подходов. Например, разбить работу на итерации, чтобы проще было вносить изменения в проект и влиять на результат.
Запутанная (Complex)
«Провести эксперимент — Наблюдать — Реагировать»
Это среда, в которой сложно сразу определить все взаимосвязи — приходится пробовать, наблюдать за результатами и быстро адаптироваться. В таких условиях лучше всего работают Agile-практики, короткие итерации и регулярные циклы инспекции и адаптации — например, спринты и ретроспективы.
Хаотическая (Chaotic)
«Действовать — Наблюдать — Реагировать»
Нет времени на долгий анализ и планирование, потому что всё меняется слишком быстро или уже вышло из-под контроля. В первую очередь нужно стабилизировать ситуацию и среагировать, чтобы вернуться хотя бы к запутанной или сложной среде. А уже потом, когда обстановка станет более предсказуемой, заниматься аналитикой и планированием.
Показательный момент хаотической среды в миссии «Аполлон-13» — это взрыв кислородного баллона. Высадка на Луну больше не имела смысла, когда главной задачей стало — срочно обеспечить возможность дышать. Астронавты, чтобы выжить, собрали самодельный углекислотный фильтр из того, что было под рукой и спаслись. И только после этого начали анализировать аварию и продумывать следующие шаги по возвращению домой.
Подробней о модели Киневин и о том, как она работает на примере реальных рабочих ситуациях, мы рассказываем на нашем курсе Certified Agile Professional.
👍5
Частый вопрос — как работать с требованиями от заказчиков?
Да, заказчик, вероятно, предоставит описание требований. Но то, каким человек представляет продукт, и то, что на практике будет приность ценность — это не всегда одно и то же. Поэтому лучше сразу пойти в верном направлении, чтобы потом не пришлось переделывать.
А софтверный продукт вообще не получится оценить заранее, пока не будет реализована хотя бы одна фича. Без этого невозможно сказать: «Вот, это оно» или наоборот — «Нет, это не то».
Почти каждый заказчик изначально уверен, что понимает, чего хочет и как это должно работать. Agile просто предлагает использовать эти знания как отправную точку — взять всё, что уже известно, и на этом строить гипотезы. Только не хвататься сразу за весь объём работы, а идти небольшими шагами, проверяя каждую гипотезу.
С большинством заказчиков вполне возможно договориться, ведь в итоге всем хочется как можно быстрее увидеть результат и потрогать что-то реальное. В традиционной модели это «что-то» может появится только через год. А в Agile — минимально работающий продукт можно получить уже через пару недель или месяцев.
Вернёмся к примеру с лодкой из иллюстрации к посту — да, это может быть плот с веслом вместо полноценного корабля. Но именно в этот момент у заказчика может возникнуть ощущение, что продукт уже работает. Он сможет увидеть ценность, понять как это можно использовать или даже продать. А главное, что всё это сделано всего за пару недель, без долгого ожидания, к которому заказчик привык в предыдущих проектах.
Мы знаем множество таких историй, потому что регулярно помогаем клиентам в подобных ситуациях
Если речь идёт о сложной, непредсказуемой среде — а именно так устроены многие проекты — просто невозможно заранее предусмотреть всё. И тут важно не впадать в крайности — требования по-прежнему нужны. Просто меняется подход — не сразу и не целиком, а небольшими частями.
В Agile мы фокусируемся не на том, что будет в самом конце, а на ближайшнем инкременте продукта — потому что невозможно заранее предсказать, куда этот путь нас приведёт.
Чтобы разобраться, как этот подход работает на практике — приходите на наш тренинг Certified Agile Professional.
— Заказчик ведь понимает, какую цель он преследует и какую прибыль хочет получить. Он может описать это на бизнес-языке. Почему тогда нельзя просто сразу всё подробно зафиксировать в требованиях и работать по ним?
Да, заказчик, вероятно, предоставит описание требований. Но то, каким человек представляет продукт, и то, что на практике будет приность ценность — это не всегда одно и то же. Поэтому лучше сразу пойти в верном направлении, чтобы потом не пришлось переделывать.
А софтверный продукт вообще не получится оценить заранее, пока не будет реализована хотя бы одна фича. Без этого невозможно сказать: «Вот, это оно» или наоборот — «Нет, это не то».
Почти каждый заказчик изначально уверен, что понимает, чего хочет и как это должно работать. Agile просто предлагает использовать эти знания как отправную точку — взять всё, что уже известно, и на этом строить гипотезы. Только не хвататься сразу за весь объём работы, а идти небольшими шагами, проверяя каждую гипотезу.
С большинством заказчиков вполне возможно договориться, ведь в итоге всем хочется как можно быстрее увидеть результат и потрогать что-то реальное. В традиционной модели это «что-то» может появится только через год. А в Agile — минимально работающий продукт можно получить уже через пару недель или месяцев.
Вернёмся к примеру с лодкой из иллюстрации к посту — да, это может быть плот с веслом вместо полноценного корабля. Но именно в этот момент у заказчика может возникнуть ощущение, что продукт уже работает. Он сможет увидеть ценность, понять как это можно использовать или даже продать. А главное, что всё это сделано всего за пару недель, без долгого ожидания, к которому заказчик привык в предыдущих проектах.
Мы знаем множество таких историй, потому что регулярно помогаем клиентам в подобных ситуациях
Если речь идёт о сложной, непредсказуемой среде — а именно так устроены многие проекты — просто невозможно заранее предусмотреть всё. И тут важно не впадать в крайности — требования по-прежнему нужны. Просто меняется подход — не сразу и не целиком, а небольшими частями.
В Agile мы фокусируемся не на том, что будет в самом конце, а на ближайшнем инкременте продукта — потому что невозможно заранее предсказать, куда этот путь нас приведёт.
Чтобы разобраться, как этот подход работает на практике — приходите на наш тренинг Certified Agile Professional.
❤3🔥1
На прошлой неделе у нас было корпоративное обучение для руководителей из крупной организации. Во время сессии директор одного из департаментов задал нам вопрос:
Всё верно. Самоорганизация — это состояние, к которому команда приходит через определённый процесс.
Представьте себе график, где на одной оси — время, а на другой — уровень самоорганизации. Этот уровень не начнёт резко расти, скажем, с понедельника. Это определённая динамика.
Чтобы команда становилась всё более самоорганизованной, требуется непрерывно прилагать усилия.
Scrum-мастер помогает изнутри команды, а менеджеры — извне. Мы, как консультанты, часто выступаем третьей стороной и плотно работаем с командами, особенно на старте — в самый сложный период самоорганизации, когда её только нужно запустить.
Бывают случаи, когда в компании разработчики с многолетним опытом прямо говорят менеджерам, что Agile им неинтересен, и их лучше не трогать, чтобы не мешать спокойно выполнять свою работу.
Их поведение может стать сигналом, что если кому-то можно остаться в стороне, то значит можно и всем остальным. В итоге желание что-то менять постепенно исчезнет, и команда просто вернётся обратно к привычному способу организации работы.
С такими ситуациями приходится работать постепенно и аккуратно подключать каждого участника команды к процессу изменений.
Но тут есть один важный момент — в компании должен быть человек, у которого есть энергия и мотивация этим заняться. Кто-то, кто возьмёт на себя роль двигателя этих изменений. Без такого человека процесс просто не сдвинется с места.
— По опыту кажется, что все команды очень разные, и я не верю, что все они могут стать самоорганизованными.
Всё верно. Самоорганизация — это состояние, к которому команда приходит через определённый процесс.
Представьте себе график, где на одной оси — время, а на другой — уровень самоорганизации. Этот уровень не начнёт резко расти, скажем, с понедельника. Это определённая динамика.
Чтобы команда становилась всё более самоорганизованной, требуется непрерывно прилагать усилия.
Scrum-мастер помогает изнутри команды, а менеджеры — извне. Мы, как консультанты, часто выступаем третьей стороной и плотно работаем с командами, особенно на старте — в самый сложный период самоорганизации, когда её только нужно запустить.
Бывают случаи, когда в компании разработчики с многолетним опытом прямо говорят менеджерам, что Agile им неинтересен, и их лучше не трогать, чтобы не мешать спокойно выполнять свою работу.
Их поведение может стать сигналом, что если кому-то можно остаться в стороне, то значит можно и всем остальным. В итоге желание что-то менять постепенно исчезнет, и команда просто вернётся обратно к привычному способу организации работы.
С такими ситуациями приходится работать постепенно и аккуратно подключать каждого участника команды к процессу изменений.
Но тут есть один важный момент — в компании должен быть человек, у которого есть энергия и мотивация этим заняться. Кто-то, кто возьмёт на себя роль двигателя этих изменений. Без такого человека процесс просто не сдвинется с места.
👍5❤1
Вокруг гибких подходов до сих пор существует много страхов и домыслов. Особенно в тех командах, которые только начинают внедрять Agile.
Например, когда мы разговаривали с руководителем QA-практики в одной компании, он поднял такой вопрос:
Конечно не придётся. Иногда понятие «кросс-функциональность» понимают не совсем верно — будто в такой команде каждый участник должен уметь работать за всех. Отсюда и возникает страх, что кого-то будут увольнять.
Но на самом деле смысл совсем в другом
В Agile под «кросс-функциональностью» понимают, что в команде собраны все необходимые компетенции, и участники могут самостоятельно поставлять работающий продукт. А ещё, чтобы у сотрудников была минимальная зависимость от других команд или внешних специалистов. Потому что каждая внешняя зависимость, как мы знаем, — это потенциальная задержка.
Поэтому в команду стараются максимально привлекать всех нужных специалистов, насколько это возможно. А те компетенции, которых не хватает и которые не удалось включить в состав команды сразу, развиваются внутри самой команды.
Допустим, команда работает как самоорганизующаяся и замечает, что им перестало хватать тестировщиков. Например, кто-то ушёл, а нового ещё не наняли. В итоге — остался один тестировщик на пять разработчиков.
Очевидно, что это нерабочая модель для большинства продуктов. Но разработчиков в команде по-прежнему пятеро, и продукт всё равно нужно выпускать. А это значит, что команда садится и начинает думать — что можно сделать своими силами, чтобы сохранить максимально возможный уровень качества в текущих условиях?
Представим, что в команде остался один мидл-тестировщик — он берёт на себя инициативу и объясняет основы тестирования всем остальным, делится базовыми материалами и знакомит команду с текущим тест-планом. После этого вся команда может выделить время, чтобы вместе протестировать сборку.
Так бывает, что на каком-то этапе команде не хватает нужных компетенций. И будет здорово, если сами участники начнут проявлять инициативу — учиться, делиться опытом и помогать друг другу двигаться вперёд. Навыки, к сожалению, сами по себе не появляются.
Чтобы помочь участникам команды развить недостающие навыки и грамотно спланировать рост специалистов, можно использовать специальный инструмент — Звёздную карту компетенций.
В Agile мы верим, что кросс-функциональная самоорганизующаяся команда вполне может самостоятельно собраться, чтобы обсудить какую-то ситуацию и найти оптимальное работающее решение.
Например, когда мы разговаривали с руководителем QA-практики в одной компании, он поднял такой вопрос:
— Правильно ли я понимаю, что в результате перехода на кросс-функциональный самоорганизующиеся команды придётся всех уволить?
Конечно не придётся. Иногда понятие «кросс-функциональность» понимают не совсем верно — будто в такой команде каждый участник должен уметь работать за всех. Отсюда и возникает страх, что кого-то будут увольнять.
Но на самом деле смысл совсем в другом
В Agile под «кросс-функциональностью» понимают, что в команде собраны все необходимые компетенции, и участники могут самостоятельно поставлять работающий продукт. А ещё, чтобы у сотрудников была минимальная зависимость от других команд или внешних специалистов. Потому что каждая внешняя зависимость, как мы знаем, — это потенциальная задержка.
Поэтому в команду стараются максимально привлекать всех нужных специалистов, насколько это возможно. А те компетенции, которых не хватает и которые не удалось включить в состав команды сразу, развиваются внутри самой команды.
Допустим, команда работает как самоорганизующаяся и замечает, что им перестало хватать тестировщиков. Например, кто-то ушёл, а нового ещё не наняли. В итоге — остался один тестировщик на пять разработчиков.
Очевидно, что это нерабочая модель для большинства продуктов. Но разработчиков в команде по-прежнему пятеро, и продукт всё равно нужно выпускать. А это значит, что команда садится и начинает думать — что можно сделать своими силами, чтобы сохранить максимально возможный уровень качества в текущих условиях?
Представим, что в команде остался один мидл-тестировщик — он берёт на себя инициативу и объясняет основы тестирования всем остальным, делится базовыми материалами и знакомит команду с текущим тест-планом. После этого вся команда может выделить время, чтобы вместе протестировать сборку.
Так бывает, что на каком-то этапе команде не хватает нужных компетенций. И будет здорово, если сами участники начнут проявлять инициативу — учиться, делиться опытом и помогать друг другу двигаться вперёд. Навыки, к сожалению, сами по себе не появляются.
Чтобы помочь участникам команды развить недостающие навыки и грамотно спланировать рост специалистов, можно использовать специальный инструмент — Звёздную карту компетенций.
В Agile мы верим, что кросс-функциональная самоорганизующаяся команда вполне может самостоятельно собраться, чтобы обсудить какую-то ситуацию и найти оптимальное работающее решение.
🔥3
В организациях с развитой продуктовой культурой принято мыслить не столько требованиями, сколько гипотезами.
Мы исходим из того, что любые, даже неоспоримые на первый взгляд требования могут измениться. Вместо того чтобы документировать их заранее, мы рассматриваем изменения как нормальную часть процесса.
Требования диктуют, что нужно сделать «вот это», и сделать именно так, как написано. А гипотеза — это предположение, которое нужно проверить. И уже по результатам проверки принимать решение, что делать дальше.
Такой подход требует от команды определённой зрелости, а от организации — готовности к экспериментам.
Во многом положительный результат зависит не только от усилий самой команды, но и от того, насколько ценности и процессы в компании соответствуют идее тестирования гипотез.
❤️ Например, требование «Отображение рекомендуемых мест на карте» может выглядеть так:
А вот так может выглядеть гипотеза:
Требование помогает команде сфокусироваться на том, что нужно СДЕЛАТЬ. А гипотеза — на том, что должно ИЗМЕНИТЬСЯ после выполнения действия. Гипотеза добавляет команде контекста о поведении пользователей, чтобы принимать более обоснованные решения в ходе экспериментов.
Подробнее мы разбираем это на нашем тренинге по управлению продуктами.
Мы исходим из того, что любые, даже неоспоримые на первый взгляд требования могут измениться. Вместо того чтобы документировать их заранее, мы рассматриваем изменения как нормальную часть процесса.
Требования диктуют, что нужно сделать «вот это», и сделать именно так, как написано. А гипотеза — это предположение, которое нужно проверить. И уже по результатам проверки принимать решение, что делать дальше.
Такой подход требует от команды определённой зрелости, а от организации — готовности к экспериментам.
Во многом положительный результат зависит не только от усилий самой команды, но и от того, насколько ценности и процессы в компании соответствуют идее тестирования гипотез.
Система должна отображать на карте объекты интереса (POI) с рейтингом не менее 4.5 звезд в радиусе до 3 км от текущего местоположения пользователя.
Система должна классифицировать отображаемые места по следующим категориям:
- Рестораны и кафе
- Достопримечательности
Обновление данных на карте должно происходить в следующих случаях:
- Автоматически при изменении местоположения пользователя более чем на 500 метров
- По запросу пользователя при нажатии кнопки обновления
- При изменении фильтров категорий
При нажатии на маркер системой должна отображаться карточка с информацией:
- Название места
- Рейтинг (включая визуальное отображение звезд)
- Количество отзывов
- Расстояние до пользователя в метрах/километрах
Система должна предоставлять возможность фильтрации мест по:
- Категориям
- Минимальному рейтингу (от 4.0 до 5.0 с шагом 0.1)
- Дистанции (500м, 1км, 2км, 3км)
А вот так может выглядеть гипотеза:
Предполагаем, что отображение высокорейтинговых локаций на картах увеличит вовлеченность пользователей на 12% и частоту возврата в приложение на 8%.
Ключевая проблема: пользователи тратят избыточное время на самостоятельный поиск релевантных мест, что приводит к фрикциям в пользовательском пути.
Валидация: Проведем двухнедельный A/B тест на 15% пользовательской базы, с фокусом на показателях:
1) метрика возврата в течение недели,
2) количество посещений рекомендованных мест,
3) CSAT после использования функции.
Требование помогает команде сфокусироваться на том, что нужно СДЕЛАТЬ. А гипотеза — на том, что должно ИЗМЕНИТЬСЯ после выполнения действия. Гипотеза добавляет команде контекста о поведении пользователей, чтобы принимать более обоснованные решения в ходе экспериментов.
Подробнее мы разбираем это на нашем тренинге по управлению продуктами.
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥4
Принцип YAGNI (You Ain’t Gonna Need It)⭐️
⭐️ Вам это не понадобится.
Он означает, что «даже если мы понимаем, какой код нам нужен — писать его заранее не стоит»
Один из Agile-принципов гласит:
В продвинутых командах, когда от заказчика приходит новый запрос — никто не спешит сразу же его реализовывать. Сначала вся команда собирается вместе и обсуждает, как максимально быстро и просто протестировать основную суть фичи и понять, стоит ли она реализации.
Каждый на равных делится своими идеями и обсуждает возможные пути решения. Важно, чтобы всегда был такой человек, который спросит:
Потому что мы все хотим придумать что-то технологичное, а значит — разрабатывать дольше и дороже. Может оказаться, что это не принесёт пользователю ценности, а нам — денег.
Поэтому стоит периодически задавать вопрос — а можно ли ещё проще?
Он означает, что «даже если мы понимаем, какой код нам нужен — писать его заранее не стоит»
Один из Agile-принципов гласит:
Простота — искусство минимизации лишней работы — крайне необходима.
В продвинутых командах, когда от заказчика приходит новый запрос — никто не спешит сразу же его реализовывать. Сначала вся команда собирается вместе и обсуждает, как максимально быстро и просто протестировать основную суть фичи и понять, стоит ли она реализации.
Каждый на равных делится своими идеями и обсуждает возможные пути решения. Важно, чтобы всегда был такой человек, который спросит:
— А можно ли сделать проще? Или сделать позже?
Потому что мы все хотим придумать что-то технологичное, а значит — разрабатывать дольше и дороже. Может оказаться, что это не принесёт пользователю ценности, а нам — денег.
Поэтому стоит периодически задавать вопрос — а можно ли ещё проще?
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥7👍1
Не удалось вовремя выловить баги? ❤️ 🐞
Причина чаще всего не в людях, а в том, как устроены процессы и продукт.
Например, в спринте остаётся слишком мало времени на тестирование. Или в системе накапливается легаси-код, который затрудняет понимание системы и мешает определить, где скрывается ошибка.
Чем сложнее архитектура, тем больше потенциальных точек отказа (point of failure) — а значит, тесты не покрывают большую часть рисков.
Поэтому, чем проще устроен продукт, тем проще его протестировать и отладить
А когда работа разбита на небольшие части, любые изменения в требованиях обходятся дешевле — ведь переделать небольшой фрагмент гораздо проще, чем переписывать целый модуль.
Эти проблемы есть почти у всех. Но хорошая новость в том, что с ними можно бороться.
Причина чаще всего не в людях, а в том, как устроены процессы и продукт.
Например, в спринте остаётся слишком мало времени на тестирование. Или в системе накапливается легаси-код, который затрудняет понимание системы и мешает определить, где скрывается ошибка.
Чем сложнее архитектура, тем больше потенциальных точек отказа (point of failure) — а значит, тесты не покрывают большую часть рисков.
Поэтому, чем проще устроен продукт, тем проще его протестировать и отладить
А когда работа разбита на небольшие части, любые изменения в требованиях обходятся дешевле — ведь переделать небольшой фрагмент гораздо проще, чем переписывать целый модуль.
Эти проблемы есть почти у всех. Но хорошая новость в том, что с ними можно бороться.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍2❤1
Иногда кажется, что какая-то фича слишком большая, чтобы поместиться в спринт, а как её разбить — непонятно. На недавнем тренинге по Scrum один из участников сказал:
Для этой ситуации существует выражение, придуманное одним из авторов Agile-манифеста, — Elephant Carpaccio, или карпаччо из слона 🐘
Оно означает, что любую фичу можно нарезать на тонкие, функционально завершённые элементы. При этом каждый из них будет нести в себе какую-то ценность.
Да, это не будет сразу показано пользователю, но пройдёт всего неделя, а заказчик уже сможет сам взять мышку и клавиатуру и ввести нужные данные.
На первом же ревью может оказаться, что представления заказчика о том, как должна работать фича, отличаются от изначально озвученных. Вот ради таких несостыковок и нужна ранняя обратная связь.
❤️ А у вас есть пример фичи, которую невозможно нарезать? Предложите в комментариях — и мы покажем, как это можно сделать.
— У нас есть фича, которую невозможно разбить на мелкие подзадачи.
Для этой ситуации существует выражение, придуманное одним из авторов Agile-манифеста, — Elephant Carpaccio, или карпаччо из слона 🐘
Оно означает, что любую фичу можно нарезать на тонкие, функционально завершённые элементы. При этом каждый из них будет нести в себе какую-то ценность.
Например, если бизнес-процесс состоит из пяти шагов, можно сначала реализовать первый шаг — например, форму для ввода данных. И это уже будет работающая часть — её можно собрать, показать и протестировать.
Да, это не будет сразу показано пользователю, но пройдёт всего неделя, а заказчик уже сможет сам взять мышку и клавиатуру и ввести нужные данные.
На первом же ревью может оказаться, что представления заказчика о том, как должна работать фича, отличаются от изначально озвученных. Вот ради таких несостыковок и нужна ранняя обратная связь.
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥4👍2😁1
Может показаться, что Scrum не до конца продуман, раз в нём нет привычных ролей. Из-за этого многие команды сами пытаются договориться, кто за что отвечает, но делают это по-старому — и ничего не меняется.
❤️ С одной из команд клиента мы обсуждали вопрос:
Это сделано специально. В Scrum всего три роли — владелец продукта, Scrum-мастер и разработчик продукта.
Если закрепить за аналитиком или любым другим участником команды отдельную зону ответственности, то сначала напишутся требования, затем — код, и только потом его проверят. Каждый будет ждать, пока закончит предыдущий.
Scrum принципиально устроен иначе
❤️ Чтобы к концу спринта появился небольшой инкремент продукта, который можно показать заказчику, участники команды свободно подключаются к задачам — не дожидаясь, пока кто-то закончит свою часть. Так фича быстрее становится частью продукта.
— За что отвечает аналитик в Scrum и почему его нет в списке ролей?
Это сделано специально. В Scrum всего три роли — владелец продукта, Scrum-мастер и разработчик продукта.
Если закрепить за аналитиком или любым другим участником команды отдельную зону ответственности, то сначала напишутся требования, затем — код, и только потом его проверят. Каждый будет ждать, пока закончит предыдущий.
Scrum принципиально устроен иначе
Please open Telegram to view this post
VIEW IN TELEGRAM
❤3🔥2
Бывает ли у вас на работе ощущение, что вы что-то делаете и при этом ловите себя на мысли:
И кажется, что раз все так работают, значит, по-другому нельзя. Но даже если все вокруг просто следуют привычному процессу, не страшно быть тем, кто скажет:
Вот, кстати, кейс, который показывает, как можно инициировать изменения в компании снизу — рекомендуем прочитать.
— Ну это же нелогично, зачем вообще так делать?
И кажется, что раз все так работают, значит, по-другому нельзя. Но даже если все вокруг просто следуют привычному процессу, не страшно быть тем, кто скажет:
— А нам это точно нужно? Давайте попробуем немного по-другому.
Вот, кстати, кейс, который показывает, как можно инициировать изменения в компании снизу — рекомендуем прочитать.
👍5🔥2
This media is not supported in your browser
VIEW IN TELEGRAM
Первый спринт после майских — всё ☀️
Как вы там, держитесь?
Как вы там, держитесь?
Please open Telegram to view this post
VIEW IN TELEGRAM
😁4
Уточнение бэклога — это обязательное событие. Но в отличие от планирования или ретро, это не всегда отдельная встреча, а скорее непрерывная работа по уточнению и оценке задач, которые войдут в следующий спринт.
Не обязывает проводить актуализацию каким-то особым способом:
«Уточнение Product Backlog — это постоянная деятельность по добавлению деталей, таких как описание, порядок и размер».
Руководство по Scrum
Иногда достаточно задержаться на 5-10 минут после дэйли, чтобы Владелец продукта рассказал команде про новую проработанную фичу, а команда быстро уточнила, всё ли им понятно.
Главное, чтобы к началу планирования большинство задач уже были оценены и готовы к взятию в работу.
Но многие команды впервые видят непроработанные задачи на планировании и тратят много времени просто на то, чтобы в них разобраться. Сложно понять, за что браться в первую очередь.
В нашей статье о backlog refinement мы рассказываем о том, как навести порядок в бэклоге и сделать так, чтобы он продолжал помогать команде.
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥3👍2
HTML Embed Code: