"..а некоторые и мышей едят" (с)

В книжках про скрам как раз активно пишут, что есть, но его надо срочно менять на скрам :)

Мне в соседнем чате буквально вчера (в оередной раз) доказывали, что есть.
Правда по нему в реальном мире работать не получается. Везде лезут какие-то итерации. Но он все равно есть! )
Но там быстро закончилось. Даже до MIL-STD-498 не дошли

Забавно, что именно пример со строительством был гневно отвергнут )
Не бывает там вотерфолла. Обязательно есть правки проекта и переделки!

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

👍

+

давайте посмотрим. автор скрама Сазерленд, его книга называется "как делать в два раза больше работы за 1/2 времени", и там нет ни слова про требования и ограничения к практикам скрама, как вы говорите

а вот инфобизнесмены после слетелись на тему, как мухи на.. плафон

как щас на б2б продажи

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

А именно:
- тиражируемость решения
- независимость от конкретной личности на уровне вплоть до C-level
- наличие большой алгоритмизуемой части

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

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

Я понимаю, когда разработка зависит от гениального математика-программиста или носителя крайне специфичных знаний и их на весь мир 100 штук, 98  - в Гугле, а у вас в коллективе - один.

Но я не понимаю, когда всё было хорошо, а потом поменялся овнер или кто там ещё, и всё рассыпалось.

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

У меня не получился пакет молока потому, что сменился скрам-мастер.
У меня не вышло испечь хлеб, так как овнер поменялся.

Камон, пагни, ляп-пам-пам. Мы все делаем 90% рутинной отлично формализуемой работы. Она не намного сложнее работы на конвейере.

Творчества в программировании - 5% от всего, и то не у всех.

Спуститесь на землю.

+

Anton Rusakov (0) увеличил репутацию Andrey Shetukhin (9)

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

Проблема в том, что Скрам нарушает самый первый принцип - про людей и инструменты. А так норм, почему бы не Скрам.

Честно говоря, не совсем уловил... первый принцип построения команды, о котором я писал,  был коммуникация и поддержка... скрам этому принципу в целом соответствует

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