Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Работа Новый топик    Ответить
Топик располагается на нескольких страницах: ←Ctrl  назад   1 .. 15 16 17 18 19 20 [21] 22 23 24   вперед  Ctrl→
 Re: Агиле/Скрам или прессинг . Part 2.  [new]
Дмитрий Мух
Member

Откуда: Зеленоград
Сообщений: 3820
Андрей Панфилов↑
skyANA↑
пропущено...

+1

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


т.е. в "военное время" можно просто взять и ослабить этот definition of done несмотря на то, что это вполне недвусмысленное требования заказчика, как так?

Что-то вы не в тему сюда definition of done и заказчика приплетаете.
Речь-то была о том, что люди у себя там между командами договорились отписываться по завершению таска в трекере, статус там менять с комментариями.
То есть приняли определённые правила взаимодействия (игры).

И вот кто-то эти правила систематически не соблюдает. То есть они не работают.

Что делать? Либо тупо отменить (они же итак не работают), либо пересмотреть так, чтобы процесс заработал.

У вас какие-то иные предложения? Высскажите их, глядишь поможете Eleanor.
24 ноя 19, 19:36    [22024100]     Ответить | Цитировать Сообщить модератору
 Re: Агиле/Скрам или прессинг . Part 2.  [new]
Андрей Панфилов
Member

Откуда: Москва > Melbourne
Сообщений: 3812
Дмитрий Мух↑

Definition of done - это набор критериев, выполнение которых говорит о том, что цель достигнута.

Что такое "слабый" definition of done? И почему он "слабый"? Что мешает определить "сильные" критерии?
Мне казалось вам лучше знать что такое "слабый", в вашей же библии пишут, а не в моей:
less
A Definition of Done is weak when it is a small subset and strong when it is almost equals Potentially Shippable. The teams discuss their context and select the subset of the activities that all teams think they realistically can do during the Sprint.
24 ноя 19, 20:06    [22024117]     Ответить | Цитировать Сообщить модератору
 Re: Агиле/Скрам или прессинг . Part 2.  [new]
Андрей Панфилов
Member

Откуда: Москва > Melbourne
Сообщений: 3812
Дмитрий Мух↑

Что-то вы не в тему сюда definition of done и заказчика приплетаете.
Как это не в тему, написано же - корпоративный регламент:
Eleanor↑

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

Претензии не к регламенту, т.к. все команды в компании, кроме одной с ним справляются:
не только отписываются после выполнения каждого пункта, но и "ответственный за оповещения о ходе работ" сообщает о начале и завершении задачи в целом и пинает тех, кто не отвечает. Здесь молчит и команда и ответственный.

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

Отказаться от оповещений не вариант, т.к. от них зависит работа других команд.

Теперь надежда на ретроспективу, где будет их менеджер.

Согласно же вашей библии такое "оповещение" должно быть включено в definition of done, вы же заявляете, что раз не получается соблюдать, то можно забить.
24 ноя 19, 20:11    [22024121]     Ответить | Цитировать Сообщить модератору
 Re: Агиле/Скрам или прессинг . Part 2.  [new]
WebSharper
Member

Откуда:
Сообщений: 569
Андрей Панфилов↑
прозрачность, инспекция, адаптация; а в другом случае мы заявляем, что вот есть лазейка в виде definition of done, которая явно не описана,


Она много где явно описана, например вот.
Еще бывает DoD по отношению к разным этапам, например, "PBI не передается на тестирование, пока не прошел code review".

и на этот definition of done можно списать что угодно
(условно у нас не Ракеш с Кумаром плохой код пишут, а это у команды "слабый" definition of done, это не product owner творит дичь, а "слабый" definition of done, и т.п.),


Команда сама принимает definition of done. Такой, который помогает ей достигать цели спринтов.


при этом ваш "коллега по цеху" придерживается несколько другого мнения:


А где вы видите логическое противоречие?

