Комментарии 30
НЛО прилетело и опубликовало эту надпись здесь
Люди и взаимодействие важнее процессов и инструментов.
Только это, почему-то — главное, что пропускают те, кто внедряет любую методологию, из-за чего она, как правило, превращается в карго-культ, где инструменты считаются магическими, а люди должны выполнять с ними ритуальные действия, веря в результат этой магии. Проблема, скорее всего, в том, что внедрение методологий слишком часто мотивировано изначально чем-то вроде желания найти магический инструмент. Так что результат оказывается заранее обречён, если не дойдет до избавления от тех, кто это с такой мотивацией инициировал.
Люди и взаимодействие важнее процессов и инструментов.
Да, только люди и взаимодействие — это внезапно и есть инструменты и процессы.
Процессы нужно выстраивать так, чтоб люди друг другу в силу своего несовершенства не мешали. Аджайл на практике о другом — нужно удовлетворить большой кусок выдвинутых новым проектом ключевых требований быстро без регистрации и смс. Как только проект начинает работать на прибыль, процент задач по фидбеку начинает ощутимо влиять на все эти ваши атомарные спринты, приходится вносить коррективы, аджайл становится не таким уж и аджайлом. Приходит момент менять методологию.
Каждому этапу свой процесс.
Неявно вы всё равно примените какую-либо методологию. Профессионалы знают, как делать, но они точно так же не знают, что именно нужно сделать. Для этого нужно или разработать ТЗ, как в классических методологиях, или «выдавливать» его из заказчика постепенно, как в Agile.Профессионалы чего? Человек который умеет профессионально создавать продукты, коммуницировать и руководить отлично справится без аджайла и метдологий.
Спасибо за заметку!
Можете поделиться опытом положительном работы в команде где не нужна метадология? Интересно сколько было человек, как организовывали работы(в общих чертах), сколько лет команда собиралась и подстраивалась, сколько команда просуществовала.
Какая-то мешанина.
Scrum ставится на одну полку с Agile (про упомянутый DevOps я вообще молчу).
Ссылка на статью от 1999 года (это за шесть лет до Agile Manifesto).
Попытки натянуть сову на глобус, говоря что методология — это «причина успеха/провала проекта», а потом доблестное опровержение этого посыла (внезапно, все более-менее менеджеры в курсе, что методология — инструмент, равно как и IDE, язык разработки и прочие баг-трекинги).
Не буду задавать простой вопрос про то, чем отличается Scrum от Agile. ;)
Спрошу лучше следующее: Согласно упомянутому Коуберну, Scrum является «меньшей» методологией, чем Waterfall или «большей»?
Scrum ставится на одну полку с Agile (про упомянутый DevOps я вообще молчу).
Ссылка на статью от 1999 года (это за шесть лет до Agile Manifesto).
Попытки натянуть сову на глобус, говоря что методология — это «причина успеха/провала проекта», а потом доблестное опровержение этого посыла (внезапно, все более-менее менеджеры в курсе, что методология — инструмент, равно как и IDE, язык разработки и прочие баг-трекинги).
Не буду задавать простой вопрос про то, чем отличается Scrum от Agile. ;)
Спрошу лучше следующее: Согласно упомянутому Коуберну, Scrum является «меньшей» методологией, чем Waterfall или «большей»?
А что, принципиально, поменялось с 1999 года?
Чем вам не угодил DevOps? Это набор практик, методология, направленная подружить разработку и сопровождение, наладить быструю и безболезненную доставку продукта.
Водопадная модель процесса, безусловно, является более «тяжелой» по сравнению со Scrum.
Чем вам не угодил DevOps? Это набор практик, методология, направленная подружить разработку и сопровождение, наладить быструю и безболезненную доставку продукта.
Водопадная модель процесса, безусловно, является более «тяжелой» по сравнению со Scrum.
У вас:
В статье:
У Scrum, думаю, больше 30 элементов наберётся. А у Waterfall сколько?
Водопадная модель процесса, безусловно, является более «тяжелой» по сравнению со Scrum.
В статье:
Под «размером» методологии я имею в виду число элементов управления в ней, к которым относятся поставляемые артефакты, стандарты, виды деятельности, меры качества и т.д.
У Scrum, думаю, больше 30 элементов наберётся. А у Waterfall сколько?
del
НЛО прилетело и опубликовало эту надпись здесь
Рассмотрим разработку критического программного обеспечения, например, систему управления атомной электростанцией или пилотируемого аппарата. Все требования заранее известны, на продукт есть обширная техническая документация, есть ГОСТы и т.д. Неудивительно, что в данных проектах используются «тяжеловесные» методологии.
Вам не кажется, что вы противоречите себе в этом абзаце? Если все требования известны, есть документация и даже ГОСТ, то к чему тогда городить проект? ;) Взяли бы и всё сделали как по инструкции. Если есть проект, то значит есть та степень неопределенности, которая не позволяет успешно завершить начатое в приемлемый срок без соответствующего управленческого подхода.
«Не тренер важен – важны вы. Вы выигрываете дуэли на поле и целые матчи, а мы только немного вам помогаем. Мы можем расставить футболистов и сориентировать – остальное делают игроки»
А теперь идите и сделайте то, в чём вы разбираетесь лучше менеджера. Он-то свою работу уже проделал на отлично — грамотно вас промотивировал.
Проект — это не только документация и требования. Это также планирование, управление качеством, стоимостью, рисками, людьми, коммуникациями и много что еще. Всем этим часто и занимается методология разработки.
Так что нет, я не противоречу себе.
Так что нет, я не противоречу себе.
По-моему, вы путаете методологию разработки и методологию управления разработкой.
Хорошо, тогда поясните, пожалуйста, где по вашему мнению граница между методологией разработки и методологией управления разработкой?
Методология управления разработкой это о задачах, сроках, рисках и т. п. А методология разработки — это о том как писать код, cнизу вверх или сверху вниз, TDD и прочие *DD.
Ок, в ваших терминах моя статья про «методологии управления разработкой». Однако, везде в литературе «методологии управления разработкой» == «методологии разработки».
То, что вы подразумеваете под методологией разработки («как писать код, cнизу вверх или сверху вниз, TDD и прочие *DD») — это программистские техники и практики.
Отвечая на ваш вопрос сверху: Нет я ничего не путаю и не смешиваю, я хорошо разбираюсь в вопросе.
То, что вы подразумеваете под методологией разработки («как писать код, cнизу вверх или сверху вниз, TDD и прочие *DD») — это программистские техники и практики.
Отвечая на ваш вопрос сверху: Нет я ничего не путаю и не смешиваю, я хорошо разбираюсь в вопросе.
Менеджеры, управленцы, проснитесь! Главные в успехе проекта – не руководитель, не процесс, а люди, которые в нем работают.
Закончить хочу цитатой одного из тренеров по футболу: «Не тренер важен – важны вы. Вы выигрываете дуэли на поле и целые матчи, а мы только немного вам помогаем. Мы можем расставить футболистов и сориентировать – остальное делают игроки».
А потом жизнь расставляет все на свои места. Оказывается, что хороший руководитель — все таки ключевое условие успеха компании. Оказывается, что средненькая команда с хорошим руководителем дает результат лучше, чем хорошая команда, со средненьким руководителем. Оказывается, что плохой руководитель способен угробить отличную команду, а хороший — слепить из слабых сотрудников сильную команду, способную решать любые задачи в своей области.
Слова футбольного тренера — это конечно хорошо. Но когда вы собираете футбольную команду, лучше начинать с хорошего тренера.
Все правильно вы пишите! Однако Пеп Гвардиола не выиграет с текущим Спартаком Лигу Чемпионов, каким крутым бы тренером он не был.
Во всем должен быть баланс, да.
Во всем должен быть баланс, да.
Для успеха важны и исполнители, и руководитель. В какой именно степени они важны в каждом конкретном случае — определяется условиями, в которых они работают, включая всё, от решаемых задач, до законодательства страны, в которой происходит дело. Общие утверждения о том, что «средний + хорошие», например, хуже, чем «хороший + средние» слишком абстрактны, чтобы вообще иметь смысл.
.
НЛО прилетело и опубликовало эту надпись здесь
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Scrum и Agile не спасут ваш проект от провала