– У нас не получится уложиться в сроки!
– Примените Agile!
– Без достаточного количества людей он нам не поможет!
– Тогда придумайте другое умное слово!
Последнее время часто слышу: они провалились, потому что неправильно выбрали методологию разработки продукта. Вот если бы вы применили Scrum/DevOps/Agile/еще что-то, то все было бы хорошо. Похоже, эти люди кое-что не понимают в разработке софта.
Еще Алистер Коуберн в своей статье проанализировал разные программные проекты, которые выполнялись по разным моделям от совершенно «легких» и гибких до очень «тяжелых» и формализованных. Он не обнаружил корреляции между успехом или провалом проектов и моделями процесса разработки, которые применялись. Отсюда Коуберн сделал вывод о том, что эффективность разработки не зависит от модели процесса.
Существуют десятки методологий, но ни одна не гарантирует результат. В каждом новом проекте процесс должен определяться каждый раз заново. В основном, выбор процесса зависит от разрабатываемого продукта и людей, участвующих в разработке. Главный принцип: не люди должны строиться под выбранную модель процесса, а модель процесса должна подстраиваться под конкретную команду, чтобы обеспечить ее наивысшую производительность.
Рассмотрим разработку критического программного обеспечения, например, систему управления атомной электростанцией или пилотируемого аппарата. Все требования заранее известны, на продукт есть обширная техническая документация, есть ГОСТы и т.д. Неудивительно, что в данных проектах используются «тяжеловесные» методологии.
Совершенно другие подходы следует применять при разработке нового модного веб-сервиса, когда требования нечеткие и постоянно меняются. Тут любимый всеми Scrum/Agile и подобные «легковесные» системы. Применение этих методологий оправдано, т.к. можно быстро получить обратную связь в условиях быстроменяющегося внешнего мира.
Сказанное выше можно также проецировать и на размер разрабатываемого продукта. Ведь совершенно разные процессы должны применяться в проектах, в которых участвуют 10 человек, и в проектах, в которых участвуют 1000 человек.
По-разному следует организовывать процесс разработки в команде студентов и в команде состоявшихся профессионалов.
Я всегда считал, что Scrum и другие методологии разработки – для тех людей, которые просто не могут самостоятельно работать. Я выделяю несколько типов команд и, в зависимости от этого, выстраиваю процессы внутри них.
Руководители, изучайте свою команду и разумно выбирайте методологию разработки в каждом случае. Каждой команде нужна своя методология.
Главные задачи менеджера при этом состоит в том, чтобы:
В последнее время приходится много собеседовать менеджеров по разработке. Примерно 7 из 10 кандидатов на вопрос о вашем главном достижении на текущем месте работы сообщает, что они стали главной частью успеха продукта, без них бы все провалилось.
Менеджеры, управленцы, проснитесь! Главные в успехе проекта – не руководитель, не процесс, а люди, которые в нем работают.
Закончить хочу цитатой одного из тренеров по футболу: «Не тренер важен – важны вы. Вы выигрываете дуэли на поле и целые матчи, а мы только немного вам помогаем. Мы можем расставить футболистов и сориентировать – остальное делают игроки».
– Примените Agile!
– Без достаточного количества людей он нам не поможет!
– Тогда придумайте другое умное слово!
Последнее время часто слышу: они провалились, потому что неправильно выбрали методологию разработки продукта. Вот если бы вы применили Scrum/DevOps/Agile/еще что-то, то все было бы хорошо. Похоже, эти люди кое-что не понимают в разработке софта.
Еще Алистер Коуберн в своей статье проанализировал разные программные проекты, которые выполнялись по разным моделям от совершенно «легких» и гибких до очень «тяжелых» и формализованных. Он не обнаружил корреляции между успехом или провалом проектов и моделями процесса разработки, которые применялись. Отсюда Коуберн сделал вывод о том, что эффективность разработки не зависит от модели процесса.
Существуют десятки методологий, но ни одна не гарантирует результат. В каждом новом проекте процесс должен определяться каждый раз заново. В основном, выбор процесса зависит от разрабатываемого продукта и людей, участвующих в разработке. Главный принцип: не люди должны строиться под выбранную модель процесса, а модель процесса должна подстраиваться под конкретную команду, чтобы обеспечить ее наивысшую производительность.
Продукт
Рассмотрим разработку критического программного обеспечения, например, систему управления атомной электростанцией или пилотируемого аппарата. Все требования заранее известны, на продукт есть обширная техническая документация, есть ГОСТы и т.д. Неудивительно, что в данных проектах используются «тяжеловесные» методологии.
Совершенно другие подходы следует применять при разработке нового модного веб-сервиса, когда требования нечеткие и постоянно меняются. Тут любимый всеми Scrum/Agile и подобные «легковесные» системы. Применение этих методологий оправдано, т.к. можно быстро получить обратную связь в условиях быстроменяющегося внешнего мира.
Сказанное выше можно также проецировать и на размер разрабатываемого продукта. Ведь совершенно разные процессы должны применяться в проектах, в которых участвуют 10 человек, и в проектах, в которых участвуют 1000 человек.
Люди
По-разному следует организовывать процесс разработки в команде студентов и в команде состоявшихся профессионалов.
Я всегда считал, что Scrum и другие методологии разработки – для тех людей, которые просто не могут самостоятельно работать. Я выделяю несколько типов команд и, в зависимости от этого, выстраиваю процессы внутри них.
- Команда профессионалов знает свое дело, как следует работать. Они могут взять на себя ответственность за результат – здесь не нужны методологии разработки, тем более навязанные сверху. Часто даже менеджер не нужен. Такие команды умеют работать самостоятельно, без постоянного контроля и всегда с завидным результатом.
- Команда опытных программистов требует периодического контроля и поддержки, но без жесткой постановки задач.
- Команда новичков же требует постоянной постановки задач, поддержки в решении, контроля сроков.
Руководители, изучайте свою команду и разумно выбирайте методологию разработки в каждом случае. Каждой команде нужна своя методология.
Главные задачи менеджера при этом состоит в том, чтобы:
- построить команду, которая сможет работать вместе на требуемый результат с достаточной эффективностью
- построить процесс работы внутри команды, чтобы он позволял сотрудникам удобным образом заниматься нужной работой
- настроить взаимодействие команды с другими подразделениями компании либо с заказчиком, чтобы общение проходило с минимумом помех основной работе команды и максимальной результативностью
- убрать все остальные преграды и препятствия для команды с пути достижения цели.
В последнее время приходится много собеседовать менеджеров по разработке. Примерно 7 из 10 кандидатов на вопрос о вашем главном достижении на текущем месте работы сообщает, что они стали главной частью успеха продукта, без них бы все провалилось.
Менеджеры, управленцы, проснитесь! Главные в успехе проекта – не руководитель, не процесс, а люди, которые в нем работают.
Закончить хочу цитатой одного из тренеров по футболу: «Не тренер важен – важны вы. Вы выигрываете дуэли на поле и целые матчи, а мы только немного вам помогаем. Мы можем расставить футболистов и сориентировать – остальное делают игроки».