Почему Вы пишите Scrum капсом? Это же не аббривеатура.
Книга так и называется — SCRUM
Книга называется «Scrum: The Art of Doing Twice the Work in Half the Time»
В SCRUM как достичь бизнес-цели, решает проектная команда, а не руководство. Такой метод мотивирует и стимулирует творческий подход, в отличие от классического менеджмента, где сотрудникам делегируют выполнение конкретных низкоуровневых действий, а те, в cвою очередь, часто даже не понимают, для чего это и как это повлияет на проект в целом.
Во-первых, в скраме нет такого понятия, как проектная команда, есть только команда разработки и скрам-команда. Во-вторых, несмотря на то, что команда разработки может принимать участие в формировании бизнес-идеи, ответственность за этот процесс несет владелец продукта. Команда же отвечает за сам процесс поставки.
В данном контексте непонятно, что Вы имеете в виду под проектной командой. Предположу, что Вы имеете в виду скрам-команду целиком. Даже в этом случае, Ваше определение не верно. Прозрачность должна достигаться в рамках всей организации, так как стейкхолдеры могут и будут находиться за пределами скрам-команды. «Significant aspects of the process must be visible to those responsible for the outcome. Transparency requires those aspects be defined by a common standard so observers share a common understanding of what is being seen.»
Stand-up митинги
Опять же, некорректное название для ежедневного события. В скраме оно называется ежедневный скрам. Его цель — не повысить прозрачность, для этого существуют другие инструменты, а проинспектировать прогресс в сторону цели спринта и в сторону выполнения задач в бэклоге спринта. «The Development Team uses the Daily Scrum to inspect progress toward the Sprint Goal and to inspect how progress is trending toward completing the work in the Sprint Backlog.»
SCRUM не отменят титулов.
Скрам отменяет все титулы, кроме разработчик.
в процессе обсуждения того или иного решения главенствующим фактором является четкая и обоснованная позиция, подкрепленная личным опытом сотрудника в обсуждаемой области
Вот с этим я спорить не стану)
SCRUM дает власть именно тем членам команды
Скрам никому не дает власти — все участники равны.
Армия джунов и мидлов (синеры, как известно, стоят дорого и их мало) уверенно коммитит в master своё творчество, а заказчик спринт за спринтом пожинает блестящие результаты SCRUM.
Коммитят в мастер не джуны или миддлы, а команды разаработки. Вся команда несет ответсвенность за коммит.
Во-первых, на проекте должны работать как минимум 1-2 как можно больше опытных инженеров, которые будут пропускать через себя все коммиты в репозиторий во время code review. Во-вторых, уделять много времени обучению (не менее 3 часов в неделю) младших и средних инженеров архитектуре ПО, паттернам проектирования и тому, как это накладывается на существующий проект.
Это, конечно, хорошие идеи, но здравый смысл подсказывает, что так и должно быть в любой организации, если это не какой-нибудь малочисленный стартап.
Выполнение практических заданий можно встраивать в backlog проектных спринтов
Проектные спринты — уши режет(
Владелец продукта решает, что нужно сделать, а команда решает — как.
Да! Все верно!
Таким образом, краеугольным камнем методологии SCRUM является обучение.
Скрам — это не методология, и поэтому процесс обучения в нем не оговаривается) Обучение — это процесс, который в каждой организации проводится по своему. Например, митапы, о которых Вы упоминали ранее, или парное программирование.
SCRUM, как и любой другой метод управления проектами, имеет свои особенности и шероховатости, которые надо знать и учитывать. Несмотря на это, он дает лучший результат среди известных на сегодняшний день методов.
Опять же, скрам — это не метод, это всего лишь фреймворк. Он не покрывает все аспекты деятельности организации. Скрам — это лишь способ эффективно организовать процесс разработки. В организациях помимо процессов разработки еще достаточно других процессов. Конечно, это не означает, что команды должны существовать в скрамовом вакууме, а организация должна оставаться работать по старым принципам. В этом случае скрам не будет эффективным.
Кроме того, если брать Аджайл в целом, то в первую очередь — это майндсет, а практики можно использовать разные
Основатели Agile Manifesto — все очень опытные инженеры, которые знают толк в производстве. К сожалению, многие проектные менеджеры, пытающиеся применять эти подходы, — нет.
Можно чуть-чуть поподробнее по поводу гипотез? Перед ее проверкой на проде она уже удовлетворяет DOD, или вы сначала проверяете ее и, в случае, если она успешна, полностью выполняете DOD и допиливаете функционал?
Теперь на sprint review мы показываем только то, что выложено на боевой сайт. Если что-то почти готово — осталось только баги пофиксить, протестировать и выложить — не показываем.
Это верный подход. Очень огорчает, когда незрелые в скраме команды пытаются скосить углы, показывая недодел.
Однако, как обстоят дела, если вы проверяете гипотезу и выкладываете её в прод?
Почему Вы пишите Scrum капсом? Это же не аббривеатура.
Книга называется «Scrum: The Art of Doing Twice the Work in Half the Time»
Во-первых, в скраме нет такого понятия, как проектная команда, есть только команда разработки и скрам-команда. Во-вторых, несмотря на то, что команда разработки может принимать участие в формировании бизнес-идеи, ответственность за этот процесс несет владелец продукта. Команда же отвечает за сам процесс поставки.
В данном контексте непонятно, что Вы имеете в виду под проектной командой. Предположу, что Вы имеете в виду скрам-команду целиком. Даже в этом случае, Ваше определение не верно. Прозрачность должна достигаться в рамках всей организации, так как стейкхолдеры могут и будут находиться за пределами скрам-команды.
«Significant aspects of the process must be visible to those responsible for the outcome. Transparency requires those aspects be defined by a common standard so observers share a common understanding of what is being seen.»
Опять же, некорректное название для ежедневного события. В скраме оно называется ежедневный скрам. Его цель — не повысить прозрачность, для этого существуют другие инструменты, а проинспектировать прогресс в сторону цели спринта и в сторону выполнения задач в бэклоге спринта.
«The Development Team uses the Daily Scrum to inspect progress toward the Sprint Goal and to inspect how progress is trending toward completing the work in the Sprint Backlog.»
Скрам отменяет все титулы, кроме разработчик.
Вот с этим я спорить не стану)
Скрам никому не дает власти — все участники равны.
Коммитят в мастер не джуны или миддлы, а команды разаработки. Вся команда несет ответсвенность за коммит.
Это, конечно, хорошие идеи, но здравый смысл подсказывает, что так и должно быть в любой организации, если это не какой-нибудь малочисленный стартап.
Проектные спринты — уши режет(
Да! Все верно!
Скрам — это не методология, и поэтому процесс обучения в нем не оговаривается) Обучение — это процесс, который в каждой организации проводится по своему. Например, митапы, о которых Вы упоминали ранее, или парное программирование.
Опять же, скрам — это не метод, это всего лишь фреймворк. Он не покрывает все аспекты деятельности организации. Скрам — это лишь способ эффективно организовать процесс разработки. В организациях помимо процессов разработки еще достаточно других процессов. Конечно, это не означает, что команды должны существовать в скрамовом вакууме, а организация должна оставаться работать по старым принципам. В этом случае скрам не будет эффективным.
Кроме того, если брать Аджайл в целом, то в первую очередь — это майндсет, а практики можно использовать разные
Это верный подход. Очень огорчает, когда незрелые в скраме команды пытаются скосить углы, показывая недодел.
Однако, как обстоят дела, если вы проверяете гипотезу и выкладываете её в прод?