т.е. в "военное время" можно просто взять и ослабить этот definition of done несмотря на то, что это вполне недвусмысленное
требования заказчика, как так?


Требование заказчика к конкретному PBI это acceptance criteria. DoD это общие требования для всего вместе, которые принимаются командой, но могут отражать какие-то общие требования заказчика.

PO решает что нужно делать, команда, как нужно делать. Команда может ошибиться и это не будет противоречить скраму. Например отменить code review не скомпенсировав ничем и полезут баги.

Вас же спросили про характеристики продукта, а вы в очередной раз уходите в сторону метрик кода.


Я ухожу? Это ТС сказал:

mirudom↑

это Вы отвечаете на поставленный мной вопрос о качестве кода, правильно ?


Я пытаюсь понять, что он имел ввиду, и вообще это какой-то отдельный вопрос или часть того, что его интересовало вначале "место на ретроспективе".

У меня сложилось впечатление, что на самом деле его вопрос не интересует, а он ищет к чему прицепиться, не находит и перестает интересоваться темой пока ему в голову не приходит идея зайти с другого неожиданного ракурса. Впрочем, мое впечатление может быть ложной.
24 ноя 19, 20:12    [22024123]     Ответить | Цитировать Сообщить модератору
 Re: Агиле/Скрам или прессинг . Part 2.  [new]
Дмитрий Мух
Member

Откуда: Зеленоград
Сообщений: 3820
Андрей Панфилов↑
Согласно же вашей библии такое "оповещение" должно быть включено в definition of done, вы же заявляете, что раз не получается соблюдать, то можно забить.

Пфффф...

Я не заявляю, что если не получается соблюдать, то можно забить. Где вы это прочитали?

Я согласен с softwarer, что в такой ситуации следует провести встречу и рассмотреть этот вопрос.
Понять, почему договорённость не соблюдается, даже после того как приняли предложения самой команды, что их не соблюдает.
И решить что делать.

А вы что предлагаете? Увольнять? Штрафовать? Что?
24 ноя 19, 20:20    [22024133]     Ответить | Цитировать Сообщить модератору
 Re: Агиле/Скрам или прессинг . Part 2.  [new]
Дмитрий Мух
Member

Откуда: Зеленоград
Сообщений: 3820
Андрей Панфилов↑
Дмитрий Мух↑

Что-то вы не в тему сюда definition of done и заказчика приплетаете.
Как это не в тему, написано же - корпоративный регламент

И при чём тут корпоративный регламент?

Простыми словами definition of done отвечает на вопрос "Что мы считаем тем, что задача сделана?".

Например в вашей заказной разработке это может быть нечто следующее:
- Перечисленные пункты ТЗ (спецификации) реализованы;
- Код прошёл ревью;
- Покрыт тестами и они успешно выполнены;
- Документация написана;
- Заказчик увидел результат и хоть раз попробовал и убедился в работе решения.
24 ноя 19, 20:27    [22024139]     Ответить | Цитировать Сообщить модератору
 Re: Агиле/Скрам или прессинг . Part 2.  [new]
Дмитрий Мух
Member

Откуда: Зеленоград
Сообщений: 3820
WebSharper↑
У меня сложилось впечатление, что на самом деле его вопрос не интересует, а он ищет к чему прицепиться

Аналогичное впечатление. Я о нём уже писал выше.
24 ноя 19, 20:29    [22024140]     Ответить | Цитировать Сообщить модератору
 Re: Агиле/Скрам или прессинг . Part 2.  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 64862
Блог
Дмитрий Мух↑
Я согласен с softwarer, что в такой ситуации следует провести встречу и рассмотреть этот вопрос.

Не "с softwarer", а "со словами softwarer о рекомендованном для гибких команд способе действий в такой ситуации". Лично softwarer не считает проведение встречи эффективным способом решения проблем.
25 ноя 19, 01:56    [22024233]     Ответить | Цитировать Сообщить модератору
 Re: Агиле/Скрам или прессинг . Part 2.  [new]
