7326
правок
Изменения
Новая страница: « 17-18.05.22 Москва [https://teamleadconf.ru/moscow/2022 Teamlead] [https://teamleadconf.ru/moscow/2022/abstracts/8412 Доклад на сайте кон…»
17-18.05.22 Москва [https://teamleadconf.ru/moscow/2022 Teamlead]
[https://teamleadconf.ru/moscow/2022/abstracts/8412 Доклад на сайте конференции]
В среде IT распространено мнение, что проектный подход, PMBOK - тяжелая, но работающая штука. И потому в случае "серьезных проектов" стоит к нему обращаться, а если руководитель говорит о каких-то практиках, ссылаясь на проектный подход, то к этому тоже стоит отнестись с уважением. К сожалению, это - заблуждение. Регламенты проектного подхода, RUP и PMBOK были в 1990-е разработаны для того, чтобы обеспечить гарантированный успех проекта, пусть ценой тяжелых процедур. Но это не дало гарантий, успешность проектов осталась примерно на прежнем уровне. И именно поэтому появились Agile-методы, признающие приоритет человеческого фактора над процедурами. С тех пор вышло несколько версий PMBOK, в которых пытались достичь успеха, но без успеха, и в результате сейчас PMI сертифицирует по Agile-методам.
Главное преимущество Agile-методов - они позволяют делать проекты некомпетентной командой, что неизбежно в условиях быстрого развития технологий: компетентных разработчиков для новых технологий просто не существует. В то время как в проектном подходе компетентная команда - непременное условие успеха. Но это - не единственное ограничение. И в докладе мы подробно разберем конструкцию и практики проектного подхода и их ограничения с тем, чтобы снять необоснованный пиетет и принимать ответственные решения об использовании тех или иных практик в ваших проектах. Ведь организацию работы следует строить индивидуально для проекта, из набора шаблонов, подобно тому, как индивидуально подбирают набор используемых шаблонов разработки софта.
Кроме того, это поможет вам вести коммуникацию с менеджерами и стейкхолдерами заказчиков, которые часто полагают, что Agile-методы - это такие игрушки для тех, кто не способен освоить хардкор проектного метода, и обосновывать для них ваш способ работы.
Я кратко рассказывал эту тему внутри докладов про историю развития IT, например, в [[Мыслить проектно: история и современность (SECR-2018)]], но там это - 3-4 слайда. А летом 2021 я написал статью [https://vc.ru/hr/272211 Agile-методы и проектный подход - в чем разница?] B в докладе тема развернута подробно, с фокусом именно на ограничения и проблемы проектного подхода как методологии. Альтернативные способы ведения проектов тоже затронуты.
В презентации - много ссылок на другие мои доклады и статьи, и на другие материалы. Для удобства собираю их в общий список.
* Мои доклады и статьи
** [[Мыслить проектно: история и современность (SECR-2018)]]
** [[Планирование проекта от демонстраций для разворачивания партнерства с заказчиком (Saint TeamLeadConf 2019)]]
** [https://vc.ru/hr/272211 Agile-методы и проектный подход - в чем разница?]
* Чужие доклады и статьи
** [http://www.developerdotstar.com/mag/articles/reeves_design.html Jack W. Reeves. What is software design] (1992), [http://lib.custis.ru/Reeves перевод]
** [http://0x1.tv/Poisson-burning-time-agiledays-lighting-talk Андрей Бибичев «Пуассоново горение сроков»]
** [https://www.omg.org/spec/Essence/About-Essence/ Стандарт OMG Essence]
** [https://practicelibrary.ivarjacobson.com/ Practice library Ивара Якобсона] с описаниями методов в модели OMG Essence. Бесплатно доступна после регистрации.
* Описания моделей в википедии
** [http://en.wikipedia.org/wiki/Waterfall_model Модель водопада], а то есть мнение, что модель водопада - придуманная фикция, которую никто не использует.
** [http://en.wikipedia.org/wiki/V-Model_(software_development) V-model]
** [https://en.wikipedia.org/wiki/Cynefin_framework Cynefin framework]
** [https://en.wikipedia.org/wiki/Technology_readiness_level TRL] - Technology readiness level
** [https://en.wikipedia.org/wiki/Conway's_law Закон Конвея]
[https://teamleadconf.ru/moscow/2022/abstracts/8412 Доклад на сайте конференции]
В среде IT распространено мнение, что проектный подход, PMBOK - тяжелая, но работающая штука. И потому в случае "серьезных проектов" стоит к нему обращаться, а если руководитель говорит о каких-то практиках, ссылаясь на проектный подход, то к этому тоже стоит отнестись с уважением. К сожалению, это - заблуждение. Регламенты проектного подхода, RUP и PMBOK были в 1990-е разработаны для того, чтобы обеспечить гарантированный успех проекта, пусть ценой тяжелых процедур. Но это не дало гарантий, успешность проектов осталась примерно на прежнем уровне. И именно поэтому появились Agile-методы, признающие приоритет человеческого фактора над процедурами. С тех пор вышло несколько версий PMBOK, в которых пытались достичь успеха, но без успеха, и в результате сейчас PMI сертифицирует по Agile-методам.
Главное преимущество Agile-методов - они позволяют делать проекты некомпетентной командой, что неизбежно в условиях быстрого развития технологий: компетентных разработчиков для новых технологий просто не существует. В то время как в проектном подходе компетентная команда - непременное условие успеха. Но это - не единственное ограничение. И в докладе мы подробно разберем конструкцию и практики проектного подхода и их ограничения с тем, чтобы снять необоснованный пиетет и принимать ответственные решения об использовании тех или иных практик в ваших проектах. Ведь организацию работы следует строить индивидуально для проекта, из набора шаблонов, подобно тому, как индивидуально подбирают набор используемых шаблонов разработки софта.
Кроме того, это поможет вам вести коммуникацию с менеджерами и стейкхолдерами заказчиков, которые часто полагают, что Agile-методы - это такие игрушки для тех, кто не способен освоить хардкор проектного метода, и обосновывать для них ваш способ работы.
Я кратко рассказывал эту тему внутри докладов про историю развития IT, например, в [[Мыслить проектно: история и современность (SECR-2018)]], но там это - 3-4 слайда. А летом 2021 я написал статью [https://vc.ru/hr/272211 Agile-методы и проектный подход - в чем разница?] B в докладе тема развернута подробно, с фокусом именно на ограничения и проблемы проектного подхода как методологии. Альтернативные способы ведения проектов тоже затронуты.
В презентации - много ссылок на другие мои доклады и статьи, и на другие материалы. Для удобства собираю их в общий список.
* Мои доклады и статьи
** [[Мыслить проектно: история и современность (SECR-2018)]]
** [[Планирование проекта от демонстраций для разворачивания партнерства с заказчиком (Saint TeamLeadConf 2019)]]
** [https://vc.ru/hr/272211 Agile-методы и проектный подход - в чем разница?]
* Чужие доклады и статьи
** [http://www.developerdotstar.com/mag/articles/reeves_design.html Jack W. Reeves. What is software design] (1992), [http://lib.custis.ru/Reeves перевод]
** [http://0x1.tv/Poisson-burning-time-agiledays-lighting-talk Андрей Бибичев «Пуассоново горение сроков»]
** [https://www.omg.org/spec/Essence/About-Essence/ Стандарт OMG Essence]
** [https://practicelibrary.ivarjacobson.com/ Practice library Ивара Якобсона] с описаниями методов в модели OMG Essence. Бесплатно доступна после регистрации.
* Описания моделей в википедии
** [http://en.wikipedia.org/wiki/Waterfall_model Модель водопада], а то есть мнение, что модель водопада - придуманная фикция, которую никто не использует.
** [http://en.wikipedia.org/wiki/V-Model_(software_development) V-model]
** [https://en.wikipedia.org/wiki/Cynefin_framework Cynefin framework]
** [https://en.wikipedia.org/wiki/Technology_readiness_level TRL] - Technology readiness level
** [https://en.wikipedia.org/wiki/Conway's_law Закон Конвея]