PMI-неPMI - все равно получишь Agile :)

«Имейте в виду, что никогда незнание не делает зла; пагубно только заблуждение. Заблуждаются же люди не потому, что не знают, а потому, что воображают себя знающими»

(жаль, что не я) Жан-Жак Руссо

Давеча прочел интересную статью о мертвых доисторических животных и их влиянии на разработку программного обеспечения.

За последнее время тема «противостояния» классических и гибких подходов к управлению проектами по разработке ПО вызывала over 9000 маленьких стычек и крупномасштабных боев на конференциях, в блогах и этих ваших интернетах.

Однако, именно указанная выше статья вызвала во мне припадок энтузиазма и желание провести анализ некоторых ее постулатов, так как, на мой взгляд, в ней собраны некоторые распространенные заблуждения по теме. Так что далее будет нудный копи-паст некоторых частей статьи и комментарии к ним.

Да, и сразу хочу отметить – никакого троллинга автора конкретной статьи не будет. Но так уж получилось, что Илья собрал несколько интересных заблуждений в одном месте в одно время. И я не удержался.

«Сразу отмечаю, что PMBOK создан без привязки к какой либо индустрии. В этой статье я рассматриваю использование PMBOK исключительно в сфере IT.»

По первой части вопросов нет, +100500. Вместе с тем, такое оптимистичное начало и дальнейшая статья у меня не связались в одно целое. Объясню почему.

Если поднять голову и вынырнуть из тысяч аутсорсинговыхпроектов по разработке ПО, то можно увидеть, что спектр ИТ проектов значительно шире. Можно ли сравнить проект по автоматизации деятельности металлургического комбината и разработку веб-сайта или банковского опер-дня? Я думаю, нет. Просто потому, что в первом проекте задач на порядки больше: тендера, закупки, прокладка сетей, управление работой субподрядчиков и администрирование договоров, настройка серверов, разработка самого ПО, его внедрение, обучение пользователей, поддержка и даже вывод из эксплуатации. Я уже не говорю о работе с рисками проекта, планировании набора команды (не бросить заявочку в отдел рекрутмента на поиск Java-разработчика, а именно планирование). Это ИТ проект. А разработка ПО – только часть и далеко не всегда самая большая.

Итак, путаница в понимании ИТ-проекта займет в нашей коллекции заблуждений место с номером 1. Так что, как принято писать в официальных документах, тут и далее под проектом мы будем понимать именно такой комплексный проект.

Вторым известным заблуждением является ссылка на отчет Standish Group – Chaos Report  1994 года –  и тех ужасных фактах, которые этот отчет содержит. На этот отчет ссылаются чуть чаще, чем постоянно все, кто желает доказать преимущество гибкости над классикой. Но из всего отчета, содержащего много полезной информации, обычно выбирают только данные о количестве провалившихся и успешных проектов. Давайте обратимся к  выдержкам из этого отчета. Уже в водной части авторы очень четко и совсем недвусмысленно очерчивают рамки своего исследования:

Consequently the focus of this latest research project at The Standish Group has been to identify:

• The scope of software project failures

• The major factors that cause software projects to fail

• The key ingredients that can reduce project failures

Отчет дает предоставление о проблемах в проектах по разработке ПО (software project), а не всей ИТ-индустрии. Дальше еще интереснее – кто-нибудь посмотрел на фокус-группу, которая была вовлечена в подготовку отчета? А Standish Group и тут ничего не скрывает: 41 IT-менеджер из 2-х городов – Сан-Франциско и Бостон. И в дополнение еще интервью с «различными ИТ-менеджерами». Япрекрасно понимаю, что в 1994 году большая часть проектов по разработке ПО выполнялась в США, но не все же:). Я ни разу не сомневаюсь в опытности и компетентности этих ИТ-менеджеров, но делать выводы о том «в каком состоянии находилась отрасль разработки ПО в начале девяностых» на основе этих данных вряд ли возможно. Кстати, специалисты Standish Group этого и не делают, в отличии от читателей их отчета.

