Развитие управления проектами и критериев качества в ИТ (Максим Цепков на AgileDays-2015)

Материал из MaksWiki
Перейти к: навигация, поиск
Еще про управление проектами
Доклад на сайте AgileDays, прочитан 19.03.2015. 
Презентация на slideshare
Видео AgileDays https://vimeo.com/123181695 (в статье тоже есть) 
По тем же слайдам был доклад на CodeFest в Новосибирске 29.03.2015. 
Видео CodeFest https://youtu.be/PayRtw122UU

Менеджеры проектов, руководители разработки (как бы не назывались их должности), в большинстве своем осваивают управление разработкой на своем опыте, сильно зависящем от традиций компаний и проектов, где они работали, от наставников. Без систематического изложения, потому что его практически нет. А тренинги обычно очень конкретны, касаются практик или личного опыта тренера. По сути, получается "разработка по примерам" вместо изучения руководства с концептом. А примеры у всех - разные, из разных времен и на разных языках.

В докладе сделана попытка представить если не цельный концепт, то систематичное изложение, Big Picture с позиционированием примеров в общем поле. По опыту выступления, попытка удалась.

Развитие темы Ответственность за качество в разных ИТ-проектах: в чем она и как ее разделять (SQAdays-20, 2016-11) и Мыслить проектно: история и современность (SECR-2018).

Аннотация

Управление проектами и критерии качества в ИТ прошли долгий путь исторического развития, сменив несколько моделей. Начиналось все с совершенного программного обеспечения (software system) как результата качественного проектирования, свойственного НИОКР. Далее был период всеобъемлющего нормирования процессов по их разработке (PMBoK 3, RUP), сменившийся, отчасти революционно, гибкими подходами к разработке (SCRUM, Kanban), которые сделали упор на сроки и предсказуемость поставки. А сейчас фокус сместился на удовлетворенность стейкхолдеров и достижение бизнес-целей (OMG Essence of Software Engineering).

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

За время доклада мы рассмотрим основные вехи развития подходов к управлению ИТ-проектами и эволюцию критериев качества ПО в мире и в России, которая в 90-х годах шла своим путем, но за последнее время приблизилась к общим трендам.

А также разберемся, для каких проектов и команд уместны те или иные модели управления проектами, в чем могут крыться их преимущества и недостатки и какие формы организации разработки им соответствуют. Понимание этого позволит не только настраивать процессы в своем проекте, но и вести содержательные дискуссии с приверженцами иных форм организации, которые часто встречаются среди заказчиков и руководства.

Видео AgileDays

Видео в HD-качестве, смотрите в полноэкранном режиме.

HTML-код включения <iframe src="https://player.vimeo.com/video/123181695?title=0&portrait=0" width="800" height="500" frameborder="0"></iframe>

Скачать → на странице видео на vimeo, кнопка «Download»

Видео CodeFest

Краткое содержание

Моды ведения проектов - исторический обзор

