Напомним, что Scaled Agile Framework содержит несколько уровней иерархии от управления командной до управления портфелем предприятия. И одним из уровней является управление цепочками добавленной стоимости. Спрос на этот уровень имеется со стороны крупных организаций, создающих масштабные или критически важные системы. Однако некоторые его элементы будут вполне полезны и не очень крупным предприятиям.
Для того чтобы оставаться конкурентоспособным, современному предприятию проходится проводить серьезные преобразования, одно из ключевых направлений которых — цифровизация, или цифровая трансформация. Это емкое понятие подразумевает не просто автоматизацию или внедрение инноваций на основе ИТ, а нечто большее: серьезное изменение как бизнес-процессов, так и бизнес-моделей — основ деятельности предприятия, зарабатывания им денег и создания ценности для клиентов. Зачастую кардинально меняются предлагаемые заказчикам продукты и услуги. В основе всего этого лежат информационные технологии.
Яркий пример тому — автомобильная отрасль. По признанию экспертов компании Ford, больше половины внедренных за последние пять-семь лет инноваций связаны с использованием передовых информационных технологий не только в конструкторских бюро и производственных цехах, но и в самих автомобилях. Так, бортовые компьютеры уже стали стандартом де-факто и появляются даже в новых моделях отечественных брендов. Все чаще встречаются машины, укомплектованные системами автоматической парковки, а то и полностью управляемые компьютерными системами. Если дело так пойдет и дальше, лет через 20-30 профессия водителя станет столь же редкой, как, например, профессия кучера, возможно, владение машиной станет таим же хобби и роскошью как владение живым скакуном.
Для многих предприятий, вставших на путь цифровой трансформации, разработка программного обеспечения постепенно перестает быть непрофильным видом деятельности, своего рода падчерицей, а становится одним из ключевых направлений развития. К примеру, в 2010 -2011гг. представители ИТ банков часто утверждали, что они не разработчики ПО и управление разработкой и качеством не их задача, а задача подрядчиков. Это теперь все же, прямой бизнес банков, ритейла, связистов и представителей других отраслей, чтобы он не превращался в тяжкое бремя, необходимо вести разработку ПО быстро (не отставая от конкурентов), качественно (не переделывая много раз и не разгребая горы рекламаций от разочарованных клиентов) и рачительно (эффективно с финансово-экономической точки зрения). Как раз это и есть цель Scaled Agile Framework (SAFe) — открытой, доступной в онлайне базы знаний, содержащих проверенные рекомендации и шаблоны для внедрения бережливых (Lean) и гибких (Agile) методик по созданию крупных программных систем, в том числе масштаба предприятия. Среди известных пользователей SAFe — Intel, Lego, BMC Software, Nordea, Accenture Technology, и HPE Software. В этой базе знаний, с одной стороны, реализуются применительно к разработке ПО и инженерных систем принципы бережливого производства — того самого, что принесло славу автоконцерну Toyota, с другой — развиваются и масштабируются до уровня крупного предприятия Agile-методики, такие как Scrum, XP и Kanban и все это сопровождается трансформацией культуры взаимодействия подразделений компании в рамках подхода DevOps. Координацией развития, а также вопросами сертификации по SAFe занимается компания Scaled Agile, Inc.
SAFe можно применять как на малых и средних предприятиях, так и в очень крупных компаниях, где разработкой программного решения могут заниматься и 500, и 1000 человек, создавая весьма сложные и значительные по масштабу системы. В относительно небольших предприятиях польза от SAFe может достигаться за счет управления всем набором технических решений в соответствии с бизнес-стратегией. Разумеется, необходимо понимать, что масштабирование имеет свою цену, и если у вас, скажем, менее 5 команд разработки, то более простые подходы к масштабированию Enterprise Agile могут быть более успешны. Это, кстати, озвучено в первом принципе фреймворка SAFe – смотрите на свою продукцию с экономической точки зрения.
Что же касается крупных компаний, то, если речь идет о создании по-настоящему сложных продуктов с использованием бережливых и Agile-подходов, альтернативы SAFe у них фактически нет, поскольку другие фреймворки масштабирования или не рассчитаны на организацию работы столь многочисленных коллективов разработчиков или недостаточно документированы. Эти продукты могут содержать и программную, и аппаратную части, в том числе электрику и электронику, оптические, механические, гидравлические и другие компоненты. Для их создания требуются разносторонние знания и усилия сотен, а иногда и тысяч специалистов — не только штатных, но и сотрудников компаний-подрядчиков. Сбои в этих системах или подсистемах, на которые нередко возложены критически важные задачи, могут привести к недопустимым экономическим и социальным последствиям.
В рамках SAFe различают четыре уровня управления разработкой: уровень портфелей, цепочек добавленной стоимости, программ и команд (см. рис. 1).
Рис. 1. Уровни SAFe.
Источник: Scaled Agile, Inc.
Спрос на этот уровень имеется со стороны крупных организаций, создающих масштабные и зачастую критически важные системы. На этом уровне определяются функции, свойства и особенности поведения нового продукта, а также контекст, в котором его предстоит развертывать, использовать, поддерживать, продвигать, комплектовать и продавать. Кроме того, формулируются правила принятия решений по экономическим аспектам разработки.
Уровень цепочек добавленной стоимости появился в четвертой версии SAFe, где он не является обязательным. Организации, создающие системы, для разработки которых достаточно нескольких сотен специалистов, могут использовать «усеченный», трехуровневый вариант SAFe, описанный в SAFe версии 3.0.
Аналогично уровню программ, данный уровень строится вокруг инкрементов (приращений) программ. Инкременты — это, по сути, циклы Деминга (планирование — исполнение — контроль — воздействие, Plan-Do-Check-Action, PDCA), для которых обеспечивается сквозная синхронизация ART-коллективов в цепочках добавленной стоимости, что позволяет организовать эффективное и планомерное взаимодействие множества команд и подрядчиков.
Рис. 2. Уровень цепочек добавленной стоимости.
Источник: Scaled Agile, Inc.
Ключевые роли на этом уровне — менеджеры решений (Solution Management), архитекторы и инженеры решений (Solution Architect/Engineering), а также инженер цепочки добавленной стоимости (Value Stream Engineer, VSE).
Краеугольный камень решения — его замысел. Именно замысел определяет поведение создаваемого изделия и связанных с ним решений, а также является единым «источником правды» и хранилищем всех требований, в том числе истории их уточнений.
Главный структурный компонент уровня цепочек добавленной стоимости — это решение, ведь над его созданием трудится вся цепочка. Решения должны функционировать не просто в соответствии с замыслами, а в своих контекстах — в том окружении, в котором им предстоит «жить» после развертывания. Эти продукты должны отвечать всем требованиям заказчиков, а кроме того, обладать заданными свойствами, быть способными поддержать те бизнес-инициативы, ради которых их создают, и таким образом реализовать свое предназначение.
Управление более масштабными инициативами осуществляется на основе набора менее крупных, но важных инициатив, реализация которых обеспечивает достижение глобальной цели. В процессе анализа этот набор преобразуется в набор свойств решений. Управление ими осуществляется посредством системы Kanban (по сути, «точно в срок»), встроенной в цепочки добавленной стоимости. Kanban помогает удостовериться, что до помещения свойств в бэклог, где их поставят в очередь на реализацию, они уже прошли стадию оценки и анализа, и помогает обеспечить эффективную и продуктивную работу участвующих в анализе этих свойств.
Еще одна функция уровня цепочек добавленной стоимости — координация ART-коллективов, совместно работающих над созданием единого решения. Этот процесс основывается на выстраивании определенной ритмичности инкрементов программ путем синхронизации итераций Agile-разработки. Таким образом обеспечивается взаимодействие не только ART-коллективов, но и подрядчиков. В начале каждого инкремента производится общее планирование на ближайший период, его осуществляют сами коллективы в ходе «планерок PI». Чтобы разработать план, единый для всех цепочек создания добавленной стоимости и учитывающий взаимозависимости между цепочками, перед началом инкрементов и по их окончании и проводятся эти встречи. Они важны для синхронизации, но затратны по вовлечению участников, собирают каждого входящего в коллектив ART, поэтому рекомендуется встречу проводить раз в 10 недель – через 5 спринтов, если их длина 2 недели. По завершении каждого инкремента решение демонстрируется заказчикам и другим заинтересованным лицам. Затем в рамках рабочей встречи анализируется эффективность всей цепочки добавленной стоимости и определяются пути улучшения существующего процесса, что вполне в духе концепции бережливого производства.
Заметим, что наличие некоторых элементов уровня цепочек добавленной стоимости обусловлено особенностями создания крупных, сложных решений и, как следствие, необходимостью организации работы больших коллективов разработчиков. Однако некоторые элементы будут вполне полезны при использовании трехуровневого варианта SAFe. В частности, это касается замысла решения, управления экономическими аспектами разработки, а также взаимодействия с подрядчиками.
Для того чтобы оставаться конкурентоспособным, современному предприятию проходится проводить серьезные преобразования, одно из ключевых направлений которых — цифровизация, или цифровая трансформация. Это емкое понятие подразумевает не просто автоматизацию или внедрение инноваций на основе ИТ, а нечто большее: серьезное изменение как бизнес-процессов, так и бизнес-моделей — основ деятельности предприятия, зарабатывания им денег и создания ценности для клиентов. Зачастую кардинально меняются предлагаемые заказчикам продукты и услуги. В основе всего этого лежат информационные технологии.
Яркий пример тому — автомобильная отрасль. По признанию экспертов компании Ford, больше половины внедренных за последние пять-семь лет инноваций связаны с использованием передовых информационных технологий не только в конструкторских бюро и производственных цехах, но и в самих автомобилях. Так, бортовые компьютеры уже стали стандартом де-факто и появляются даже в новых моделях отечественных брендов. Все чаще встречаются машины, укомплектованные системами автоматической парковки, а то и полностью управляемые компьютерными системами. Если дело так пойдет и дальше, лет через 20-30 профессия водителя станет столь же редкой, как, например, профессия кучера, возможно, владение машиной станет таим же хобби и роскошью как владение живым скакуном.
Для многих предприятий, вставших на путь цифровой трансформации, разработка программного обеспечения постепенно перестает быть непрофильным видом деятельности, своего рода падчерицей, а становится одним из ключевых направлений развития. К примеру, в 2010 -2011гг. представители ИТ банков часто утверждали, что они не разработчики ПО и управление разработкой и качеством не их задача, а задача подрядчиков. Это теперь все же, прямой бизнес банков, ритейла, связистов и представителей других отраслей, чтобы он не превращался в тяжкое бремя, необходимо вести разработку ПО быстро (не отставая от конкурентов), качественно (не переделывая много раз и не разгребая горы рекламаций от разочарованных клиентов) и рачительно (эффективно с финансово-экономической точки зрения). Как раз это и есть цель Scaled Agile Framework (SAFe) — открытой, доступной в онлайне базы знаний, содержащих проверенные рекомендации и шаблоны для внедрения бережливых (Lean) и гибких (Agile) методик по созданию крупных программных систем, в том числе масштаба предприятия. Среди известных пользователей SAFe — Intel, Lego, BMC Software, Nordea, Accenture Technology, и HPE Software. В этой базе знаний, с одной стороны, реализуются применительно к разработке ПО и инженерных систем принципы бережливого производства — того самого, что принесло славу автоконцерну Toyota, с другой — развиваются и масштабируются до уровня крупного предприятия Agile-методики, такие как Scrum, XP и Kanban и все это сопровождается трансформацией культуры взаимодействия подразделений компании в рамках подхода DevOps. Координацией развития, а также вопросами сертификации по SAFe занимается компания Scaled Agile, Inc.
SAFe можно применять как на малых и средних предприятиях, так и в очень крупных компаниях, где разработкой программного решения могут заниматься и 500, и 1000 человек, создавая весьма сложные и значительные по масштабу системы. В относительно небольших предприятиях польза от SAFe может достигаться за счет управления всем набором технических решений в соответствии с бизнес-стратегией. Разумеется, необходимо понимать, что масштабирование имеет свою цену, и если у вас, скажем, менее 5 команд разработки, то более простые подходы к масштабированию Enterprise Agile могут быть более успешны. Это, кстати, озвучено в первом принципе фреймворка SAFe – смотрите на свою продукцию с экономической точки зрения.
Что же касается крупных компаний, то, если речь идет о создании по-настоящему сложных продуктов с использованием бережливых и Agile-подходов, альтернативы SAFe у них фактически нет, поскольку другие фреймворки масштабирования или не рассчитаны на организацию работы столь многочисленных коллективов разработчиков или недостаточно документированы. Эти продукты могут содержать и программную, и аппаратную части, в том числе электрику и электронику, оптические, механические, гидравлические и другие компоненты. Для их создания требуются разносторонние знания и усилия сотен, а иногда и тысяч специалистов — не только штатных, но и сотрудников компаний-подрядчиков. Сбои в этих системах или подсистемах, на которые нередко возложены критически важные задачи, могут привести к недопустимым экономическим и социальным последствиям.
Уровни SAFe
В рамках SAFe различают четыре уровня управления разработкой: уровень портфелей, цепочек добавленной стоимости, программ и команд (см. рис. 1).
Рис. 1. Уровни SAFe.
Источник: Scaled Agile, Inc.
- Уровень команд — самый нижний. Эти, как правило, небольшие (не более 9 специалистов, в идеале) Agile-команды трудятся на основе подхода ScrumXP, и\или в том числе с использованием.
- На уровне программ, втором по иерархии, формируются виртуальные коллективы, название которых — Agile Release Trains — можно перевести как «поезда, доставляющие Agile-релизы» (далее будем для краткости называть их ART-коллективами). Смысл этой метафоры в том, что, подобно поездам, следующим от станции к станции с различными грузами, эти коллективы должны действовать ритмично, четко соблюдать расписание и двигаться с заранее заданной скоростью согласно намеченному плану, доставляя заказчикам прототипы, модели, программные продукты, оборудование, документацию и пр. Специалисты, входящие в состав этих виртуальных коллективов, вместе планируют свою совместную деятельность, фиксируют принятые обязательства и затем их исполняют. Акцент в планировании сделан не на сроках выпуска продукта или релизах, а на ритмичности и синхронизации взаимодействия всех заинтересованных сторон. Если команды успешно трансформированы в Feature teams, то с минимальными синхронизациями такие команды будут успешно работать в рамках своего спринта. При этом в продуктивную среду релиз может уйти в любой момент, как достигнут, к примеру, важный объем функционала.
- Третий уровень — уровень цепочек добавленной стоимости (Value Stream Level). При создании сложных решений, когда требуется применять как научные знания, так и практические навыки, необходимы усилия множества ART-коллективов и компаний-подрядчиков. Цепочка добавленной стоимости — это, по сути, некий процесс, обеспечивающий создание определенного продукта или изделия в интересах одного из бизнес-направлений. Примерами такой цепочки могут служить кредитный конвейер банка или бизнес-процесс интернет-банкинга. Каждым направлением будет заниматься отдельный ART-коллектив, в составе которого — множество команд разработки. Кстати, именно на этом уровне определяется стратегия развития создаваемых продуктов.
- Наконец, четвертый уровень SAFe — уровень портфелей. Портфель содержит набор цепочек добавленной стоимости, а также ряд элементов для общего управления всем, что касается создания и совершенствования продуктов, услуг и решений в соответствии с бизнес-стратегией предприятия, а также их финансирования.
Уровень цепочек добавленной стоимости
Спрос на этот уровень имеется со стороны крупных организаций, создающих масштабные и зачастую критически важные системы. На этом уровне определяются функции, свойства и особенности поведения нового продукта, а также контекст, в котором его предстоит развертывать, использовать, поддерживать, продвигать, комплектовать и продавать. Кроме того, формулируются правила принятия решений по экономическим аспектам разработки.
Уровень цепочек добавленной стоимости появился в четвертой версии SAFe, где он не является обязательным. Организации, создающие системы, для разработки которых достаточно нескольких сотен специалистов, могут использовать «усеченный», трехуровневый вариант SAFe, описанный в SAFe версии 3.0.
Аналогично уровню программ, данный уровень строится вокруг инкрементов (приращений) программ. Инкременты — это, по сути, циклы Деминга (планирование — исполнение — контроль — воздействие, Plan-Do-Check-Action, PDCA), для которых обеспечивается сквозная синхронизация ART-коллективов в цепочках добавленной стоимости, что позволяет организовать эффективное и планомерное взаимодействие множества команд и подрядчиков.
Рис. 2. Уровень цепочек добавленной стоимости.
Источник: Scaled Agile, Inc.
Ключевые роли на этом уровне — менеджеры решений (Solution Management), архитекторы и инженеры решений (Solution Architect/Engineering), а также инженер цепочки добавленной стоимости (Value Stream Engineer, VSE).
- Менеджеры решений представляют интересы заказчиков, контролируют выполнение их требований и реализацию стратегических направлений развития портфеля — бизнес-целей, связывающих портфель SAFe и бизнес-стратегию. Вместе с входящими в ART-коллективы менеджерами продуктов они осуществляют детализацию свойств решений и определяют их функции и возможности. Помимо этого на них возлагается ответственность за ведение бэклога всего решения и каждой команды соответственно, в которых будет отражен план создания решения, и установление приоритетов. Им же поручается выработка правил принятия решений по экономическим аспектам создания систем, которые необходимы для управления процессом принятия решений в ART-коллективах и Agile-командах.
- Архитекторы и инженеры решений — команда, определяющая архитектуру решения в целом и, таким образом, объединяющая ART-коллективы. Они работают в тесной связке с системными архитекторами ART-коллективов и инженерами, помогая им определить архитектурный скелет создаваемых продуктов в соответствие с предполагаемой дорожной картой развития продукта.
- Инженер цепочки добавленной стоимости отвечает за то, чтобы цепочка работала четко, без сбоев и задержек, для чего он должен своевременно выявлять узкие места и устранять их. Кроме того, он помогает организовать совещания участников цепочки, отслеживает точность соблюдения сроков выполнения работ (Kanban) и другие показатели метрик, характеризующих цепочку.
Краеугольный камень решения — его замысел. Именно замысел определяет поведение создаваемого изделия и связанных с ним решений, а также является единым «источником правды» и хранилищем всех требований, в том числе истории их уточнений.
Главный структурный компонент уровня цепочек добавленной стоимости — это решение, ведь над его созданием трудится вся цепочка. Решения должны функционировать не просто в соответствии с замыслами, а в своих контекстах — в том окружении, в котором им предстоит «жить» после развертывания. Эти продукты должны отвечать всем требованиям заказчиков, а кроме того, обладать заданными свойствами, быть способными поддержать те бизнес-инициативы, ради которых их создают, и таким образом реализовать свое предназначение.
Управление более масштабными инициативами осуществляется на основе набора менее крупных, но важных инициатив, реализация которых обеспечивает достижение глобальной цели. В процессе анализа этот набор преобразуется в набор свойств решений. Управление ими осуществляется посредством системы Kanban (по сути, «точно в срок»), встроенной в цепочки добавленной стоимости. Kanban помогает удостовериться, что до помещения свойств в бэклог, где их поставят в очередь на реализацию, они уже прошли стадию оценки и анализа, и помогает обеспечить эффективную и продуктивную работу участвующих в анализе этих свойств.
Еще одна функция уровня цепочек добавленной стоимости — координация ART-коллективов, совместно работающих над созданием единого решения. Этот процесс основывается на выстраивании определенной ритмичности инкрементов программ путем синхронизации итераций Agile-разработки. Таким образом обеспечивается взаимодействие не только ART-коллективов, но и подрядчиков. В начале каждого инкремента производится общее планирование на ближайший период, его осуществляют сами коллективы в ходе «планерок PI». Чтобы разработать план, единый для всех цепочек создания добавленной стоимости и учитывающий взаимозависимости между цепочками, перед началом инкрементов и по их окончании и проводятся эти встречи. Они важны для синхронизации, но затратны по вовлечению участников, собирают каждого входящего в коллектив ART, поэтому рекомендуется встречу проводить раз в 10 недель – через 5 спринтов, если их длина 2 недели. По завершении каждого инкремента решение демонстрируется заказчикам и другим заинтересованным лицам. Затем в рамках рабочей встречи анализируется эффективность всей цепочки добавленной стоимости и определяются пути улучшения существующего процесса, что вполне в духе концепции бережливого производства.
Заметим, что наличие некоторых элементов уровня цепочек добавленной стоимости обусловлено особенностями создания крупных, сложных решений и, как следствие, необходимостью организации работы больших коллективов разработчиков. Однако некоторые элементы будут вполне полезны при использовании трехуровневого варианта SAFe. В частности, это касается замысла решения, управления экономическими аспектами разработки, а также взаимодействия с подрядчиками.
Комментарии (14)
Vkuvaev
12.04.2016 01:26Бесспорно, равно как и то, что Agile есть прилагательное, и если его употреблять как прилагательное, можно многих ловушек избежать.
Если Agile — это в первую очередь идея, то SAFe — инструмент. Не надо его возводить в ранг чего-то высокого. Т.е. сертификация SAFe лишь на уровне понимания фреймворка. В этом плане он честнее чем CSM.
Если интересно, посмотрите на их сайте, все что там написано немыслимо постичь, без принятия образа мышления описанного в манифесте, ну и без понимания Lean.
Я читал дважды за последнее время его статью, видео не смотрел раньше, посмотрел сейчас, спасибо, не все сказанное на видео было в блоге.
Есть один момент, которым я был недоволен раньше и укрепился в своем мнении сейчас. Dave критикует индустрию «Agile», но совершенно не признает, что именно благодаря ей, настоящих последователей гибких методик стало очень много, т.е. Людей которые поняли в чем идея. Да, побочно, что есть люди которые считают Agile отличной методикой. Но так бывает с любым знанием, что оно искажается.
Поэтому, когда кто-то ругает инструмент, или людей которые его придумали, и огорчается, что он не это имел в виду, мне становится неприятно. Черт возьми, если считаешь, что все исказили и неправильно делают, помоги, объясни как надо. А если не знаешь как, то не мешай тем кто пусть и топорными методами, с точки зрения критикующего, но все же помогает, т.е. реально результаты проектов разработки улучшаются.
Все кто в теме знают, что на большую организацию эти подходы не ложатся просто так. Есть спрос на это знание и опыт. Его кто-то и как-то заполняет. Очевидно, что под копирку это знание не работает. То вот KPI какой-то мешается, то планирование сложное.
Можно всегда что-то улучшить.
Может быть с этого все же можно начать? Сделать на одном проекте, посмотреть как получилось, понять что не так, что-то изменить, повторить цикл. Так родится собственный набор правил конкретной организации. Я не прав?
Или дело в зависти?Vkuvaev
12.04.2016 01:59странная система комментирования, :( хотел доразвить мысль, и подкорректировать неясности, сказала, что поздно. Подозрительно напоминает системы helpdesk \ crm где ничего нельзя менять… Или после нескольких минут это все куда-то отсылается ;)?
chilicoder
12.04.2016 02:26посмотрите на их сайте, все что там написано немыслимо постичь,
И это не случайно. Чтобы постичь (а тем более внедрить) нужно нанять консультантов. И обязательно сертифицированных. А то будет agile не православный.
Я согласен, что последователей стало много, Scrum это модно. Но вот насчет
«людей которые поняли в чем идея» не уверен. Во всех организациях, в которых я наблюдал внедрение Scrum, менеджеры начинали с утреннего standup и planning сессий. При этом все остальное они оставляют как было. Ни вам создания cross-functional команд и делегирования им полномочий. Ни сосредоточения у product owner'у права расставлять приоритет. Ни retrospections. Вишенкой на торте обычно является совмещение роли product owner и scrum-master.
В общем, не согласен я с аргументом «зато agile идет в массы». Идет смещение акцента с ценностей в сторону инструментов. А смысл agile как раз в изменении ценностей. Прежде чем внедрять новые инструменты (не забыв демонтировать старые) менеджеры должны переосмыслить свое понимание процесса. Принять ценности. Это первично.
… объясни как надо.
Вот он и объясняет)
Сделать на одном проекте, посмотреть как получилось, понять что не так, что-то изменить, повторить цикл. Так родится собственный набор правил конкретной организации. Я не прав?
вы объяснили в точности то, что предлагает Dave. И заметьте, для того чтобы донести суть, вы не использовали SAF.
DeBovuar
12.04.2016 14:13Определенно с менеджерами Вам не очень везло.
К слову, не смотря на то, что на сайте действительно описано как-то сложно, на деле все очень логично и просто. Уровни есть в любой компании, просто для Agile — методологий о них пару слов вскользь. Частично поэтому SAFe кажется необычным и громоздким, ну и также, конечно, за счет масштабов.
Vkuvaev
12.04.2016 16:52+1Во всех организациях, в которых я наблюдал внедрение Scrum, менеджеры начинали с утреннего standup и planning сессий. При этом все остальное они оставляют как было. Ни вам создания cross-functional команд и делегирования им полномочий. Ни сосредоточения у product owner'у права расставлять приоритет. Ни retrospections. Вишенкой на торте обычно является совмещение роли product owner и scrum-master.
Согласен, Некоторые люди полагают, что гибкость заключается в том, чтобы внедрить Scrum частично. Жаль, что они не поняли идею.
Но есть ведь и другая сторона:
Организация включающая хотя бы 100 разработчиков с менеджерами, директором, руководителями PM'ами, и иже с ними, закосневшая в годовых релизах и управляемая прямой иерархией не сможет воспринять эти четыре ценности. Даже если владелец послушал Германа Оскаровича, и очень хочет чтобы его компания стала феноменально гибкой.
Иногда нужно пнуть, чтоб полетело. За это и платят деньги. Я как-то имел бесплодный диспут с разработчиком банка, я ему про идеи Scrum, как это работает в маленькой команде, про психологию самоорганизации, а он все гнет про то, что как это без руководства и утверждения планов, непорядок…
Ну не виноваты разработчики SAFe, что в манифесте нет ответа на то, как масштабировать эти принципы на большую организацию и как подтягивать уровень зрелости людей. Эволюционно получается медленно. Революционно — плохо. Что делать-то?
… Идет смещение акцента с ценностей в сторону инструментов.
Смещение от ценностей в сторону инструментов присутствует, но с SAFe это никак не связано, тут скорее жажда наживы, как и всегда было до этого, ну вот хоть с ITIL. Или наивная надежда, что начнем как нибудь, а там стерпится — слюбится.
вы объяснили в точности то, что предлагает Dave. И заметьте, для того чтобы донести суть, вы не использовали SAF.
Мне приятно, разумеется, что я как-то сумел переформулировать цикл Деминга.
Но как PDCA применить к большой организации, предположим вы приглашенный гуру подписавший манифест и вот перед вами сидят эти самые, полные скепсиса, 100 разработчиков, весь управленческий состав и PMO. И вы рисуете этот круг и говорите — вот цикл, и четыре ценности в манифесте. Это все что нужно. Стряхиваете мел с рук и говорите немому залу — какие будут вопросы. Думаю будет тишина, затем шум отодвигаемых стульев.
Люди не смогут этому следовать, в это нужно поверить и желательно попробовать как ребенок, под контролем, провести ретроспективу с опытным гуру, осознать ошибки в восприятии предмета, еще раз, и еще, и еще. И так полетит. CSM тренинг не напоминает? Ну а SAFe, чуть сложнее.
Может быть это я наивен и не видел трэш тренингов по Scrum где ценность и идея отодвинуты на задний план? Мне даже интересно есть ли такие примеры?chilicoder
12.04.2016 20:21Организация включающая хотя бы 100 разработчиков с менеджерами, директором, руководителями PM'ами, и иже с ними, закосневшая в годовых релизах и управляемая прямой иерархией не сможет воспринять эти четыре ценности.
Так им не нужна agile разработка. Их устраивает текущая организация и система управления.
И вы рисуете этот круг и говорите — вот цикл, и четыре ценности в манифесте. Это все что нужно. Стряхиваете мел с рук и говорите немому залу — какие будут вопросы. Думаю будет тишина, затем шум отодвигаемых стульев.
И неудивительно. Потому что у них у всех будет один вопрос «А где в этой системе мы?»
Вы почему то решили, что решение о переходе к agile разработке должно быть «продано» менеджерам среднего звена. Это было бы нужно только для того, чтобы потом делегировать им внедрение. Но на месте владельца будет большой ошибкой поручать внедрение agile разработки нижестоящим менеджерам. Потому что весь смысл этой реорганизации в том, чтобы делегировать полноту принятия решения непосредственно в команды. Перейти от иерархии к сетевой структуре. У кого мы забираем власть в данном случае? У всех менеджеров, включая владельца. Мотив владельца понятен, вырастет эффективность, упадут издержки, компания станет расти лучше, стоить больше. А вот у остальных менеджеров есть мотив всячески саботировать этот переход.
Поэтому это решение принимает владелец. Остальные менеджеры либо подстраиваются под новые правила, находя себе новые роли в организации (становятся product-owner'ами, scrum-master'ами, coach'ами, консультантами или, например senior-разработчиками) либо замещаются новыми лидерами.
pan_KOST
13.04.2016 13:02Остальные менеджеры либо подстраиваются под новые правила,
Задача топ-руководителя, на мой взгляд, в этом как раз и состоит — чтобы научить и настроить процесс принятия управленческих решений таким образом, чтобы существующая команда перешла на новые рельсы, т.е. они не сами должны всё-таки перейти, а руководитель должен их туда перевести.
В целом, считаю, что для действительно крупных и сложных компаний — любой фреймворк — это скорее, отправная точка для построения собственной эффективной модели управления.
Я считаю, что тот же Agile, в том, старом смысле, он действительно предназначен для малых команд, в то время как для больших имеет смысл строить свои модели управления на основе Lean, JIT, ТОC и т.д. — они просто оперируют большими уровнями абстракции в соответствии с увеличением количества уровней принятия решения в компании и, соответственно, уровня сложности организации.
Кстати, если посмотреть внимательно — тот же Agile взял многое из как раз таких «тяжелых» инструментов и приспособил полезное для небольших команд, но маркетологи от консалтинга, к сожалению, сейчас пытаются найти новые способы привлечь к себе внимание за счёт раскрученного бренда Agile
DmLapygin
14.04.2016 12:25Статья интересная, полезная, есть что пообсуждать :)
Было бы интересно увидеть в окончании некий вывод/заключение по итогам описанного.
Что же касается крупных компаний, то, если речь идет о создании по-настоящему сложных продуктов с использованием бережливых и Agile-подходов, альтернативы SAFe у них фактически нет, поскольку другие фреймворки
по этой цитате 2 вопроса:
— когда именно нужно использовать бережливые и Agile-подходы — отдельная тема, но неплохо бы дать ссылку на материал, если такой имеется. Поскольку сложные продукты создают уже довольно давно, когда понятия Agile еще не было.
— какие другие фреймворки можно привести в пример? Я могу припомнить разве что работы Scott Ambler по Disciplined Agile Delivery (DAD) и Agile Scaling Model (ASM) — http://www.ambysoft.com/scottAmbler.html#sthash.2q9wuhmZ.dpuf
DmLapygin
14.04.2016 12:34При внимательном прочтении не нашел четкого раскрытия темы:
Цепочка добавленной стоимости — это, по сути, некий процесс, обеспечивающий создание определенного продукта или изделия в интересах одного из бизнес-направлений. Примерами такой цепочки могут служить кредитный конвейер банка или бизнес-процесс интернет-банкинга. Каждым направлением будет заниматься отдельный ART-коллектив, в составе которого — множество команд разработки.
отсюда я вижу, что цепочка — направление — отдельный ART-коллектив
а выше было
На уровне программ, втором по иерархии, формируются виртуальные коллективы, название которых — Agile Release Trains
т.е. я вижу уравнивание по коллективу уровня программы и уровня цепочки. получается что и там и там может работать отдельный ART-коллектив.
тогда чем они отличаются? хотелось бы более подробно разобраться в этом.chilicoder
14.04.2016 18:19посмотрите на картинку. цепочка добавленной стоимости — это, подозреваю, value stream.
а программа это уровень на котором работают несколько команд и составляют Agile release train.
Из картинки видно, что несколько ART составляют VS.DmLapygin
15.04.2016 01:06Картинки бывают разные и каждый по своему понимает, что там нарисовано. Например, тут http://dougdockery.com/wp-content/uploads/2014/10/SAFe-3.0-8.5x11_print.jpg мы находим VS на уровне портфелей.
Я в статье не нашел для себя ясного понимания зачем введен новый уровень для VS. То что он не обязателен — еще более затуманивает для меня этот вопрос.
Ответ «не хотите — не используйте» меня не устроит :) Хотелось бы разобраться, что нового и полезного он может дать. Пока не увидел.chilicoder
15.04.2016 18:34Именно про эту картинку я и говорил.
Вы вначале про «зачем» не спрашивали)
chilicoder
15.04.2016 18:41Только чем ART от VS отличается). Кстати, на этой же картинке есть VS из одного ART, а есть из двух.
Зачем все эти уровни? На мой взгляд их придумывают для того, чтобы декларируя переход к self-managment командам на деле сохранить иерархическую модель в организации.
chilicoder
Как раз об этом рассказывал Dave Thomas в своем выразительном критическом выступлении
Смысл Agile разработки вовсе не в сертификации, KPI, общем планировании и единых планах. Смысл сводится к четырем простым слоганам выраженных в манифесте.