В нормально построенных процессах.

за качество :)

Если бы команда отвечала за продукт, то у нас бы все продукты были чисто консольные. Ну нам удобно, и работает всё.

решение - соответствует ли продукт требованиям должен принимать один человек, а не команда голосованием.

Если бы команда отвечала за продукт, то у нас бы все продукты были чисто консольные. Ну нам удобно, и работает всё.

Грустно, если вы работаете с такими людьми.

А если это человек - тестировщик, то слишком часто будет убыточный идеализм (не пущу, пока все баги не пофиксят)

решение - соответствует ли продукт требованиям должен принимать один человек, а не команда голосованием.

Да, это человек, который мержит релизбранч.

Продукт оунер тут не при чем.

мердж - это технический процесс, отвечает человек - который отдаёт команду - мерджи! И странно, если это тестировщик)

решение - соответствует ли продукт требованиям должен принимать один человек, а не команда голосованием.

правильно

но кто же?? Скрам мастер? Программист? Тестировщик? Админ гита?

Человек, который мержит что-то в мастер берет на себя ответственность за то, что то, что он мержит соответствует требованиям.

Человек, который мержит что-то в мастер берет на себя ответственность за то, что то, что он мержит соответствует требованиям.

Да глупости какие. Стрелочник-мержитолог?

Это могу быть я, может быть разработчик, может быть продуктовнер.

Сориян, это называется "команда делает продукт", а не "перекидываем мячик ответственности".

Демократия, ну хорошо)

мердж - это технический процесс, отвечает человек - который отдаёт команду - мерджи! И странно, если это тестировщик)

почему странно то? я проверил, подтвердил что все окей, мердж – деплой

Ну если чел что-то уточняет у команды это норм, но так то решение он же сам принимает (у нас это один человек который решает)

мердж и деплой на мне, и не только в моей команде, я знаю много примеров)

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

Ему так удобно?

мердж и деплой может и обезьяна сделать (сорри, автоматизированный скрипт), дело не в действии, а в решении.

Ему так удобно?

Ему удобно, команде нет.

очень интересно посмотреть, как скрипт будет мердж делать :)

Чьи интересы побеждают в таких диллемах? Правильно: команды.

ну мы командой решили, что мерджит и деплоит кто-то один, и все счастливы

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

интересы команды - ничерта не делать, получать з.п. и бухать пиво по вечерам)

Если есть траблы все ж могут их высказать

интересы команды - ничерта не делать, получать з.п. и бухать пиво по вечерам)

соболезную

интересы команды - ничерта не делать, получать з.п. и бухать пиво по вечерам)

Сорян, вы работаете в каких-то не тех командах.

QA это делать удобнее, чем кому-то другому, потому что можно доставлять фичи по мере поступления и проверки

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

если он неидеальный (ни у кого так не бывает, да?) - то задача ПО решать, пускаем так или работаем дальше.

Нет, это не задача ПО.

Задача ПО - быть центром бизнес-экспертизы в команде.

Всё.

Он не может кем-то руководить или что-то за кого-то решать.

А если он в это шурупит?

Решение о том, как деливерить принимает команда на основе той инфы, которая есть у команды и которую поставляет ПО.

Если инфы недостаточно для принятия решений - подтягивается бизнес-заказчик, для обсуждения рисков и всякого такого.

Назначить человека, который "ответственный за продукт" это как раз путь к "зачем думать о том, что льем в мастер, ПО виднее".

О я кажется вкурил

Shoo говорит о ПМ как о заказчике. А Alexei говорит о ПМ как о руководителе.

Оба кейса имеют место быть в жизнях.

ПО и ПМ это разные люди

в разных процессах

Ой, ПО да

я опечатался

речь была про ПО, ПО не руководит разработчиками и проектом и вообще никем

Оба кейса имеют место быть в жизнях.

это ж скрам, у него ж правила

тогда одно скрам, а другое нет, если и то и то имеет место быть

Shoo говорит о ПМ как о заказчике. А Alexei говорит о ПМ как о руководителе.

Я говорил о Product Owner как о части команды, который является представителем бизнеса внутри разработки.

это ж скрам, у него ж правила

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

но есть все-таки столпы у него

основа скрама – что все равны и руководителей нет :)

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

Вам врали :D

Да не, именитые скрум мастера говорили что если команда берет скрам и следует ему как есть, не подпиливая под себя, то всем грустно.

Задача ПО - быть центром бизнес-экспертизы в команде.

Ты путаешь, бизнес-экспертиза - это может быть и член команды

(бизнес-аналитик)

ПО это именно ответственный

цитата из ScaledScrum: The PO is the only team member who can accept stories as done. This includes validation that the story meets acceptance criteria and has the appropriate, persistent acceptance tests, and that it otherwise meets its Definition of Done. In so doing, the PO also fulfills a quality assurance function, focusing primarily on fitness for use.

Сори что прерываю) Ситуация: есть некий документ, после его сохранения с сервера приходит ответ: {"success":true,"ObjectId":12237,"duplicationIds":[]} Что нужно сделать: в c# получить id документа Тесты на c# + selenium И собственно вопрос: как?

