Related Posts
Оценка и планирование проекта
Мысли о видах информационных систем…
Конфигурация "Выдача пропусков и учет рабочего времени"
Управление ИТ-проектами. Модуль 3: продвинутый курс по гибкому управлению проектами. Agile. Первый поток. Вебинары проходят с 11 сентября по 27 ноября 2024 г.
Загрузка/Выгрузка Excel для справочника "Графики работы сотрудников"
Онлайн-курсы по управлению ИТ-проектами от Марии Темчиной
Замечательная статья, но немного из своей практики agile в 1С с 2009 года — касательно аксиом:
1. «водопад» дешевле и проще — ограничение данной аксиомы: водопад дешевле и проще, если вы раньше не работали с agile. Когда большой опыт работы по agile, думаешь зачем вообще нужен водопад? Не могу найти случаев, когда он был бы полезнее в принципе. Когда очень большой опыт, понимаешь, что водопад — это просто-напросто одна слишком большая итерация, а по сути agile — это по факту ускоренный водопад.
2. Атмосфера сотрудничества — при отсутствии атмосферы сотрудничества, не взлетит и водопад. Но agile при отсутствии атмосферы сотрудничества лучше — 1) вы раньше уйдете с проекта, и займетесь чем-то полезным другим. 2) Снижается риск того, что заказчик не заплатит по итогу проекта (это уже видно по результату первых спринтов в agile) 3) С психологической точки зрения если в самом начале видишь проблемы и прерываешь работу, нет выгорания участников проекта, чем когда один большой водопадный проект, в ходе которого проблемы растут большим комом и сотрудники начинают демотивироваться
3. Agile редко предлагает самое дешевое решение. Вот за что люблю agile, так за экономию бюджета (часто). Когда показываешь заказчику, что за счет гибкости сделали 70% функций от бюджета, и все собственно говоря уже летает (early delivery), то он говорит, а нафига нам еще 30% низкоприоритетных? Мы и без них обойдемся. С другой стороны, если в ходе первых спринтов выясняется, что прогноз из-за меняющихся требований оказывается в разы больше, можно раньше остановить проект из-за снижения ожидаемой отдачи и сэкономить деньги на этом
Agile — это либо тянуть кота за хвост по наименьшей цене либо постоянно и непрерывно разрабатывать достаточно большие блоки автоматизации.
Проблема в величине блока, который имеет смысл автоматизировать для конкретного разработчика.
Там, где Agile может создавать какую-то иллюзию внедрения, водопад — это просто первоапрельский розыгрыш.
В качестве дополнения.
В жизни 1С есть не только переход с одной конфигурации на другую, еще огромное пространство занято развитием и совершенствованием (употребимо и кастомизацией) внедренной ранее 1С.
Кто-то из Заказчиков собирает свою команду, кто-то развивает систему силами аутсорсинга.
И вот на полях кастомизации Agile резко повышает свои шансы на применимость.
В какой-то мере (а иногда и добрых 100%) старая добрая почасовка по кастомизации еще времен 1С 77 есть прямое воплощение Agile.
Конечно, при почасовке хватало do&fix (тяп-ляп), может в абсолютном выражении даже в большинстве случаев.
Но совсем нередко обычная почасовка приносила успех, очаровывала клиентов, давала результат как раз тем, что мы вдохновенно читаем в манифесте принципов Agile.
Тут тебе и сотрудничество и взаимодействие и работающий продукт и готовность к изменениям, и было же немало случаев, когда все это выполнялось сходя из принципа «не отрицая важности того, что справа», т.е. оставляя задокументированные результаты, выстроив процессы внедрения по схеме почасовки и т.п.
В такой почасовке рождались примеры применимости гибких методов даже для случая «безжалостной» кастомизации (это когда типовая медленно становилась мини-отраслевым решением).
Но почасовка не обязательна, любое послепроектное сопровождение и развитие системы вполне может быть организовано в соответствии с принципами Agile, разве что перед Заказчиком возникнет задача реинжиниринга таких мастшабов, что придется вспоминать старый добрый водопад+прототипы.
(1) Спасибо за комментарий, очень конструктивно и по делу. Наконец, дошли руки ответить
1. «водопад» дешевле и проще — ограничение данной аксиомы: водопад дешевле и проще, если вы раньше не работали с agile.
Соглашусь с вами, что, возможно, я зря написала здесь слово «аксиома». Ибо у каждого проекта и у каждой команды своя история. Что я имела в виду? Agile часто предполагает переделки уже сделанного, более внимательное вникание в детали и т. п. По моему опыту, как раз водопад позволяет нередко довольно дешевое решение получить… Но, увы, не всегда подходящее…
Когда большой опыт работы по agile, думаешь зачем вообще нужен водопад? Не могу найти случаев, когда он был бы полезнее в принципе.
Мой опыт показывает, что в ситуациях высокой определенности, в ситуациях, когда требуется понимать на старте сложную архитектуру — классические подходы к управлению проектами часто оказываются уместными (хотя отдельные элементы Agile улучшат даже самый водопадистый водопад).
2. Атмосфера сотрудничества — при отсутствии атмосферы сотрудничества, не взлетит и водопад.
Водопад лучше позволяет разводить имитацию бурной деятельности, получать деньги за никому не нужный проект и делать лицо кирпичом — все согласно условиям контракта, мы ничего не знаем…
3. Agile редко предлагает самое дешевое решение. Вот за что люблю agile, так за экономию бюджета (часто).
Повторюсь, у каждого своя история. В моей практике специалисты, готовые работать по Agile часто оказываются дороже, например.
(2)
Я генерально согласна с точкой зрения, что Agile в классическом виде не очень подходит для сложных решений, связанных с кардинальной переработкой архитектуры. Ибо если в этом месте мастерить маленькими кусочками, можно на выходе получить странноватого монстра. Так что да — величина блока имеет значения.
А можно и по-другому сказать. Там, где водопад в принципе невозможен, потому что требования крайне размыты и методы технической реализации вообще не понятны, Agile может дать возможность получить [хоть какой-то] результат.
(3) Да, Valerych, согласна с вами — действительно, принципы давно применялись толковыми командами и до появления Agile манифеста. Плюс Agile в том, что интуитивные находки превратились в используемую и тиражируемую технологию.
Проекты внедрения иногда тоже можно делать по Agile. Вопрос, действительно, в том числе в масштабах бедствия.
А еще у Agile есть одна интересная ниша — спасательного круга для проектов, утонувших в классическом водопаде. Когда после мучительной агонии большого проекта у заказчика остаются обломки в виде недопиленных (и плохо документированных) кастомных модулей, покрывающих какую-то часть бизнес-процессов, недообученных пользователей и скептически настроенного руководства, а глобальные планы «МЫ АВТОМАТИЗИРУЕМ ВАМ ВСЕ» со сроком исполнения 6-12 месяцев отвергаются прямо с порога. Вот в такой обстановке Agile заходит «на ура», потому что первые (пусть и скромные) результаты можно увидеть уже через месяц.
Да, соглашусь! Вообще, неоднократно сталкивалась с точкой зрения, что «первая команда», пришедшая автоматизировать, часто терпит крах, а «вторая команда», пришедшая исправлять недоделанное — часто гораздо успешнее.
Метафору «проекты, утонувшие в водопаде» с вашего позволения возьму на вооружение
(8) С тем, что «спасатели» чаще более успешны, чем «первопроходцы» — соглашусь. Но причина, имхо, не столько в разнице между командами, сколько в разнице субъектов «Заказчик ДО краха первого проекта» и «Заказчик ПОСЛЕ». Во втором случае резко снижается административный апломб («Я всегда прав, по определению»), формальность подхода к сотрудничеству («Вы же специалисты — вот и сделайте мне конфетку из того, что есть»), и так же резко повышается ответственность при выполнении своей части работы («Еще одного провала моя карьера точно не выдержит»), и готовность прислушиваться к рекомендациям этих самых специалистов («В прошлый раз мы уже попробовали реализовать ВСЕ наши хотелки, не особо вникая, о чем нас там предупреждает Исполнитель»)…
А метафорой — пользуйтесь на здоровье, конечно. У меня их еще много ))
(0) контракты по классической схеме и по гибким методологиям подразумевают знание программного продукта — и там, и там надо оценивать объем работ и трудоемкость каждой задачи, каждого функционального блока. Если программный продукт новый для Исполнителя для внедрения, то оценить объем работ и трудоемкость будет невозможно при любых методологиях. так ведь?
а без этого понимания рамочный договор нельзя будет составить… получается, что чем больше внедренец и разработчик знает программный продукт, тем легче оценить объем работ и трудоемкость задач.