Big Picture of IT project managerment Tsepkov AgileDays-2015.pdf
  1. Исторически ИТ-разработка выросла из норм ведения НИОКР, к которым термин "услуга" применим в значительной степени условно. Ситуация изменилась с появлением персональных компьютеров, достаточно мощных для автоматизации предприятий, которые сделали востребованной осуществление этой автоматизации как услугу. Оказание этой услуги методами НИОКР оказалось невозможным из-за кадрового голода: формат НИОКР предполагает достаточно квалифицированный персонал, которого в необходимых объемах просто не существовала. Первый подход к решению этой задачи заключался в нормировании процессов.
  2. На первую половину 2000-х нормой оказания ИТ-услуги является ведение проекта по разработке (внедрению) ИТ-системы, которую необходимо спроектировать, а затем изготовить и внедрить с заданными критериями качества. Этот подход зафиксирован в PMBOK 3 версии (2004), на него же ориентирован RUP (2003). При этом упор делался на правильную организацию и надлежащее исполнение процессов. Далее я буду это называть "классическим подходом".
  3. Проекты, не смотря на тяжелые процессы, не приводили к результату. Проблемы касались качественного планирования и проектирования, которое разбивалось об изменчивость мира. На уровне стандарта (PMBOK) было зафиксировано, что даже тщательное исполнение процессов и реализация в соответствии не дает гарантии достижения целей проекта.
  4. Как ответ на вызов - появился Agile и SСRUM внутри него.
    1. SСRUM во главу угла поставил наблюдение за движением по проектной траектории. При этом было сформулировано, что задачу планирования решать бесполезно, надо определить цель и мерить до нее расстояние. А двигаться - итерациями, корректируя план.
    2. Нормировка качественного проекта изменилась, теперь в основу ставят адекватность оценки расстояния до цели и соответствие продвижения в итерацию предварительным оценкам. Для целей мониторинга движения к цели в отрасль втянута концепция SMART-целей, характеризующихся, в частности, измеримостью (Measurable). Сама концепция была известна в менеджменте с 60-х, приписывается то ли Друкеру (английская вики), то ли другим основателям.
    3. SCRUM позволил существенно снизить планку требований к младшему управленческому персоналу в ИТ с сохранением приемлемого уровня исполнения проектов, чем и объясняется его успех.
    4. После успеха SCRUM в отрасли итерационность разработки попробовали заложить в PMBOK 4 версии (2008), но по факту получилась эклектика. Там же попробовали нормировать проектирование (аналитическую работу), но через организацию процессов это тоже не получилось. Отмечу, что в RUP итерационность была изначально, а в другом стандарте, SWEBOK появилась в версии 3 (2004), однако там по факту речь шла о тяжелых итерациях, которые не возможно прокрутить быстро, как того требовал Agile. Таким образом, в стандарте уровня отрасли нормы Agile проявлены не были.
  5. Это путь развития в масштабе мира. В России на этот тренд накладываются события 90-х, в результате которых обеспеченность ИТ-отрасли квалифицированными кадрами, вышедшими из науки и способными оказывать ИТ-услугу методами НИОКР была существенно выше, чем в мире. В результате использование процессного нормирования оказалось существенно менее выражено. В настоящее время эффект в значительной степени размыт, и отличие России от всего мира - нивелируется.

Современное состояние и вектора развития

  1. Agile и SCRUM сдвинули норму оказания отрасли от проектной деятельности к непрерывной, процессной. Такую организацию можно применять не только для начальной разработки или существенному реинжинирингу, но и к текущему развитию и доработке систем. Следующим шагом на пути в этом направлении стал ИТ-вариант Kanban-процесса. Это примерно 2010. Дальнейшее развитие этого сдвига - тренд DevOps.
  2. Ортогональная сдвижка, произошедшая в отрасли примерно в то же время - смещение фокуса от качества ИТ-системы (во всех смыслах, включая функционирование) к удовлетворенности стейкхолдеров проекта. Это смещение отчасти отразилось в PMBOK 5 версии (2013).
  3. Еще одно направление сдвижки - фокус на достижение возможностей для бизнеса, которые должны обеспечить ИТ. Эта сдвижка видна преимущественно в стартап-проектах и в продуктовой разработке, особенно в производстве игр. Сдвиг произошел после 2010.
  4. Произошедшие сдвижки нормирования зафиксированы в The Essence of Software Engineering, выдвинутой SEMAT и принимаемый сейчас OMG (beta1 - july 2013, beta2 - may 2014). В процессе работы из стандарта тщательно вычищали слово "проект", обеспечивая применимость на всех стадиях жизненного цикла. А в основные альфы включены стейкхолдеры, с которыми идет работа и возможности для бизнеса, которые желают получить.
  5. Проблема правильного проектирования систем и нормировки в этом поле не решена в отрасли по-прежнему. Лучшее известное мне решение для процесса управления проектом - FDD (Джефф де Люка), а для способа разработки проекта - DDD (Эрик Эванс)

