У каждого есть право на свое мнение, оставлю свои две копейки здесь.
К сожалению, мне очень кажется, что автор статьи не читал вдумчиво первоисточники, если уже в первых строках ссылается на Википедию, а не на текст самого манифеста: agilemanifesto.org
Авторы методологии Скрам напрямую указывают, что проект можно развивать по любым правилам, но называть его Скрам-проектом разрешено только тогда, когда все спринт-цикл с сопутствующими ролями и артефактами выдержаны на 100 % (сравните хотя бы последний абзац из «Руководства по Скраму» (https://www.scrumguides.org/). По всей видимости, большинство проектов, заявляющие Скрам в качестве методологии разработки, живут по каким-то совершенно другим правилам.
Автор допускает ряд терминологических неточностей:
Обсудил идею со жрецами (stakeholders) и назначил своего виночерпия ответственным за проект (product owner). Виночерпий подыскал грамотного каменщика (scrum master). Каменщик нанял помошников (scrum team), а те пошли на невольничий рынок и набрали рабов (рабочие инструменты: ПК, сервера, софт для разработки и т.д.).
Виночерпий в этом случае все же отвечает не за проект, а за продукт, то есть за результат, а не за процесс.
«Грамотный каменщик» — это совершенно не роль скрам-мастера, тут скорее нужен массажист или кухарка. А высококвалифицированные каменщики будут входить в команду разработчиков (Development Team, совсем не Scrum Team). Не стоит передавать роль тимлида скрам-мастеру.
Так как фараон приказал ежемесячно докладывать ему о ходе строительства, то каменщик (с помощниками) стал ежемесячно проводить показ стройки (demo) для виночерпия. Во время показа обсуждалось не только уже сделанное (retrospective), но и составлялся план на следующий месяц (sprint). Для того, чтобы ничего не упустить, виночерпий весь месяц обсуждал со жрецами их хотелки (user stories) и записывал в специальный пергамент (backlog), из которого хотелки попадали в план следующего месяца.
В терминологии Скрама нет понятия «demo», существует «Sprint Review», и это собрание проводится отнюдь не скрам-мастером (который может даже не пристутствовать на нем), а все же самим виночерпием.
Ретроспектива проводится не во время «показа», а в виде отдельного собрания. И обсуждается тут все же не сделанное, а успехи и проблемы в процессе разработки. Ну и совершенно отдельным собранием проводится планирование. «Хотелки» записываются все же не просто в «backlog», а в Product Backlog (который отличается от Sprint Backlog и уж точно не обязан формулироваться с применением User Stories).
Следует четко понимать, что итеративные методики разработки приносят с собой высокие накладные расходы, так как проводится большой объем работы по самокоррекции каждый цикл. Поэтому применяются подобные методики там, где нет возможности (по целому ряду причин) разработать эффективный план. Пример с постройкой дома — это пример неправильного применения итеративных методик. В постройке типового дома (сайта, форума, магазина) есть давно отработанные технологии, опирающиеся на опыт создания таких же типовых продуктов. Использовать Скрам для этого — это тратить дорого оплаченное время разработчиков.
Осталось впечатление, что эта статья не про гибкие методы разработки, не про Скрам, а про то, что автор пытается нам объяснить, что гвозди не стоит забивать микроскопом, даже если сейчас это крайне «модно и молодежно» и практикуется всеми «красноглазыми пионерами».
За это автору особая благодарность!
Прощу прощения, а в чем вопрос по существу? Мы говорим о цели подобного ежедневнного собрания. А подобные предложения пытаются заменить цель формой. Каждый член команды в своей работе прекрасно ощущает, хватает ли ему информации для его работы. Если такое состояние достигается за 90 секунд, то все сэкономили время.
Если признать, что информированность всех членов команды важна, то ежедневный «стендап» реализует достижение этой цели. Во время такой встречи происходит обмен информацией.
Если команда обменивается информацией иначе, то ежедневные встречи могут быть избыточными.
А возможность «посмотреть в гите» была и остается, только ведь разница в том, посмотрю ли я или буду иметь возможность посмотреть. В нашей практике всегда было проще проактивно рассказать, что важного произошло за прошлый день, чем ожидать правильного самостоятельного понимания изменений от других членов команды и отвечать всем десять раз на один и тот же вопрос.
Позволю себе маленькое замечание: все же хотелось бы видеть прямую ссылку на работу (или хотя бы полные выходные данные), если работа используется для обоснования собственной точки зрения. А так пока только Клиффорд Насс на просторах сети… Кто такой, где публиковался, какого года статья.
А разве это нелогично, если учитывать демографическую ситуацию на планете? Образованные люди в развитых странах (а юго-восток Азии достаточно развит) подчинаются понятному закону распределения, их доля в общем населении сравнима.
К сожалению, мне очень кажется, что автор статьи не читал вдумчиво первоисточники, если уже в первых строках ссылается на Википедию, а не на текст самого манифеста: agilemanifesto.org
Авторы методологии Скрам напрямую указывают, что проект можно развивать по любым правилам, но называть его Скрам-проектом разрешено только тогда, когда все спринт-цикл с сопутствующими ролями и артефактами выдержаны на 100 % (сравните хотя бы последний абзац из «Руководства по Скраму» (https://www.scrumguides.org/). По всей видимости, большинство проектов, заявляющие Скрам в качестве методологии разработки, живут по каким-то совершенно другим правилам.
Автор допускает ряд терминологических неточностей:
Виночерпий в этом случае все же отвечает не за проект, а за продукт, то есть за результат, а не за процесс.
«Грамотный каменщик» — это совершенно не роль скрам-мастера, тут скорее нужен массажист или кухарка. А высококвалифицированные каменщики будут входить в команду разработчиков (Development Team, совсем не Scrum Team). Не стоит передавать роль тимлида скрам-мастеру.
В терминологии Скрама нет понятия «demo», существует «Sprint Review», и это собрание проводится отнюдь не скрам-мастером (который может даже не пристутствовать на нем), а все же самим виночерпием.
Ретроспектива проводится не во время «показа», а в виде отдельного собрания. И обсуждается тут все же не сделанное, а успехи и проблемы в процессе разработки. Ну и совершенно отдельным собранием проводится планирование. «Хотелки» записываются все же не просто в «backlog», а в Product Backlog (который отличается от Sprint Backlog и уж точно не обязан формулироваться с применением User Stories).
Следует четко понимать, что итеративные методики разработки приносят с собой высокие накладные расходы, так как проводится большой объем работы по самокоррекции каждый цикл. Поэтому применяются подобные методики там, где нет возможности (по целому ряду причин) разработать эффективный план. Пример с постройкой дома — это пример неправильного применения итеративных методик. В постройке типового дома (сайта, форума, магазина) есть давно отработанные технологии, опирающиеся на опыт создания таких же типовых продуктов. Использовать Скрам для этого — это тратить дорого оплаченное время разработчиков.
Осталось впечатление, что эта статья не про гибкие методы разработки, не про Скрам, а про то, что автор пытается нам объяснить, что гвозди не стоит забивать микроскопом, даже если сейчас это крайне «модно и молодежно» и практикуется всеми «красноглазыми пионерами».
За это автору особая благодарность!
Если команда обменивается информацией иначе, то ежедневные встречи могут быть избыточными.
А возможность «посмотреть в гите» была и остается, только ведь разница в том, посмотрю ли я или буду иметь возможность посмотреть. В нашей практике всегда было проще проактивно рассказать, что важного произошло за прошлый день, чем ожидать правильного самостоятельного понимания изменений от других членов команды и отвечать всем десять раз на один и тот же вопрос.
Божидар Батсов -> Божидар Бацов
В остальном же бодренько написано!
А кого бы вы называли автором первого электронного компьютера?