JP
Ну тогда ладно
Size: a a a
2020 April 20
DN
An increment is a body of inspectable, done work that supports empiricism at the end of the Sprint. The increment is a step toward a vision or goal.
Да, 👍 кусок работы который нас приближает к конечной цели. И этот кусок должен быть работоспособным. Вопрос в следующем, определение работающего куска «инкремента» согласовывается на кикоффе с заказчиком или вытекает из обсуждения с командой? Ведь ценных в перспективе, инкрементов для общей цели в спринте много может быть, а клиенту нужен именно работающий.
VR
Обсуждается, конечно. Попробуйте, не обсудите с заказчиком, что ему давать )
DN
:)
JS
Добрый день! У кого-то есть понимание,когда мы вновь перейдём с удаленки в офис?
V
на днях
ДШ
Dark Ness
Да, 👍 кусок работы который нас приближает к конечной цели. И этот кусок должен быть работоспособным. Вопрос в следующем, определение работающего куска «инкремента» согласовывается на кикоффе с заказчиком или вытекает из обсуждения с командой? Ведь ценных в перспективе, инкрементов для общей цели в спринте много может быть, а клиенту нужен именно работающий.
определение работающего куска «инкремента» - вытекает из планирования спринта, чтобы реализовать инкремент, не всегда нужно код писать. Вы формулируете цель, потом обсуждаете метод ее достижения, возможно на бумажке нарисуете что-то. Потом обсуждаете метрики, как вы поймете что цели достигли с помощь. вашей бумажки. Сможете проверить, значит инкремент работающий)
VR
Работает = даёт обратную связь, т.е. инфу куда идти дальше.
DN
определение работающего куска «инкремента» - вытекает из планирования спринта, чтобы реализовать инкремент, не всегда нужно код писать. Вы формулируете цель, потом обсуждаете метод ее достижения, возможно на бумажке нарисуете что-то. Потом обсуждаете метрики, как вы поймете что цели достигли с помощь. вашей бумажки. Сможете проверить, значит инкремент работающий)
👍
ДШ
Работает = даёт обратную связь, т.е. инфу куда идти дальше.
👌
V
Коллеги, всем привет. То и дело сталкиваюсь в работе сспрактикой, когда одна команда пилит продукт с использованием нескольких систем. Как следствие, есть разрабы-спецы по 1 системе и по второй. Задачи часто просто не пересекаются, но важны для поставки инкремента. Внимание вопрос к знатокам - как производить оценку таких задачь? Только с теми участниками, кто смыслит в конкретной системе + тестирование? Буду признателен за кейсы и помощь.
V
а зачем проводить оценку с участием других разработчиков, которые в системе не шарят?
N
Vsevolod
Коллеги, всем привет. То и дело сталкиваюсь в работе сспрактикой, когда одна команда пилит продукт с использованием нескольких систем. Как следствие, есть разрабы-спецы по 1 системе и по второй. Задачи часто просто не пересекаются, но важны для поставки инкремента. Внимание вопрос к знатокам - как производить оценку таких задачь? Только с теми участниками, кто смыслит в конкретной системе + тестирование? Буду признателен за кейсы и помощь.
не совсем понятно - задачи не пересекаются или все же зависят друг от друга?
V
Не, не пересекаются
V
Те, которые пересекаются оцениваем вместе )
N
тогда не вижу повода для вопроса. Задачи разные. Инкремент разный, зависимости нет... Оценить то можно и вместе - в штатной процедуре оценки нет ничего сложного, но на вопрос "почему именно столько" ответят только специалисты.
V
Спасибо. Хотел убедиться, что мой разум нашёл то же решение, что и коллективный)
MP
Vsevolod
Спасибо. Хотел убедиться, что мой разум нашёл то же решение, что и коллективный)
Будьте осторожны. Вы пришли в аджай-чатик с аджайл-ворпросом и получили пиэмский ответ
MP
если он вас устраивает, то и хорошо
V
Михаил, спасибо. Я логикой понимаю, что надо шарить компетенции, т-шейп и т.д. но команда пока не т-шейп ) буду очень благоларен, если дадите agile ответ на этот вопрос. Так как я пока не понимаю, как может разраб, не понимающий вдругой системе дать оценку работы. Пришёл сюда за agile мудростью )