- PVSM.RU - https://www.pvsm.ru -
Сейчас много говорят о гибких подходах к разработке программного обеспечения. И даже пытаются внедрить для выполнения гос. контрактов. С другой стороны, много компаний спотыкаются на этих подходах. И хотя в компаниях делают что нужно, и даже Scrum-мастер в них есть, программный Продукт почему-то перестает развиваться, и появляется много задач на исправление дефектов. Давайте разберемся почему так происходит.
Гибкие подходы к разработке программного обеспечения, начали применяться в России с 2002 года, после выхода книжек Кента Бека «Экстремальное программирование» (XP). Но, настоящую популярность принес Scrum, во главе со Scrum Alliance и сертификацией Scrum-мастеров. Всем понравилась простота применения, игры в планирование, геймификация ретроспектив, и очевидные ежедневные планерки, которые ранее применялись на заводах и в конструкторских бюро. И все уверовали в то, что можно меньше писать документации и больше общаться, а код сам по себе создастся качественным.
В результате, получилась интересная штука. Благодаря хорошей пропаганде (сертификация Scrum-мастера стоит не маленьких денег) под Agile-процессом разработки ПО начали понимать Scrum и наоборот. Но, зачастую при внедрении Scrum, и практик улучшающих общение, забыли об инженерных техниках обеспечивающих качественную разработку ПО.
В итоге, Agile превратился в карго-культ в который верят. А программный продукт, как не разрабатывался хорошим, так и не разрабатывается.
Давайте посмотрим внимательней на историю движения Agility применительно к разработке ПО.
Основным конфликтом который решался был следующий:
Для того чтобы Заказчик был доволен, нужно создать качественное и полезное программное обеспечение. Для создания качественного Продукта, нужно не менять требования в процессе разработки ПО. И одновременно с этим, чтобы создать полезный Продукт, нужно корректировать требования к Продукту, адаптировать под потребности. Нельзя одновременно менять требования и не менять требования.
Но как же тогда быть? Когда нельзя, но очень хочется, то можно. И авторы XP задумались: как бы сделать так, чтобы требования можно было менять (корректировать), а продукт был качественным?
Основной нежелательный эффект изменений требований к ПО состоит в том, что программный комплекс очень сложный, и изменение в одном месте может повлечь за собой непредсказуемое поведение в других местах. Для снижения влияния этого эффекта следует использовать модульные тесты, непрерывный рефакторинг и непрерывную интеграцию.
Таким образом, все инженерные техники XP увязывались в единую систему:
С другой стороны, необходимо не забывать и о Заказчике, и о том чтобы вовремя знать что он задумал и держать его в курсе. А также держать в курсе и всю команду:
Как следствие, если мы из всей системы практик вынем хоть один кирпич, то система рухнет и похоронит Продукт. Что впрочем и получается.
Как результат неполного применения всех техник лежащих в основе появились мифы описанные в статье Hayim Makabee. Конец Agile: смерть от примитивизма. //Практика проектирования систем.-2015. [1]
Но я думаю, что и эти мифы возникли не на пустом месте. Корневая причина этих мифов в том что, вместо применения полноценного процесса XP, который и был базой для Agile-подхода, все пользуются Scrum- коммуникационным фреймворком, который просто не покрывает всех потребностей разработки программного обеспечения.
Никакую практику нельзя применять бездумно, просто потому, что это модно или так сказал ОН. Всегда! Всегда нужно думать наперед.
Модульные тесты (TDD) позволяют сразу проверять, и создавать нужные программные интерфейсы. Но они не защищают от неправильной архитектуры. В момент написания теста мы думаем тактически, а не стратегически. Что влечет за собой неверные решения и отсутствия небольшой на будущее.
Хорошая техника «Парное программирование», обеспечивает думание стратегически на лету. При парном программировании один ВСЕГДА будет «навигатором» — стратегом (без клавиатуры), а второй «пилотом» за клавиатурой. Это позволяет охватывать сразу весь код в общем, и принимать решения по месту.
В Методологии XP нигде не написано «Не пишите документацию». Коммуникации важнее документации, но если документация является способом коммуникации, то система Wiki обеспечивает создание этой документации ровно в том объеме в котором надо. Что, в свою очередь, улучшает синхронизацию пары (пилот-навигатор) и создание качественного кода за счет проработки и обсуждения архитектуры.
Также, в практиках Экстремального Программирования нигде не написано «делайте технический долг и сделаете заказчика счастливым», там написано «делайте непрерывный рефакторинг, тесты защитят вас. да прибудет с вами Сила». Это значит что при завершении КАЖДОЙ задачи не должно оставаться технического долга. Совсем.
В Методологии XP, также, не написано «Не проектируйте всю систему наперед». Там написано «Будьте готовы к изменениям», это значит, что необходимо делать архитектуру в меру гибкой, и одновременно с этим в меру достаточной для реализации известного объема работ и демонстрации частого результата Заказчику.
Q: А бывают ли проекты по Scrum успешными?
A: Только если они делаются с применением практик XP. Или в случае если весь проект выполняется менее чем за 1 месяц под ключ.
Автор: BiPulse
Источник [2]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/scrum/114518
Ссылки в тексте:
[1] Hayim Makabee. Конец Agile: смерть от примитивизма. //Практика проектирования систем.-2015.: http://reqcenter.pro/agile-myths/
[2] Источник: https://megamozg.ru/post/24562/
Нажмите здесь для печати.