Гибкая разработка сайта: программирование + дизайн
|
О гибких (agile) методологиях по разработке программных продуктов информации довольно много. Но, мне пока нигде не попадалась информация (на русском) о применении agile для разработки сайтов. Я имею ввиду достаточно крупные проекты, например социальные сервисы, где подразумевается постоянное совершенствование продукта и где важен ранний запуск бета-версии. В частности, меня интересует вопрос планирования параллельной разработки дизайна и программной части проекта. Рассмотрим типичную ситуацию — у нас есть идея проекта. Далее есть 2 пути:
Стоп. А где же здесь дизайн? Как разрабатывать дизайн на часть проекта? Да еще в рамках спринта? Ведь для того, чтобы разработать т.н. дизайн-концепцию, необходимо целостное видение функциональности проекта. И инкрементальный подход (сначала спрограммировали и нарисовали профиль пользователя, затем механизм публикации и т.д.) противоречит основному принципу разработки дизайна — от общего к частному. После того, как базовая функциональность проекта, достаточная для запуска в эксплуатацию, разработана, вполне можно в рамках спринтов разрабатывать и дорабатывать дизайн отдельных интерфейсов, не выходя за рамки дизайн-концепции или стилевого решения проекта. Но, как спланировать именно разработку стилевого решения в условиях итеративной разработки? Вот что у меня получилось в теории:
Для наглядности, декомпозиция процесса разработки дизайн-концепции не отображена. Она традиционна. Таким образом, в закрытой фазе разработки, созданная функциональность отображается в технологических шаблонах, без какого-то ни было оформления. А параллельно, на основе идеи и с учетом промежуточных релизов разрабатываются дизайн-концепция и интерфейсы проекта. В рамках последнего перед публикацией проекта спринта, дизайн и программная часть воссоединяются и предстают перед публикой. Этот торжественный момент отмечен красной линией на схеме. Но, это теория. Хорошо бы узнать мнение практиков. И еще немного теории в обзоре методологии Scrum Асхата Уразбаева (500 КБ, .pdf). Очень рекомендую. |
Денис, думается, ваш подход достаточно адаптирован для разработки интернет стартапов. Есть один нюанс (собственно, этот вопрос остался для меня не решенным и в методологиях разработки обычного ПО).
Как оценивать стоимость проекта и как это предоставлять заказчику?
С одной стороны, для заказчика очевидно, что работа должна быть оплачена пропорционально трудозатратам исполнителя, заказчик на каждом витке проекта видит результат, динамику, с другой — заказчик не дурак (особенно в России), что исполнителю выгодно растягивать проект до как можно больших размеров, чтобы больше “срубить бабла”.
Одним словом, када процесс разработки уже запущен, сколько платить за проект, заказчику понятно — по результатам каждой итерации. А када заказчик еще в разработке как быть? Как ему пообещать, что он получит ожидаемый результат за конечное число циклов? :(
Иван, согласно методологии Scrum, насколько я помню, заказчик является владельцем продукта и формирует product backlog, иначе говоря список возможностей (features) будущего продукта. Собственно, этот объем возможностей и представляет собой ожидаемый результат.
Вопрос взаиморасчетов это отдельная тема и лучше спросить об этом более опытных людей. Но проблема “растягивания” проекта исполнителем в рамках Scrum решается довольно просто — заказчик принимает прямое участие в разработке, в качестве уже упомянутого владельца продукта.
Насчет ожидания результата я имел в виду, что заказчик знает не ЧТО он получит, а КОГДА, т.е. за какое число итераций получит ожидаемый продукт. Из вашего замечания получается, что явно это не обговаривается. Иными словами, подразумевается, что разработчики предельно честны и нацелены на результат, и заказчик придерживается таких же позиций :)
Я говорил о том, что честность разработчиков вопрос не первой важности, поскольку клиент является членом команды. И это не главное, главное другое — agile-методологии как раз и применяются в тех случаях, когда проект не имеет конечного объема работ и предполагается постоянное развитие. Поэтому реализуется минимальный объем работ, срок сдачи которого очевиден для всех. Далее идет развитие функциональности уже работающего проекта.