Андрей Панфилов
Member

Откуда: Москва > Melbourne
Сообщений: 3812
WebSharper↑

Требование заказчика к конкретному PBI это acceptance criteria. DoD это общие требования для всего вместе, которые принимаются командой, но могут отражать какие-то общие требования заказчика.
Вы что-то путаете. Требование заказчика - это полученный в срок работающий продукт за указанные деньги, все ваши спринты, бэклоги и прочие ритуалы, т.ч. acceptance criteria - это внутренняя кухня исполнителя, из которой наружу торчит только договоренность периодически показывать что-то кому-то.

WebSharper↑
Команда сама принимает definition of done. Такой, который помогает ей достигать цели спринтов.
На мой взгляд вы в очередной раз жонглируете понятиями. Вот тут пишут:
less
Scrum’s inspect-adapt cycles require transparency in order to be effective. Formally defining the meaning of ‘done’ reduces variability and the likelihood of undone work and measuring progress unambiguously (‘done’ or ‘not done’) increases transparency.

A perfect Definition of Done includes everything that the organization has to do to deliver the product to customers. Achieving this should be relatively easy for a one-team product group. When the team isn’t able to achieve the perfect Definition of Done then they define ‘done’ as a subset of the perfect set. The team’s goal is to improve so that, one day, their Definition of Done is perfect and they can ship each Sprint or more.

The Definition of Done is an agreed list of criteria that the software will meet for each Product Backlog Item. Achieving this level of completeness requires the Team to perform a list of tasks. When all tasks are completed, the item is done. Don’t confuse the Definition of Done with acceptance criteria, which are specific conditions an individual item has to fulfill to be accepted. The Definition of Done applies uniformly to all Product Backlog items.
Т.е. в книжке пишут, что definition of done - помогает измерить готовность продукта, и в пределе оно должно соответствовать критериям, которые предъявляет экспуатант, т.е. в пределе наличие самодеятельности не предполагается, вы же пишете, что оно каким-то образом "помогает достигать цели" и при его формировании допустима анархия.

WebSharper↑
Вас же спросили про характеристики продукта, а вы в очередной раз уходите в сторону метрик кода.
Я ухожу? Это ТС сказал...
там же (на первых двух страницах) диалог следующий:
mirudom↑
Подскажите пожалуйста, есть ли в Вашем окончании итерации, т.е. Ретроспективе, место для оценки
технических характеристик полученного продукта ( кода или ... ) ?
Ежели такое место есть - укажите пожалуйста.
что-то про SLA и ITSM, которые вообще из Operations, а не Transition
mirudom↑
это Вы отвечаете на поставленный мной вопрос о качестве кода, правильно ?
Дмитрий Мух↑
вы не поставили вопрос о качестве кода
вы спрашивали, есть ли место на Ретроспективе для оценки технических характеристик продукта

если вас интересует именно качество кода, то сформулируйте соответсвующий вопрос
Потом мы вроде как выяснили, что на ретроспективе оценивается процесс, а не продукт:
Дмитрий Мух↑
Андрей Панфилов↑
нужно регулярно проводить ретроспективу чтобы улучшить процессы (прошу заменить, что именно процессы, а не продукт)

Да, цель ретроспективы итерации - улучшить процесс.

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



WebSharper↑
Я пытаюсь понять, что он имел ввиду, и вообще это какой-то отдельный вопрос или часть того, что его интересовало вначале "место на ретроспективе".

У меня сложилось впечатление, что на самом деле его вопрос не интересует, а он ищет к чему прицепиться, не находит и перестает интересоваться темой пока ему в голову не приходит идея зайти с другого неожиданного ракурса. Впрочем, мое впечатление может быть ложной.
На мой взгляд ждут ответа в духе: скрам - это не про сроки, бюджеты и качество, а про "гибкость".
25 ноя 19, 05:58    [22024256]     Ответить | Цитировать Сообщить модератору
 Re: Агиле/Скрам или прессинг . Part 2.  [new]
