Igor
поэтому и трактуют как хочется гибкость же :DDD
Alex
🦠
АЖАЛЬ
Igor
на самом деле так не только в EPAM
Igor
нормальные ребята мне встречались редко в IQ Option например
Igor
если читать на английском там все понятно
Igor
ну еще и перевод первых редакций был так себе
Igor
Они кросс-функциональны: команда обладает всеми навыками, которые
необходимы для создания Инкремента Продукта. - вот эта формулировка на самом деле зло
Igor
с одной стороны человек который понимает agile ценности все сделает правильно
Almaz
Almaz
Igor
ее можно интерпритировать не правильно потому что команда может быть и группой индивидуумов которые все все умеют
Igor
потому как под командой воспринимается не сумма а каждый индивид по отдельности
Almaz
:) так нам не написано, тут уже все от индивидуального восприятия
Igor
в английской версии написано что девтим имеет все навыки чтобы как команда делать инкремент продукта
Igor
и это как раз таки сложнее интерпритировать не правильно
Igor
а восприятие у многих испорченное
Igor
Igor
и это прямо в скрамгайде написано
Igor
что можно 😞
Pavel
Pavel
Элементы убирать можно, главное очень четко понимать, зачем элемент был добавлен и какой бенефит будет от того, что его уберут.
Pavel
Там не говорится, что нельзя :)
Mikhail
Можно реализовывать его частично, но это уже нельзя будет назвать Скрамом как таковым
Vladimir
Scrum’s roles, events, artifacts, and rules are immutable
and although implementing only parts of Scrum is possible, the result is not Scrum.
Vladimir
Исключать можно, но уже не скрам будет.
Almaz
Pavel
Vladimir
Pavel
Я все-таки напомню, пока тут не разгорелся холивар:
1. Скрам - это фреймворк
2. Agile не заканчивается на скраме
Vladimir
Опять из-за разных контекстов чуть не начали спорить )
Pavel
Все-таки модель ШуХаРи и Tuckman model надо включить в скрам-гайд :)
Vladimir
Главное дойти до Ри )
Vladimir
и тогда можно все
Almaz
👍👍👌👌
Vladimir
Спасибо, что разрешили )
Pavel
Vladimir
Но религиозный подход вполне уместен на этапе Шу )
Pavel
Cynefin, кстати, в скрам и так включен, просто неявно :)
Almaz
Хммм. Каким образом? Что именно вам "мешает" в Скраме?
Almaz
Pavel
Pavel
Но я уже минимум дважды сталкивался с командами, которым мешали итерации.
Pavel
И не в смысле "мы не умеем ими пользоваться", а в смысле именно мешали, потому что полностью потеряли смысл.
Almaz
А как именно мешали?
Almaz
Итерации!
Pavel
именно.
Almaz
Так и не понял, как мешали?
Pavel
А как именно мешали?
существовали в альтернативной реальности по отношению к способности команды поставлять каждый PBI немедленно после готовности в прод.
Almaz
Инкремент должен быть готов к релизу в продакшн после каждого спринта, но не обязательно релизился. Это раз.
Релизить после каждой итерации хорошо, но не обязательно. Могут быть опред.расходы
Pavel
т.е. команда давно уже жила в single piece flow, давно умела работать с definition of ready так, что эстимейт терял смысл и deliery pipeline позволял выкатывать в прод изменения после каждого коммита.
Pavel
Vladimir
Наконец я узнал, что комынды описанные Гойко Аджичем действительно существуют
Pavel
И таки они релизили.
Almaz
Pavel
Всякие вещи типа "планирование спринта", "ревью итерации" и сама концепция итерации существовали сугубо в виде административных процедур :)
Pavel
Almaz
:)) можно провести спринт ретро и спросить команду. Попробовать анти-паттерны отменив их
Pavel
Кто мешает проводить ретро не итеративно?
Almaz
Almaz
Чтобы понять, что вы делаете именно то самое?
Pavel
Almaz
Usage index, customer satisfaction, ...
Pavel
Даже процент использования фич.
Almaz
Pavel
Только сразу скажу, чтоб не получлиось, что я себе чужие достижения приписываю: я эти команды именоо что знаю, я с ними не работаю :)
Almaz
Ок :)) если ивенты просто превратились в админ.события, то они/вы перестали понимать их смысл/значимость.
Almaz
Каждое событие нацелено на достижение высокого уровня прозрачности, для инспекции и адаптации после.
Pavel
Almaz
Ну может быть для вас это так...
Pavel
Pavel
Команда фокусируется на PBI.
Pavel
PO знает, что команда всегда работает по приоритетам