Подозреваю что те, кто не хочет прочитать PMOK, создают мифы про него :)
Вы затронули очень важную тему. Я бы продолжил ее следующим образом: «Подозреваю, что все противостояние между методологиями развивают люди, которые не потрудились из изучить»
Чаще всего, в сравнении Waterfall и Agile происходит сравнение нечто, что нельзя отнести ни к какой-то Agile методологии, ни к Waterfall
Наличие ТЗ, после которого «херачим » до окончания срока, а потом мучаемся на этапе сдачи продукта, потому как Заказчик получил вообще не то, что хотел. И снова «дохерачиваем», чтобы подписать акт о приёмо-передачи — Это НЕ Waterfall. Это разработка «на коленке» с наличием какого-то ТЗ.
Наличие понятия Спринта, хотя продолжается то же самое «херачим» что-то, но каждые 2-3 недели смотрим, на то, что получилось, и снова «херачим» код. А потом и вообще забываем даже о том, для чего нам Спринты. Без цели спринта, без фидбэка со стороны заказчика, без постоянного процесса интеграции, без переоценки Бэклога — Это не Scrum. Это снова разработка «на коленке»
Вот и выходит, что не зависимо от используемых терминов, довольно часто сравниваются не методологии, а очень искаженное представление о них.
Waterfall — это один из «китов» проектного менеджмента. Причем с очень широкой областью применения и степенью распространенности. Мне кажется, в этом причина подобных сравнений.
Но следует отметить, что Project Management Institute (PMI) , авторы PMBOK (руководство, на котором основывается Waterfall), организация, выдающая один из самых уважаемых и признаваемых сертификатов в области проектного менеджмента — PMP, также выдает сертификаты в области управления проектами посредствам Agile методологий — PMI-ACP.
Этот факт, по моему мнению, свидетельствует о том, что даже PMI признает Agile, понимая его различия в сравнении с Waterfall, и разные области применения. Признает право на существование различных подходов.
Уважаемый http2, во первых с утверждений начали Вы.
А ниче, что Agile никакая не гибкая методология?.. :)
При этом несколько раз вас просили объяснить, как вы пришли к такому мнению, чем, что, и по каким параметрам мерили? Ответа вы так и не дали.
Эти вопросы я задавал, чтобы разговор был предметным. Потому как иначе придется угадывать, о чем именно вы имели в виду, так как первое, что я предположил, что Вы хотите обсудить некоторые проблемы каких-то из методологий семейства Agile.
Сейчас же это выглядет так, что Вы не владеете темой, и высказали утверждение, которое принадлежит не Вам. Хотя опыта я вашего и не знаю, и что-то утверждать было бы неправильным с моей стороны.
Итак, «Agile никакая не гибкая методология?»
1) «Agile» переводится на русский, как «Гибкий». Поэтому наверняка вы сравнивали с Водопадной моделью не по смыслу в названии
2) Agile — это не методология. Это семейство методологий, которые придерживаются Agile Манифеста . Это такие методологии, как Kanban, Lean Six Sigma, XP, Scrum. Это разные методологии, имеющие разные степени ограничений.
3) Если сравнивать Scrum, описанный в этой статье, с Водопадной моделью, то Скрам «гибче» в следующих моментах:
— В Скрам есть только 2 жестоких ограничения во время выполнения проекта:
— — Длительность Спринта после его начала
— — Цель Спринта
Также есть пункты, которые говорят о том, что это Скрам. Если их не придерживаться, то это уже не Скрам. Например: единственная роль в Дев. команде, это Разработчик, не зависимо от специализации сотрудника (ДБА, Тестировщих, Кодер, Аналитик и т.д.). Или то, что результатом любого Спринта должен быть потенциально «Готовый» к релизу инкремент продукта.
Водопадная модель имеет жесткие ограничения по разрабатываемому функционалу (ТЕхническому заданию) и срокам разработки (Планом проекта). Можно мне возразить, что в водопадной модели предполагаются заложенные риски, в рамках которых можно что-то поменять? Но это тоже жесткие сроки, которые выделяются на возможные риски в соответствии с их оценкой. Не заложенные изменения можно сделать в рамках «не критического пути», что все-равно не отменяет наличие «критического пути» с его спланированными сроками.
То есть, отличия в самой концепции, подходе к разработке, заложенные в основу каждой из методологий.
4) Ни один опытный человек (как я считаю) не скажет что Водопадная модель — хуже или лучше, к примеру Скрам. Потому как они просто разные. Каждая имеет свои плюсы и минусы. И каждая имеет области наилучшего применения.
То есть можно сказать, что в каком-то конкретном случае Водопадная модель будет работать хуже/лучше Agile модели. Но не в общем.
5) И последнее: Нельзя судить о самой методологии, основываясь на примере ее кривого применения. Как вы сказали, в умелых руках Водопадная модель отлично работает! И я с вами согласен. И добавлю, что в умелых руках, когда человек понимает разницу, плюсы, минуса и области применения, все хорошо работает.
Уважаемый http2, если Вы хотите обсудить какие-то тонкости, прошу Вас, делая утверждения, все-же давать объяснения, на чем эти утверждения основаны. Это поможет не угадывать, что именно вы имели в виду, пытаясь написать Вам ответ.
Не понимаю вашего ответа.
Сначала вы утверждаете, что:
«Agile никакая не гибкая методология»
А на вопрос, что вы понимаете под понятием «гибкости», то есть по каким параметрам сравниваете, вы отвечаете:
«Я хз.»
Также:
«В том значении, в котором это слово используется в словосочетании «гибкая методология»»
Если говорить об этом значении слова «Гибкость», то хотелось бы узнать ваше мнение, на чем основано ваше утверждение:
водопад в умных руках гибче
Но даже в этом случае, предполагаю, что возможно разночтение словосочетания «Гибкая методология». Поэтому для начала хочу спросить, что оно означает в вашем понимании?
Также можно сказать, что в умелых руках — все будет работать хорошо. В неумелых — все плохо. А также следует четко понимать, что каждая методология имеет свою плюсы и минусы, и области применения.
Но для того, чтобы разговор был предметным, не могли бы вы пояснить ваше понимание слова «Гибкости» в данном контексте.
В статье говорится о том, что есть два противоречащих утверждения (в руководстве PMBOK и в книге Брукса «Мифический человеко-месяц»), и оба эти утверждения доказали свою состоятельность.
Причина этому противоречию в понятии «ресурс» в каждом из высказываний. Руководство PMBOK — это более общее руководство по управлению проектами в различных сферах. И понятие «ресурса» в PMBOK включает больше, чем сотрудники, тем более сотрудники, разрабатывающие новый «продукт». И именно о таких сотрудниках говорит Фред Брукс.
То есть противоречия на самом деле нет, если брать во внимание, что Брукс говорит о «нематериальных» ресурсах, а PMBOK обобщает понятие ресурса.
Чаще всего, в сравнении Waterfall и Agile происходит сравнение нечто, что нельзя отнести ни к какой-то Agile методологии, ни к Waterfall
Наличие ТЗ, после которого «херачим » до окончания срока, а потом мучаемся на этапе сдачи продукта, потому как Заказчик получил вообще не то, что хотел. И снова «дохерачиваем», чтобы подписать акт о приёмо-передачи — Это НЕ Waterfall. Это разработка «на коленке» с наличием какого-то ТЗ.
Наличие понятия Спринта, хотя продолжается то же самое «херачим» что-то, но каждые 2-3 недели смотрим, на то, что получилось, и снова «херачим» код. А потом и вообще забываем даже о том, для чего нам Спринты. Без цели спринта, без фидбэка со стороны заказчика, без постоянного процесса интеграции, без переоценки Бэклога — Это не Scrum. Это снова разработка «на коленке»
Вот и выходит, что не зависимо от используемых терминов, довольно часто сравниваются не методологии, а очень искаженное представление о них.
Но следует отметить, что Project Management Institute (PMI) , авторы PMBOK (руководство, на котором основывается Waterfall), организация, выдающая один из самых уважаемых и признаваемых сертификатов в области проектного менеджмента — PMP, также выдает сертификаты в области управления проектами посредствам Agile методологий — PMI-ACP.
Этот факт, по моему мнению, свидетельствует о том, что даже PMI признает Agile, понимая его различия в сравнении с Waterfall, и разные области применения. Признает право на существование различных подходов.
Эти вопросы я задавал, чтобы разговор был предметным. Потому как иначе придется угадывать, о чем именно вы имели в виду, так как первое, что я предположил, что Вы хотите обсудить некоторые проблемы каких-то из методологий семейства Agile.
Сейчас же это выглядет так, что Вы не владеете темой, и высказали утверждение, которое принадлежит не Вам. Хотя опыта я вашего и не знаю, и что-то утверждать было бы неправильным с моей стороны.
Итак, «Agile никакая не гибкая методология?»
1) «Agile» переводится на русский, как «Гибкий». Поэтому наверняка вы сравнивали с Водопадной моделью не по смыслу в названии
2) Agile — это не методология. Это семейство методологий, которые придерживаются Agile Манифеста . Это такие методологии, как Kanban, Lean Six Sigma, XP, Scrum. Это разные методологии, имеющие разные степени ограничений.
3) Если сравнивать Scrum, описанный в этой статье, с Водопадной моделью, то Скрам «гибче» в следующих моментах:
— В Скрам есть только 2 жестоких ограничения во время выполнения проекта:
— — Длительность Спринта после его начала
— — Цель Спринта
Также есть пункты, которые говорят о том, что это Скрам. Если их не придерживаться, то это уже не Скрам. Например: единственная роль в Дев. команде, это Разработчик, не зависимо от специализации сотрудника (ДБА, Тестировщих, Кодер, Аналитик и т.д.). Или то, что результатом любого Спринта должен быть потенциально «Готовый» к релизу инкремент продукта.
Водопадная модель имеет жесткие ограничения по разрабатываемому функционалу (ТЕхническому заданию) и срокам разработки (Планом проекта). Можно мне возразить, что в водопадной модели предполагаются заложенные риски, в рамках которых можно что-то поменять? Но это тоже жесткие сроки, которые выделяются на возможные риски в соответствии с их оценкой. Не заложенные изменения можно сделать в рамках «не критического пути», что все-равно не отменяет наличие «критического пути» с его спланированными сроками.
То есть, отличия в самой концепции, подходе к разработке, заложенные в основу каждой из методологий.
4) Ни один опытный человек (как я считаю) не скажет что Водопадная модель — хуже или лучше, к примеру Скрам. Потому как они просто разные. Каждая имеет свои плюсы и минусы. И каждая имеет области наилучшего применения.
То есть можно сказать, что в каком-то конкретном случае Водопадная модель будет работать хуже/лучше Agile модели. Но не в общем.
5) И последнее: Нельзя судить о самой методологии, основываясь на примере ее кривого применения. Как вы сказали, в умелых руках Водопадная модель отлично работает! И я с вами согласен. И добавлю, что в умелых руках, когда человек понимает разницу, плюсы, минуса и области применения, все хорошо работает.
Уважаемый http2, если Вы хотите обсудить какие-то тонкости, прошу Вас, делая утверждения, все-же давать объяснения, на чем эти утверждения основаны. Это поможет не угадывать, что именно вы имели в виду, пытаясь написать Вам ответ.
Сначала вы утверждаете, что:
А на вопрос, что вы понимаете под понятием «гибкости», то есть по каким параметрам сравниваете, вы отвечаете:
Также:
Если говорить об этом значении слова «Гибкость», то хотелось бы узнать ваше мнение, на чем основано ваше утверждение: Но даже в этом случае, предполагаю, что возможно разночтение словосочетания «Гибкая методология». Поэтому для начала хочу спросить, что оно означает в вашем понимании?
Также можно сказать, что в умелых руках — все будет работать хорошо. В неумелых — все плохо. А также следует четко понимать, что каждая методология имеет свою плюсы и минусы, и области применения.
Но для того, чтобы разговор был предметным, не могли бы вы пояснить ваше понимание слова «Гибкости» в данном контексте.
Причина этому противоречию в понятии «ресурс» в каждом из высказываний. Руководство PMBOK — это более общее руководство по управлению проектами в различных сферах. И понятие «ресурса» в PMBOK включает больше, чем сотрудники, тем более сотрудники, разрабатывающие новый «продукт». И именно о таких сотрудниках говорит Фред Брукс.
То есть противоречия на самом деле нет, если брать во внимание, что Брукс говорит о «нематериальных» ресурсах, а PMBOK обобщает понятие ресурса.