Igor
поэтому и трактуют как хочется гибкость же :DDD
🦠
АЖАЛЬ
Igor
на самом деле так не только в EPAM
Igor
нормальные ребята мне встречались редко в IQ Option например
Alex
поэтому и трактуют как хочется гибкость же :DDD
Ну вот, как бы, имеем что имеем. Вы же согласны, что однозначную формулировку нельзя трактовать неоднозначно?
Igor
Ну вот, как бы, имеем что имеем. Вы же согласны, что однозначную формулировку нельзя трактовать неоднозначно?
проблема вытекает из того что многие если и додумаются прочитать скрамгайд делают это на русском. а у нас в языке очень много слов у которых больше одного значения
Igor
если читать на английском там все понятно
Igor
ну еще и перевод первых редакций был так себе
Igor
Они кросс-функциональны: команда обладает всеми навыками, которые необходимы для создания Инкремента Продукта. - вот эта формулировка на самом деле зло
Igor
с одной стороны человек который понимает agile ценности все сделает правильно
Igor
ее можно интерпритировать не правильно потому что команда может быть и группой индивидуумов которые все все умеют
Igor
потому как под командой воспринимается не сумма а каждый индивид по отдельности
Almaz
:) так нам не написано, тут уже все от индивидуального восприятия
Igor
в английской версии написано что девтим имеет все навыки чтобы как команда делать инкремент продукта
Igor
и это как раз таки сложнее интерпритировать не правильно
Igor
а восприятие у многих испорченное
Pavel
я когда на собеседовании в EPAM был, оказалось ребята внедрают скрам но скрамгайд не читали
Очень удивлён. Все SM из EPAM, с которыми мне довелось пересекаться - очень глубоко знают и понимают скрам в частности и agile в целом :)
Igor
и это прямо в скрамгайде написано
Igor
что можно 😞
Pavel
Элементы убирать можно, главное очень четко понимать, зачем элемент был добавлен и какой бенефит будет от того, что его уберут.
Almaz
и это прямо в скрамгайде написано
Где именно написано? Там как раз говориться что нельзя! Immutable
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
Исключать можно, но уже не скрам будет.
Vladimir
:)))
😕
Pavel
Я все-таки напомню, пока тут не разгорелся холивар: 1. Скрам - это фреймворк 2. Agile не заканчивается на скраме
Vladimir
Опять из-за разных контекстов чуть не начали спорить )
Pavel
Все-таки модель ШуХаРи и Tuckman model надо включить в скрам-гайд :)
Almaz
Все-таки модель ШуХаРи и Tuckman model надо включить в скрам-гайд :)
Зачем? Скрам же не методология, а именно как коллеги это фреймворк, контейнер для различных подходов и практик.
Vladimir
Зачем? Скрам же не методология, а именно как коллеги это фреймворк, контейнер для различных подходов и практик.
Павел как раз говорит что на скраме аджайл не заканчивается. Да, уже не скрам, но вполне таки аджал... может остаться
Vladimir
Главное дойти до Ри )
Almaz
Все-таки модель ШуХаРи и Tuckman model надо включить в скрам-гайд :)
Даже если включили бы, что это дало бы и чего помогло бы избежать? Что на счет модели док. Белбина и фреймворка Кеневина?! Их тоже надо включить, если следовать логике.
Vladimir
и тогда можно все
Almaz
👍👍👌👌
Vladimir
Спасибо, что разрешили )
Pavel
Даже если включили бы, что это дало бы и чего помогло бы избежать? Что на счет модели док. Белбина и фреймворка Кеневина?! Их тоже надо включить, если следовать логике.
Это помогло бы избежать религиозного подхода к тому, что такое скрам и что из него "можно" или "нельзя" исключать
Vladimir
Но религиозный подход вполне уместен на этапе Шу )
Pavel
Cynefin, кстати, в скрам и так включен, просто неявно :)
Almaz
Хммм. Каким образом? Что именно вам "мешает" в Скраме?
Almaz
Pavel
Но я уже минимум дважды сталкивался с командами, которым мешали итерации.
Pavel
И не в смысле "мы не умеем ими пользоваться", а в смысле именно мешали, потому что полностью потеряли смысл.
Almaz
А как именно мешали?
Almaz
Итерации!
Pavel
именно.
Almaz
Так и не понял, как мешали?
Pavel
А как именно мешали?
существовали в альтернативной реальности по отношению к способности команды поставлять каждый PBI немедленно после готовности в прод.
Almaz
Инкремент должен быть готов к релизу в продакшн после каждого спринта, но не обязательно релизился. Это раз. Релизить после каждой итерации хорошо, но не обязательно. Могут быть опред.расходы
Pavel
т.е. команда давно уже жила в single piece flow, давно умела работать с definition of ready так, что эстимейт терял смысл и deliery pipeline позволял выкатывать в прод изменения после каждого коммита.
Vladimir
Наконец я узнал, что комынды описанные Гойко Аджичем действительно существуют
Pavel
И таки они релизили.
Pavel
Всякие вещи типа "планирование спринта", "ревью итерации" и сама концепция итерации существовали сугубо в виде административных процедур :)
Pavel
Хммм. Это никоим образом ничему не противоречат. Скорее в плюс, time-2-market
Не противоречат. А в чем их ценность в такой системе?
Almaz
:)) можно провести спринт ретро и спросить команду. Попробовать анти-паттерны отменив их
Pavel
Кто мешает проводить ретро не итеративно?
Almaz
Чтобы понять, что вы делаете именно то самое?
Pavel
Чтобы понять, что вы делаете именно то самое?
Вагон метрик, все связаны с продуктом :)
Almaz
Usage index, customer satisfaction, ...
Pavel
Даже процент использования фич.
Pavel
Только сразу скажу, чтоб не получлиось, что я себе чужие достижения приписываю: я эти команды именоо что знаю, я с ними не работаю :)
Almaz
Ок :)) если ивенты просто превратились в админ.события, то они/вы перестали понимать их смысл/значимость.
Almaz
Каждое событие нацелено на достижение высокого уровня прозрачности, для инспекции и адаптации после.
Almaz
Ну может быть для вас это так...
Pavel
Ну может быть для вас это так...
Для команд - однозначно так.
Pavel
Команда фокусируется на PBI.
Pavel
PO знает, что команда всегда работает по приоритетам