Давайте еще пройдемся по этому отчету. Он содержит много действительно интересных цифр, но ни одного слово о методологиях. Хотя нет, слово "methodology" в тексте есть – это название раздела, описывающего процесс создания самого отчета :).

Но автор упомянутой статьи и многие другие, ссылающиеся на этот отчет, делают зачастую однозначный вывод – в малом проценте успешных проектов виноват «водопад». На первый взгляд логика вполне понятна и автор это демонстрирует: «В девяностых годах доминировали Водопадные и около Водопадные методы работы».

На этом этапе нас накрывает "водопадом" третьего распространенного заблуждения.

Здесь нам придется сделать небольшой экскурс в историю. Откуда появился этот "водопад", он же  "waterfall", и почему он в ответе за все?

История уходит в корнями в 1970 год, когда разработкой коммерческого ПО практически на занимались. В 1970 году появляется статья, изменившая мир проектов разработки ПО: “Managing the development of large software systems” доктора Уинстона Ройса. Наш доктор был не хирургом и даже не терапевтом, а доктором наук, причем в аэронавтике. Думаю, нет смысла говорить о том, что конец 60-х – начало 70-х годов был периодом великих достижений в этой области по обе стороны Атлантики. 

1970 год подарил миру целый ряд знаменательных событий и явлений. И это были не только расцвет хард-рока Led Zeppelin, Black Sabbath, Deep Purple. И даже не троектратное чемпионство сборной Бразилии по футболу:). В 1970 году совершил первый коммерческий рейс Boeing 747, IBM представила дискету диаметром в 8″, Intel разработала модуль памяти Dynamic Random Access Memory, DRAM. В конце концов, именно в 1970 году Дуглас Энгельбарт получил патент на компьютерную «мышь», а весь мир услышал переданную из космоса фразу «Houston, we’ve had a problem»!

Смею предположить, что доктор Ройс, работая в компании TRW Inc., которая занимала в то время место №57 в списке Fortune 500, был человеком умным и умел анализировать факты и теории.

Доктор Ройс сделал одну катастрофическую ошибку. На второй странице своей статьи он разместил эту схему:

Еще и как подписал: «Implementation steps to develop a large computer program for delivery to a customer”! И несмотря на то, что в первом же предложении после этой схемы доктор Ройс говорит: «Я верю в эту концепцию, но описанная выше имплементация рискованна и может привести к проблемам», схема настолько понравилась, что позднее легла в основу стандарта DOD-STD-2167 Министерства обороны самих США. А если такой МОнстр заказной разработки требует от подрядчиков соответствия стандарту, то эти самые подрядчики взяли под козырек и начали активно внедрять у себя  этот стандарт.

Но тут опять незадачка: в статье Ройса ни разу не встречается слово «waterfall». Хм, а где же он, наш ватерфол? Если что-то не знаешь – спроси у Гугла. На этот вопрос Гугл, как выяснилось, знает ответ и даже дает нам графическое представление в виде N-gram:

Термин «водопад» появился только в 1985 году, через 15лет после выхода в свет статьи Уинстона Ройса, что удивительным образом совпадает с датой публикации стандарта МО тех самых США.

Более того, самому Ройсу пришлось до конца своих дней «отмываться» от глупости этого стандарта и доказывать, что такой подход губителен в разработке ПО. Тоже самое доказывал и разработчик методологии RUP – Уокер Ройс. Ага, не просто однофамилец, а сын Уинстона Ройса:

«He was always a proponent of iterative, incremental, evolutionary development. His paper described the waterfall as the simplest description, but that it would not work for all but the most straightforward projects»

Так что же на самом деле говорил доктор Ройс?

•      Делать все задачи в одной последовательности неэффективно

•      Лучшая модель предполагает итерации и последовательные шаги

•      «Сделайте  так, чтобы финальная версия, переданная для использованию клиенту, была в действительности второй версией»

