7078
правок
Изменения
Новая страница: «Категория:ДокладыКатегория:Люди [http://msk15.agiledays.ru/members/profile/898/#report-19 Доклад на сайте ко…»
[[Категория:Доклады]][[Категория:Люди]]
[http://msk15.agiledays.ru/members/profile/898/#report-19 Доклад на сайте конференции]
[http://www.slideshare.net/mtsepkov/big-picture-of-it-project-managerment-tsepkov-agile-days-2015 Презентация на slideshare]
{{red|Видео ожидается}}
Менеджеры проектов, руководители разработки (как бы не назывались их должности), в большинстве своем осваивают управление разработкой на своем опыте, сильно зависящем от традиций компаний и проектов, где они работали, от наставников. Без систематического изложения, потому что его практически нет. А тренинги обычно очень конкретны, касаются практик или личного опыта тренера. По сути, получается "разработка по примерам" вместо изучения руководства с концептом. А примеры у всех - разные, из разных времен и на разных языках.
В докладе сделана попытка представить если не цельный концепт, то систематичное изложение, Big Picture с позиционированием примеров в общем поле. По опыту выступления, попытка удалась.
= Аннотация =
Управление проектами и критерии качества в ИТ прошли долгий путь исторического развития, сменив несколько моделей. Начиналось все с совершенного программного обеспечения (software system) как результата качественного проектирования, свойственного НИОКР. Далее был период всеобъемлющего нормирования процессов по их разработке (PMBoK 3, RUP), сменившийся, отчасти революционно, гибкими подходами к разработке (SCRUM, Kanban), которые сделали упор на сроки и предсказуемость поставки. А сейчас фокус сместился на удовлетворенность стейкхолдеров и достижение бизнес-целей (OMG Essence of Software Engineering).
Но развитие не остановилось. Непонимание места конкретных подходов, методологий и практик в контексте общего развития отрасли не позволяет эффективно их использовать и порождает множество пустых дискуссий среди разработчиков о том, как правильно.
За время доклада мы рассмотрим основные вехи развития подходов к управлению ИТ-проектами и эволюцию критериев качества ПО в мире и в России, которая в 90-х годах шла своим путем, но за последнее время приблизилась к общим трендам.
А также разберемся, для каких проектов и команд уместны те или иные модели управления проектами, в чем могут крыться их преимущества и недостатки и какие формы организации разработки им соответствуют. Понимание этого позволит не только настраивать процессы в своем проекте, но и вести содержательные дискуссии с приверженцами иных форм организации, которые часто встречаются среди заказчиков и руководства.
= Краткое содержание =
== Моды ведения проектов - исторический обзор ==
[[File:Big Picture of IT project managerment Tsepkov AgileDays-2015.pdf|page=18|400px|border|right]]
# Исторически ИТ-разработка выросла из норм ведения НИОКР, к которым термин "услуга" применим в значительной степени условно. Ситуация изменилась с появлением персональных компьютеров, достаточно мощных для автоматизации предприятий, которые сделали востребованной осуществление этой автоматизации как услугу. Оказание этой услуги методами НИОКР оказалось невозможным из-за кадрового голода: формат НИОКР предполагает достаточно квалифицированный персонал, которого в необходимых объемах просто не существовала. Первый подход к решению этой задачи заключался в нормировании процессов.
# На первую половину 2000-х нормой оказания ИТ-услуги является ведение проекта по разработке (внедрению) ИТ-системы, которую необходимо спроектировать, а затем изготовить и внедрить с заданными критериями качества. Этот подход зафиксирован в PMBOK 3 версии (2004), на него же ориентирован RUP (2003). При этом упор делался на правильную организацию и надлежащее исполнение процессов. Далее я буду это называть "классическим подходом".
# Проекты, не смотря на тяжелые процессы, не приводили к результату. Проблемы касались качественного планирования и проектирования, которое разбивалось об изменчивость мира. На уровне стандарта (PMBOK) было зафиксировано, что даже тщательное исполнение процессов и реализация в соответствии не дает гарантии достижения целей проекта.
# Как ответ на вызов - появился Agile и SСRUM внутри него.
## SСRUM во главу угла поставил наблюдение за движением по проектной траектории. При этом было сформулировано, что задачу планирования решать бесполезно, надо определить цель и мерить до нее расстояние. А двигаться - итерациями, корректируя план.
## Нормировка качественного проекта изменилась, теперь в основу ставят адекватность оценки расстояния до цели и соответствие продвижения в итерацию предварительным оценкам. Для целей мониторинга движения к цели в отрасль втянута концепция SMART-целей, характеризующихся, в частности, измеримостью (Measurable). Сама концепция была известна в менеджменте с 60-х, приписывается то ли Друкеру (английская вики), то ли другим основателям.
## SCRUM позволил существенно снизить планку требований к младшему управленческому персоналу в ИТ с сохранением приемлемого уровня исполнения проектов, чем и объясняется его успех.
## После успеха SCRUM в отрасли итерационность разработки попробовали заложить в PMBOK 4 версии (2008), но по факту получилась эклектика. Там же попробовали нормировать проектирование (аналитическую работу), но через организацию процессов это тоже не получилось. Отмечу, что в RUP итерационность была изначально, а в другом стандарте, SWEBOK появилась в версии 3 (2004), однако там по факту речь шла о тяжелых итерациях, которые не возможно прокрутить быстро, как того требовал Agile. Таким образом, в стандарте уровня отрасли нормы Agile проявлены не были.
# Это путь развития в масштабе мира. В России на этот тренд накладываются события 90-х, в результате которых обеспеченность ИТ-отрасли квалифицированными кадрами, вышедшими из науки и способными оказывать ИТ-услугу методами НИОКР была существенно выше, чем в мире. В результате использование процессного нормирования оказалось существенно менее выражено. В настоящее время эффект в значительной степени размыт, и отличие России от всего мира - нивелируется.
== Современное состояние и вектора развития ==
# Agile и SCRUM сдвинули норму оказания отрасли от проектной деятельности к непрерывной, процессной. Такую организацию можно применять не только для начальной разработки или существенному реинжинирингу, но и к текущему развитию и доработке систем. Следующим шагом на пути в этом направлении стал ИТ-вариант Kanban-процесса. Это примерно 2010. Дальнейшее развитие этого сдвига - тренд DevOps.
# Ортогональная сдвижка, произошедшая в отрасли примерно в то же время - смещение фокуса от качества ИТ-системы (во всех смыслах, включая функционирование) к удовлетворенности стейкхолдеров проекта. Это смещение отчасти отразилось в PMBOK 5 версии (2013).
# Еще одно направление сдвижки - фокус на достижение возможностей для бизнеса, которые должны обеспечить ИТ. Эта сдвижка видна преимущественно в стартап-проектах и в продуктовой разработке, особенно в производстве игр. Сдвиг произошел после 2010.
# Произошедшие сдвижки нормирования зафиксированы в The Essence of Software Engineering, выдвинутой SEMAT и принимаемый сейчас OMG (beta1 - july 2013, beta2 - may 2014). В процессе работы из стандарта тщательно вычищали слово "проект", обеспечивая применимость на всех стадиях жизненного цикла. А в основные альфы включены стейкхолдеры, с которыми идет работа и возможности для бизнеса, которые желают получить.
# Проблема правильного проектирования систем и нормировки в этом поле не решена в отрасли по-прежнему. Лучшее известное мне решение для процесса управления проектом - FDD (Джефф де Люка), а для способа разработки проекта - DDD (Эрик Эванс)
== BigPicture методов ведения проектов ==
[[File:Big Picture of IT project managerment Tsepkov AgileDays-2015.pdf|page=19|400px|border|right]]
Историческая картина есть. Можно применять на практике? Нет, сначала нужно положить это на схемы, сделать Big Picture, на которых можно об этом рассуждать.
# Эпохи в историческом развитии - самый простой способ. Но лишь показывает историю, а не дает возможность конструирования своего.
# Вектора развития. Все они сохраняют актуальность, так как следующий этап - дополняет и расширяет предыдущий. Похожая, но отличающаяся картина - [http://lib.custis.ru/Культуры_программных_проектов_(Энтони_Лаудер) Энтони Лаудер "Культуры программных проектов"].
# История развитие как смещение фокусов внимания на схеме OMG Essence.
# Изменения на V-диаграмме: ИТ-проект как интегрированная часть бизнес-проекта, раньше их рассматривали достаточно изолировано.
== Применение на практике ==
[[File:Big Picture of IT project managerment Tsepkov AgileDays-2015.pdf|page=32|400px|border|right]]
# На уровне проекта. Понимать, в чем фишка проекта.
# На уровне компании. Что компания делает для мира и каким образом. Примеры различных концептов компаний.
# Как с этим работать практически и для чего оно нужно.
{{----}}
= Полная презентация =
<div style="text-align:left;">[[File:Big Picture of IT project managerment Tsepkov AgileDays-2015.pdf|page=-|400px|border]]</div>
[http://msk15.agiledays.ru/members/profile/898/#report-19 Доклад на сайте конференции]
[http://www.slideshare.net/mtsepkov/big-picture-of-it-project-managerment-tsepkov-agile-days-2015 Презентация на slideshare]
{{red|Видео ожидается}}
Менеджеры проектов, руководители разработки (как бы не назывались их должности), в большинстве своем осваивают управление разработкой на своем опыте, сильно зависящем от традиций компаний и проектов, где они работали, от наставников. Без систематического изложения, потому что его практически нет. А тренинги обычно очень конкретны, касаются практик или личного опыта тренера. По сути, получается "разработка по примерам" вместо изучения руководства с концептом. А примеры у всех - разные, из разных времен и на разных языках.
В докладе сделана попытка представить если не цельный концепт, то систематичное изложение, Big Picture с позиционированием примеров в общем поле. По опыту выступления, попытка удалась.
= Аннотация =
Управление проектами и критерии качества в ИТ прошли долгий путь исторического развития, сменив несколько моделей. Начиналось все с совершенного программного обеспечения (software system) как результата качественного проектирования, свойственного НИОКР. Далее был период всеобъемлющего нормирования процессов по их разработке (PMBoK 3, RUP), сменившийся, отчасти революционно, гибкими подходами к разработке (SCRUM, Kanban), которые сделали упор на сроки и предсказуемость поставки. А сейчас фокус сместился на удовлетворенность стейкхолдеров и достижение бизнес-целей (OMG Essence of Software Engineering).
Но развитие не остановилось. Непонимание места конкретных подходов, методологий и практик в контексте общего развития отрасли не позволяет эффективно их использовать и порождает множество пустых дискуссий среди разработчиков о том, как правильно.
За время доклада мы рассмотрим основные вехи развития подходов к управлению ИТ-проектами и эволюцию критериев качества ПО в мире и в России, которая в 90-х годах шла своим путем, но за последнее время приблизилась к общим трендам.
А также разберемся, для каких проектов и команд уместны те или иные модели управления проектами, в чем могут крыться их преимущества и недостатки и какие формы организации разработки им соответствуют. Понимание этого позволит не только настраивать процессы в своем проекте, но и вести содержательные дискуссии с приверженцами иных форм организации, которые часто встречаются среди заказчиков и руководства.
= Краткое содержание =
== Моды ведения проектов - исторический обзор ==
[[File:Big Picture of IT project managerment Tsepkov AgileDays-2015.pdf|page=18|400px|border|right]]
# Исторически ИТ-разработка выросла из норм ведения НИОКР, к которым термин "услуга" применим в значительной степени условно. Ситуация изменилась с появлением персональных компьютеров, достаточно мощных для автоматизации предприятий, которые сделали востребованной осуществление этой автоматизации как услугу. Оказание этой услуги методами НИОКР оказалось невозможным из-за кадрового голода: формат НИОКР предполагает достаточно квалифицированный персонал, которого в необходимых объемах просто не существовала. Первый подход к решению этой задачи заключался в нормировании процессов.
# На первую половину 2000-х нормой оказания ИТ-услуги является ведение проекта по разработке (внедрению) ИТ-системы, которую необходимо спроектировать, а затем изготовить и внедрить с заданными критериями качества. Этот подход зафиксирован в PMBOK 3 версии (2004), на него же ориентирован RUP (2003). При этом упор делался на правильную организацию и надлежащее исполнение процессов. Далее я буду это называть "классическим подходом".
# Проекты, не смотря на тяжелые процессы, не приводили к результату. Проблемы касались качественного планирования и проектирования, которое разбивалось об изменчивость мира. На уровне стандарта (PMBOK) было зафиксировано, что даже тщательное исполнение процессов и реализация в соответствии не дает гарантии достижения целей проекта.
# Как ответ на вызов - появился Agile и SСRUM внутри него.
## SСRUM во главу угла поставил наблюдение за движением по проектной траектории. При этом было сформулировано, что задачу планирования решать бесполезно, надо определить цель и мерить до нее расстояние. А двигаться - итерациями, корректируя план.
## Нормировка качественного проекта изменилась, теперь в основу ставят адекватность оценки расстояния до цели и соответствие продвижения в итерацию предварительным оценкам. Для целей мониторинга движения к цели в отрасль втянута концепция SMART-целей, характеризующихся, в частности, измеримостью (Measurable). Сама концепция была известна в менеджменте с 60-х, приписывается то ли Друкеру (английская вики), то ли другим основателям.
## SCRUM позволил существенно снизить планку требований к младшему управленческому персоналу в ИТ с сохранением приемлемого уровня исполнения проектов, чем и объясняется его успех.
## После успеха SCRUM в отрасли итерационность разработки попробовали заложить в PMBOK 4 версии (2008), но по факту получилась эклектика. Там же попробовали нормировать проектирование (аналитическую работу), но через организацию процессов это тоже не получилось. Отмечу, что в RUP итерационность была изначально, а в другом стандарте, SWEBOK появилась в версии 3 (2004), однако там по факту речь шла о тяжелых итерациях, которые не возможно прокрутить быстро, как того требовал Agile. Таким образом, в стандарте уровня отрасли нормы Agile проявлены не были.
# Это путь развития в масштабе мира. В России на этот тренд накладываются события 90-х, в результате которых обеспеченность ИТ-отрасли квалифицированными кадрами, вышедшими из науки и способными оказывать ИТ-услугу методами НИОКР была существенно выше, чем в мире. В результате использование процессного нормирования оказалось существенно менее выражено. В настоящее время эффект в значительной степени размыт, и отличие России от всего мира - нивелируется.
== Современное состояние и вектора развития ==
# Agile и SCRUM сдвинули норму оказания отрасли от проектной деятельности к непрерывной, процессной. Такую организацию можно применять не только для начальной разработки или существенному реинжинирингу, но и к текущему развитию и доработке систем. Следующим шагом на пути в этом направлении стал ИТ-вариант Kanban-процесса. Это примерно 2010. Дальнейшее развитие этого сдвига - тренд DevOps.
# Ортогональная сдвижка, произошедшая в отрасли примерно в то же время - смещение фокуса от качества ИТ-системы (во всех смыслах, включая функционирование) к удовлетворенности стейкхолдеров проекта. Это смещение отчасти отразилось в PMBOK 5 версии (2013).
# Еще одно направление сдвижки - фокус на достижение возможностей для бизнеса, которые должны обеспечить ИТ. Эта сдвижка видна преимущественно в стартап-проектах и в продуктовой разработке, особенно в производстве игр. Сдвиг произошел после 2010.
# Произошедшие сдвижки нормирования зафиксированы в The Essence of Software Engineering, выдвинутой SEMAT и принимаемый сейчас OMG (beta1 - july 2013, beta2 - may 2014). В процессе работы из стандарта тщательно вычищали слово "проект", обеспечивая применимость на всех стадиях жизненного цикла. А в основные альфы включены стейкхолдеры, с которыми идет работа и возможности для бизнеса, которые желают получить.
# Проблема правильного проектирования систем и нормировки в этом поле не решена в отрасли по-прежнему. Лучшее известное мне решение для процесса управления проектом - FDD (Джефф де Люка), а для способа разработки проекта - DDD (Эрик Эванс)
== BigPicture методов ведения проектов ==
[[File:Big Picture of IT project managerment Tsepkov AgileDays-2015.pdf|page=19|400px|border|right]]
Историческая картина есть. Можно применять на практике? Нет, сначала нужно положить это на схемы, сделать Big Picture, на которых можно об этом рассуждать.
# Эпохи в историческом развитии - самый простой способ. Но лишь показывает историю, а не дает возможность конструирования своего.
# Вектора развития. Все они сохраняют актуальность, так как следующий этап - дополняет и расширяет предыдущий. Похожая, но отличающаяся картина - [http://lib.custis.ru/Культуры_программных_проектов_(Энтони_Лаудер) Энтони Лаудер "Культуры программных проектов"].
# История развитие как смещение фокусов внимания на схеме OMG Essence.
# Изменения на V-диаграмме: ИТ-проект как интегрированная часть бизнес-проекта, раньше их рассматривали достаточно изолировано.
== Применение на практике ==
[[File:Big Picture of IT project managerment Tsepkov AgileDays-2015.pdf|page=32|400px|border|right]]
# На уровне проекта. Понимать, в чем фишка проекта.
# На уровне компании. Что компания делает для мира и каким образом. Примеры различных концептов компаний.
# Как с этим работать практически и для чего оно нужно.
{{----}}
= Полная презентация =
<div style="text-align:left;">[[File:Big Picture of IT project managerment Tsepkov AgileDays-2015.pdf|page=-|400px|border]]</div>