@Sergey Titkov - "авторы" статьи создатели LeSS фреймворка Craig Larman и Bass Vodde. Про кошек и ипотеку судить не берусь, но люди уважаемые.

Про "избыточный" принимается. хотя я бы применил "ненужных процессов", лишних процессов

Тут важен контекст. Избыточный процесс - процесс который в данном случае содержит слишком много не нужных элементов. Ненужный процесс - он просто не нуже, в силу разных обстоятельств

Гайз, давайте для перевода всё-таки отдельный чатик? И киньте сюда ссылку Дело хорошее, но не всем 2000+ людям интересно)

А я это не сказал. Я только сказал, что так нельзя переводить. Это ужасный русский язык.

Хорошая идея, все кому не наплевать на эджайл в России могут принять участие в переводе

Ммм... А вас разве не учили указывать смысл процессов его модели, шага в его описании?

Может вам RACI нужен?

Может вам RACI нужен?

https://en.m.wikipedia.org/wiki/Responsibility_assignment_matrix

Список ролей в виде таблицы, роль, что делает, а дальше идут столбцы с разрешениями.

Вот решение)

нет, это роли в команде, а я хочу в продукте. Мы будем делать видеоплатформу, вот и надо написать, кто там че делает, типо редактор выставялет контент и тп

а какая-то кроссфункциональность предполагается?)

думаю, к счастью, время покажет)

думаю, к счастью, время покажет)

Не знаю, где спросить, возможно сможете помочь. Есть ли какие-то расширения для Жиры, которые позволяют сортировать задачи в эпике по статусам? У самой жиры данный тикет висит с 2012 года и не двигается с места. Загуглить расширение не получилось (

свидетили последних дней jira обитают тут https://t.me/augmoscow

Тут спросите

В первых версиях Скрам Гайда так и было. И в литературе это видно https://www.amazon.com/Agile-Project-Management-Developer-Practices/dp/073561993X

Предположительно книжка писалась для менеджеров. А если так - я ставлю себе цели, я выбираю действия исходя из целей, я пересматриваю результаты своих действий, анализирую причины успеха и неуспеха, я тестирую цель на актуальность, я пытаюсь разбираться с неосознанными реакциями. Все это значит - я управляю своей жизнью. (на всякий случай - это я не про смебя) Не в том смысле, что моя жизнь мне полностью подконтрольна, а в том, что я прикладываю усилия. Почему такой же подход к проектам нельзя назвать управлением? Ведь в названии книги ничего не сказано о том кто управляет. Самоуправление вполне вписывается в управление. Про методологию - это наука о создании методов. Не знаю как на счет научности, но следуя ценностям и приципам Scrum вполне себе создается метод работы - индивидуальный для команды/проекта/продукта. Мочему бы не назвать Scrum методологией?

Предположительно книжка писалась для менеджеров. А если так - я ставлю себе цели, я выбираю действия исходя из целей, я пересматриваю результаты своих действий, анализирую причины успеха и неуспеха, я тестирую цель на актуальность, я пытаюсь разбираться с неосознанными реакциями. Все это значит - я управляю своей жизнью. (на всякий случай - это я не про смебя) Не в том смысле, что моя жизнь мне полностью подконтрольна, а в том, что я прикладываю усилия. Почему такой же подход к проектам нельзя назвать управлением? Ведь в названии книги ничего не сказано о том кто управляет. Самоуправление вполне вписывается в управление. Про методологию - это наука о создании методов. Не знаю как на счет научности, но следуя ценностям и приципам Scrum вполне себе создается метод работы - индивидуальный для команды/проекта/продукта. Мочему бы не назвать Scrum методологией?

Почему не назвать методологией? Имхо. Потому что Scrum не ставит целью выработку метода разработки в отдельно взятом контексте команды/продукта. Scrum - запатентованный процессный фреймворк.. и больше ничего. От его внедрения вам может полегчать. Быть может даже выстроится ваш особый метод. Быть может разработчик почувствует свободу и собственную значимость, а директор прозрачность и управляемость.. Но Scrum'у на это всё так же наплевать, как и Вселенной наплевать на людей. У вас получилось после внедрения Scrum'а повысить управляемость проектом? Ну ок. Не получилось? Мне, как фреймворку, тоже ок, ведь я вам не обещал ничего более того, что записано в гайде.

Почему не назвать методологией? Имхо. Потому что Scrum не ставит целью выработку метода разработки в отдельно взятом контексте команды/продукта. Scrum - запатентованный процессный фреймворк.. и больше ничего. От его внедрения вам может полегчать. Быть может даже выстроится ваш особый метод. Быть может разработчик почувствует свободу и собственную значимость, а директор прозрачность и управляемость.. Но Scrum'у на это всё так же наплевать, как и Вселенной наплевать на людей. У вас получилось после внедрения Scrum'а повысить управляемость проектом? Ну ок. Не получилось? Мне, как фреймворку, тоже ок, ведь я вам не обещал ничего более того, что записано в гайде.

Вот вы жили как-то до Scrum'а. Применяли традиционно какие-то инженерные и управленческие практики и методы, чтобы допинать идею до релиза. Но жизнь была без вкуса, как без юппи. Пришёл Scrum и сказал (по доброму) - давайте разберем на запчасти ваш сарай, соберём каркас по инструкции, в который выложим ваши старые практики и методы. Да, можно не все. Так можно было, да. И да, новые можно. Можно даже на лету. Но лучше не баловаться. Как Scrum я привнесу вам с гарантией (при правильной эксплуатации) следующее: адаптивность, быструю обратную связь.. (ну и так далее, вам ли мне рассказывать 😉)

Имхо. В первую очередь - адаптивность средств разработки. Во вторую - продукта. Собственно с решения этих двух проблем и начался Scrum

А под средствами разработки, что понимается?

Опять же, мой поинт в том что Scrum не гарантирует выработки метода. Если в процессе эксплуатации он у вас выработался - хорошо. Но я могу использовать Scrum не создавая новые методы, а используя существующие, хорошо себя зарекомендовавшие.

Эм.. Люди же =)

Как по мне - нет. Но это сугубо личное мнение. Выработка метода, для меня, это более сложная задача, чем компановка существующих