Pull to refresh

Comments 54

А ниче, что Agile никакая не гибкая методология?.. :)
То, что под Agile могут маскировать всё что угодно, не отменяет её первичных принципов и признаков, как непосредственно гибкой методологии.

Как по мне, то Agile — не методология, а набор "первичных принципов и признаков", на базе которых создаются различные методологии, относимые к Agile.

Тогда вообще не использовать слово «Agile», раз 99% неправильно его понимает.
Используйте просто «гибкая методология».
Под Agile обычно понимается Scrum.
Под Agile обычно понимается Scrum.

А Kanban не Agile?

Обычно
А статьи чуть реже, чем всегда, о Scrum.

Тем не менее, это не синонимы. И если статья о Scrum, то это явно упоминается.

Поясните, чем она гибче водопада.
Вернее, даже водопад в умных руках гибче ее. :)
На самом деле, многим.

Также можно сказать, что в умелых руках — все будет работать хорошо. В неумелых — все плохо. А также следует четко понимать, что каждая методология имеет свою плюсы и минусы, и области применения.

Но для того, чтобы разговор был предметным, не могли бы вы пояснить ваше понимание слова «Гибкости» в данном контексте.
Я хз.
Берите в том значении, в котором это слово используется в словосочетании «гибкая методология». :)
Не понимаю вашего ответа.
Сначала вы утверждаете, что:
«Agile никакая не гибкая методология»

А на вопрос, что вы понимаете под понятием «гибкости», то есть по каким параметрам сравниваете, вы отвечаете:
«Я хз.»


Также:
«В том значении, в котором это слово используется в словосочетании «гибкая методология»»
Если говорить об этом значении слова «Гибкость», то хотелось бы узнать ваше мнение, на чем основано ваше утверждение:
водопад в умных руках гибче
Но даже в этом случае, предполагаю, что возможно разночтение словосочетания «Гибкая методология». Поэтому для начала хочу спросить, что оно означает в вашем понимании?
Дается утверждение, что Agile гибкая.
Ну так скажите в чем ее гибкость.
А то начали переливать из пустого в порожнее.
Уважаемый http2, во первых с утверждений начали Вы.
А ниче, что Agile никакая не гибкая методология?.. :)
При этом несколько раз вас просили объяснить, как вы пришли к такому мнению, чем, что, и по каким параметрам мерили? Ответа вы так и не дали.

Эти вопросы я задавал, чтобы разговор был предметным. Потому как иначе придется угадывать, о чем именно вы имели в виду, так как первое, что я предположил, что Вы хотите обсудить некоторые проблемы каких-то из методологий семейства Agile.
Сейчас же это выглядет так, что Вы не владеете темой, и высказали утверждение, которое принадлежит не Вам. Хотя опыта я вашего и не знаю, и что-то утверждать было бы неправильным с моей стороны.

Итак, «Agile никакая не гибкая методология?»
1) «Agile» переводится на русский, как «Гибкий». Поэтому наверняка вы сравнивали с Водопадной моделью не по смыслу в названии

2) Agile — это не методология. Это семейство методологий, которые придерживаются Agile Манифеста . Это такие методологии, как Kanban, Lean Six Sigma, XP, Scrum. Это разные методологии, имеющие разные степени ограничений.

3) Если сравнивать Scrum, описанный в этой статье, с Водопадной моделью, то Скрам «гибче» в следующих моментах:
— В Скрам есть только 2 жестоких ограничения во время выполнения проекта:
— — Длительность Спринта после его начала
— — Цель Спринта
Также есть пункты, которые говорят о том, что это Скрам. Если их не придерживаться, то это уже не Скрам. Например: единственная роль в Дев. команде, это Разработчик, не зависимо от специализации сотрудника (ДБА, Тестировщих, Кодер, Аналитик и т.д.). Или то, что результатом любого Спринта должен быть потенциально «Готовый» к релизу инкремент продукта.