Дмитрий Мух
Member

Откуда: Зеленоград
Сообщений: 3820
softwarer↑
Дмитрий Мух↑
Я согласен с softwarer, что в такой ситуации следует провести встречу и рассмотреть этот вопрос.

Не "с softwarer", а "со словами softwarer о рекомендованном для гибких команд способе действий в такой ситуации". Лично softwarer не считает проведение встречи эффективным способом решения проблем.

Хорошо. У softwarer есть своё предложение о том, как эффективно решить описанную Eleanor проблему?
25 ноя 19, 10:06    [22024348]     Ответить | Цитировать Сообщить модератору
 Re: Агиле/Скрам или прессинг . Part 2.  [new]
Eleanor
Member

Откуда:
Сообщений: 3196
 		Проблемы нет. Нужно было просто проговорить ее и всё.
25 ноя 19, 10:15    [22024360]     Ответить | Цитировать Сообщить модератору
 Re: Агиле/Скрам или прессинг . Part 2.  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 64862
Блог
Дмитрий Мух↑
У softwarer есть своё предложение о том, как эффективно решить описанную Eleanor проблему?

softwarer не до конца эту проблему понимает, но в целом привык считать эффективным методом "автоматизировать то, что автоматизируется, а в том, что не автоматизируется, выстроить процесс таким образом, чтобы человеку (или команде) было легко, удобно и выгодно ему следовать и тяжело, сложно и дорого его нарушать".

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

Если проблема в том, что люди не ставят статусы в трекере, нужно сделать этот статус необходимой частью процесса. Например, автоматизировать сборку и загребать в неё только задачи с заданным статусом. Например, при расчёте всяких метрик и KPI считать только задачи в этом статусе. Технически ограничить возможность брать в работу новые задачи при незакрытых старых. Детектировать задачи, висящие в предфинальном статусе без движения, и начать задалбывать ежедневными сообщениями "пора закрыть задачу X". В конце концов, поставить сумму премии в зависимость от чёткости и своевременности закрытия задач. В общем, способ или комбинацию способов, подходящих к ситуации, найти можно.
25 ноя 19, 10:27    [22024378]     Ответить | Цитировать Сообщить модератору
 Re: Агиле/Скрам или прессинг . Part 2.  [new]
Дмитрий Мух
Member

Откуда: Зеленоград
Сообщений: 3820
softwarer↑
Дмитрий Мух↑
У softwarer есть своё предложение о том, как эффективно решить описанную Eleanor проблему?

softwarer не до конца эту проблему понимает, но в целом привык считать эффективным методом "автоматизировать то, что автоматизируется, а в том, что не автоматизируется, выстроить процесс таким образом, чтобы человеку (или команде) было легко, удобно и выгодно ему следовать и тяжело, сложно и дорого его нарушать".

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

Если проблема в том, что люди не ставят статусы в трекере, нужно сделать этот статус необходимой частью процесса. Например, автоматизировать сборку и загребать в неё только задачи с заданным статусом. Например, при расчёте всяких метрик и KPI считать только задачи в этом статусе. Технически ограничить возможность брать в работу новые задачи при незакрытых старых. Детектировать задачи, висящие в предфинальном статусе без движения, и начать задалбывать ежедневными сообщениями "пора закрыть задачу X". В конце концов, поставить сумму премии в зависимость от чёткости и своевременности закрытия задач. В общем, способ или комбинацию способов, подходящих к ситуации, найти можно.

И вот это всё сделать никому не сказав, ни кому не сообщив, в одностороннем порядке?
Или всё-таки сначала некий proposal оформить, advice process запустить? В письменном виде.
25 ноя 19, 10:45    [22024389]     Ответить | Цитировать Сообщить модератору
 Re: Агиле/Скрам или прессинг . Part 2.  [new]
Дмитрий Мух
Member

Откуда: Зеленоград
Сообщений: 3820
Eleanor↑
Проблемы нет. Нужно было просто проговорить ее и всё.
Круто.

