Scrum - одна из гибких методик (agile) разработки программного обеспечения в группе. У нас в Exact'е одна из .NET групп приняла её к использованию, а до этого я слышал на лекциях английского что коллеги в других конторах тоже используют. А тут ещё набрёл на статью Антона на Хабре с переводом книжки для украинских девелоперов, думаю и мне она пригодится.
От себя могу заметить что никакая методика не заменит хорошей комманды,
она лишь меняет способ управления. В частности ежедневные стоячие
совещания по 15 минут утром я терпеть немогу.
Многие наверняка слышали про Rational Unified Process. Вообще методик по управлению "ресурсами" человеко-часов уйма и принятие одной из них в свою фирму может дать не только бумажку, но и неэффективность всвязи с тем что такая методика не подходит для области деятельности фирмы.
OpenUP - бесплатная методика ( тогда как некоторые более 700$ стоят) и ориентирована на развитие небольших проектов в небольших фирмах (до 36 человеко-месяцев). Вполне подходит для IT, поскольку текучка кадров большая, а проекты стоять не хотят.
Ради достижения успешности проекта, группа разделяется на 3-6 ролей (вспоминаем сразу классы в RPG?):
клиент
управляющий проектом
аналитик
архитектор
тестер
разработчик
Весь процесс разбивается на 4 этапа - основание, переработка, разработка, заключение. В первом закладывается суть проблемы, во втором она рассматривается, в третьем решается, в четвёртом подтверждается.
Несомненно в мире множество фирм в каждой из которых принят некий обычай как проект надо делать, а для этого созданы всевозможные процессы развития проекта типа waterfall, spiral, RUP и тд.
Попробую изложить, как на моём опыте обычно ведётся IT-проект (CMS, CRM, intranet, custom-инфосистема) или как бы этого хотелось в идеале.
Общение с клиентом
Как правило самая важная техническая часть это узнать разделы проекта, что-бы примерно понять насколько он сложен. В остальном клиенту вешают лапшу на уши, что-бы он остался доволен переговорами и согласился на договор. Показывают как работает фирма, показывают портфолио и слеланные работы. Намечают следующую встречу, где уже более детально всё прорабатывается
Может помочь использование brain-storm методики при разговором с клиентом, запись в MindMeister, MindManager, Freemind, что-бы как можно подробней зарисовать пожелания.
Нельзя использовать неопределённости размера, времени, пользователей
Нельзя выдумывать новые понятия, не определив их заранее.
RAD это методология быстрой разработки приложений, в которой часто жертвуют производительностью, функциональностью и удобствами usability. Возникла она из-за того, что чем больше проект, тем сложней его сделать не столько из-за масштабов, сколько из-за динамики развития самого проекта, которая обрушивала основы по которым он изначально проектировался.
RAD фокусируется на качестве и скорости, поэтому проект должен быть разбиваем на части, которые реализуются коммандой из 2-6 человек. Для быстрой реакции со стороны клиента наобходимо свести к минимуму число людей решающих что хочет клиент.
