Всего в опросе приняло участие 86 человек, и поскольку в опросе была возможность давать несколько ответов, общее число ответов 105. Часто один человек одновременно участвует в нескольких проектах и эти проекты могут использовать разные методологии.
Таким образом у нас есть 105 проектов, и в среднем на одного человека приходится 1,2 проекта.
Традиционные, "тяжелые" методики используются в 15% проектов. Из них на долю MSF (Microsoft Solution Framework) приходится лишь 3%, а на долю RUP (Rational Unified Process) - 12%.
Гибкие методологии используются в 43% проектов. Extrime Programming используют 14%, и 29% предпочитают всевозможные менее экстремальные Agile методики.
Как ни печально, но 41% всех проектов не используют никакой методологии.
Признаюсь честно, последняя цифра оказалась для меня весьма неожиданной. Если учесть тот факт, что на части проектов вывеска Agile прикрывает полное отсутствие проектного управления, то получается, что около половины всей разработки находится в состоянии дремучего бардака.
Для микро-проектов, с числом программистов не более одного, можно сказать что организация процесса не имеет особого значения. Хотя и в этом случае без применения нормальных инженерных практик, таких как тестирование или анализ требований, вероятность получения результата будет стремится к нулю.
Я то думал, что времена, когда программистов усаживали писать софт не определив ни целей, ни требований, ни сроков, уже давно канули в лету. Ан нет.
Раз все так плохо, может мне стоит открыть консалтинговый бизнес по постановке процесса разработки. Не по аутсорсингу разработки, а именно по выстраиванию нормальной модели проектной команды и проектного процесса. Когда в команду приходит инструктор, и по ходу реального проекта помогает решать рабочие вопросы: требования, взаимодействие с заказчиком, коммуникаций внутри команды, интеграция, тесты, и т.д. и т.п., параллельно выстраивая Процесс в соответствии со спецификой проекта и потребностями клиента. То, что обозначается модным сейчас словом коучинг (от coach - тренер). Многочисленные agile евангелисты сейчас вплотную подбираются к такой модели бизнеса. Но почему только agile?
6 комментариев:
У меня два коментария:
1) MSF for CMMI можно назвать тфжелым формализированым проектом. MSF for Agile - врядли. Да он более формализирован чем бардак. Но например приблизительно равен Скраму. Тоесть реально его нельзя в полном смысле назвать тяжелым проектом.
2) Иногда не один человек на нескольких проектах, а один проект использует несколько методологий. У нас например своя, основанная на MSF. Но при этом мв используем и скрамовские практики, и ХР, и RUP.
XP и RUP в одном проекте, это для меня потрясающая новость :)
Как вы, например, работаете с требованиями? Use cases - но тогда это не XP, user story - тогда это уже не RUP. Поотму что нельзя работать по XP если у вас постоянно не присутствует заказчик и нельзя работать по RUP, если у вас не формализованы требования.
Можно говорить об использовании определенных практик из различных методологий. Некоторые практики, например, непрерывная интеграция, входят практически во все методологии. Но есть практики просто не всовместимые в рамках одного проекта. Пример тому, работа с требованиями в XP и RUP. В рамках своей родной методологии все работает нормально, но перенести их на другую почву не прихватив при этом все остальное просто не возможно. Проект развалится.
Я то думал, что времена, когда программистов усаживали писать софт не определив ни целей, ни требований, ни сроков, уже давно канули в лету. Ан нет.
нет, ну почему же? вот мне например сроки определили - "должно быть готово на вчера". Жаль, что все остальное забыли...
И правда жуть...
Sergey Rozovik, а чего это вас удивляет? Мы не используем user stories. Зато, например, мы используем TDD и Peer Code Review.
Собно вы сами сказали:
>> "Можно говорить об использовании определенных практик из различных методологий."
Именно это и имелось ввиду. Я не вижу разночтения в своем предложении.
Ну это происходит по одной единственной причине: многие проекты делаются, условно говоря, за $1.5 доллара в час - что внутренние, что заказные. Сроки по ним, вполне естесственно, нереальные, и потому у исполнителей нет ни времени, ни желания что-то внедрять.
почему только agile? 8-)
[imho]
потому, что сейчас то, что не следует до-буквенно процессу тяжеловесному, в том числе и заточенные под текущую ситуацию процессы, принято обозначать agile. Некоторые называют также их RUP 8-), что тоже ... забавно.
Также это(agile) обозначение модно, потому его избегают использовать те, кто не любит buzz words.
о качестве таких процессов можно сказать мало что до ознакомления - так что про дремучий бардак - зря.
[/imho]
Отправить комментарий