Лет 10 назад веб-проекты по большей части были статическими, а технологический процесс порой — прост до безобразия. Теперь грань между веб-приложениями и настольными приложениями стирается, функциональная сложность веб-проектов растет. Это диктует новые требования к веб-разработке. Обычная ситуация нынче, в эпоху «удиви меня 2.0», — когда проект долгосрочный, в нем задействовано множество специалистов (и не специалистов также), щедро орошающих многострадальный product backlog новыми идеями и целями, как до начала разработки, так и после. Как вы понимаете, цели и истории мутируют, а вместе с ними и задачи. Предварительная оценка по времени теряет свою целесообразность. И т.д. и т.п. Очевидно, нужна специальная методология разработки. Можно попробовать приобщиться к Rational Unified Process (RUP) или Process Mentor. Однако, не стоит. Среди столь популярных ныне Agile методик имеется то, что нам надо — Feature Driven Development (FDD).
В общих чертах подход можно описать следующей последовательностью:
В идеале на выходе мы получаем платформу, постепенно обрастающую свойствами. Звучит как-то подозрительно просто. Давайте все же посмотрим, что это такое.
Как выразился автор методологии Джеф Делюка (Jeff Deluca — http://www.jeffdeluca.com), общая модель – больше набросок или очертание, нежели детальное содержание. Однако чтобы получить эту модель, недостаточно просто требований к проекту. Модель – это видение проекта, основанное на результатах предварительных исследований. Спасибо Луису Розенфельду (Louis Rosenfeld — http://louisrosenfeld.com) – мы знаем, насколько важна роль информационной архитектуры при веб-разработке. На этапе общей модели у нас должны быть – анализ целевой аудитории, анализ контента и контекста его использования, структура контента, включая метаданные и тезаурус. Должен быть документ, описывающий принципы пользовательского интерфейса, список используемых UX-компонентов, описание их свойств и поведения.
Рис.1. Пирамида информационной архитектуры
В данном подходе подразумевается, чтомы приступаем кразработке, имея лишь наброски системы, которыепо мере разработки обрастают деталями. Таким образом, детальные каркасы (wireframes) будут разработаны входе создания соответствующих свойств (features) или, другими словами, частей проекта. Однако на стадии общей модели таки потребуются «сырые» каркасы основных интерфейсов и предварительная карта сайта.
Все выше описанное –сопутствующие документы. Основной результат этапа–модель домена (Domain model). Это статическая UML диаграмма, включающая все определенные к данному моменту логические объекты проекта и их взаимодействие (объект является частью другого объекта, объект расширяет другой объект и т.д.).
Не думаю, что здесь мне стоит вдаваться вподробности. Большинствоиз вас использует методику SCRUM, а список свойств в FDD – то же самое, что и product backlog в SCRUM. Разве что стоит еще раз напомнить: при создании списка следует оперировать именно целями и подцелями, но не задачами.
Все бы хорошо, но как же оценить время разработки свойств проекта, когда детали туманны. Связанные задачи для разработчиков будут предельно ясны только тогда, когда будут выполнены все предварительные работы по данному свойству. Как же планировать? И тут на помощь приходит Story Point Estimation. Мы оцениваем свойства не в человеко-днях, а в абстрактных баллах по мере сложности свойства. Из всего списка предлагается выбрать свойство минимальной сложности и присвоить ему 2 балла сложности. Рекомендуется использовать экспоненциальную шкалу, например: 1, 2, 3, 5, 8. Тогда спрашивается, почему мы не назначили 1 самому пустяковому свойству. На всякий случай. Список свойств огромный и с первого взгляда маловероятно, что вы будете максимально точны в оценке.
В оценке принимают участие все члены команды. Т.е., каждое свойство обсуждается с позиций всех этапов разработки до тех пор, пока команда не приходит к единой оценке сложности. Достаточно утомительно, я вам скажу, но – продуктивно.
Итак, приоритеты определены, выбрано свойство для реализации. Самое время описать требования. Для этого создается модель прецедентов (Use Cases) относительно выбранного свойства. Данный документ хорошо бы снабдить диаграммой активности (Activity Diagram) для визуализации логики сопряженных сценариев использования. Сами прецеденты можно отразить в соответствующей UML диаграмме (Use Case diagram). В ходе обзора (review) документа, опять же, принимают участие все члены команды.
Рис.2. Модель прецедентов привносит детали в документы общей модели
Далее работы могут вестись параллельно: часть группы занимается техническим дизайном, часть работает над каркасами (или же над детализацией каркасов, если они уже были подготовлены на стадии общей модели).
Технический дизайн предполагает UML-диаграмму с сущностями модели домена, список и диаграмму классов (где это уместно), сопряженных со свойством моделей, DAO, контроллеров, сервисов, декораторов (возможно хелперов). Там же представлена архитектура БД, покрывающая свойство в виде модели «сущность-связь» (ER Diagram). Если свойство затрагивает какие-либо внешние системы (например, профайлер пользовательских предпочтений), это должно быть также отражено в техническом дизайне, скажем, в виде диаграммы последовательностей (Sequence diagram).
Помимо прочего следует подготовить варианты тестирования (Test Cases), что позволит QA-специалистам полноценно оценить качество реализации свойства.
Когда диаграмма сущностей модели домена для выбранного свойства закончена, проявляются детали, неучтенные в общей модели. Так и должно быть: вы просто отражаете новые детали на общей модели по мере их появления.
По окончанию этапа вся команда разработчиков принимает участие в обзоре технического дизайна. Помимо «полировки» всех аспектов документа, это обеспечивает глубокое проникновение в идеи архитектуры всех разработчиков проекта.
В то время как визуальный дизайнер будет трудиться над пользовательским интерфейсом, программисты могут создать описанные в техническом дизайне компоненты в виде прототипа. Таким образом, после обзора визуального дизайна и прототипа свойства, производится xHTML-верстка и модификация декораторов (views). Наверняка творческий гений визуального дизайнера потребует от вас также дополнительного программирования на клиентской стороне (JS). Когда свойство готово, оно передается в QA-отдел для тестирования.
После того, как свойство протестировано и ушло в продукт, берем следующее по приоритетам свойство, повторяем цикл дизайна/реализации.
В общих чертах подход можно описать следующей последовательностью:
- Разработка общей модели
- Создание списка свойств
- Планирование по свойствам
- По каждому свойству – технический дизайн и реализация.
В идеале на выходе мы получаем платформу, постепенно обрастающую свойствами. Звучит как-то подозрительно просто. Давайте все же посмотрим, что это такое.
Разработка общей модели (Develop an Overall Model)
Как выразился автор методологии Джеф Делюка (Jeff Deluca — http://www.jeffdeluca.com), общая модель – больше набросок или очертание, нежели детальное содержание. Однако чтобы получить эту модель, недостаточно просто требований к проекту. Модель – это видение проекта, основанное на результатах предварительных исследований. Спасибо Луису Розенфельду (Louis Rosenfeld — http://louisrosenfeld.com) – мы знаем, насколько важна роль информационной архитектуры при веб-разработке. На этапе общей модели у нас должны быть – анализ целевой аудитории, анализ контента и контекста его использования, структура контента, включая метаданные и тезаурус. Должен быть документ, описывающий принципы пользовательского интерфейса, список используемых UX-компонентов, описание их свойств и поведения.
Рис.1. Пирамида информационной архитектуры
В данном подходе подразумевается, чтомы приступаем кразработке, имея лишь наброски системы, которыепо мере разработки обрастают деталями. Таким образом, детальные каркасы (wireframes) будут разработаны входе создания соответствующих свойств (features) или, другими словами, частей проекта. Однако на стадии общей модели таки потребуются «сырые» каркасы основных интерфейсов и предварительная карта сайта.
Все выше описанное –сопутствующие документы. Основной результат этапа–модель домена (Domain model). Это статическая UML диаграмма, включающая все определенные к данному моменту логические объекты проекта и их взаимодействие (объект является частью другого объекта, объект расширяет другой объект и т.д.).
Создание списка свойств (Build a Feature List)
Не думаю, что здесь мне стоит вдаваться вподробности. Большинствоиз вас использует методику SCRUM, а список свойств в FDD – то же самое, что и product backlog в SCRUM. Разве что стоит еще раз напомнить: при создании списка следует оперировать именно целями и подцелями, но не задачами.
Планирование по свойствам (Plan by Feature)
Все бы хорошо, но как же оценить время разработки свойств проекта, когда детали туманны. Связанные задачи для разработчиков будут предельно ясны только тогда, когда будут выполнены все предварительные работы по данному свойству. Как же планировать? И тут на помощь приходит Story Point Estimation. Мы оцениваем свойства не в человеко-днях, а в абстрактных баллах по мере сложности свойства. Из всего списка предлагается выбрать свойство минимальной сложности и присвоить ему 2 балла сложности. Рекомендуется использовать экспоненциальную шкалу, например: 1, 2, 3, 5, 8. Тогда спрашивается, почему мы не назначили 1 самому пустяковому свойству. На всякий случай. Список свойств огромный и с первого взгляда маловероятно, что вы будете максимально точны в оценке.
В оценке принимают участие все члены команды. Т.е., каждое свойство обсуждается с позиций всех этапов разработки до тех пор, пока команда не приходит к единой оценке сложности. Достаточно утомительно, я вам скажу, но – продуктивно.
Технический дизайн свойства (Design by Feature)
Итак, приоритеты определены, выбрано свойство для реализации. Самое время описать требования. Для этого создается модель прецедентов (Use Cases) относительно выбранного свойства. Данный документ хорошо бы снабдить диаграммой активности (Activity Diagram) для визуализации логики сопряженных сценариев использования. Сами прецеденты можно отразить в соответствующей UML диаграмме (Use Case diagram). В ходе обзора (review) документа, опять же, принимают участие все члены команды.
Рис.2. Модель прецедентов привносит детали в документы общей модели
Далее работы могут вестись параллельно: часть группы занимается техническим дизайном, часть работает над каркасами (или же над детализацией каркасов, если они уже были подготовлены на стадии общей модели).
Технический дизайн предполагает UML-диаграмму с сущностями модели домена, список и диаграмму классов (где это уместно), сопряженных со свойством моделей, DAO, контроллеров, сервисов, декораторов (возможно хелперов). Там же представлена архитектура БД, покрывающая свойство в виде модели «сущность-связь» (ER Diagram). Если свойство затрагивает какие-либо внешние системы (например, профайлер пользовательских предпочтений), это должно быть также отражено в техническом дизайне, скажем, в виде диаграммы последовательностей (Sequence diagram).
Помимо прочего следует подготовить варианты тестирования (Test Cases), что позволит QA-специалистам полноценно оценить качество реализации свойства.
Когда диаграмма сущностей модели домена для выбранного свойства закончена, проявляются детали, неучтенные в общей модели. Так и должно быть: вы просто отражаете новые детали на общей модели по мере их появления.
По окончанию этапа вся команда разработчиков принимает участие в обзоре технического дизайна. Помимо «полировки» всех аспектов документа, это обеспечивает глубокое проникновение в идеи архитектуры всех разработчиков проекта.
Реализация свойства (Build by Feature)
В то время как визуальный дизайнер будет трудиться над пользовательским интерфейсом, программисты могут создать описанные в техническом дизайне компоненты в виде прототипа. Таким образом, после обзора визуального дизайна и прототипа свойства, производится xHTML-верстка и модификация декораторов (views). Наверняка творческий гений визуального дизайнера потребует от вас также дополнительного программирования на клиентской стороне (JS). Когда свойство готово, оно передается в QA-отдел для тестирования.
После того, как свойство протестировано и ушло в продукт, берем следующее по приоритетам свойство, повторяем цикл дизайна/реализации.
