недавно был на курсе у Jeff Sutherland по скраму. ( мужик интересно рассказывает, хотя были непонятки). на некоторые вещи отвечал уклончиво. главный косяк: внушал, что велосити будет постоянно расти с ускорением. я спросил его: что через 4 года при большом проекте? ... типа будет расти все равно. чем загнал меня в тупик понимания. говорю как? есть сплоченная команда, все опытные волки, бэклог берут с большой скоростью, что дальше? промямлил, типа всегда есть способы для ускорения. показал на график той оты... воонщем не впечатлил. очень в большом количестве лекция прохцодила в духе "мы лучше и быстрее ватерфола в 4-10 раз". раклама кароче. подошел к нему на перерыве, сказал: вы лучше ватерфола в 2 раза только потому, что не надо писать кучу говно-документации. в принципе согласился что это главняя причина, все остальное продающийся сахар.
Здравствуйте, goondick, Вы писали:
G>недавно был на курсе у Jeff Sutherland по скраму. ( мужик интересно рассказывает, хотя были непонятки). на некоторые вещи отвечал уклончиво. главный косяк: внушал, что велосити будет постоянно расти с ускорением. я спросил его: что через 4 года при большом проекте? ... типа будет расти все равно. чем загнал меня в тупик понимания. говорю как? есть сплоченная команда, все опытные волки, бэклог берут с большой скоростью, что дальше? промямлил, типа всегда есть способы для ускорения. показал на график той оты... воонщем не впечатлил. очень в большом количестве лекция прохцодила в духе "мы лучше и быстрее ватерфола в 4-10 раз". раклама кароче. подошел к нему на перерыве, сказал: вы лучше ватерфола в 2 раза только потому, что не надо писать кучу говно-документации. в принципе согласился что это главняя причина, все остальное продающийся сахар.
Одновременно, отсутствие "кучи говно-документации" обеспечивает отсутствие "долговременной памяти" о целях развития проекта или продукта.
Т.е. есть вариант не додумывая до конца одну и ту же фичу в разные стороны править на разных итерациях.
Почему то они всегда противопоставляют себя то "водопаду" а не другим осмысленным итеративным процессам.
Наверно потому что наличие Стратегии даёт преимущество по сравнению с любыми разновидностями тактики.
А таки да.
Если в организации разработки бардак, то самый простой способ его упорядочить — это разновидности agle.
Если конечно с "самоорганизацией" команды всё сложится.
Здравствуйте, goondick, Вы писали:
G>недавно был на курсе у Jeff Sutherland по скраму. ( мужик интересно рассказывает, хотя были непонятки). на некоторые вещи отвечал уклончиво. главный косяк: внушал, что велосити будет постоянно расти с ускорением. я спросил его: что через 4 года при большом проекте? ... типа будет расти все равно. чем загнал меня в тупик понимания. говорю как? есть сплоченная команда, все опытные волки, бэклог берут с большой скоростью, что дальше? промямлил, типа всегда есть способы для ускорения. показал на график той оты... воонщем не впечатлил. очень в большом количестве лекция прохцодила в духе "мы лучше и быстрее ватерфола в 4-10 раз". раклама кароче. подошел к нему на перерыве, сказал: вы лучше ватерфола в 2 раза только потому, что не надо писать кучу говно-документации. в принципе согласился что это главняя причина, все остальное продающийся сахар.
Если вам говорят что в скраме velocity растет, то вас обманывают. Скорее всего тот, кто утверждает такое сам никогда по скраму не сделал ни одного большого проекта. Velocity обычно уменьшается из-за наличия багов. Баги зачастую надо исправлять сразу, а не в следующей итерации, это съедает время, и, соответственно, уменьшает velocity. А после релиза начинается операционная поддержка, которая также кушает время, как и багфикс.
Если же что-то можно улучшить, чтобы получить прирост velocity, то тоже самое можно улучшить и в водопадной модели.
Если вас рассказывают, что скрам лучше в N раз, то выясните как считали. Иногда такую чушь начинают рассказывать. Типа "мы год работали по водопаду и все было плохо, а потом наняли консультанта и он на рассказал что мы теперь работает по скрам и проект был сдан за месяц". Очевидно в этой ситуации заслуга скрама минимальна, если не отсутствует полностью.
По моей практике при ведении проектов по скраму общая продолжительность работ увеличивается по сравнению в водопадом, при прочих равных факторах — одинаковый объем (в том числе документации), одинаковая периодичность релизов, одинаковая команда, одинаковый заказчик, одинаковая сложность предметной области и техническая сложность проекта.
Но при скраме полученный фидбек мы сразу вносим в беклог и работаем наравне с остальными задачами. Поэтому скрам быстрее приносит ценность заказчику, как следствие растет удовлетворение заказчика и он охотнее вкладывается в доработки.
Если конечный результат уже известен вплоть до деталей и не будет меняться (например вы пишите ПО для железки), то скрам окажется неэффективен.
Главное, что надо понимать, что весь скрам описывается в трех-четырех абзацах, а все остальное, о чем говорят на тренингах и пишут в книгах, мотивация и механизмы его внедрения. И потому, что скрам описывается в трех-четырех абзацах, он не отвечает на львиную долю вопросов о процессе разработки, а значит и не решает большую часть проблем. Скрам можно прекрасно сочетать с водопадом, потому что крупномасштабное планирование, аналитика, проектирование интерфейса и написание требований вполне могут быть вынесены и в крупных проектах выносятся за пределы спринтов. Скрам очень непросто ложится на по настоящему крупные проекты с кучей интеграции и параллельной разработкой нескольких релизов, и в таких ситуациях его обычно творчески переосмысляют.
Здравствуйте, goondick, Вы писали:
G>"мы лучше и быстрее ватерфола в 4-10 раз". раклама кароче.
Дак это же маркетологи.
С вики
Каскадная модель ... В качестве источника названия часто указывают статью, опубликованную У. У. Ройсом (W. W. Royce) в 1970 году; при том, что сам Ройс использовал итеративную модель разработки.
В реальности ватерфолл никуда не делся при выполнении запроса пользователя все этапы и сейчас присутствую. В те далекие годы, компьютеры и периферия были сильно скуднее чем сейчас и весь этот процесс можно было скорее всего уложить во вполне разумные сроки. Развитие ПО напрямую зависит от развития железа на котором оно работает. ДУмаю что в аппаратном конструировании никто не сравнивает методологии с разницей в несколько десятков лет.
Здравствуйте, goondick, Вы писали:
G>недавно был на курсе у Jeff Sutherland по скраму. ( мужик интересно рассказывает, хотя были непонятки). на некоторые вещи отвечал уклончиво. главный косяк: внушал, что велосити будет постоянно расти с ускорением. я спросил его: что через 4 года при большом проекте? ... типа будет расти все равно. чем загнал меня в тупик понимания. говорю как? есть сплоченная команда, все опытные волки, бэклог берут с большой скоростью, что дальше? промямлил, типа всегда есть способы для ускорения. показал на график той оты... воонщем не впечатлил. очень в большом количестве лекция прохцодила в духе "мы лучше и быстрее ватерфола в 4-10 раз". раклама кароче.
Был как-то (давно, задолго до всех скрамов) в Одессе на научной конференции. Выступал московский учёный (профессор, д.т.н., даже фамилию его помню), говорит: "применяя мои алгоритмы, мы получаем выигрыш в отношении сигнал/шум в 28 раз."
G>подошел к нему на перерыве, сказал: вы лучше ватерфола в 2 раза только потому, что не надо писать кучу говно-документации. в принципе согласился что это главняя причина,
Подошёл к нему на пляже, говорю: "Вот мой начальник (тоже д.т.н.) занимается той же проблематикой, но у него самый лучший результат — это 12 дБ (в 4 раза)." Он: "Да, да, я оговорился, не более 12 дБ". В материалах конференции велосити выросла в 7 раз в сравнении с реальностью вошло число 28.
G>все остальное продающийся сахар.
Ничего не меняется в этом мире.