То есть scrum-команда заработала, поговорив с утёнком :)
25 ноя 19, 10:46    [22024393]     Ответить | Цитировать Сообщить модератору
 Re: Агиле/Скрам или прессинг . Part 2.  [new]
Дмитрий Мух
Member

Откуда: Зеленоград
Сообщений: 3820
Андрей Панфилов↑
На мой взгляд ждут ответа в духе: скрам - это не про сроки, бюджеты и качество, а про "гибкость".

Сроки соблюдены. Чистая прибыль выше плана на 11,4%. Качество на уровне. Артели используют Scrum.

Что не так?

Может поступим как японцы.
Рассмотрим успешные компании, где практикуется Agile и Scrum, и попытаемся понять что там про что, а?
25 ноя 19, 10:51    [22024398]     Ответить | Цитировать Сообщить модератору
 Re: Агиле/Скрам или прессинг . Part 2.  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 64862
Блог
Дмитрий Мух↑
И вот это всё сделать никому не сказав, ни кому не сообщив, в одностороннем порядке? Или всё-таки сначала некий proposal оформить, advice process запустить? В письменном виде.

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

Сообщение было отредактировано: 25 ноя 19, 22:57
25 ноя 19, 22:12    [22025067]     Ответить | Цитировать Сообщить модератору
 Re: Агиле/Скрам или прессинг . Part 2.  [new]
Андрей Панфилов
Member

Откуда: Москва > Melbourne
Сообщений: 3812
Дмитрий Мух↑
Андрей Панфилов↑
На мой взгляд ждут ответа в духе: скрам - это не про сроки, бюджеты и качество, а про "гибкость".

Сроки соблюдены. Чистая прибыль выше плана на 11,4%. Качество на уровне. Артели используют Scrum.

Что не так?

Может поступим как японцы.
Рассмотрим успешные компании, где практикуется Agile и Scrum, и попытаемся понять что там про что, а?
Т.е. я правильно понял, что если завтра, к примеру, Безос разоткровенничается и расскажет что они по пятницам практикуют садо-мазо вечеринки, то в тот же день зеленоградская артель опустошит ближайший секс-шоп? Вообще тут как в байке про то, использует ли гугл php, вопрос же не в том, что использует кто-то скрам или нет, а в применимости методологии в данном конкретном случае, или вы на 100% уверены что в том же гугле народ не просто почерпнул некие идеи и решил их использовать, а вот прямо на 100% следует библии? Мне вот как-то кажется, что, учитывая ставки инженеров в "успешных компаниях", выбор методологии разработки - это никакой не решающий фактор.
26 ноя 19, 08:47    [22025193]     Ответить | Цитировать Сообщить модератору
 Re: Агиле/Скрам или прессинг . Part 2.  [new]
Дмитрий Мух
Member

Откуда: Зеленоград
Сообщений: 3820
Андрей Панфилов↑
Дмитрий Мух↑
пропущено...

Сроки соблюдены. Чистая прибыль выше плана на 11,4%. Качество на уровне. Артели используют Scrum.

Что не так?

Может поступим как японцы.
Рассмотрим успешные компании, где практикуется Agile и Scrum, и попытаемся понять что там про что, а?
Т.е. я правильно понял...

Нет, вы поняли опять на свой лад и сделали свои, не понятно на чём, основанные выводы.

Вот мы делаем успешный продукт: "Wild Apricot".
Это SaaS, где нет заказчика, что выставит требования, нет специально обученных людей, кто формализует эти требования и оформит в виде чёткого и понятного ТЗ (спецификации), распишет в виде задач в Jira - сиди и делай.
А есть мы, разбившиеся на команды (называем их артелями), по интересам - областям в продукте.
И каждая артель в своей области занимается и и исследованием, и сбором требований, и анализом, проектированием, разрботкой, тестированием, выкаткой, сбором обратной связи.
То есть полным циклом разработки своей части большой системы "Wild Apricot".