Да не, именитые скрум мастера говорили что если команда берет скрам и следует ему как есть, не подпиливая под себя, то всем грустно.

если команда берет скрам и не понимает, зачем она его берет, то будут проблемы, это правда

Да не, именитые скрум мастера говорили что если команда берет скрам и следует ему как есть, не подпиливая под себя, то всем грустно.

Все подпиливают, слепой скрам не дает повышения производительности

Сори что прерываю) Ситуация: есть некий документ, после его сохранения с сервера приходит ответ: {"success":true,"ObjectId":12237,"duplicationIds":[]} Что нужно сделать: в c# получить id документа Тесты на c# + selenium И собственно вопрос: как?

ну json спарсить хочешь просто ?

спарси и все

о, вбросьте в чат как парсится json в сишарпе, интересно

ERROR: S client not available

Прям не загуглить даже

цитата из ScaledScrum: The PO is the only team member who can accept stories as done. This includes validation that the story meets acceptance criteria and has the appropriate, persistent acceptance tests, and that it otherwise meets its Definition of Done. In so doing, the PO also fulfills a quality assurance function, focusing primarily on fitness for use.

вот да мы все время показывали демо, помимо стейкхолдеров, ПО, и там уже решалось, оживлять или допилить

Все подпиливают, слепой скрам не дает повышения производительности

В чистом скраме почти ничего нет, что надо подпиливать. Там надо как на кость - мускулы наращивать, и конечно каждая команда - по своему.

В чистом скраме почти ничего нет, что надо подпиливать. Там надо как на кость - мускулы наращивать, и конечно каждая команда - по своему.

Мы обычно убираем все то что нам не подходит или не имеет смысла, пока не было проекта где стандартный скрам подходил

Прям не загуглить даже

спарсить не проблема. как в коде получить этот ответ?

По хорошему, ПО может много делегировать (тестировщикам, лидам, команде) - тем не менее он - ответсвенный.

Мы обычно убираем все то что нам не подходит или не имеет смысла, пока не было проекта где стандартный скрам подходил

Например. Что убираете?

спарсить не проблема. как в коде получить этот ответ?

эм, спарсить json и вытащить, чувак, тебе на stackoverflow

Например. Что убираете?

утренние стендапы

в одном

утренние стендапы

В скаме нет утренних стендэапов. Только ежедневные.

А мне утренние нравятся

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

По хорошему, ПО может много делегировать (тестировщикам, лидам, команде) - тем не менее он - ответсвенный.

Прагматично например иметь договоренность, если команда находит блокеры, то без всякого ПО понятно, что не релизим, или наоборот - если всё вообще по плану - то релизим. Но когда есть несколько мнений - решает не команда, а ПО.

в текущем скрам-гайде не нашел дословно, только намёками: If part of the work is potentially releasable, the Product Owner typically accepts it.

намёк на то, что может и не accept.

мердж - это технический процесс, отвечает человек - который отдаёт команду - мерджи! И странно, если это тестировщик)

зависит от контекста. В одной конторе, где я работал, таким тестировщиком был я.

мердж - это технический процесс, отвечает человек - который отдаёт команду - мерджи! И странно, если это тестировщик)

сейчас работаю в такой роли, всё окей.

в текущем скрам-гайде не нашел дословно, только намёками: If part of the work is potentially releasable, the Product Owner typically accepts it.

Я видимо читаю какой-то другой скрам гайд, потому что согласно моему задачей PO является формирование критериев Definitions of Done и донесение value задач до Developers Team.

При этом инкремент в продукте может делать участник developer team, что как бы намекает нам на отстуствие здесь боттлнека и какого-то центра решения у PO.

do и accept - две большие разницы

http://www.scrumguides.org/scrum-guide.html

Есть ещё замечательная оговорка про: > This Increment is useable, so a Product Owner may choose to immediately release it. Что как бы говорит про принятие решений о релизе продукт овнером, с одной поправкой.

А почему вы думаете что скрум гайд написан идеальными богами и в нем не может быть идеологических косяков?

Тем более что это все сильно зависит от человеческой ментальности

западники вообще сильны в коллективной ответственности, а у нас наоборот все хотят ответственность переложить на ПО

http://www.scrumguides.org/scrum-guide.html

http://www.scrumguides.org/docs/scrumguide/v2016/2016-Scrum-Guide-US.pdf Не нашел там строчки, на которую ты ссылался, но возможно я плохо пользуюсь cmd+f

В прочем whatever. Если кому-то комфортнее делигировать ответственность за продукт на "начальника, которому виднее" - ваше право.

Мне комфортнее, когда команда понимает что и зачем она делает. И здесь роль продукт овнера это формировать definitions of done для команды, а не валидировать их.

я так смотрю у вас уважаемые в почти стандартное время споры возникают - с 14 до 16 и с 19 до 22 походу еда как то негативно действует

я не вижу в двух абзацах противоречия. Команда - понимает, ПО - ответственный)