Водопадная модель имеет жесткие ограничения по разрабатываемому функционалу (ТЕхническому заданию) и срокам разработки (Планом проекта). Можно мне возразить, что в водопадной модели предполагаются заложенные риски, в рамках которых можно что-то поменять? Но это тоже жесткие сроки, которые выделяются на возможные риски в соответствии с их оценкой. Не заложенные изменения можно сделать в рамках «не критического пути», что все-равно не отменяет наличие «критического пути» с его спланированными сроками.

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

4) Ни один опытный человек (как я считаю) не скажет что Водопадная модель — хуже или лучше, к примеру Скрам. Потому как они просто разные. Каждая имеет свои плюсы и минусы. И каждая имеет области наилучшего применения.
То есть можно сказать, что в каком-то конкретном случае Водопадная модель будет работать хуже/лучше Agile модели. Но не в общем.

5) И последнее: Нельзя судить о самой методологии, основываясь на примере ее кривого применения. Как вы сказали, в умелых руках Водопадная модель отлично работает! И я с вами согласен. И добавлю, что в умелых руках, когда человек понимает разницу, плюсы, минуса и области применения, все хорошо работает.

Уважаемый http2, если Вы хотите обсудить какие-то тонкости, прошу Вас, делая утверждения, все-же давать объяснения, на чем эти утверждения основаны. Это поможет не угадывать, что именно вы имели в виду, пытаясь написать Вам ответ.
Уважаемый http2, во первых с утверждений начали Вы.

Я?
А как же заголовок статьи?:
7 препятствий для внедрения гибких методологий в больших организациях


Agile — это не методология

ОК, берем рассматриваемый в статье Scrum (обычно под Agile и понимают Scrum).

Если сравнивать Scrum, описанный в этой статье, с Водопадной моделью

О, до Вас дошло. :)

Или то, что результатом любого Спринта должен быть потенциально «Готовый» к релизу инкремент продукта.

Не после любого спринта можно релизить.
Если это разработка нового продукта, то ничего вы не зарелизите.
А если это правки существующего, то да.

Водопадная модель имеет жесткие ограничения по разрабатываемому функционалу (ТЕхническому заданию) и срокам разработки (Планом проекта).

Кто Вам такое сказал? :)

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

Так какая концепция? Какой подход?
Наличие спринтов якобы с готовым продуктом?
Это фейк, развод лохов.

То есть можно сказать, что в каком-то конкретном случае Водопадная модель будет работать хуже/лучше Agile модели.

Ах, уже водопад не всегда хуже? :)
А когда он лучше?

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

Просто чет нету некривых применений Скрама :)
Везде куча косяков и стало только хуже :)

Как вы сказали, в умелых руках Водопадная модель отлично работает!

Рад, что Вы согласились. :)
И от добра добра не ищут. :)

В водопаде при изменениях требований пропадает впустую куча проделанной работы по планированию уже не актуальных вещей. В Agile тоже, но горизонты планирования различаются на порядок, если не больше.

Если все «прибито гвоздями» на уровне архитектуры, то потери будут большие.
Если изменения поместятся в какоей-то уже распланированное «окно возможностей» то и незаметит никто.
А с нормальной инструментальной поддержкой — перепланировать в виде «что если» и оценить на что повлияет будет тоже в рамках «текущей работы»

Я не про архитектуру, архитектура — это собственно разработка, а аджайл, водопад и т. п. — принципы управления разработкой, они для менеджеров прежде всего. И в водопаде можно сделать гибкую архитектуру, и в аджайле можно всё прибить гвоздями.


Я именно про управления разработкой: менеджеры и прочий бизнес могут потратить кучу времени на составление планов, согласования, бюджетирование и т. д. на годы вперёд, а потом всё это окажется мусором.

но горизонты планирования различаются на порядок

Сколько эти горизонты планирования?
То есть в Agile, начиная делать сайт вообще не понимают, что хотят получить или как? :)

