- •Rup и другие методологии разработки по. Часть 1. Принципы сравнения методологий разработки по
- •Как «измерить» методологию
- •Итеративная или каскадная разработка
- •Каскадный подход
- •Итеративный подход
- •Почему это важно
- •Уровень формализма Что такое формализм в проекте
- •Почему важна степень формализма
- •Что будем сравнивать
- •Часть 2. Сравнение методологий разработки по
- •Как получится…
- •Структурные методологии
- •Гибкие методологии
- •EXtreme Programming, или xp (экстремальное программирование)
- •Crystal Clear
- •Feature Driven Development
- •Общие черты
- •Модели зрелости процесса разработки (cmm, cmmi)
- •Часть 3. Как выбирать методологию?
- •Сколько формализма нужно? Польза документации
- •Общение вместо документации
- •Как выбирать?
- •Сколько итераций потребуется? Еще раз об итерациях
- •Польза и вред итераций
- •Как выбирать?
- •Подведем итоги
Часть 3. Как выбирать методологию?
Алексей Закис
Сколько формализма нужно?
Польза документации
Общение вместо документации
Как выбирать?
Сколько итераций потребуется?
Еще раз об итерациях
Польза и вред итераций
Как выбирать?
Подведем итоги
В первой части статьи мы определили ключевые показатели, по которым имеет смысл сравнивать методологии, во второй — проанализировали некоторое количество методологий. Теперь пора решить, какая же методология лучше.
Если вернуться к аналогии с выбором цифровой фотокамеры, то можно сказать, что мы уже разобрались, по каким принципиальным параметрам камеры отличаются друг от друга, прочитали обзор, в котором для каждой камеры указаны размер изображения в мегапикселах, характеристики объектива и количество программ съемки. Теперь мы хотим найти ответ на самый главный вопрос: что же все-таки выбрать?
В случае и с камерой, и с методологией ответ будет одинаков: не следует гнаться за экстремальными характеристиками, нужно выбрать то, что отвечает вашим задачам. Для этого при выборе методологии надо решить, какую степень формализма вы хотите обеспечить и насколько итерационным должен быть проект.
Сколько формализма нужно? Польза документации
В информационной индустрии долгое время считалось, что чем больше тщательно оформленной документации выпускается в ходе выполнения проекта, тем лучше — значит, тем тщательнее проработан проект, тем полнее сохраняются и передаются в группу сопровождения знания и проектные решения по проекту и тем проще в дальнейшем сопровождать продукт.
Однако, как оказалось, это не совсем так. Впрочем, причину, по которой возникали проблемы, сначала определили, как это нередко бывает, неправильно. Решили, что вопрос только в объеме документации — вот если бы она была компактнее… Почитайте старые (да, десятилетние для информационных технологий — это даже очень старые) руководства по структурному анализу и проектированию — сколько там радости по поводу того, что удалось заменить толстые тома компактными диаграммами! Действительно, одна удачная диаграмма может заменить иногда десяток страниц текста. Документация с большим количеством диаграмм стала более доступной и компактной.
Общение вместо документации
Однако наличие самой лучшей документации спасает не всегда. Разработка идет значительно быстрее, а ошибок совершается гораздо меньше, если есть не только документация, но и человек, который знает, что в ней написано, и может объяснить это всем заинтересованным лицам. Как постоянный контакт с заказчиком, позволяющий быстро получить ответ на любой вопрос, ускоряет работу аналитика, точно так же возможность обратиться непосредственно к аналитику и уточнить детали предложенного им решения ускоряет работу разработчика и так далее по цепочке. Кроме того, подобные контакты дают участникам разработки возможность получить объективную оценку качества предложенных ими решений и накопить весьма полезный профессиональный опыт. Не следует также забывать, что разработка и рецензирование документации являются весьма трудоемкими операциями, требующими существенных ресурсов и времени.
Таким образом, формальная документация проекта не является единственным и, более того, самым быстрым каналом передачи информации между участниками разработки. Использование других возможностей, прежде всего непосредственного контакта, позволяет существенно ускорить обмен информацией, уменьшить затраты на разработку документации и сократить сроки разработки. Однако увлечение личным общением и пренебрежение формальным документированием и другими формализованными процедурами ведет к потере управляемости проектом. Превышение некоторого объема сведений, который участники разработки должны помнить, или удлинение периода, в течение которого их нужно помнить, приводит к росту количества ошибок и соответственно затрат на их исправление.
