Comments 30
UFO just landed and posted this here
Люди и взаимодействие важнее процессов и инструментов.
Только это, почему-то — главное, что пропускают те, кто внедряет любую методологию, из-за чего она, как правило, превращается в карго-культ, где инструменты считаются магическими, а люди должны выполнять с ними ритуальные действия, веря в результат этой магии. Проблема, скорее всего, в том, что внедрение методологий слишком часто мотивировано изначально чем-то вроде желания найти магический инструмент. Так что результат оказывается заранее обречён, если не дойдет до избавления от тех, кто это с такой мотивацией инициировал.
Люди и взаимодействие важнее процессов и инструментов.
Да, только люди и взаимодействие — это внезапно и есть инструменты и процессы.
Процессы нужно выстраивать так, чтоб люди друг другу в силу своего несовершенства не мешали. Аджайл на практике о другом — нужно удовлетворить большой кусок выдвинутых новым проектом ключевых требований быстро без регистрации и смс. Как только проект начинает работать на прибыль, процент задач по фидбеку начинает ощутимо влиять на все эти ваши атомарные спринты, приходится вносить коррективы, аджайл становится не таким уж и аджайлом. Приходит момент менять методологию.
Каждому этапу свой процесс.
Неявно вы всё равно примените какую-либо методологию. Профессионалы знают, как делать, но они точно так же не знают, что именно нужно сделать. Для этого нужно или разработать ТЗ, как в классических методологиях, или «выдавливать» его из заказчика постепенно, как в 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
UFO just landed and posted this here
Рассмотрим разработку критического программного обеспечения, например, систему управления атомной электростанцией или пилотируемого аппарата. Все требования заранее известны, на продукт есть обширная техническая документация, есть ГОСТы и т.д. Неудивительно, что в данных проектах используются «тяжеловесные» методологии.
Вам не кажется, что вы противоречите себе в этом абзаце? Если все требования известны, есть документация и даже ГОСТ, то к чему тогда городить проект? ;) Взяли бы и всё сделали как по инструкции. Если есть проект, то значит есть та степень неопределенности, которая не позволяет успешно завершить начатое в приемлемый срок без соответствующего управленческого подхода.
«Не тренер важен – важны вы. Вы выигрываете дуэли на поле и целые матчи, а мы только немного вам помогаем. Мы можем расставить футболистов и сориентировать – остальное делают игроки»
А теперь идите и сделайте то, в чём вы разбираетесь лучше менеджера. Он-то свою работу уже проделал на отлично — грамотно вас промотивировал.
Проект — это не только документация и требования. Это также планирование, управление качеством, стоимостью, рисками, людьми, коммуникациями и много что еще. Всем этим часто и занимается методология разработки.
Так что нет, я не противоречу себе.
Так что нет, я не противоречу себе.
По-моему, вы путаете методологию разработки и методологию управления разработкой.
Хорошо, тогда поясните, пожалуйста, где по вашему мнению граница между методологией разработки и методологией управления разработкой?
Методология управления разработкой это о задачах, сроках, рисках и т. п. А методология разработки — это о том как писать код, cнизу вверх или сверху вниз, TDD и прочие *DD.
Ок, в ваших терминах моя статья про «методологии управления разработкой». Однако, везде в литературе «методологии управления разработкой» == «методологии разработки».
То, что вы подразумеваете под методологией разработки («как писать код, cнизу вверх или сверху вниз, TDD и прочие *DD») — это программистские техники и практики.
Отвечая на ваш вопрос сверху: Нет я ничего не путаю и не смешиваю, я хорошо разбираюсь в вопросе.
То, что вы подразумеваете под методологией разработки («как писать код, cнизу вверх или сверху вниз, TDD и прочие *DD») — это программистские техники и практики.
Отвечая на ваш вопрос сверху: Нет я ничего не путаю и не смешиваю, я хорошо разбираюсь в вопросе.
Менеджеры, управленцы, проснитесь! Главные в успехе проекта – не руководитель, не процесс, а люди, которые в нем работают.
Закончить хочу цитатой одного из тренеров по футболу: «Не тренер важен – важны вы. Вы выигрываете дуэли на поле и целые матчи, а мы только немного вам помогаем. Мы можем расставить футболистов и сориентировать – остальное делают игроки».
А потом жизнь расставляет все на свои места. Оказывается, что хороший руководитель — все таки ключевое условие успеха компании. Оказывается, что средненькая команда с хорошим руководителем дает результат лучше, чем хорошая команда, со средненьким руководителем. Оказывается, что плохой руководитель способен угробить отличную команду, а хороший — слепить из слабых сотрудников сильную команду, способную решать любые задачи в своей области.
Слова футбольного тренера — это конечно хорошо. Но когда вы собираете футбольную команду, лучше начинать с хорошего тренера.
Все правильно вы пишите! Однако Пеп Гвардиола не выиграет с текущим Спартаком Лигу Чемпионов, каким крутым бы тренером он не был.
Во всем должен быть баланс, да.
Во всем должен быть баланс, да.
Для успеха важны и исполнители, и руководитель. В какой именно степени они важны в каждом конкретном случае — определяется условиями, в которых они работают, включая всё, от решаемых задач, до законодательства страны, в которой происходит дело. Общие утверждения о том, что «средний + хорошие», например, хуже, чем «хороший + средние» слишком абстрактны, чтобы вообще иметь смысл.
.
UFO just landed and posted this here
Sign up to leave a comment.
Scrum и Agile не спасут ваш проект от провала