Типа строим дом, но не планируем по началу канализацию, а потом быстренько покоцалили фундамент и ок? :)
Иногда и так бывавает.
— Хочу домик отдохнуть.
— Ок. мы их делаем. что именно вы хотите?
— Ну хз. предложите что-то «вы же спец»
— обычно по вашему профилю: делаем домик, окна со стеклом, кухню с газом но вам рекомендуем электричество и подключение к канализации и водопроводом.
— ок. беру.
Прошло Y дней…
— Парни что за хрень вы вы мне впарили, а где я поставлю аквариум с бегемотом ?!
— ?!?!?!?!
Сколько эти горизонты планирования?

Зависит от конкретных методологий и проектных решений. В скраме рекомендуется порядка двух недель планировать деятельность, остальное — в бэклог.


То есть в Agile, начиная делать сайт вообще не понимают, что хотят получить или как? :)

Грубо говоря, да. Точнее — исходят из предположения что заказчик не понимает и будет менять как сами требования к конечному результату, так и приоритет реализации тех или иных фич.


Типа строим дом, но не планируем по началу канализацию, а потом быстренько покоцалили фундамент и ок? :)

Типа да, если заказчик не сказал о канализации в начале.

Гибкость эджайла растет из структуры — множество коротких полных производственных циклов в противовес одному или нескольким циклам водопада. Предполагается, что бОльшую часть рисков, связанных с неопределенностью требований заказчика и все связанные с нею, выявляются на этапах реализации, тестирования и использования. Короткие производственные циклы позволяют выявлять эти риски рано и регулярно. Разработка же вертикальными срезами нужна для того, чтобы функциональный заказчик (внешний и внутренний) мог видеть прогресс и управлять им, корректируя требования.
Это несколько упрощенное объяснение, но суть должна стать ясна.
множество коротких полных производственных циклов

Сколько и какая длительность цикла при разработке среднего сайта?

в противовес одному или нескольким циклам водопада

Это Вы в книжках по Agile решили, что в водопаде будет 1 цикл? :)
Какая длительность цикла будет тут?
Сайтами не занимаюсь, с водопадом и с эджайлом знаком на практике и, надеюсь, достаточно в теории. Холиваром на эту тему не интересуюсь — подумал, что Вам интересен ответ на вопрос. Ну и вторую цитату в собственном каменте перечитайте еще разок — там написано «одному или нескольким». По Ройсу, кстати, именно один, емнип — да, с возвратами между этапами, но это совсем не итеративность циклов, а итеративность для этапов. Но в жизни, конечно, бывают очереди, которыми режут больших слонов.
Я дискретности, кстати, вообще не вижу здесь, по мне классический водопад — так вполне себе вырожденный [одно]итеративный процесс, и он лежит с абстрактным эджайлом в одном спектре итеративных процессов. Посередине не пустота, а кучка разных эджайл и совсем не эджайл зверушек с разными размерами циклов и обертками.
Гибкость эджайла растет из структуры ...

Крылья… ноги… главное хвост! Цель какая?
Короткие производственные циклы позволяют выявлять эти риски рано и регулярно.

Именно — минимизация рисков. От этого строится методология и управление рисками.
Главная причина невнедрения — ответственные лица не видят чем внедрение улучшит ситуацию. Или понимают, что в долгосрочной перспективе улучшит, но здесь и сейчас ухудшит…
Работаю в такой организации :) Как раз пытаются «внедрить Agile» в виде SCRUM. Такие смешные… Во-первых, конечной цели нет — т.е. цели такие:
— сделать все дешевле
— четко знать, какой разработчик что делает, чтобы все были при деле
— ну и потому что Греф сказал, что надо быть Agile…

А так — все как написано — четкое разделение труда, кросс-функциональность встречается в штыки, еще больше наваливание работы, и прочее.
работаю в той же организации, но делаю совершенно противоположные выводы ;)
В отношении программного обеспечения, Фред Брукс (в книге «Мифический человеко-месяц») дает утверждение, которое противоречит предыдущему


Брукс создавал операционную систему, если вы не в курсе.
И народу там было очень даже дохрена.

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

