Право на ошибку. Деньги и методологии разработки в ИТ
Есть много разных методологий разработки: Waterfall, Agile, Lean и другие. Ситуацию усложняют различные схемы оплаты разработки в ИТ. Что лучше: Fixed Price, Time&Material или взять людей на аутстафф? Человеку, далёкому от коммерческой разработки, бывает сложно разобраться что и когда стоит использовать. Чтобы помочь с этим разобраться, рассмотрим…
а какую методологию используете вы в своем компании? нередко команды переделывают хрестоматийные методологии под себя.
Чаще всего мы занимаемся нестандартными и крупными проектами, для них не существует «идеальной методологии». Если удаётся ограничить объем работ, то удобно использовать Unified Process с поэтапной сдачей. К тому же поэтапная сдача и оплата повышает для заказчика безопасность и управляемость процессом разработки.
Был проект с чудовищной изменчивостью требований (по объективным причинам), его пришлось делать даже не по методологии, а по Agile Manifesto. Это было похоже на итеративную разработку, но длина итерации колебалась от 1 до 4 недель, и могли прилетать срочные изменения. Например, Scrum в таких условиях сразу бы отказал. Вытаскивать все приходилось за счёт управления ожиданиями, управления рисками и созданием общей команды проекта в которой были не только наши сотрудники, но и сотрудники заказчика.
Есть уже взрослые системы, на которых работа идёт по «Канбан», и там этого хватает.
Есть продуктовая разработка по SCRUMbut, и там это удобно, как нам, так и заказчику.
Внутри себя мы не пропагандируем идеологию той либо иной методологии разработки либо инструмента разработки, используем то, что удобно и эффективно под конкретную задачу.
Единственное, что мы предпочитаем работать малыми и слаженными командами. Так скорость и эффективность выше. Но это общее для многих методологий.