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

Расширяя горизонты

​​Дайджест 2020w40

📌 Как объяснить дедушке, что такое "фреймворк"

🎙 Чпуля межсезонная. Тыдыщ!

📄 Why No One Understands Agile, SCRUM & DevOps

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

📌 Планируемые изменения в Scrum Guide 2020

📌 Пример того как запрос в сообщество перерос в zoom-митап с прикладным характером и что из этого получилось = Kanban talks, о визуализации рабочих процессов

📽 Алексей Жеглов, Время в Канбан-системе – что мы о нём знаем и как использовать

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

©️ цитата от Павла Озолина

Про цитату от Павла - работа agile трансформатора она в длинную, на мой взгляд. Не за год и не за два весь выхлоп будет получен.

Так что как там кто считал - под вопросом )

Здравствуйте!
1. Когда проводите ретроспективы с генерацией идей и голосованием за идею,  вы фиксируете куда-то идеи, которые набрали минимум голосов и "не попали под реализацию"?
2. Нормальная ли практика модифицировать ряд фибоначчи, используемый для оценок историй, под себя? Сейчас используем ряд 0, 1, 2, 3, 5, 8 , 13, 20. Разработчики просят добавить оценку 10, т.к. при сложении оценок 5 и 5 сталкиваемся со сложностями (по некоторым задачам отдельно оцениваем бэк и фронт, затем складываем).

1.Да, обязательно. 2. Конечно, вай нот, главное чтобы все в команде понимали (а, фронт и бек не разделяем и не складываем).

1. Идеи не вошедшие в спринт остаются на борде, и в следующих ретроспективах участвуют в голосовании.
2. Не складываем оценки и не оцениваем отдельно бэк и фронт, так как в большинстве случаев эти задачи в отдельности не имеют ценности.

1. Это странная затея, потому что в следующем спринте должно болеть что-то другое, а фиксация будет работать как расфокусировка. 2 СП нельзя складывать бэк+фронт, смысл СП в оценке задачи целиком. Поэтому ответ в этом случае - нет, не делаем. Но по описанию у вас не СП, а значит можно и складывать

1. А мы записываем, но не фокусируемся на них. Чтобы не было эффекта, что твою идею вообще забыли

1. Фиксируйте только то, что пошло в работу, если что-то из того, что вы отложили горит, то оно само всплывает, но это скорее редкость
2. Складывать оценки плохая затея. Вы же оцениваеие должны фичи, а не из декомпозицию беку/фронту/бухгалтеру.

Дело в том, что бэкендеры могут не знать объем работ на фронте и наоборот

Так оцените вместе, в чем проблема?)

Смысл как раз в том, чтобы знали

Да, это пока открытый вопрос. Многие не хотят Т-шейпиться

Это не тишейпинг ни разу

Совместное владение кодом?

Это не открытый вопрос. Это вопрос зачем вам Скрам. Если структурировать работу отдельных товарищей, то ок, но некоторые конструкции тогда плохо применимы

Зачем им совместно владеть кодом? При чем тут тишейп? Вы просто оунриваеие вместе. Так и возможные проблемы узнаете заранее.

1. Как при чем? Бэкендер, который может оценивать работы по фронту, разве не Т-шейпд спец? 2. Ок, оцениваем вместе. Оценили бэкендеры в 5, а фронтендеры в 2, какая тогда в итоге?

Я рекомендовал оценить вместе. То есть дать фичу оценить вместе бекендеру и фронтендеру. А не только беку.

Пусть согласуют. Бек пояснит почему 5, фронт пояснит почему 2, придут у единой какой-то оценке