Брукс имел ввиду другое.
В статье говорится о том, что есть два противоречащих утверждения (в руководстве PMBOK и в книге Брукса «Мифический человеко-месяц»), и оба эти утверждения доказали свою состоятельность.

Причина этому противоречию в понятии «ресурс» в каждом из высказываний. Руководство PMBOK — это более общее руководство по управлению проектами в различных сферах. И понятие «ресурса» в PMBOK включает больше, чем сотрудники, тем более сотрудники, разрабатывающие новый «продукт». И именно о таких сотрудниках говорит Фред Брукс.

То есть противоречия на самом деле нет, если брать во внимание, что Брукс говорит о «нематериальных» ресурсах, а PMBOK обобщает понятие ресурса.

«Понимание задачи, обучение, межличностное общение и инновации» — это никакие не ресурсы. Из всего можно принять с натяжкой «затраты на обучение».

Эджайл — это методика, основанная на убеждении, что если пороть кодера нагайкой, то он быстрее и больше накодит. Я думаю, этой моде осталось года два — три от силы.
Успех внедрения методики не в самой методике, а в сопутствующих вложенных ресурсах в проект.
UFO landed and left these words here
Waterfall — это один из «китов» проектного менеджмента. Причем с очень широкой областью применения и степенью распространенности. Мне кажется, в этом причина подобных сравнений.

Но следует отметить, что Project Management Institute (PMI) , авторы PMBOK (руководство, на котором основывается Waterfall), организация, выдающая один из самых уважаемых и признаваемых сертификатов в области проектного менеджмента — PMP, также выдает сертификаты в области управления проектами посредствам Agile методологий — PMI-ACP.

Этот факт, по моему мнению, свидетельствует о том, что даже PMI признает Agile, понимая его различия в сравнении с Waterfall, и разные области применения. Признает право на существование различных подходов.
UFO landed and left these words here
Спасибо за ссылку!
Подозреваю что те, кто не хочет прочитать PMOK, создают мифы про него :)
Вы затронули очень важную тему. Я бы продолжил ее следующим образом: «Подозреваю, что все противостояние между методологиями развивают люди, которые не потрудились из изучить»

Чаще всего, в сравнении Waterfall и Agile происходит сравнение нечто, что нельзя отнести ни к какой-то Agile методологии, ни к Waterfall

Наличие ТЗ, после которого «херачим » до окончания срока, а потом мучаемся на этапе сдачи продукта, потому как Заказчик получил вообще не то, что хотел. И снова «дохерачиваем», чтобы подписать акт о приёмо-передачи — Это НЕ Waterfall. Это разработка «на коленке» с наличием какого-то ТЗ.

Наличие понятия Спринта, хотя продолжается то же самое «херачим» что-то, но каждые 2-3 недели смотрим, на то, что получилось, и снова «херачим» код. А потом и вообще забываем даже о том, для чего нам Спринты. Без цели спринта, без фидбэка со стороны заказчика, без постоянного процесса интеграции, без переоценки Бэклога — Это не Scrum. Это снова разработка «на коленке»

Вот и выходит, что не зависимо от используемых терминов, довольно часто сравниваются не методологии, а очень искаженное представление о них.
UFO landed and left these words here
Если вы согласитесь отправить статью мне в ЛС, буду рад быть среди первых читателей. И обещаю написать Вам честный отзыв.
UFO landed and left these words here
UFO landed and left these words here
PMBOK (руководство, на котором основывается Waterfall)

Когда уже читать научатся «проповедники Agile», такое впечатление, что специально обманывают.

1.1 Цель Руководства PMBOK®

