Раньше работал по водопадной модели, тоже можно достигать результатов. Но скрам, лично для меня, оказался наиболее эффективной моделью. Правда она выжимает все соки.
Видимо я не правильно выразился. Происходит демонстрация функциональных требований, которые были описаны аналитиками и взяты разработчиками в работу. И тут же происходит анализ и, если надо, корректировка требований на следующий спринт. Это все сопровождается рассказом программиста:«Я на этом спринте реализовывал вот эту задачу» Идет демонстрация и одновременное обсуждение.
Кодом владеют все и каждый может заменить другого. Но глубина владения кодом у каждого разная. И есть один, кто в данный момент владеет модулем. Его глубина погружения в детали выше всех. Значит он аргументированно может лучше оценить разработку. Если ему сильно кто — то возражает и говорит, что сделает быстрее, его ответ, как правило, простой:«Делай».
Выше речь шла, конечно о функциональных требованиях. Аналитики описывает их, и часто вместе с остальной командой и PO. В них описывается результат, который надо предъявить в конце спринта.
Нам повезло, так получилось, что команда и PO не находятся по разные стороны баррикад. Они сражаются на одной стороне. Задачу обсуждают все и выигрывают, как правило, аргументы. Но у PO есть привилегия, бремя ответственности — выбирать решения между множеством предложенных.
Выше речь шла, конечно о функциональных требованиях. Аналитики описывает их, и часто вместе с остальной командой и PO. В них описывается результат, который надо предъявить в конце спринта.
бремя ответственности— выбирать решения между множеством предложенных.