И артели используют Scrum. А я готов и пытаюсь рассказать как.

Думаю не я один тут такой: из успешной продуктовой компании, практикующей Agile, Lean, Scrum, DevOps.

И не нужен нам тут Безос и его Amazon, и Google не нужен. Куда вас, ей богу, понесло? :)
26 ноя 19, 10:45    [22025293]     Ответить | Цитировать Сообщить модератору
 Re: Агиле/Скрам или прессинг . Part 2.  [new]
Дмитрий Мух
Member

Откуда: Зеленоград
Сообщений: 3820
softwarer↑
Дмитрий Мух↑
И вот это всё сделать никому не сказав, ни кому не сообщив, в одностороннем порядке? Или всё-таки сначала некий proposal оформить, advice process запустить? В письменном виде.

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

Окей. Вот только эта ваша работа не решила бы проблему Eleanor, если подумать.
26 ноя 19, 10:46    [22025295]     Ответить | Цитировать Сообщить модератору
 Re: Агиле/Скрам или прессинг . Part 2.  [new]
Дмитрий Мух
Member

Откуда: Зеленоград
Сообщений: 3820
 		У хороших руководителей видимо не принято погружаться в проблемы коллектива Картинка с другого сайта.
26 ноя 19, 10:47    [22025296]     Ответить | Цитировать Сообщить модератору
 Re: Агиле/Скрам или прессинг . Part 2.  [new]
DaniilSeryi
Member

Откуда:
Сообщений: 1758
Дмитрий Мух↑
У хороших руководителей видимо не принято погружаться в проблемы коллектива Картинка с другого сайта.


Хороший руководитель - вещь редкая. Да ещё и мутируют частенько в ох#$%евших рукойводителей, к сожалению.
А уж лидеры - нет сынок, их не существует, это фантастика!
26 ноя 19, 12:09    [22025442]     Ответить | Цитировать Сообщить модератору
 Re: Агиле/Скрам или прессинг . Part 2.  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 64862
Блог
Дмитрий Мух↑
Окей. Вот только эта ваша работа не решила бы проблему Eleanor, если подумать.

Конечно. Её решат только встречи и совещания
26 ноя 19, 12:30    [22025481]     Ответить | Цитировать Сообщить модератору
 Re: Агиле/Скрам или прессинг . Part 2.  [new]
skyANA
Member

Откуда: Зеленоград
Сообщений: 28368
softwarer↑
Дмитрий Мух↑
Окей. Вот только эта ваша работа не решила бы проблему Eleanor, если подумать.

Конечно. Её решат только встречи и совещания Картинка с другого сайта.

Давайте без только. Только это ваше. Только то как считает softwarer, является наиболее эффективным :)
26 ноя 19, 13:22    [22025565]     Ответить | Цитировать Сообщить модератору
 Re: Агиле/Скрам или прессинг . Part 2.  [new]
WebSharper
Member

Откуда:
Сообщений: 569
Андрей Панфилов↑
WebSharper↑

Требование заказчика к конкретному PBI это acceptance criteria. .
Вы что-то путаете. Требование заказчика - это полученный в срок работающий продукт за указанные деньги,


Продукт это продукт, требования - это требования. Частью описания может быть то, как убедиться в том, что они выпонены. Я согласен, что в AC могут быть не только требования заказчика, но они там должны как-то отражаться, если на эти требоания согласились.

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


AC могут как торчать наружу так и не торчать.

WebSharper↑
Команда сама принимает definition of done.
На мой взгляд вы в очередной раз жонглируете понятиями. Вот тут пишут:


Вы цитируете текст из less - надстройкой над SCRUM для координации работы нескольких команд.
Там ниже есть раздел определений:

Definition of Done terms
Definition of Done—An agreement between the teams and the Product Owner on which activities are performed inside the Sprint. A Definition of Done is perfect when it equals to Potentially Shippable. The teams strive to improve towards a perfect Definition of Done.