Руководство PMBOK® выделяет ту часть Свода знаний по управлению проектами, которая обычно считается хорошей практикой. «Обычно считается» означает, что описываемые знания и практики применимы к большинству проектов в большинстве случаев, причем относительно их значения и пользы существует консенсус. «Хорошая практика» означает, что в целом существует согласие относительно того, что правильное применение этих знаний, навыков, инструментов и методов способно повысить вероятность успеха для широкого диапазона различных проектов.
«Хорошая практика» не означает, однако, что описываемые знания должны всегда одинаковым образом применяться ко всем проектам; организация и/или команда управления проектом самостоятельно определяет применимость этих знаний к тому или иному проекту.
Руководство PMBOK® состоит из ~600 страниц, у Agile всего одна:
http://agilemanifesto.org
Люди и взаимодействие важнее процессов и инструментов
Работающий продукт важнее исчерпывающей документации
Сотрудничество с заказчиком важнее согласования условий контракта
Готовность к изменениям важнее следования первоначальному плану

Waterfall, в большинстве случаев, и отличается тем, что согласование плана важнее всего процесса, а разработчики «общаются» с заказчиком через менеджеров.

В рамках Agile/(Scrum/Kanban|XP|...) первоначальные условия могут измениться на диаметрально противоположные. Здесь вообще отсутствует что-либо, где можно было бы зацепиться за отсутствие гибкости у Agile или неприемлемость Waterfall.
UFO landed and left these words here
Здесь разногласий нет совершенно. И дело вовсе не в том, что «многабукфф»… а том, как подходит руководство к процессу интеграции тех или иных подходов. В контексте Agile и PMBOK сравнивать вообще нельзя. «Манифест методологии не товарищ». Аля проповедование Agile направлено лишь на один единственный пункт из PMBOK — «Руководство проектом»
… это функция надзора, соответствующая модели организационного руководства и охватывающая жизненный цикл проекта. Система руководства проектом предоставляет руководителю проекта и команде проекта структуру, процессы, модели принятия решений и инструменты для управления проектом, одновременно поддерживая и контролируя проект с целью достижения успеха.


Waterfall был взят лишь в качестве примера, для отражения «Подготовительной и заключительной фаз»
Waterfall, в большинстве случаев, и отличается тем, что согласование плана важнее всего процесса, а разработчики «общаются» с заказчиком через менеджеров.

Где тут смайл «биться головой о стену» ?! С какого перепугу вы это решили ?!
А контрольный вопрос такой: у кого знания предметной области в проекте? кто понимает значение термина HairCut для банка? а CMR ее жизненный цикл?

Случаем не ProductOwner согласовывает, что нужно сделать в следующем спринте? Это как-то отличается от «согласование плана важнее всего процесса» иначе процесс тупо станет колом?
Относитель принципов: сами эти принципы бред, если их «трактовать» в лоб.

Люди и взаимодействие важнее процессов и инструментов

Самая наглая ложь, пи... и провокация. Сам Святой SCRUM и есть регламентация… процесса.
Методология, ставящая на первое место людей без соблюдения методологии и «Scrum board» просто… не выполнит своего предназначения. Забавно.

Работающий продукт важнее исчерпывающей документации
Сам по себе product backlog, sprint back log ну и конечно критерии приемки — есть часть документации проекта. Если их не вести и корректно с ними не работать — проект даже не начнется.
Если коснемся вопросов «передачи знаний» при найме нового человека или «умер» участник команды, оценки последствий «а как эта фича повлияет на предыдущие» и что делать если возник конфликт хотелок 5, 8 и 16 спринтами — без вменяемой документации фиг разобраться.
Добавим сюда «разбор полетов» после спринта и, конечно, Burn down chart…
Так что та еще сказка.

Сотрудничество с заказчиком важнее согласования условий контракта

Ну ну… Этим кто-то будет себя успокаивать, когда будет продавать квартиру или почку что бы покрыть убытки клиента согласно условиям контрата :)) Банку будет пофиг, когда потребует возврат кредита с процентами :))

Готовность к изменениям важнее следования первоначальному плану

А вот с этим на 100% согласен. Только есть один нюанс — «водопад» не запрещает вносить измененния по ходу проекта :)
image
Waterfall или существует другое представление данной методологии? Не раз возникали ситуации, когда не согласен со спецификацией, «спущенной сверху»… но договор подписан и суммы озвучены. В случае с Continues Integration, Agile/Scrum выглядит куда привлекательней лично для меня, Product Owner на каждом StandUp, можно высказаться и скорректировать развитие продукта.