•      «Важно  привлекать заказчика  к участию в проекте , так, чтобы он принимал определённые обязательства на ранних стадиях проекта, до  выпуска  финальной версии»

Поправьте меня, но это очень похоже на основы «гибких» подходов :).

Но мы отвлеклись и время вернуться к нашей статье: «Проекты, использующие гибкую разработку, оказываются ровно в три раза успешнее». И дальше графики-пирожки с цифрами из CHAOS Manifesto 2011 года. 42% успешных проектов с использованием Agile против 14 по… хорошо, пусть будет по «ватерфолу». Точно, в три раза. Математику не люблю, но калькулятор не обманешь.

Но природный скептицизм заставляет снова начать читать отчет, а не только его веселые картинки.

The agile process is the universal remedy for software development project failure. Software applications developed through the agile process have three times the success rate of the traditional waterfall method and a much lower percentage of time and cost overruns

Хм, так CHAOS Manifesto говорит о проектах по разработке ПО, а не об ИТ-проектах!  Что же мы тогда сравнивали до этого? Теплое с мягким?:)

Но если начали, то давайте идти до конца. Возьмем свежий манифест 2013 года, страница 25:

Size of a project trumps methodology. The agile process benefits from small projects. Overall, small projects have a better success rate than agile projects and waterfall projects when you include other types. In the last 10 years, 45% of agile projects were less than $1 million in labor cost. In contrast, only 14% of waterfall projects were less than $1 million in labor cost. Head to head, small, agile, and waterfall projects have almost the same success and failure rates.

Внезапно так. А ребята из Standish Group копают еще глубже. Кроме веселых картинок они еще ввели бальную оценку и ранжирование факторов успеха проектов, которые попадают в параметры их исследований. Глубоко копать уже было лень:) и я взял манифесты за последние четыре года с 2010 по 2013.  Место Agile-методологий (я бы добавил – методологий как таковых) уверенно балансирует на 5-6 месте. А ключевыми остаются поддержка топ-менеджмента, вовлечение пользователей, четкие бизнес цели, эмоциональная зрелость и оптимизация. Кстати, PMBOK уделяет первым трем факторам очень большое внимание и даже ввел отдельный раздел по управлению заинтересованными лицами.

"А PMI к этому времени выпустил уже 5-е по счету издание PMBOK! За двадцать лет эффективность классической модели менеджмента в IT отрасли не претерпела никаких изменений."

Вот тут я совсем потерялся :). Мы же несколько абзацев тому утверждали, что  PMBOK не имеет привязки к отрасли, а теперь обвиняем его (или его создателей) в том, что не просто работа с проектами по разработке ПО, а эффективность управления во всей ИТ отрасли не изменилась! На каком основании сделан этот вывод не очень ясно. Черт с ним, опять запутались в том, что такое ИТ проект и разработка ПО. Но почему нет претензий к другим стандартам, явно регламентирующим работу в software проектах? Где козни против SWEBOK или ГОСТ 34 серии или ISO/IEC 12207 и т.д.? 

Зачем же мы каждый раз пытаемся сравнить Свод знаний по управлению проектами и свод практик по организации работы софтверной команды?

«И напоследок. Так как же я, все таки, отношусь к PMI и PMBOK 5th Edition? Никак. Не стоит будить мертвого динозавра. Он уже никогда не проснется.»

Сложно комментировать этот вывод (конечно, если отдал 550 баксов за сертификацию, то сложно признать себя ослом :)). Хотя, уверен, и почти 600 тысячам сертифицированным менеджерам, которые применяют практики PMBOK в строительных проектах, проектах химической и фармацевтической промышленности, в атомной энергетике, авиастроении и даже в крупных ИТ-проектах сложно будет признать, что они работают (похоже, достаточно успешно) по подходам мертвых динозавров.

Кстати, PMI тоже идет в ногу со временем и не отрицает эффективности гибких подходов. Так что кто "гибче" - это еще вопрос ;).

Максим Вишнивецкий, PMP, IPMA, CSM (у последнего сертификата, правда, истек срок действия :))