Крайние два месяца работаю в проекте, в котором используется методолгия разработки SCRUM. Это мой первый опыт использования SCRUM как dev, внутри команды. Один раз довелось принять участие в качестве «продукт оунера» в проекте, ну так меня тамошние программеры называли, а в особенности их процесса я не вникал. :-)

Судя по описаниям, у нас в проекте прямо самый настоящий скрам, почти в максимальном его проявлении. Сейчас перечислю все характеристики, которые мне заметны изнутри, как разрабочику.

1. Спринты по 2 недели.
2. Каждую неделю вносятся изменения в changelog.
3. Каждый день ровно в 17 проводится meeting, каждому отводится 2-3 минуты на рассказ о том, что за сегодня сделал, какие проблемы возникли.
4. В конце спринта проект показывают product owner-у, в конце каждого второго спринта — заказчику.
5. В конце «вехи» разработки проводится ретроспектива.

Как видно, под описание «скрам» наш процесс очень даже подходит. И мне очень нравится этот режим разработки. Вроде как бы процесс идет нон-стоп, и временные рамки очень четко заданы. Привчка с времен фриланса — в жестких временных рамках работается гораздо проще, чем когда известно, что проект нужно выкатить через 3 месяца. Ну и постоянный контроль от product-owner и заказчиков — в случае, если команда начинает делать что-то не то, что нужно, быстро приходит обратная связь с требованием коррекции функционала проекта.

Еще одним достоинством могу назвать ротацию разработчиков по частям проекта. Каждый разработчик время от времени работает над разными частями проекта, и имеет представление о системе в целом, а не только о своем «куске, который он месяцами пилит». Это же касается и тестирования, у нас на каждого девелопера приходится по одному тестеру, но это не значит, что они «приставлены» к dev-ам, какой тикет придет на тестирование, тот и проверяют.

В целом, полностью поддерживаю мнение Ханка Рейнвотера («Как пасти котов»), в том, что Agile это скорее всего единственная действенная «философия» разработки ПО, к которой должны, в конечном итоге, сводиться все остальные методологии. Методология позволяет сохранять ритм, увеличивать или замедлять темп разработки, позволяет команде быть довольно гибкой, ротация задач по разработчикам позволяет dev-aм не засиживаться над скучными задачами, а работодателю — иметь примеро одинаково осведомленных о проекете сотрудников, что защищает его от неожиданностей — любой дев из команды сможет подхватить работу другого разработчика. Мастхевная технология.