Scrum — лишь один из множества в семействе Agile, но даже при нем
без соблюдения методологии и «Scrum board» просто… не выполнит своего предназначения

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

Если коснемся вопросов «передачи знаний» при найме нового человека или «умер» участник команды

Проще не брать нового человека, скорость разработки всегда существенно проседает. Перенабор команды происходит после потери более 3 разработчиков, minimal points rate при этом обнуляется и начинаются экспериментальные спринты для установки новой медианы.
что делать если возник конфликт хотелок 5, 8 и 16 спринтами — без вменяемой документации фиг разобраться.

Абсолютно не понял, как может возникнуть конфликт, если каждый спринт заканчивается релизом в production. 5 фича противоречит 8му спринту? не вопрос, обсудим на Refinement Session, выкосим функционал или перенастроим под 8ку. В 16м захотелось перебить функционал. Да не вопрос… В этом и есть весь смысл, в отсутствии противоречий в требованиях, даже если они противоречат себе из спринта в спринт. Заказчик значит захотел поэкспериментировать, имеет право.

Этим кто-то будет себя успокаивать, когда будет продавать квартиру или почку что бы покрыть убытки клиента согласно условиям контрата :)) Банку будет пофиг, когда потребует возврат кредита с процентами

Какой-то уж больно жирный троллинг… Обычное долгосрочное делегирование разработчиков напрямую заказчику. Клиент сам покрывает свои убытки, если таковые случаются; а бездарное составление контрактов никакого отношения к вопросу методологий не имеет.

Каждая модель имеет право на жизнь пока имеет своих адептов. Поэтому, даже если что-то не вклинивается в парадигму, непринятие лучше провокационного словоблудия.
Не раз возникали ситуации, когда не согласен со спецификацией, «спущенной сверху»… но договор подписан и суммы озвучены

А причем тут «не согласен со спецификацией»? Ты кто? Ты что ?! Ты зонтик! (с) «Мультики: Мой друг зонтик»
но договор подписан и суммы озвучены.

Никакая религия не запрещает сделать дополнение к контракту, согласно вновь открытых обстоятельств, и юридически корректно провести. Этим ПМ занимается.

В этом и есть весь смысл, в отсутствии противоречий в требованиях,

Банальное: 15..20 спринтов пилили платежку «с преферансом и стразиками». Потом вспомнили, что PCI DSS сертификация нужна. Дооолго будете искать «на пальцах» что и куда в системе распихано и хранится и в каком виде и вообще как это все приводить во вменяемое состояние… Знаю одну контору что разорилась на таком просто «Scrum» и была продана с дисконтом 75% :)))

можно высказаться и скорректировать развитие продукта.

Смешно… с личиком в калашный ряд. Вы можете скорректировать разработку продукта (выбрать контролы, базу данных и т.д.) но не его развитие.
Развитие — это бизнес цели Клиента. А вы не знаете ни рынка, ни маркетинговых предпосылок, ни предметной области, и не несете никакой юридической и финансовой ответственности ни перед собственниками ни перед акционерами Клиента/Заказчика за результат который принесет Продукт по вашим «рекомндациям».
Ваша задача — уменьшать риски, но никак не провоцировать новые.

Какой-то уж больно жирный троллинг…

Это когда вы собственной рукой будете подписывать контракт и брать на себя юридические и финансовые обязательства перед Клиентом — выглядит чуть по другому.
А пока «ты зонтик» и максимум что тебе грозит просто не выплата з/п за месяц и увольнение — можно считать все «тролингом».
Хватит скатываться во флейм с элементами нарциссизма. Вы понятия не имеете, с кем общаетесь (собственно, как и я)… поэтому любой переход на личности с голословными обвинениями не более чем элементы черной риторики для смещения фокуса с непосредственной темы.

Никакая религия не запрещает сделать дополнение к контракту, согласно вновь открытых обстоятельств, и юридически корректно провести. Этим ПМ занимается