Так как PO и Dev Team составляет Scrum Team по Scrum Guide

Scrum guide
The Scrum Team consists of a Product Owner, the Development Team, and a Scrum Master.
...
During each Sprint Retrospective, the Scrum Team plans ways to increase product quality by improving work processes or adapting the definition of "Done", if appropriate and not in conflict with product or organizational standards.


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

В идеале оно должен содержать все, что надо сделать, чтобы выпустить версию. Но может и не содержать, если идеал не достигнут. Еще там не сказано, что оно должно содержать только это. Т.е. написано к чему надо стремиться, а не как непременное условие.

Т.е. в книжке пишут, что definition of done - помогает измерить готовность продукта, и в пределе оно должно соответствовать критериям, которые предъявляет экспуатант, т.е. в пределе наличие самодеятельности не предполагается, вы же пишете, что оно каким-то образом "помогает достигать цели" и при его формировании допустима анархия.


Так это и есть цель спринта "a potentially releasable Increment of "Done" product at the end of each Sprint.".

Заметьте, что DoD состоит из активностей - там фактически то, что надо сделать, а не то, каким должен быть результат.
+ картинка

Картинка с другого сайта.


Так же туда включают часто всякие code review и прочее. Т.е. это не то, что "эксплуатант" напрямую определяет, а то, на что соглашается команда исходя из его и своих представлений о том, что надо делать, чтобы результат удовлетворял требованиям.


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


Скрам это некоторый организационный каркас на который можно навешать конкретные вещи в достаточно широких пределах.
Я читал, что изначально в Скрам захотели добавить XP, но потом решили что так он хуже будет продаваться и в итоге там нет технических практик "XPers often joke, with some justification, that Scrum is just XP without the technical practices that make it work.".

Про качество в scrum guide есть несколько ограничений общего порядка (поищите quality), остальное на выбор того кто реализовывает - как технические так и организационные практики которые не противоречат.
27 ноя 19, 16:47    [22026846]     Ответить | Цитировать Сообщить модератору
 Re: Агиле/Скрам или прессинг . Part 2.  [new]
mirudom
Member

Откуда:
Сообщений: 1148
 		Уважаемые форумчане, про то, что я имел ввиду.

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

Вижу, пришли форумчане и говорят, что мол есть чУдная вещь - называется скрам-аджайл, у нас( них ) все
служит удовлетворенности желаний и потребностей и клиентов и исполнителей.

Мне естественно интересно, как взять на вооружение чУдную что-то, та как деньги просто так не платят.
Я не имею ввиду различные варианты аффелированности заказчика и исполнителя.

Но, так как фантазеров и шарамыжников много, то мне интересны механизмы достижимости рузультата.
Начинаю спрашивать: что, как, почему, зачем, и какими средствами.
В ответ получаю наставление типа "Верьте мне люди" или "есть великолепная практика под названием
Ретроспектива и вот на ней ....." .

Задаю вопрос:
mirudom
Подскажите пожалуйста, есть ли в Вашем окончании итерации, т.е. Ретроспективе, место для оценки
технических характеристик полученного продукта ( кода или ... ) ?
Ежели такое место есть - укажите пожалуйста.
Тут начинается самое интересно, а именно интерпретация вопроса.

Пока получается, что и применение и понимание скрам-аджайла сильно зависит от контекста (задачи-процесса-опыта-инструментов-участников-достижимость результата).
Но нет возможности добиться от skyANA или Дмитрий Мух или WebSharper внятного ответа на вопрос о соблюдении финансовой дисциплины на проектах с применением скрам-аджайл. Без чего нет коммерческой разработки.

Ссылки на благодарности пенсионеров смахивают на известное выражение:
"Спасибо товарищу Сталину за наше счастливое детство !".
30 ноя 19, 21:37    [22029569]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: ←Ctrl  назад   1 .. 15 16 17 18 19 20 [21] 22 23 24   вперед  Ctrl→
Все форумы / Работа Ответить