Scrum и Agile не спасут ваш проект от провала

[Moskus]

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

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

[Moskus]

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

[InOdinWeTrust]

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

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

[vyatsek]

Неявно вы всё равно примените какую-либо методологию. Профессионалы знают, как делать, но они точно так же не знают, что именно нужно сделать. Для этого нужно или разработать ТЗ, как в классических методологиях, или «выдавливать» его из заказчика постепенно, как в Agile.

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

[VolCh]

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

[time2rfc]

Спасибо за заметку!
Можете поделиться опытом положительном работы в команде где не нужна метадология? Интересно сколько было человек, как организовывали работы(в общих чертах), сколько лет команда собиралась и подстраивалась, сколько команда просуществовала.

[Imbecile]

Какая-то мешанина.
Scrum ставится на одну полку с Agile (про упомянутый DevOps я вообще молчу).
Ссылка на статью от 1999 года (это за шесть лет до Agile Manifesto).
Попытки натянуть сову на глобус, говоря что методология — это «причина успеха/провала проекта», а потом доблестное опровержение этого посыла (внезапно, все более-менее менеджеры в курсе, что методология — инструмент, равно как и IDE, язык разработки и прочие баг-трекинги).
Не буду задавать простой вопрос про то, чем отличается Scrum от Agile. ;)
Спрошу лучше следующее: Согласно упомянутому Коуберну, Scrum является «меньшей» методологией, чем Waterfall или «большей»?

[digore]

А что, принципиально, поменялось с 1999 года?
Чем вам не угодил DevOps? Это набор практик, методология, направленная подружить разработку и сопровождение, наладить быструю и безболезненную доставку продукта.
Водопадная модель процесса, безусловно, является более «тяжелой» по сравнению со Scrum.

[Imbecile]

У вас:

Водопадная модель процесса, безусловно, является более «тяжелой» по сравнению со Scrum.

В статье:

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

У Scrum, думаю, больше 30 элементов наберётся. А у Waterfall сколько?

[digore]

Вы точно разбираетесь в сути вопроса и представляете, что такое Scrum и Waterfall?
Работали по обоим процессам разработки?

Меряться не буду.

[Imbecile]

Да, работал. А ещё по RUP. И имею представление.

[digore]

Ну, раз вы продвинутый пользователь, то без труда перечислите для всех 30 артефактов и практик «скрама»!

[Imbecile]

del

[uzverkms]

Рассмотрим разработку критического программного обеспечения, например, систему управления атомной электростанцией или пилотируемого аппарата. Все требования заранее известны, на продукт есть обширная техническая документация, есть ГОСТы и т.д. Неудивительно, что в данных проектах используются «тяжеловесные» методологии.

Вам не кажется, что вы противоречите себе в этом абзаце? Если все требования известны, есть документация и даже ГОСТ, то к чему тогда городить проект? ;) Взяли бы и всё сделали как по инструкции. Если есть проект, то значит есть та степень неопределенности, которая не позволяет успешно завершить начатое в приемлемый срок без соответствующего управленческого подхода.

«Не тренер важен – важны вы. Вы выигрываете дуэли на поле и целые матчи, а мы только немного вам помогаем. Мы можем расставить футболистов и сориентировать – остальное делают игроки»

А теперь идите и сделайте то, в чём вы разбираетесь лучше менеджера. Он-то свою работу уже проделал на отлично — грамотно вас промотивировал.

[digore]

Проект — это не только документация и требования. Это также планирование, управление качеством, стоимостью, рисками, людьми, коммуникациями и много что еще. Всем этим часто и занимается методология разработки.
Так что нет, я не противоречу себе.

[VolCh]

По-моему, вы путаете методологию разработки и методологию управления разработкой.

[digore]

Хорошо, тогда поясните, пожалуйста, где по вашему мнению граница между методологией разработки и методологией управления разработкой?

[VolCh]

Методология управления разработкой это о задачах, сроках, рисках и т. п. А методология разработки — это о том как писать код, cнизу вверх или сверху вниз, TDD и прочие *DD.

[digore]

Ок, в ваших терминах моя статья про «методологии управления разработкой». Однако, везде в литературе «методологии управления разработкой» == «методологии разработки».
То, что вы подразумеваете под методологией разработки («как писать код, cнизу вверх или сверху вниз, TDD и прочие *DD») — это программистские техники и практики.
Отвечая на ваш вопрос сверху: Нет я ничего не путаю и не смешиваю, я хорошо разбираюсь в вопросе.

[VolCh]

Это инженерные методологии, а не управленческие.

[InOdinWeTrust]

Менеджеры, управленцы, проснитесь! Главные в успехе проекта – не руководитель, не процесс, а люди, которые в нем работают.

Закончить хочу цитатой одного из тренеров по футболу: «Не тренер важен – важны вы. Вы выигрываете дуэли на поле и целые матчи, а мы только немного вам помогаем. Мы можем расставить футболистов и сориентировать – остальное делают игроки».

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

Слова футбольного тренера — это конечно хорошо. Но когда вы собираете футбольную команду, лучше начинать с хорошего тренера.

[digore]

Все правильно вы пишите! Однако Пеп Гвардиола не выиграет с текущим Спартаком Лигу Чемпионов, каким крутым бы тренером он не был.

Во всем должен быть баланс, да.

[InOdinWeTrust]

Если посмотреть его историю, не таким уж и крутым тренером он был.

В истории можно найти примеры хороших тренеров, которые смогли сделать из середнячков чемпионские команды. Например, Херб Брукс и сборная США по хоккею.

[Moskus]

Для успеха важны и исполнители, и руководитель. В какой именно степени они важны в каждом конкретном случае — определяется условиями, в которых они работают, включая всё, от решаемых задач, до законодательства страны, в которой происходит дело. Общие утверждения о том, что «средний + хорошие», например, хуже, чем «хороший + средние» слишком абстрактны, чтобы вообще иметь смысл.

[digore]

.