В рамках Watefall, когда каждую из итераций представляет отдельно взятая фирма (или несколько фирм), ни о каких дополнениях к соглашению речи не идет. Препирательства по архитектуре решения приводят к замене человека / команды / фирмы на более сговорчивых согласно представленному ТЗ.

Банальное: 15..20 спринтов пилили платежку «с преферансом и стразиками». Потом вспомнили, что PCI DSS сертификация нужна

Если после 20 релизов заказчику (и пользователям) не понадобилась PCI DSS, так может она и не нужна была? За год то можно было выявить отсутствие краеугольных камней. А если не было вывода кода на реальные сервера, то при чем здесь Scrum? Аккредитованный Scrum Master с уровнем Solution/Sofrware Architect? Сертифицированные разработчики в команде с уровнем Senior? Scrum Master не следил за целостностью проекта? Документация не велась вообще? А тесты?

Если согнать студентов и назвать Scrum Team,… да еще и оставить их наедине с задачей на год или два, то эффекта в лучшем случае не будет. Отсутствие должной компетенции всегда продуцирует проблемы. Да и нет волшебной методологии, гарантирующей 100% успех… к слову:
image

Scrum предполагает высокую степень самоорганизации, соответствующей квалификации и мотивации всех членов команды. И если считать своё мнение превыше метров IT; а фамилии Фаулер, Бек и Дейв — воспринимать как пустой звук; то дискуссия в принципе завершена.
В рамках Watefall, когда каждую из итераций представляет отдельно взятая фирма (или несколько фирм), ни о каких дополнениях к соглашению речи не идет.

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


Если после 20 релизов заказчику (и пользователям) не понадобилась PCI DSS, так может она и не нужна была?

Была не нужна, а потом понадобилась, когда выяснилось, что значительная часть пользователей отваливается на этапе перехода на сторонний сайт — уходят и не возвращаются. Нормальная ситуация — ошибка определения предпочтений ЦА. Не менее редкая — неправильная оценка правового поля юристами заказчика и(или) изменения этого поля и(или) смена юрисдикции заказчика.

Хватит скатываться во флейм с элементами нарциссизма. Вы понятия не имеете, с кем общаетесь (собственно, как и я)… поэтому любой переход на личности с голословными обвинениями не более чем элементы черной риторики для смещения фокуса с непосредственной темы.

Я, в общем, никого ни в чем не обвинял. Если приняли это на свой счет, значит не верно выразил свою мысль. Приношу извинения.

Препирательства по архитектуре решения приводят к замене человека / команды / фирмы на более сговорчивых согласно представленному ТЗ.

Кто платит тот и музыку заказывает. Бизнес. Ничего личного.

За год то можно было выявить отсутствие краеугольных камней.

Упсъ… это же Scrum Agile. зачем смотреть «вперед»? итерацию сделали — и ладушки.

Документация не велась вообще?

А как же указанный выше принцип «Работающий продукт важнее исчерпывающей документации»? продукт работал. Scrum заветы выполнены :)

Scrum Master с уровнем Solution/Sofrware Architect?

Нет. Сертификацированного не было. Полагаете именно в этом дело?
оставить их наедине с задачей на год или два, то эффекта в лучшем случае не будет.

Product Owner регулярно закидывал новые хотелки
А если не было вывода кода на реальные сервера

Scrum обязательно требует «рабочих серверов»? Вроде нет. А так были даже некоторые клиенты этой системы.

И если считать своё мнение превыше метров IT; а фамилии Фаулер, Бек и Дейв — воспринимать как пустой звук; то дискуссия в принципе завершена.

Я в общем-то отвык верить на слово, даже джентельменам.
Я привык видеть «value и их cost & profit» решения и по ним сравнивать. И пока мне не представят «сравнительную табличку» с costs сравниваемых решений — любые мэтры мне пофигу. Не получится сослаться на Фаулер, Бек и Дейв в случае если Клиенту не сделан продукт и был нанесен ущерб.
У этих уважаемых джентельменов value и их cost & profit были указаны.

