Статья в хабе "аджайл", я не знаю, как она к вам в рекомендации залетела. Гугл вроде тоже пока работает, а для уверенных в себе есть яндекс. Серьезно, вы на любой непонятный термин идете не в гугл, а в комментарии? Это не энциклопедия. Но специально для вас я дам определение в комментарии.
Scrum — это гибкая методология управления проектами и разработки программного обеспечения, которая используется для эффективного создания продуктов в условиях неопределенности и постоянных изменений. Основные принципы и элементы Scrum включают:
Итеративный и инкрементальный подход: Работа над проектом делится на короткие итерации, называемые спринтами, продолжительность которых обычно составляет от одной до четырех недель. В конце каждого спринта команда предоставляет работающий продукт или его часть.
Роли: В Scrum есть три основные роли:
Product Owner (владелец продукта): Ответственен за максимизацию ценности продукта и управление бэклогом продукта.
Scrum Master: Обеспечивает соблюдение Scrum-процессов, помогает команде устранять препятствия и содействует улучшению.
Development Team (команда разработки): Кросс-функциональная команда, которая работает над созданием продукта.
Артефакты:
Product Backlog (бэклог продукта): Список всех задач и требований к продукту, приоритезированный владельцем продукта.
Sprint Backlog (бэклог спринта): Набор задач из бэклога продукта, отобранных для выполнения в текущем спринте.
Increment (инкремент): Завершенная часть продукта, созданная за спринт, которая добавляется к предыдущим инкрементам.
События:
Sprint Planning (планирование спринта): Встреча, на которой команда планирует задачи на предстоящий спринт.
Daily Scrum (ежедневный скрам): Короткие (до 15 минут) ежедневные встречи, где команда обсуждает прогресс и выявляет препятствия.
Sprint Review (обзор спринта): Встреча в конце спринта для демонстрации выполненной работы и сбора обратной связи.
Sprint Retrospective (ретроспектива спринта): Встреча, где команда анализирует прошедший спринт и разрабатывает планы по улучшению процессов.
Scrum ориентирован на сотрудничество, адаптивное планирование и быструю доставку ценного продукта клиенту.
Я бы так не скзазал. Мое понимание Agile таково, что он про гибкость, но это не исключает коммитменты. Просто не нужно делать коммитменты, которые исключают гибкость: например, можно зафиксировать бюджет, что зафиксирует человеко-часы, но при этом будет гибкость по деливери.
С другой стороны, можно зафиксировать скоуп, но тогда либо сроки будут плавать, либо качество.
Нет. Я предполагал, что читатели хабра знают базовые вещи, как скрам, электричество, воздух и пользование туалетом, поэтому решил опустить определение.
Я сопровождал SAP. Конечно бывают ошибки, на которые уходят дни (а то и недели). Но в целом в сопровождении риски напороться на подводные камни, которые значительно раздуют сроки, куда ниже, чем в разработке с нуля.
Но мне кажется причина в требовании коммитмента на сроках В Agile про коммитмент ничего не сказано и он скорее противоречит духу гибкой методологии
Во-первых, agile и гибкая методология это одно и тоже, это буквальный перевод.
Во-вторых, agile в целом ничего не говорит про коммитменты, он скорее про коммуникации и построение процессов вокруг коммуникации, а не вокруг документации. Сверху можно навалить больше методологических слоев, которые уже помогут зафиксировать сроки, обработать риски и прочее, например - тот самый SAFe.
То, о чем вы говорите, скорее вытекает из нежелания бизнеса признавать триаду проектного управления, из чего вытекают нереалистичные ожидания. Скрам тут только подливает масла в огонь, так как построен вокруг баланса скоуп-время (при фиксированном размере команды обычно, то есть бюджете), что в свою очередь просто не подходит для проектной деятельности, где все три параметра зафиксированы заранее.
В чем проблема взять задачу-плейсхолдер на весь спринт
Именно про это я и говорю! Какая польза от этого? Мы синтетически "натягиваем" рабочий процесс на спринты, чтобы "было по скраму", при этом скрам никак не отражает реальный процесс, а то, что мы видим в нем - фикция, плейсхолдер.
В итоге рабочий процесс идет как и шел, а в трекере стоят нерепрезентативные заглушки, но зато менеджмент доволен, все под контролем!
Наверное, в совсем наивных компаниях (командах) Scrum - это лекарство от всего, однако сейчас люди все же понимают, что Agile != Scrum, и что методологий множество, начиная с банального Kanaban.
Не уверен, что это действительно так. Кроме каких-то совсем маленьких компаний или компнаий с "особым путем", все поголовно используют скрам, многие лишь потому что "ну все так делают".
И да, задачи на RnD можно тоже декомпозировать. И даже оценить. Потому что брать в работу задачу даже анализ которой займет месяц не всегда имеет смысл.
Наверное можно, мне не доводилось видеть процесс, где это хорошо и повторяемо работает. Я бы хотел такое увидеть и понять, как у людей это получается на постоянной основе.
В стартапе на 20 человек можно прекрасно жить без единого процесса, однако когда в разработке у тебя 100-150 человек, то процессы придется строить.
К процессам претензий нет, претензия к карго-культизму. Когда процесс не ради решения задач, а потому что надо.
А у нас WiP limit измеряется кол-вом задач или все же с поправкой на их размер?
Я бы сказал, что это зависит. Большие задачи само по себе не очень хорошо, и дробление задач оправдано, когда это делается с целью уменьшения энтропии, а не с целью "чтобы влезло в спринт". Не знаю, делают ли так, но не вижу причин не ввести поправку на размер, если конечно мы умеем определять размер.
Как раз такие проекты отлично ложатся на Kanban, когда нам нужно выполнять определенным кол-вом людей (=пропускная способность команды) определенный объем задач.
Такие проекты вообще на любую методологию хорошо ложатся. Управлять известным объемом при известном капасити много ума не надо. Сложности (и потребность в методологиях) повышается, когда растут неизвестные, а с ними и риски.
Вы подаете свой тезис под соусом "скрам за все хорошее и против всего плохого". У меня нет претензий к скраму как к методологии. Как мне кажется, это хорошая, продуманная и целостная методология, которая была нужна индустрии, особенно энтерпрайзам.
Проблема (и моя претензия) в применении методологии на практике. Когда скрам спускают сверху, не глядя, а что там за процессы у команд. И когда на крики снизу "нам эти спринты только мешают, ну не ложится процесс на них, приходится выдумывать синтетические костыли" им отвечают "вы просто неправильно работаете, надо по скраму, а вы все по-старинке".
Совещания здесь плохо, совещания там плохо. А ничего, что стандартного бизнес-человека беспокоит два вопроса:
Что происходит?
Когда будет готово?
Ответы на эти вопросы можно найти в Jira; в любой момент времени и в любом формате. Не обязательно всех в шеренгу ставить.
Когда требования и планы могут меняться каждый месяц...
Вы сейчас описываете не скрам, а аджайл манифесто.
Скрам то изначально и задумывался действительно как противовес ватерфолу и как одну из реализаций идеи гибких методологий. Но со временем вырос в большой корпоративный карго-культ.
Краткий ответ - декомпозиция очень важный инженерный навык, с этим спорить было бы глупо. Однако разбивать RnD задачи на мелкие атомарные части часто не получается, или получается плохо, так как скоуп задачи заранее неизвестен, и часто может измениться на несколько порядков от оценки.
Можно свалить на неумение разбивать - с этим тоже не спорю. Большинство аргументов в пользу скрама и сводятся к тезису "вы просто не умеете его готовить".
Но если мало кто умеет его готовить, может не в поваре дело?
Ответил выше, да, в каждом доменном сервисе реализован эдакий оркестратор, однако оркестрация ориентирована не на процесс, а на сам домен. То есть общий процесс может по факту затрагивать разные части домена и разные его возможности, доступные через контракт этого сервиса. А внутри сервис управляет тем, как и когда инициировать команды к прямым зависимостям этого сервиса.
Я не пурист, поэтому предпочитаю использовать существующие практики и адаптировать их к конкретным задачам, нежели стремиться строго советовать постулатам (очень общим и абстрактным в конкретном случае), выдвинутым довольно давно и уже обросшими своими практиками. DDD, как мы знаем, тоже не только Big Blue Book, а имеет множество интерпретаций, в том числе противоречивых. Грегу привет.
Касательно p2p ответил в комментарии про p2p, мне кажется вы что-то превратно поняли. Высокой зависимости у нас нигде нет, максимальная зависимость в том, что инициирующий команду сервис знает контракт сервиса, куда он команду отправляет, но на этом все. Нагрузку сервисы могут обрабатывать и масштабироваться как угодна, потому что все команды происходят асинхронно.
Через gRPC происходит чтение данных моделей других сервисов (доменов). Я не знаю, какую альтернативу вы тут видите - агрегация всех данных в каком-то data lake и чтение оттуда, либо переход на event-sourcing и построение локального view каждой модели внутри сервиса?
Мы не используем event-sourcing, у нас более классический подход, основанный на CQRS, где запросы выполняются синхронно по gRPC, а команды асинхронно через сообщения. Где вы в такой модели видите размытия границ, я не вижу, при том, что запросы на чтение ничего не изменяют (а значит, никакого bounded contexts по факту там нет, да и доменов нет, потому что для запросов в CQRS отдельные упрощенные и оптимизированные для скорости чтения и кеширования модели), а запросы на изменение (команды) четко ограничены обработкой внутри домена, и никаких открытых соединений с другими сервисами в процессе этого нет, только чтение из брокера и запись в брокер..
В какой-то степени это так. Каждый домен выступает по сути оркестратором того процесса, которым он владеет (например, домен ВМ "владеет" процессом создания ВМ), но при этом оркестритует только в прямой видимости, коей являются контракты сервисов, к которым он напрямую обращается.
В итоге в дереве вызовов (или дереве транзакций) из A->B->C получается, что A оркестрирует B, а B оркестрирует C (в статье даже есть картинка). При этом А ничего не знает про С, С не знает про B, и B не знает про A, и это больше похоже на хореографическую сагу.
Получается что если идти по дереву транзакции/вызовов от корня, то каждый переход - это оркестрируемая транзакция, но только на ближайшего потомка. Если же идти к корню, то получается хореографическая транзакция.
Мы пишем на go, поэтому FSM решили реализовать в духе go-way - максимально просто и читабельно. В итоге каждый FSM это обычный switch вида
switch state {
case model.InitialState:
switch event {
case eventNodeChanged:
// ...
case eventNodeDeleted:
// ...
}
case model.NodeInstanceCreationPending:
switch event {
case eventNodeChanged:
// ...
case eventNodeDeleted:
// ...
}
case ...
}
Да, в отдельных случаях такой свич разрастается до внушительных размеров, и его становится не очень удобно читать. Но при этом такой код понятен "без дебаггера" и прост в доработке и траблшутинге. Изначально тоже пробовал разные библиотеки, думал над табличной или иной динамической реализацией, но здравый смысл в итоге победил, и самое простое решение оказалось самым простым. Более того, код в принципе понятен и тем, кто не сильно знаком с концепцией конечных автоматов, потому что он (код) прост и вполне линееню
Чтобы ответить на этот вопрос, мне бы хотелось сначала понять - а как вы решаете эту проблему, и в чем состоит та реализация саги, про которую вы говорите. Можно со ссылками и так далее.
Статья в хабе "аджайл", я не знаю, как она к вам в рекомендации залетела.
Гугл вроде тоже пока работает, а для уверенных в себе есть яндекс.
Серьезно, вы на любой непонятный термин идете не в гугл, а в комментарии? Это не энциклопедия. Но специально для вас я дам определение в комментарии.
Scrum — это гибкая методология управления проектами и разработки программного обеспечения, которая используется для эффективного создания продуктов в условиях неопределенности и постоянных изменений. Основные принципы и элементы Scrum включают:
Итеративный и инкрементальный подход: Работа над проектом делится на короткие итерации, называемые спринтами, продолжительность которых обычно составляет от одной до четырех недель. В конце каждого спринта команда предоставляет работающий продукт или его часть.
Роли: В Scrum есть три основные роли:
Product Owner (владелец продукта): Ответственен за максимизацию ценности продукта и управление бэклогом продукта.
Scrum Master: Обеспечивает соблюдение Scrum-процессов, помогает команде устранять препятствия и содействует улучшению.
Development Team (команда разработки): Кросс-функциональная команда, которая работает над созданием продукта.
Артефакты:
Product Backlog (бэклог продукта): Список всех задач и требований к продукту, приоритезированный владельцем продукта.
Sprint Backlog (бэклог спринта): Набор задач из бэклога продукта, отобранных для выполнения в текущем спринте.
Increment (инкремент): Завершенная часть продукта, созданная за спринт, которая добавляется к предыдущим инкрементам.
События:
Sprint Planning (планирование спринта): Встреча, на которой команда планирует задачи на предстоящий спринт.
Daily Scrum (ежедневный скрам): Короткие (до 15 минут) ежедневные встречи, где команда обсуждает прогресс и выявляет препятствия.
Sprint Review (обзор спринта): Встреча в конце спринта для демонстрации выполненной работы и сбора обратной связи.
Sprint Retrospective (ретроспектива спринта): Встреча, где команда анализирует прошедший спринт и разрабатывает планы по улучшению процессов.
Scrum ориентирован на сотрудничество, адаптивное планирование и быструю доставку ценного продукта клиенту.
Я бы так не скзазал. Мое понимание Agile таково, что он про гибкость, но это не исключает коммитменты. Просто не нужно делать коммитменты, которые исключают гибкость: например, можно зафиксировать бюджет, что зафиксирует человеко-часы, но при этом будет гибкость по деливери.
С другой стороны, можно зафиксировать скоуп, но тогда либо сроки будут плавать, либо качество.
Нет. Я предполагал, что читатели хабра знают базовые вещи, как скрам, электричество, воздух и пользование туалетом, поэтому решил опустить определение.
Я сопровождал SAP. Конечно бывают ошибки, на которые уходят дни (а то и недели). Но в целом в сопровождении риски напороться на подводные камни, которые значительно раздуют сроки, куда ниже, чем в разработке с нуля.
Во-первых, agile и гибкая методология это одно и тоже, это буквальный перевод.
Во-вторых, agile в целом ничего не говорит про коммитменты, он скорее про коммуникации и построение процессов вокруг коммуникации, а не вокруг документации. Сверху можно навалить больше методологических слоев, которые уже помогут зафиксировать сроки, обработать риски и прочее, например - тот самый SAFe.
То, о чем вы говорите, скорее вытекает из нежелания бизнеса признавать триаду проектного управления, из чего вытекают нереалистичные ожидания. Скрам тут только подливает масла в огонь, так как построен вокруг баланса скоуп-время (при фиксированном размере команды обычно, то есть бюджете), что в свою очередь просто не подходит для проектной деятельности, где все три параметра зафиксированы заранее.
Плюс-минус согласен.
Именно про это я и говорю! Какая польза от этого? Мы синтетически "натягиваем" рабочий процесс на спринты, чтобы "было по скраму", при этом скрам никак не отражает реальный процесс, а то, что мы видим в нем - фикция, плейсхолдер.
В итоге рабочий процесс идет как и шел, а в трекере стоят нерепрезентативные заглушки, но зато менеджмент доволен, все под контролем!
Не уверен, что это действительно так. Кроме каких-то совсем маленьких компаний или компнаий с "особым путем", все поголовно используют скрам, многие лишь потому что "ну все так делают".
Наверное можно, мне не доводилось видеть процесс, где это хорошо и повторяемо работает. Я бы хотел такое увидеть и понять, как у людей это получается на постоянной основе.
К процессам претензий нет, претензия к карго-культизму. Когда процесс не ради решения задач, а потому что надо.
Я бы сказал, что это зависит. Большие задачи само по себе не очень хорошо, и дробление задач оправдано, когда это делается с целью уменьшения энтропии, а не с целью "чтобы влезло в спринт". Не знаю, делают ли так, но не вижу причин не ввести поправку на размер, если конечно мы умеем определять размер.
Такие проекты вообще на любую методологию хорошо ложатся. Управлять известным объемом при известном капасити много ума не надо. Сложности (и потребность в методологиях) повышается, когда растут неизвестные, а с ними и риски.
Вы мне про теорию, а я вам про практику. Если такого нет, почему я это вижу во многих проектах разных компаний разных стран?
Вы подаете свой тезис под соусом "скрам за все хорошее и против всего плохого".
У меня нет претензий к скраму как к методологии. Как мне кажется, это хорошая, продуманная и целостная методология, которая была нужна индустрии, особенно энтерпрайзам.
Проблема (и моя претензия) в применении методологии на практике. Когда скрам спускают сверху, не глядя, а что там за процессы у команд. И когда на крики снизу "нам эти спринты только мешают, ну не ложится процесс на них, приходится выдумывать синтетические костыли" им отвечают "вы просто неправильно работаете, надо по скраму, а вы все по-старинке".
Ответы на эти вопросы можно найти в Jira; в любой момент времени и в любом формате. Не обязательно всех в шеренгу ставить.
Как и везде? Было бы странно рассматривать методологию в отрыве от практики ее применения.
Сам по себе скрам неплох, но увы - делают с ним что-то не то.
Вы сейчас описываете не скрам, а аджайл манифесто.
Скрам то изначально и задумывался действительно как противовес ватерфолу и как одну из реализаций идеи гибких методологий. Но со временем вырос в большой корпоративный карго-культ.
Краткий ответ - декомпозиция очень важный инженерный навык, с этим спорить было бы глупо.
Однако разбивать RnD задачи на мелкие атомарные части часто не получается, или получается плохо, так как скоуп задачи заранее неизвестен, и часто может измениться на несколько порядков от оценки.
Можно свалить на неумение разбивать - с этим тоже не спорю. Большинство аргументов в пользу скрама и сводятся к тезису "вы просто не умеете его готовить".
Но если мало кто умеет его готовить, может не в поваре дело?
А каковы масштабы у вас? Сколько сервисов и сколько событий происходит в рамках среднего процесса?
Ответил выше, да, в каждом доменном сервисе реализован эдакий оркестратор, однако оркестрация ориентирована не на процесс, а на сам домен. То есть общий процесс может по факту затрагивать разные части домена и разные его возможности, доступные через контракт этого сервиса. А внутри сервис управляет тем, как и когда инициировать команды к прямым зависимостям этого сервиса.
Я не пурист, поэтому предпочитаю использовать существующие практики и адаптировать их к конкретным задачам, нежели стремиться строго советовать постулатам (очень общим и абстрактным в конкретном случае), выдвинутым довольно давно и уже обросшими своими практиками. DDD, как мы знаем, тоже не только Big Blue Book, а имеет множество интерпретаций, в том числе противоречивых. Грегу привет.
Касательно p2p ответил в комментарии про p2p, мне кажется вы что-то превратно поняли. Высокой зависимости у нас нигде нет, максимальная зависимость в том, что инициирующий команду сервис знает контракт сервиса, куда он команду отправляет, но на этом все. Нагрузку сервисы могут обрабатывать и масштабироваться как угодна, потому что все команды происходят асинхронно.
Через gRPC происходит чтение данных моделей других сервисов (доменов). Я не знаю, какую альтернативу вы тут видите - агрегация всех данных в каком-то data lake и чтение оттуда, либо переход на event-sourcing и построение локального view каждой модели внутри сервиса?
Мы не используем event-sourcing, у нас более классический подход, основанный на CQRS, где запросы выполняются синхронно по gRPC, а команды асинхронно через сообщения. Где вы в такой модели видите размытия границ, я не вижу, при том, что запросы на чтение ничего не изменяют (а значит, никакого bounded contexts по факту там нет, да и доменов нет, потому что для запросов в CQRS отдельные упрощенные и оптимизированные для скорости чтения и кеширования модели), а запросы на изменение (команды) четко ограничены обработкой внутри домена, и никаких открытых соединений с другими сервисами в процессе этого нет, только чтение из брокера и запись в брокер..
В какой-то степени это так. Каждый домен выступает по сути оркестратором того процесса, которым он владеет (например, домен ВМ "владеет" процессом создания ВМ), но при этом оркестритует только в прямой видимости, коей являются контракты сервисов, к которым он напрямую обращается.
В итоге в дереве вызовов (или дереве транзакций) из A->B->C получается, что A оркестрирует B, а B оркестрирует C (в статье даже есть картинка). При этом А ничего не знает про С, С не знает про B, и B не знает про A, и это больше похоже на хореографическую сагу.
Получается что если идти по дереву транзакции/вызовов от корня, то каждый переход - это оркестрируемая транзакция, но только на ближайшего потомка. Если же идти к корню, то получается хореографическая транзакция.
Мы пишем на go, поэтому FSM решили реализовать в духе go-way - максимально просто и читабельно. В итоге каждый FSM это обычный switch вида
Да, в отдельных случаях такой свич разрастается до внушительных размеров, и его становится не очень удобно читать. Но при этом такой код понятен "без дебаггера" и прост в доработке и траблшутинге. Изначально тоже пробовал разные библиотеки, думал над табличной или иной динамической реализацией, но здравый смысл в итоге победил, и самое простое решение оказалось самым простым. Более того, код в принципе понятен и тем, кто не сильно знаком с концепцией конечных автоматов, потому что он (код) прост и вполне линееню
Чтобы ответить на этот вопрос, мне бы хотелось сначала понять - а как вы решаете эту проблему, и в чем состоит та реализация саги, про которую вы говорите. Можно со ссылками и так далее.