Привет тебе, дорогой читатель! В предыдущей статье я рассказывал о том, как 28 разработчиков смогли выстроить рабочий процесс, в котором нет роли менеджера. Мы продолжаем с удовольствием работать и выпускать сложные фичи одну за одной. Скоро нам предстоят бессонные ночи перед выпуском релиза. И затем самый приятный этап — технический спринт и проведение ретро релиза, а также мероприятия по планированию следующего релиза.
Сегодня я расскажу об активностях, которые обеспечивают максимальную прозрачность рабочего процесса и позволяют не выпадать разработчикам из событий, происходящих в целом компании и в других командах в частности. Хотите выстроить качественные процессы и работать с удовольствием? Добро пожаловать под кат!
Перед тем, как продолжить делиться опытом организации процесса разработки, я хочу уточнить пару вопросов относительно специфики компании. Бизнес-структура компании подразумевает разработку продукта in-house и последующую продажу решения клиентам. В компании есть маркетинговый отдел, отдел сбыта и другие подразделения помимо отдела разработки. Это во многом определяет возможность взаимодействия напрямую с продуктовым аналитиком, который и является поставщиком основных требований к продукту. В обычном смысле, у нас нет клиента-заказчика со стороны. Мы сами вырабатываем требования, сами разрабатываем и сами продаем. Традиционная продуктовая компания.
Тем не менее, я настаиваю на том, что опыт организации процессов между командами разработки и разработчиками внутри команд может быть использован как пример для выстраивания процессов в Вашей компании, будь она разработчиком аутсорсных решений или продуктовой компанией. Классический скрам «по книжкам», как показывает опыт, не применим в реалиях разработки реальных продуктов, и именно поэтому специфика продукта определяет специфику процессов.
Напомню, в нашей компании работает на данный момент 28 разработчиков. То, что применимо для 7 команд (по четыре разработчика в команде) может стать нецелесообразным при работе 15 команд и наоборот. В то же время, и разработка качественной архитектуры кодовой базы, и выстраивание качественных процессов подразумевает свободу масштабирования без больших затрат. Кроме этого, в большинстве компаний отдел разработки одного направления большого продукта состоит как раз из 5-7 команд (20-30 человек). Такой отдел, как правило, имеет свободу принятия независимых архитектурных решений, свободу организации внутренних взаимодействий и выстраивания процессов.
Итак, 5-7 команд, разработка собственного продукта. Как же выстроить процесс без участия менеджера? В первой части статьи я уже рассказал о таких активностях, как груминг, плнирование и ретро команд. Далее речь пойдет об активностях, позволяющих синхронизировать работу нескольких команд и двигаться в одном направлении.
Пример проекта в Renga Structure
Длина спринта у нас — десять рабочих дней. Между спринтами есть два дня для проведения демо, ретро и планирования. Если между спринтами есть два дня на ретро, демо и планирование — это не значит, что в эти два дня не пишется код. Это значит, что в эти дни активности идут с бОльшим приоритетом, чем написание кода. Эти два дня являются хорошим буфером для амортизации недооценок/переоценок по спринту. Синхронизация команд — активность, не привязанная к графику спринтов. Такая синхронизация проводится каждую пятницу в одно и то же время после обеда. На синхронизации присутствуют все разработчики, тестировщики и продуктовые аналитики. В общем смысле, синхронизация команд — это стендап, где от каждой команды выступает один разработчик и рассказывает, что командой было сделано, какие участки кода были затронуты и как это может повлиять на другие команды.
Часто в компаниях синхронизация проводится в виде собрания тимлидов команд. У этого подхода есть минус, который я подробно обсуждал в предыдущей статье: один человек может забыть, не обратить внимание на множество деталей, которые важны для других. Таким образом, синхронизация тимлидов экономит время команд, но существенно уступает качеству коммуникаций. Подразумевается, что после такого собрания тимлид будет рассказывать каждый своей команде о прогрессе других команд, что опять же потратит время каждой команды. Здесь появляется минус «глухого телефона» при передаче знаний от тимлида команде. Таким образом, команда остается как бы «в стороне» от работы других команд, общаясь только посредством тимлида. Как результат, падает заинтересованность, увеличивается разрыв в понимании общего движения разработки всего отдела. Экономия времени команды никак не может покрывать минусы от отстраненности от общего направления разработки и общения между разработчиками.
После каждого выступления команды, как правило, задаются уточняющие вопросы от любого из присутствующих. Если кто-то понимает, что ответ на вопрос перерастает в отстраненную продолжительную дискуссию, то он/она может прервать диалог и предложить перенести его на другое время. Таким образом, синхронизация семи команд длится не более сорока минут и позволяет всем разработчикам оставаться в струе развития продукта другими командами.
Другой важный аспект, который обсуждается на синхронизации — актуализация сроков разработки. Как правило, раз в две недели команды публично оценивают свои шансы на «успеть вовремя к релизу». В процессе обсуждения становится понятно, какая команда не успевает, а какая выполняет задачи в срок. Кроме этого, благодаря присутствию продуктовых аналитиков, можно изменить приоритеты разработки. Например, одна команда не успевает выпустить функциональность к релизу. Другая команда также не успевает, но аналитик понимает, что бизнес-значимость (business-value) работы первой команды выше, поэтому вторая команда откладывает функциональность, запланированную к релизу и помогает первой команде закончить работу в срок. При этом важно, что каждый член команды слышит рассуждения и аргументы, которые привели к такому решению. Я уверен, что в большинстве компаний, где такое решение было бы принято на синхронизации тимлидов, у команд возникло бы явное непонимание, почему чьи-то фичи важнее, а чьи-то — нет. Здесь же все вопросы можно задать и непонятных моментов остаться не должно.
Результатом проведения таких синхронизаций является осознание и принятие каждым участником процесса разработки актуальных сроков и приоритетов разработки. Также каждый участник понимает актуальные изменения в различных частях кода приложения, что позволяет избежать непонимания при мержах, конфликтах версий и других неожиданных изменениях при работе приложения.
Пример проекта в Renga Architecture
Другой активностью, позволяющей оставаться в курсе изменений в продукте уже не на уровне кода, а на уровне пользователя — демо. Демо проводится на следующий день после завершения спринта. Демо организуется продуктовыми аналитиками для всех стейкхолдеров продукта — инвесторов, маркетингового отдела, руководителей компании и внутренних отделов разработки. Ведущие демо — аналитики команд, каждый из которых представляет разработанную, протестированную и слитую в основную ветку разработки функциональность продукта. Каждый сценарий демо проверяется накануне показа на соответствие требованиям (Definition of done). Важно понимать, на демо никогда не показываются незаконченные фичи или сценарии. Подразумевается, что любой сценарий, показанный на демо, может быть с хорошей вероятностью использован конечным пользователем продукта без каких-либо ошибок.
В процессе показа сценария, как правило, разъясняется основная мотивация к разработке этой фичи, показываются основные пользовательские сценарии работы. После завершения сценария, все присутствующие могут задавать вопросы. Как правило, стейкхолдеры уточняют тонкости работы фичи, маркетинговый отдел — применимость фичи для клиента и какие-то особенности внедрения, высказывают пожелания по улучшению. Уже не раз в процессе показа, от отдела маркетинга появлялись запросы на доработку фичи, которые добавлялись в план разработки на следующие спринты.
Результатом проведения демо является публикация очередного приращения функционала продукта для всех заинтересованных лиц. Благодаря присутствию на демо разработчиков, тестировщиков, сотрудников отдела маркетинга, проясняется множество моментов, происходит обмен актуальной информацией о сценариях работы продукта. Такая прозрачность знаний о продукте минимизирует расхождения в ожиданиях от той или иной функциональности и позволяет оперативно реагировать на любые предложения.
Одной из самых долгих и трудозатратных активностей является ретро релиза. Эта активность длится около 5 часов с перерывом на обед. Ведущим ретро может стать любой желающий, но, как правило, проводится тимлидами-евангелистами. Ретро релиза разбито на несколько смысловых блоков-заданий, выполняемых каждой командой. По результатам каждого задания появляется определенный артефакт, например, карта успеха, карта разочарования, карта полезных и мешающих моментов в течение релиза. Каждый такой артефакт презентуется, как правило, разными членами команды. По результату ретро каждая команда берет в работу позитивные практики работы других команд и старается найти решение негативных моментов в методах работы других команд. Каждое ретро релиза призвано повысить прозрачность практик, применяемых внутри каждой команды, и помочь командам обсуждать различные подходы решения проблем, возникающих в процессе разработки.
Пожалуй, ретро релиза — это самое интересное и полезное мероприятие из всех активностей, применяемых в компании. В короткий срок все команды обмениваются позитивным и негативным опытом, помогают друг другу найти решения задач организации рабочего процесса, оценок задач, составления описаний для фич.
Тайная комната — это наш демо-зал, в котором проводятся все описанные активности. Здесь есть все, что необходимо — флип-чарты, столы по количеству команд, доски и проектор. В нашем отделе разработки много конструктивных отсылок к Гарри Поттеру. У нас есть Sirius, Ravenclaw и даже Order of Phoenix, но об этом в следующих статьях.
В нашем отделе разработки много отсылок к Гарри Поттеру
В комментариях к предыдущей статье была высказана идея, что в таком процессе «без менеджеров» на собрания уходит слишком много времени разработчиков. Я позволил себе оценить отвлечения на активности.
По чистому времени выходит около 0.4 часа на стендапы, 5 часов на планирование, 2 часа на ретро, 2 часа на демо. 28*0.4*10 + 5*28 + 2*28 + 2*28= 364 человеко-часа за 12 дней на 28 человек или 1 час в день на одного человека. Я не учел активности вроде code-review, архитектурных обсуждений, потому что считаю их неотделимой частью процесса разработки.
Поделитесь, сколько времени интегрально у Вас (или Ваших команд) уходит на активности помимо разработки? На мой взгляд, 1 час в день «на поговорить» — очень небольшая плата за распространение знаний, рефлексию команд и повышение прозрачности.
Анатолий Осокин, ведущий инженер-программист, Renga Software.
Сегодня я расскажу об активностях, которые обеспечивают максимальную прозрачность рабочего процесса и позволяют не выпадать разработчикам из событий, происходящих в целом компании и в других командах в частности. Хотите выстроить качественные процессы и работать с удовольствием? Добро пожаловать под кат!
Перед тем, как продолжить делиться опытом организации процесса разработки, я хочу уточнить пару вопросов относительно специфики компании. Бизнес-структура компании подразумевает разработку продукта in-house и последующую продажу решения клиентам. В компании есть маркетинговый отдел, отдел сбыта и другие подразделения помимо отдела разработки. Это во многом определяет возможность взаимодействия напрямую с продуктовым аналитиком, который и является поставщиком основных требований к продукту. В обычном смысле, у нас нет клиента-заказчика со стороны. Мы сами вырабатываем требования, сами разрабатываем и сами продаем. Традиционная продуктовая компания.
Тем не менее, я настаиваю на том, что опыт организации процессов между командами разработки и разработчиками внутри команд может быть использован как пример для выстраивания процессов в Вашей компании, будь она разработчиком аутсорсных решений или продуктовой компанией. Классический скрам «по книжкам», как показывает опыт, не применим в реалиях разработки реальных продуктов, и именно поэтому специфика продукта определяет специфику процессов.
Напомню, в нашей компании работает на данный момент 28 разработчиков. То, что применимо для 7 команд (по четыре разработчика в команде) может стать нецелесообразным при работе 15 команд и наоборот. В то же время, и разработка качественной архитектуры кодовой базы, и выстраивание качественных процессов подразумевает свободу масштабирования без больших затрат. Кроме этого, в большинстве компаний отдел разработки одного направления большого продукта состоит как раз из 5-7 команд (20-30 человек). Такой отдел, как правило, имеет свободу принятия независимых архитектурных решений, свободу организации внутренних взаимодействий и выстраивания процессов.
Подробнее о семействе продуктов Renga (Осторожно, маркетинг!)
Renga Architecture – система для архитектурно-строительного проектирования. Программа создана для максимальной помощи проектировщику в решении его задач: создание архитектурного облика здания и информационной модели, быстрая компоновка чертежей согласно стандартам СПДС и многое другое.
Renga Structure — cистема для проектирования конструктивной части зданий/сооружений. Программа для инженеров-конструкторов и проектировщиков по созданию информационной модели здания или сооружения и получению чертежей марок КР/КЖ/КЖИ/КМ/АС.
Семейство продуктов Renga предназначено для проектирования по технологии BIM. Высокая производительность систем позволяет работать с большими проектами без видимого снижения качества работы с 3D-моделью:
Объектное проектирование
Создание в Renga 3D-модели здания/сооружения инструментами объектного проектирования (стена, колонна, окно и т.д.)
Коллективная работа
Обмен, хранение и управление данными осуществляется с помощью BIM-Server Pilot.
Взаимодействие со сметными системами.
Интеграция Renga посредством API со сметными системами 1С-смета и ABC-смета для взаимодействия проектного и сметного отделов.
Обмен данными
Renga позволяет обмениваться данными с другими системами через различные форматы (.ifc, .dwg, .dxf, .obj, .dae, .stl, .3ds, .lwo и .csv).
Автоматизация получения спецификаций и ведомостей
В Renga реализована функция получения отчетов для формирования спецификаций, ведомостей и экспликаций.
Автоматизация получения чертежей
По данным 3D-модели автоматически получаются виды (фасады, разрезы и планы) и размещаются на чертежах в заданных масштабах.
Renga Structure — cистема для проектирования конструктивной части зданий/сооружений. Программа для инженеров-конструкторов и проектировщиков по созданию информационной модели здания или сооружения и получению чертежей марок КР/КЖ/КЖИ/КМ/АС.
Семейство продуктов Renga предназначено для проектирования по технологии BIM. Высокая производительность систем позволяет работать с большими проектами без видимого снижения качества работы с 3D-моделью:
Объектное проектирование
Создание в Renga 3D-модели здания/сооружения инструментами объектного проектирования (стена, колонна, окно и т.д.)
Коллективная работа
Обмен, хранение и управление данными осуществляется с помощью BIM-Server Pilot.
Взаимодействие со сметными системами.
Интеграция Renga посредством API со сметными системами 1С-смета и ABC-смета для взаимодействия проектного и сметного отделов.
Обмен данными
Renga позволяет обмениваться данными с другими системами через различные форматы (.ifc, .dwg, .dxf, .obj, .dae, .stl, .3ds, .lwo и .csv).
Автоматизация получения спецификаций и ведомостей
В Renga реализована функция получения отчетов для формирования спецификаций, ведомостей и экспликаций.
Автоматизация получения чертежей
По данным 3D-модели автоматически получаются виды (фасады, разрезы и планы) и размещаются на чертежах в заданных масштабах.
Итак, 5-7 команд, разработка собственного продукта. Как же выстроить процесс без участия менеджера? В первой части статьи я уже рассказал о таких активностях, как груминг, плнирование и ретро команд. Далее речь пойдет об активностях, позволяющих синхронизировать работу нескольких команд и двигаться в одном направлении.
Пример проекта в Renga Structure
Синхронизация команд
Длина спринта у нас — десять рабочих дней. Между спринтами есть два дня для проведения демо, ретро и планирования. Если между спринтами есть два дня на ретро, демо и планирование — это не значит, что в эти два дня не пишется код. Это значит, что в эти дни активности идут с бОльшим приоритетом, чем написание кода. Эти два дня являются хорошим буфером для амортизации недооценок/переоценок по спринту. Синхронизация команд — активность, не привязанная к графику спринтов. Такая синхронизация проводится каждую пятницу в одно и то же время после обеда. На синхронизации присутствуют все разработчики, тестировщики и продуктовые аналитики. В общем смысле, синхронизация команд — это стендап, где от каждой команды выступает один разработчик и рассказывает, что командой было сделано, какие участки кода были затронуты и как это может повлиять на другие команды.
Часто в компаниях синхронизация проводится в виде собрания тимлидов команд. У этого подхода есть минус, который я подробно обсуждал в предыдущей статье: один человек может забыть, не обратить внимание на множество деталей, которые важны для других. Таким образом, синхронизация тимлидов экономит время команд, но существенно уступает качеству коммуникаций. Подразумевается, что после такого собрания тимлид будет рассказывать каждый своей команде о прогрессе других команд, что опять же потратит время каждой команды. Здесь появляется минус «глухого телефона» при передаче знаний от тимлида команде. Таким образом, команда остается как бы «в стороне» от работы других команд, общаясь только посредством тимлида. Как результат, падает заинтересованность, увеличивается разрыв в понимании общего движения разработки всего отдела. Экономия времени команды никак не может покрывать минусы от отстраненности от общего направления разработки и общения между разработчиками.
После каждого выступления команды, как правило, задаются уточняющие вопросы от любого из присутствующих. Если кто-то понимает, что ответ на вопрос перерастает в отстраненную продолжительную дискуссию, то он/она может прервать диалог и предложить перенести его на другое время. Таким образом, синхронизация семи команд длится не более сорока минут и позволяет всем разработчикам оставаться в струе развития продукта другими командами.
Другой важный аспект, который обсуждается на синхронизации — актуализация сроков разработки. Как правило, раз в две недели команды публично оценивают свои шансы на «успеть вовремя к релизу». В процессе обсуждения становится понятно, какая команда не успевает, а какая выполняет задачи в срок. Кроме этого, благодаря присутствию продуктовых аналитиков, можно изменить приоритеты разработки. Например, одна команда не успевает выпустить функциональность к релизу. Другая команда также не успевает, но аналитик понимает, что бизнес-значимость (business-value) работы первой команды выше, поэтому вторая команда откладывает функциональность, запланированную к релизу и помогает первой команде закончить работу в срок. При этом важно, что каждый член команды слышит рассуждения и аргументы, которые привели к такому решению. Я уверен, что в большинстве компаний, где такое решение было бы принято на синхронизации тимлидов, у команд возникло бы явное непонимание, почему чьи-то фичи важнее, а чьи-то — нет. Здесь же все вопросы можно задать и непонятных моментов остаться не должно.
Результатом проведения таких синхронизаций является осознание и принятие каждым участником процесса разработки актуальных сроков и приоритетов разработки. Также каждый участник понимает актуальные изменения в различных частях кода приложения, что позволяет избежать непонимания при мержах, конфликтах версий и других неожиданных изменениях при работе приложения.
Пример проекта в Renga Architecture
Демо
Другой активностью, позволяющей оставаться в курсе изменений в продукте уже не на уровне кода, а на уровне пользователя — демо. Демо проводится на следующий день после завершения спринта. Демо организуется продуктовыми аналитиками для всех стейкхолдеров продукта — инвесторов, маркетингового отдела, руководителей компании и внутренних отделов разработки. Ведущие демо — аналитики команд, каждый из которых представляет разработанную, протестированную и слитую в основную ветку разработки функциональность продукта. Каждый сценарий демо проверяется накануне показа на соответствие требованиям (Definition of done). Важно понимать, на демо никогда не показываются незаконченные фичи или сценарии. Подразумевается, что любой сценарий, показанный на демо, может быть с хорошей вероятностью использован конечным пользователем продукта без каких-либо ошибок.
В процессе показа сценария, как правило, разъясняется основная мотивация к разработке этой фичи, показываются основные пользовательские сценарии работы. После завершения сценария, все присутствующие могут задавать вопросы. Как правило, стейкхолдеры уточняют тонкости работы фичи, маркетинговый отдел — применимость фичи для клиента и какие-то особенности внедрения, высказывают пожелания по улучшению. Уже не раз в процессе показа, от отдела маркетинга появлялись запросы на доработку фичи, которые добавлялись в план разработки на следующие спринты.
Результатом проведения демо является публикация очередного приращения функционала продукта для всех заинтересованных лиц. Благодаря присутствию на демо разработчиков, тестировщиков, сотрудников отдела маркетинга, проясняется множество моментов, происходит обмен актуальной информацией о сценариях работы продукта. Такая прозрачность знаний о продукте минимизирует расхождения в ожиданиях от той или иной функциональности и позволяет оперативно реагировать на любые предложения.
Ретро релиза
Одной из самых долгих и трудозатратных активностей является ретро релиза. Эта активность длится около 5 часов с перерывом на обед. Ведущим ретро может стать любой желающий, но, как правило, проводится тимлидами-евангелистами. Ретро релиза разбито на несколько смысловых блоков-заданий, выполняемых каждой командой. По результатам каждого задания появляется определенный артефакт, например, карта успеха, карта разочарования, карта полезных и мешающих моментов в течение релиза. Каждый такой артефакт презентуется, как правило, разными членами команды. По результату ретро каждая команда берет в работу позитивные практики работы других команд и старается найти решение негативных моментов в методах работы других команд. Каждое ретро релиза призвано повысить прозрачность практик, применяемых внутри каждой команды, и помочь командам обсуждать различные подходы решения проблем, возникающих в процессе разработки.
Пожалуй, ретро релиза — это самое интересное и полезное мероприятие из всех активностей, применяемых в компании. В короткий срок все команды обмениваются позитивным и негативным опытом, помогают друг другу найти решения задач организации рабочего процесса, оценок задач, составления описаний для фич.
Тайная комната
Тайная комната — это наш демо-зал, в котором проводятся все описанные активности. Здесь есть все, что необходимо — флип-чарты, столы по количеству команд, доски и проектор. В нашем отделе разработки много конструктивных отсылок к Гарри Поттеру. У нас есть Sirius, Ravenclaw и даже Order of Phoenix, но об этом в следующих статьях.
В нашем отделе разработки много отсылок к Гарри Поттеру
Вместо заключения
В комментариях к предыдущей статье была высказана идея, что в таком процессе «без менеджеров» на собрания уходит слишком много времени разработчиков. Я позволил себе оценить отвлечения на активности.
По чистому времени выходит около 0.4 часа на стендапы, 5 часов на планирование, 2 часа на ретро, 2 часа на демо. 28*0.4*10 + 5*28 + 2*28 + 2*28= 364 человеко-часа за 12 дней на 28 человек или 1 час в день на одного человека. Я не учел активности вроде code-review, архитектурных обсуждений, потому что считаю их неотделимой частью процесса разработки.
Поделитесь, сколько времени интегрально у Вас (или Ваших команд) уходит на активности помимо разработки? На мой взгляд, 1 час в день «на поговорить» — очень небольшая плата за распространение знаний, рефлексию команд и повышение прозрачности.
Анатолий Осокин, ведущий инженер-программист, Renga Software. Комментарии (10)
KirEv
31.12.2017 03:18Интересно, или что-то недоговариваете, или уже в полном объеме описывайте чем вы там и как занимаетесь.
Кроме этого, благодаря присутствию продуктовых аналитиков, можно изменить приоритеты разработки. Например, одна команда не успевает выпустить функциональность к релизу. Другая команда также не успевает, но аналитик понимает, что бизнес-значимость (business-value) работы первой команды выше, поэтому вторая команда откладывает функциональность, запланированную к релизу и помогает первой команде закончить работу в срок.
не понимаю, если спринт 10 дней, в него входит одна фича/группа фич…
4 человека говорят: мы сделаем определенный пул задач/фич к релизу…
скорее всего были рассуждения и т.п. в кругу этих 4х человек (одна группа разработчиков), они определяли структуры фич, с чего да как фича должна рождаться и как в результате выглядеть…
план построили, начали делать, пройдя пол-пути поняли: мы это и это не успеем…
… вот скажите, как можно переопределить обязанности и поручить дело другой команде? это же нужно им пояснить бизнес задачу, новые люди свежим взглядом могут тыкнуть где просчет, начать заново переосмысливать некоторые вещи и т.п…
где у меня пробелы после прочтения? )oas
31.12.2017 11:27+1Вы абсолютно правы!
Были груминги в рамках команды с аналитиком. Записали требования к фиче, обсудили, разошлись. Требования выявляем заранее, спринта за 2-3 до фактической реализации. И вот через 2-3 спринта, понимаем, что не успеваем сделать эту фичу. На синхронизации выяснилось, что у другой команды возникает пул времени, так как большую фичу они сделать не успеют, а маленькие закончились.
На следующий день, вторая команда-помощник собирается обсуждать аналитику фичи (как бы второй раз), но уже без аналитика, — только тим лид от первой команды. Обсуждают требования, как на груминге (как бы второй раз). И вот тут Вы абсолютно правы. Новая команда смотрит свежим взглядом и тут же находит пару непонятных моментов, которые уточнили у аналитика. В этом как раз видится большой плюс.
Так что не похоже, что остались какие-то пробелы :) С другой стороны, и цикл статей не окончен!
FadeToBlack
01.01.2018 06:55Мне кажется, или статьи пытаются высказать такую мысль: «Менеджеры — это плохо?». Мне лично кажется, выстраиванием командных взаимодействий без менеджера вы решаете какую-то проблему, например, проблему отсутствия в природе нужного количества адекватных менеджеров. Их долго и дорого искать, и на рынке труда очень много самозванцев.
oas
01.01.2018 17:36Приветствую. Скорее, посыл статьи: «И без менеджеров возможно». В современном IT мире большинство книг и методологий настаивают на том, что обязательно должен быть в IT структуре *отдельный* человек с функциями менеджера. Я же пытаюсь показать, что возможно организовать эффективную работу без такого человека. Я могу быть не прав, готов спорить. Но пока что спор никак не завязывается :)
funca
поскольку product owner у вас не является частью команды, это не scrum. вы можете и дальше называть все эти активности словом «скрам», если видите в этом какую-то пользу, но это какой-то другой процесс. насколько он адекватен? очевидно, что решение инженерной задачи не сводится только лишь к написанию кода. поэтому вопрос не в наличии «активностей», как таковых, а в их эффективности. попробуйте для начала оценить хотя бы это.
oas
Приветствую. Если хотите конструктивно обсудить, разъясните, пожалуйста, что Вы вкладываете в фразу «po является частью команды»?
Что касается терминологии, может, у нас и не скрам, но мы эффективно доставляем пак фичей к сроку. В этом и есть посыл моих статей. Книжная методология — не панацея и не решение всех проблем. Каждая организация должна найти свои активности и свои процессы, которые позволяют максимально эффективно доставить продукт конечным пользователям в срок и с нужным качеством.
funca
если вы изучали scrum, наверно должны это помнить. как вы понимаете, что ваш процесс не просто достаточно эффективен, чтобы укладываться в сроки (которые по предыдущей статье выставляют сами разработчики, и вероятно с учетом всех этих «активностей»), а в самом деле эффективен максимально?
oas
С PO как частью команды вопрос тогда снимается.
Позвольте мне провести аналогию с Вашим вопросом. Это очень похоже на такую критику: бизнес работает с маржинальностью в 40%. Участники бизнеса всем довольны. Приходит критик и говорит, ваша эффективность не максимальна! Так и не надо, если только Вы не хотите поупражняться в решении математической задачи оптимизации «эффективности процессов agile» :)
В этом-то и суть. Баланс между затрачиваемыми на процесс усилиями и выхлопом в виде прозрачности, повышения качества архитектуры кода и т.д. Мы не пытаемся найти максимальную эффективность, мы решаем задачи, которые перед нами ставит бизнес. И решаем их с эффективностью, достаточной для успешного закрытия бизнес-планов.
funca
del
sasha1024
Может я чего-то не понимаю, но Ваш комментарий вызывает у меня
жуткийразрыв шаблона.В Scrum'е product owner как раз не может быть частью команды.Team, product owner и scrum master — это три разные роли, и если team и scrum master ещё можно совмещать (scrum master может быть в команде)…
А, упс, вру, я перепутал: это product owner и scrum master не могут быть одним человеком; а product owner может быть в команде и scrum master теоретически может быть в команде.
Но в любом случае, это отнюдь не обязательно — совмещать роли.