В мире, идут сначала юридические соглашения, в которых платят реальными деньгами/активами. А уже после идут всякие Scrum Waterfall и прочие для исполнения этих юридических соглашений. Разработник на своей з/п этого не видит, ибо это не входит в круг его понятий да и ответственноти тоже. С этой точки зрения Сотрудничество с заказчиком важнее согласования условий контракта — выглядит забавно, поскольку это Сотрудничество ограничено уже заключенным контрактом.

Да и нет волшебной методологии, гарантирующей 100% успех… к слову:

А статистика что вы показали:
  • Так 100% умерших оказались с рыжей бородой и пили морковный сок хоть раз в жизни. Умерли, правда, от старости :)
  • Полагаю, что из этой статистики исключили плотину Гувера, запуск на луну, египетские пирамиды и собор «какой-то-там-матери». Врядли их делали по Scrum :)
Это я к тому, что было бы интересно посмотреть первоисточник этой статистики и методологию расчета. Без этого — не более чем прикольная картинка.
NASA работал и продолжает работать в рамках Scrum методологии

И да, Agile/Scrum требует, чтобы по завершению каждого спринта изменения уходили в LIVE.

И пока мне не представят «сравнительную табличку»

«value и их cost & profit» в силу вполне явных причин указывать не в праве, но переход с Watefall на Agile/Scrum c 3 недельным циклом дал ускорение разработке на ~30% и снизил рейт оплат на ~60%. Сам проект стабилен уже больше двух лет после миграции. Code Coverage по критическим модулям не ниже 95%, покрытие увеличивается каждый спринт и является обязательной частью разработки (Team City, Test Rail, Robot Framework, PHPUnit, JUnit, Jasmine). Документация через JIRA/Confluence обновляется через User Story и от изменений в коде, каждый push происходит через линковку с JIRA тикетом, что отражается в логах; ну и Api Gen никто не отменял.

Дело всегда в отсутствии должных знаний:
«Огромное число людей, помноженное на низкую квалификацию и чудовищный спрос, рождает высокую необъективную самооценку, невежество, илитизм» Perl Power
«Низкая квалификация ведет к незнанию стандартов, а высокая самооценка ведет к их игнорированию» Perl Power
И да, Agile/Scrum требует, чтобы по завершению каждого спринта изменения уходили в LIVE.

Давайте обратимся к первоисточнику
The Definitive Guide to Scrum: The Rules of the Game
©2016 Scrum.Org and ScrumInc. Offered for license under the Attribution Share-Alike license of Creative Commons, accessible at http ://creativecommons.org/licenses/by -sa/4.0/legalcode and also described in summary form at http ://creativecommons.org/licenses/by -sa/4.0/.
By utilizing this Scrum Guide y ou acknowledge and agree that you have read and agree to be bound by the terms of the Attribution Share-Alike license of Creative Commons.

Scrum Artifacts
  • Increment
    The Increment is the sum of all the Product Backlog items completed during a Sprint and the value of the increments of all previous Sprints. At the end of a Sprint, the new Increment must be “Done,” which means it must be in useable condition and meet the Scrum Team’s definition of “Done.” It must be in useable condition regardless of whether the Product Owner decides to actually release it.
    Инкремент продукта
    Инкремент продукта – новая функциональность продукта, созданная во время спринта спринта.


Что-то не заметно тут слов production/ live server и т.д.

Watefall на Agile/Scrum c 3 недельным циклом дал ускорение разработке на ~30% и снизил рейт оплат на ~60%

Я за НАСА безумно рад.
В общем-то ради этих денег бизнес и потребовал Agile методологий, потому что ИТ просто не был компетентен в предметных областях и просто не успевал за бизнесом. Поэтому бизнес начал просто «кушать слона по кусочкам», бизнес аналитиков вывел за штат ИТ проектов оставив техническую сторону технарям, а бизнес у бизнеса.
Only those users with full accounts are able to leave comments. Log in, please.