– Примените Agile!
– Без достаточного количества людей он нам не поможет!
– Тогда придумайте другое умное слово!
Последнее время часто слышу: они провалились, потому что неправильно выбрали методологию разработки продукта. Вот если бы вы применили Scrum/DevOps/Agile/еще что-то, то все было бы хорошо. Похоже, эти люди кое-что не понимают в разработке софта.
Еще Алистер Коуберн в своей статье проанализировал разные программные проекты, которые выполнялись по разным моделям от совершенно «легких» и гибких до очень «тяжелых» и формализованных. Он не обнаружил корреляции между успехом или провалом проектов и моделями процесса разработки, которые применялись. Отсюда Коуберн сделал вывод о том, что эффективность разработки не зависит от модели процесса.
Существуют десятки методологий, но ни одна не гарантирует результат. В каждом новом проекте процесс должен определяться каждый раз заново. В основном, выбор процесса зависит от разрабатываемого продукта и людей, участвующих в разработке. Главный принцип: не люди должны строиться под выбранную модель процесса, а модель процесса должна подстраиваться под конкретную команду, чтобы обеспечить ее наивысшую производительность.
Продукт
Рассмотрим разработку критического программного обеспечения, например, систему управления атомной электростанцией или пилотируемого аппарата. Все требования заранее известны, на продукт есть обширная техническая документация, есть ГОСТы и т.д. Неудивительно, что в данных проектах используются «тяжеловесные» методологии.
Совершенно другие подходы следует применять при разработке нового модного веб-сервиса, когда требования нечеткие и постоянно меняются. Тут любимый всеми Scrum/Agile и подобные «легковесные» системы. Применение этих методологий оправдано, т.к. можно быстро получить обратную связь в условиях быстроменяющегося внешнего мира.
Сказанное выше можно также проецировать и на размер разрабатываемого продукта. Ведь совершенно разные процессы должны применяться в проектах, в которых участвуют 10 человек, и в проектах, в которых участвуют 1000 человек.
Люди
По-разному следует организовывать процесс разработки в команде студентов и в команде состоявшихся профессионалов.
Я всегда считал, что Scrum и другие методологии разработки – для тех людей, которые просто не могут самостоятельно работать. Я выделяю несколько типов команд и, в зависимости от этого, выстраиваю процессы внутри них.
- Команда профессионалов знает свое дело, как следует работать. Они могут взять на себя ответственность за результат – здесь не нужны методологии разработки, тем более навязанные сверху. Часто даже менеджер не нужен. Такие команды умеют работать самостоятельно, без постоянного контроля и всегда с завидным результатом.
- Команда опытных программистов требует периодического контроля и поддержки, но без жесткой постановки задач.
- Команда новичков же требует постоянной постановки задач, поддержки в решении, контроля сроков.
Руководители, изучайте свою команду и разумно выбирайте методологию разработки в каждом случае. Каждой команде нужна своя методология.
Главные задачи менеджера при этом состоит в том, чтобы:
- построить команду, которая сможет работать вместе на требуемый результат с достаточной эффективностью
- построить процесс работы внутри команды, чтобы он позволял сотрудникам удобным образом заниматься нужной работой
- настроить взаимодействие команды с другими подразделениями компании либо с заказчиком, чтобы общение проходило с минимумом помех основной работе команды и максимальной результативностью
- убрать все остальные преграды и препятствия для команды с пути достижения цели.
В последнее время приходится много собеседовать менеджеров по разработке. Примерно 7 из 10 кандидатов на вопрос о вашем главном достижении на текущем месте работы сообщает, что они стали главной частью успеха продукта, без них бы все провалилось.
Менеджеры, управленцы, проснитесь! Главные в успехе проекта – не руководитель, не процесс, а люди, которые в нем работают.
Закончить хочу цитатой одного из тренеров по футболу: «Не тренер важен – важны вы. Вы выигрываете дуэли на поле и целые матчи, а мы только немного вам помогаем. Мы можем расставить футболистов и сориентировать – остальное делают игроки».
Комментарии (30)
time2rfc
20.11.2018 14:12+1Спасибо за заметку!
Можете поделиться опытом положительном работы в команде где не нужна метадология? Интересно сколько было человек, как организовывали работы(в общих чертах), сколько лет команда собиралась и подстраивалась, сколько команда просуществовала.
Imbecile
20.11.2018 14:54-1Какая-то мешанина.
Scrum ставится на одну полку с Agile (про упомянутый DevOps я вообще молчу).
Ссылка на статью от 1999 года (это за шесть лет до Agile Manifesto).
Попытки натянуть сову на глобус, говоря что методология — это «причина успеха/провала проекта», а потом доблестное опровержение этого посыла (внезапно, все более-менее менеджеры в курсе, что методология — инструмент, равно как и IDE, язык разработки и прочие баг-трекинги).
Не буду задавать простой вопрос про то, чем отличается Scrum от Agile. ;)
Спрошу лучше следующее: Согласно упомянутому Коуберну, Scrum является «меньшей» методологией, чем Waterfall или «большей»?digore Автор
20.11.2018 15:11А что, принципиально, поменялось с 1999 года?
Чем вам не угодил DevOps? Это набор практик, методология, направленная подружить разработку и сопровождение, наладить быструю и безболезненную доставку продукта.
Водопадная модель процесса, безусловно, является более «тяжелой» по сравнению со Scrum.Imbecile
20.11.2018 15:28-1У вас:
Водопадная модель процесса, безусловно, является более «тяжелой» по сравнению со Scrum.
В статье:
Под «размером» методологии я имею в виду число элементов управления в ней, к которым относятся поставляемые артефакты, стандарты, виды деятельности, меры качества и т.д.
У Scrum, думаю, больше 30 элементов наберётся. А у Waterfall сколько?digore Автор
20.11.2018 15:39Вы точно разбираетесь в сути вопроса и представляете, что такое Scrum и Waterfall?
Работали по обоим процессам разработки?
Меряться не буду.
uzverkms
20.11.2018 22:58Рассмотрим разработку критического программного обеспечения, например, систему управления атомной электростанцией или пилотируемого аппарата. Все требования заранее известны, на продукт есть обширная техническая документация, есть ГОСТы и т.д. Неудивительно, что в данных проектах используются «тяжеловесные» методологии.
Вам не кажется, что вы противоречите себе в этом абзаце? Если все требования известны, есть документация и даже ГОСТ, то к чему тогда городить проект? ;) Взяли бы и всё сделали как по инструкции. Если есть проект, то значит есть та степень неопределенности, которая не позволяет успешно завершить начатое в приемлемый срок без соответствующего управленческого подхода.
«Не тренер важен – важны вы. Вы выигрываете дуэли на поле и целые матчи, а мы только немного вам помогаем. Мы можем расставить футболистов и сориентировать – остальное делают игроки»
А теперь идите и сделайте то, в чём вы разбираетесь лучше менеджера. Он-то свою работу уже проделал на отлично — грамотно вас промотивировал.digore Автор
21.11.2018 08:39Проект — это не только документация и требования. Это также планирование, управление качеством, стоимостью, рисками, людьми, коммуникациями и много что еще. Всем этим часто и занимается методология разработки.
Так что нет, я не противоречу себе.VolCh
21.11.2018 16:11По-моему, вы путаете методологию разработки и методологию управления разработкой.
digore Автор
21.11.2018 16:50Хорошо, тогда поясните, пожалуйста, где по вашему мнению граница между методологией разработки и методологией управления разработкой?
VolCh
21.11.2018 17:38Методология управления разработкой это о задачах, сроках, рисках и т. п. А методология разработки — это о том как писать код, cнизу вверх или сверху вниз, TDD и прочие *DD.
digore Автор
21.11.2018 18:02Ок, в ваших терминах моя статья про «методологии управления разработкой». Однако, везде в литературе «методологии управления разработкой» == «методологии разработки».
То, что вы подразумеваете под методологией разработки («как писать код, cнизу вверх или сверху вниз, TDD и прочие *DD») — это программистские техники и практики.
Отвечая на ваш вопрос сверху: Нет я ничего не путаю и не смешиваю, я хорошо разбираюсь в вопросе.
InOdinWeTrust
21.11.2018 13:21Менеджеры, управленцы, проснитесь! Главные в успехе проекта – не руководитель, не процесс, а люди, которые в нем работают.
Закончить хочу цитатой одного из тренеров по футболу: «Не тренер важен – важны вы. Вы выигрываете дуэли на поле и целые матчи, а мы только немного вам помогаем. Мы можем расставить футболистов и сориентировать – остальное делают игроки».
А потом жизнь расставляет все на свои места. Оказывается, что хороший руководитель — все таки ключевое условие успеха компании. Оказывается, что средненькая команда с хорошим руководителем дает результат лучше, чем хорошая команда, со средненьким руководителем. Оказывается, что плохой руководитель способен угробить отличную команду, а хороший — слепить из слабых сотрудников сильную команду, способную решать любые задачи в своей области.
Слова футбольного тренера — это конечно хорошо. Но когда вы собираете футбольную команду, лучше начинать с хорошего тренера.digore Автор
21.11.2018 13:41Все правильно вы пишите! Однако Пеп Гвардиола не выиграет с текущим Спартаком Лигу Чемпионов, каким крутым бы тренером он не был.
Во всем должен быть баланс, да.InOdinWeTrust
21.11.2018 14:15Если посмотреть его историю, не таким уж и крутым тренером он был.
В истории можно найти примеры хороших тренеров, которые смогли сделать из середнячков чемпионские команды. Например, Херб Брукс и сборная США по хоккею.
Moskus
21.11.2018 23:25+1Для успеха важны и исполнители, и руководитель. В какой именно степени они важны в каждом конкретном случае — определяется условиями, в которых они работают, включая всё, от решаемых задач, до законодательства страны, в которой происходит дело. Общие утверждения о том, что «средний + хорошие», например, хуже, чем «хороший + средние» слишком абстрактны, чтобы вообще иметь смысл.
VMichael
21.11.2018 15:58Здравая статья.
Никакая методология не поможет людям которые не знают, что и как делать.
А люди, знающие что и как делать и без методологии создадут продукт.
К сожалению очень часто, возможно даже в подавляющем большинстве случаем использование некоей методологии это действительно карго культ.
staticlab
Неявно вы всё равно примените какую-либо методологию. Профессионалы знают, как делать, но они точно так же не знают, что именно нужно сделать. Для этого нужно или разработать ТЗ, как в классических методологиях, или "выдавливать" его из заказчика постепенно, как в Agile.
Внезапно Agile Manifesto: Люди и взаимодействие важнее процессов и инструментов.
Moskus
Только это, почему-то — главное, что пропускают те, кто внедряет любую методологию, из-за чего она, как правило, превращается в карго-культ, где инструменты считаются магическими, а люди должны выполнять с ними ритуальные действия, веря в результат этой магии. Проблема, скорее всего, в том, что внедрение методологий слишком часто мотивировано изначально чем-то вроде желания найти магический инструмент. Так что результат оказывается заранее обречён, если не дойдет до избавления от тех, кто это с такой мотивацией инициировал.
staticlab
Это да. Собственно
и есть карго-культ :)
Moskus
Технически, культ возникает тогда, когда появляется набор инструментов и ритуалов. А до этого есть только желание магическим образом решить проблему (реальную или кажущуюся).
InOdinWeTrust
Да, только люди и взаимодействие — это внезапно и есть инструменты и процессы.
Процессы нужно выстраивать так, чтоб люди друг другу в силу своего несовершенства не мешали. Аджайл на практике о другом — нужно удовлетворить большой кусок выдвинутых новым проектом ключевых требований быстро без регистрации и смс. Как только проект начинает работать на прибыль, процент задач по фидбеку начинает ощутимо влиять на все эти ваши атомарные спринты, приходится вносить коррективы, аджайл становится не таким уж и аджайлом. Приходит момент менять методологию.
Каждому этапу свой процесс.
vyatsek
staticlab
А могли бы рассказать про свой процесс?
VolCh
С большой вероятностью у него так или иначе будет методология, пускай и своя собственная. А может и несколько. По крайней мере выглядит неэффективно на каждую ситуацию проекта вырабатывать локальное решение, как в ней поступать.