BigPicture методов ведения проектов

Big Picture of IT project managerment Tsepkov AgileDays-2015.pdf

Историческая картина есть. Можно применять на практике? Нет, сначала нужно положить это на схемы, сделать Big Picture, на которых можно об этом рассуждать.

  1. Эпохи в историческом развитии - самый простой способ. Но лишь показывает историю, а не дает возможность конструирования своего.
  2. Вектора развития. Все они сохраняют актуальность, так как следующий этап - дополняет и расширяет предыдущий. Похожая, но отличающаяся картина - Энтони Лаудер "Культуры программных проектов".
  3. История развитие как смещение фокусов внимания на схеме OMG Essence.
  4. Изменения на V-диаграмме: ИТ-проект как интегрированная часть бизнес-проекта, раньше их рассматривали достаточно изолировано.

Применение на практике

Big Picture of IT project managerment Tsepkov AgileDays-2015.pdf
  1. На уровне проекта. Понимать, в чем фишка проекта.
  2. На уровне компании. Что компания делает для мира и каким образом. Примеры различных концептов компаний.
  3. Как с этим работать практически и для чего оно нужно.

Полная презентация

Big Picture of IT project managerment Tsepkov AgileDays-2015.pdf Big Picture of IT project managerment Tsepkov AgileDays-2015.pdf Big Picture of IT project managerment Tsepkov AgileDays-2015.pdf Big Picture of IT project managerment Tsepkov AgileDays-2015.pdf Big Picture of IT project managerment Tsepkov AgileDays-2015.pdf Big Picture of IT project managerment Tsepkov AgileDays-2015.pdf Big Picture of IT project managerment Tsepkov AgileDays-2015.pdf Big Picture of IT project managerment Tsepkov AgileDays-2015.pdf Big Picture of IT project managerment Tsepkov AgileDays-2015.pdf Big Picture of IT project managerment Tsepkov AgileDays-2015.pdf Big Picture of IT project managerment Tsepkov AgileDays-2015.pdf Big Picture of IT project managerment Tsepkov AgileDays-2015.pdf Big Picture of IT project managerment Tsepkov AgileDays-2015.pdf Big Picture of IT project managerment Tsepkov AgileDays-2015.pdf Big Picture of IT project managerment Tsepkov AgileDays-2015.pdf Big Picture of IT project managerment Tsepkov AgileDays-2015.pdf Big Picture of IT project managerment Tsepkov AgileDays-2015.pdf Big Picture of IT project managerment Tsepkov AgileDays-2015.pdf Big Picture of IT project managerment Tsepkov AgileDays-2015.pdf Big Picture of IT project managerment Tsepkov AgileDays-2015.pdf Big Picture of IT project managerment Tsepkov AgileDays-2015.pdf Big Picture of IT project managerment Tsepkov AgileDays-2015.pdf Big Picture of IT project managerment Tsepkov AgileDays-2015.pdf Big Picture of IT project managerment Tsepkov AgileDays-2015.pdf Big Picture of IT project managerment Tsepkov AgileDays-2015.pdf Big Picture of IT project managerment Tsepkov AgileDays-2015.pdf Big Picture of IT project managerment Tsepkov AgileDays-2015.pdf Big Picture of IT project managerment Tsepkov AgileDays-2015.pdf Big Picture of IT project managerment Tsepkov AgileDays-2015.pdf Big Picture of IT project managerment Tsepkov AgileDays-2015.pdf Big Picture of IT project managerment Tsepkov AgileDays-2015.pdf Big Picture of IT project managerment Tsepkov AgileDays-2015.pdf Big Picture of IT project managerment Tsepkov AgileDays-2015.pdf Big Picture of IT project managerment Tsepkov AgileDays-2015.pdf Big Picture of IT project managerment Tsepkov AgileDays-2015.pdf Big Picture of IT project managerment Tsepkov AgileDays-2015.pdf