Создание программных продуктов стало индустрией с тех пор как появились персональные компьютеры, «коробочное» ПО и Internet. Как и в любой другой индустрии тут существует продукт, потребители и производители этого продукта. И, как и в любой другой индустрии, производители стремятся держать под контролем процесс создания (производства) продукта. Конечно, это не единственный процесс, который надо наладить для достижения успеха, но один из основных. И для этого важного процесса нужен метод, который позволит управлять ситуацией, не сковывая творческий порыв разработчиков. О методе и пойдет речь. Мы рассмотрим хорошо известную методологию Agile, и сравним наиболее популярные варианты применения данного метода на практике.
Специфика производства ПО в том, что технологии позволяют пробовать достаточно много различных решений одной и той же задачи, и создают возможность для быстрого старта производства. А что, сейчас сядем и придумаем, а как все придумаем так все и напишем, и сразу же будем продавать ( или раздавать, кому как нравится ). И на всем протяжении работы команда сильно рискует, т.к. можно неправильно оценить ситуацию и сделать не то, что хотел заказчик, или не уложиться в сроки, или потратить деньги и терпение инвестора раньше выпуска первого коммерческого релиза. Agile software development – семейство методологий разработки ПО. Краткое описание можно найти здесь В этом методе процесс разработки разбивается на итерации от 1 до 4 недель. Каждая итерация – полноценный цикл производства: планирование, анализ требований, дизайн, кодирование, тестирование и документирование. Цель каждой итерации – получение следующего стабильного (без ошибок 
) релиза. Каждый следующий релиз или улучшает существующую или прибавляет некоторое количество новой полезной функциональности. Или и то и другое. В конце итерации команда пересматривает приоритеты проекта. Отдавая предпочтение прямой коммуникации внутри команды и с заказчиками, данный метод требует минимум документации. Но, все равно требует, причем качественной. Перечислим некоторые принципы agile методологии разработки (далее будем говорить «гибкая методология разработки») :
- Быстрая реакция на запросы заказчика, выпуск релизов, полезных заказчику.
- Частый выпуск релизов ( счет времени между релизами идет на недели а не на месяцы)
- Релиз – главный показатель прогресса производства
- Изменения в требованиях принимаются в любой момент, даже на поздних стадиях реализации продукта
- Тесное, ежедневное сотрудничество команды разработчиков с заказчиком и всеми заинтересованными в продукте лицами
- Взаимодействие лицом к лицу. Прямое общение лучший способ взаимодействия.
- Проект развивают мотивированные члены команды которым следует доверять
- Постоянное внимание техническому совершенствованию и дизайну системы
- Простота
- Самоорганизующиеся команды
- Постоянное приспособление к меняющимся обстоятельствам
Метод предъявляет сравнительно немного требований к команде разработчиков. Но это сильные требования. Команда должна состоять из профессионалов, потому что команда принимает много важных решений. Коллектив должен быть дружным и открытым. На практике это не всегда легко устроить. Но главное, на мой взгляд, – это тесная, практически постоянная связь с заказчиком. Это самое важное и самое трудное в успешном применении данного метода. Потому что заказчики бывают разные. И главное, в данном методе заказчик берет на себя очень большую ответственность. На практике к этому не всегда готовы. Если все-таки результат работы будет неудачным, у заказчика в данном подходе практически нет шансов сказать фразу «Я не знал. Меня не предупредили». Также может быть, что заказчик хочет получить продукт, не прилагая к этому никакого труда. Логика бывает убийственно проста: «Вам платят деньги – вы и думайте, чтоб мне все понравилось. Мне некогда. Будет готово – буду смотреть». Такое встречается все реже, но все еще встречается. Дело будет погублено. Большое искусство организовать прочные и деловые отношения с заказчиком.
Гибкая методология разработки – это итеративный и инкрементный процесс. В этих рамках прогресс движется короткими и частыми шагами. Это очень демократичный подход, в котором нет мнений, которые не обсуждаются, а дело действительно общее. Одновременно, этот метод требует высокой профессиональной культуры от каждого участника. Именно профессиональная культура и индивидуальная организованность защищает команду от конфликтов, непродуктивных споров и безответственных решений. Роли руководителя команды и заказчика имеют огромное значение.
Recent Comments