Коммерческая веб-разработка существует уже более 10 лет. Как индустрия, она еще довольно молода, если учесть других, которые существовали веками. Но относительная молодость как отрасль не освобождает от ответственности за то, что она не делает лучше
Подумайте о количестве сайтов, которые перестраиваются для клиентов каждый день, и вы, вероятно, согласитесь с тем, что по-прежнему много работы низкого качества, которая затрагивает всех нас: это означает, что клиенты более осторожны и менее доверяют веб-разработчикам. Все, что бросает тень на нашу отрасль, может бросить тень на всех нас в отдельности.
Испытанный, надежный и стандартизированный подход к веб-разработке во многом поможет избежать ошибок, которые мы все видим снова и снова. Нам нужна веб-методология. Однако найти методологию, которая кажется подходящей для веб-разработки, нелегко; заставить его работать в реальном мире еще сложнее.
Как менеджер по развитию команды из 20 человек, в бурные дни доткомов я столкнулся именно с этой дилеммой. В этой статье рассматриваются проблемы, которые возникли из-за отсутствия у нас достойной методологии, и как мы, как команда, пытались их решить. Результатом стала успешная адаптация существующей методологии для веб-разработки.
Симптомы
Ряд факторов в совокупности заставляет команду веб-разработчиков вносить изменения в то, как мы работаем.
В первую очередь, проекты постоянно шли со временем. Для этого не было конкретной причины; каждый проект, казалось, имел свои особенности. В некоторых случаях клиент передумал. В других случаях наша команда интерпретировала требования клиента иначе, чем его собственная интерпретация. А для других это была простая недооценка работы, необходимой для завершения проекта. Независимо от причины, конечный результат был одним и тем же: проекты, которые работают сверхурочно, выходят за рамки бюджета, если клиент не желает платить больше. И каждый поздний проект также влияет на новые проекты.
Чем чаще это происходило, тем хуже становилось, до тех пор, пока у нас не возникла ситуация, когда почти каждый проект становился высокорисковым и подвергался ползучести, создавал низкий моральный дух персонала и, как ожидается, имел нереальные сроки.
Ответ был довольно прост: нам нужен был лучший способ сделать что-то — проверенный способ доставки проектов, которые отвечали бы потребностям клиента вовремя и в рамках бюджета. Решение также должно соответствовать нашей организационной культуре.
Нам нужна была веб-методология.
Принять, адаптировать или построить свой собственный
После того, как было принято решение найти лучший способ ведения дел, мы поняли, что у нас есть три пути на выбор:
- принять существующую методологию
- адаптировать от существующей методологии
- построить нашу собственную методологию
Команда разработчиков была разделена по этому вопросу. Некоторые члены полагали, что мы должны сделать это сами; другие говорили, что мы не должны изобретать велосипед. Было ясно, что нам нужно было провести какое-то исследование, чтобы найти лучший путь для нас.
В то время не было общепризнанных веб-методологий (хотя, как показывают недавние исследования, ситуация не сильно изменилась). Таким образом, для принятия или адаптации у нас не было иного выбора, кроме как взглянуть на существующие методологии разработки программного обеспечения.
Критерии оценки
Когда мы начали искать методологии, мы решили, что важно знать, что мы ищем. Первым шагом было определение критериев, по которым мы будем их оценивать.
сложность
Решение должно было быть чем-то большим, нежели простым руководством, но на другом конце шкалы, если оно было слишком большим, не было никакого способа, которым оно могло бы работать. Нам нужно что-то, что было бы легко понять на первый взгляд — поскольку и персонал, и клиенты должны были уметь это понимать — но имели достаточную глубину, чтобы дать разработчикам необходимое руководство.
Размер
Трудно заставить людей читать документацию в лучшие времена, поэтому толстый документ, объясняющий методологию, вряд ли будет эффективным. Скорее всего, если бы у нас было 100-страничное руководство с 10-страничным резюме в конце, большинство людей использовали бы только резюме.
Стоимость
Все, что стоит денег, должно быть оправдано; чем меньше денег потребовалось, тем лучше.
риск
Мы не могли позволить себе ошибиться в методологии. Крайне маловероятно, что я смогу убедить людей пройти процесс второй методологии, если первая не сработала.
прагматический
Решение должно было работать, а не основываться на теории. Должны были быть реальные примеры проектов, к которым он был успешно применен, не раз!
Методологии оценены
рациональный унифицированный процесс
У нас было две презентации от представителей RUP. Первая была часовая сессия, вторая — более подробная двухчасовая презентация. Оба раза я был более смущен после презентации, чем раньше. Я также поговорил с несколькими друзьями, которые работали с RUP и имели положительные отзывы о процессе.
Область применения RUP чрезвычайно широка. Он охватывает практически все во всем SDLC, что является его сильной и слабой стороной. Недавно я был на конференции и посетил сессию Филиппа Крутчена, одного из ведущих авторитетов RUP. По его мнению, главная проблема, которая возникала, когда люди пытались использовать RUP, заключалась в том, что они пытались использовать все это. Это был тот же совет, который я слышал от друзей, которые использовали RUP. Он большой и сложный, и ключ в том, чтобы использовать только те аспекты процесса, которые вам нужны для вашего проекта. Это имеет большой смысл, учитывая, что проекты часто меняются, и один и тот же подход не будет работать в каждом случае.
Однако, учитывая контекст нашей команды, RUP представил ряд вопросов:
- RUP был большим, сложным и сложным, но нашей команды не было! У нас были некоторые члены команды, которые все еще изучали SDLC, и попытаться представить что-то настолько сложное, как RUP, потребовало бы значительного дополнительного обучения.
- Несмотря на то, что RUP был всеобъемлющим, нам нужно было бы его подробно изучить, прежде чем мы сможем решить, какие элементы мы будем применять в наших проектах. Затем нам нужно будет испытать и усовершенствовать процесс с течением времени.
- Затраты, связанные с инструментами, которые требовались для использования RUP (например, рациональная роза, необходимые про … и т. Д.), Были высокими.
В целом, реализация RUP или уменьшенной версии RUP представляла собой потенциально сложный, сложный, трудоемкий и дорогостоящий процесс с высоким риском сбоя.
Мы также получили презентацию от представителя Process Mentor. Сам процесс был более компактным, чем RUP, и, следовательно, его легче было понять. По сути, это был веб-сайт с серией шагов, форм и шаблонов, которые можно использовать для запуска проекта. Мы чувствовали себя более комфортно с Process Mentor, чем с RUP, потому что это было не так подавляюще, но все же не совсем правильно. Не было ничего такого, что могло бы стать серьезной проблемой, как это случилось с RUP, но, тем не менее, Process Mentor не чувствовал себя как правильный подход.
Внутренние методологии
В нашу команду входило несколько опытных разработчиков, которые работали с «домашними» процессами из предыдущих работ с такими тяжеловесами, как IBM GSA. Каждый из этих разработчиков рассказал о своем опыте, объяснил, что сработало, что им понравилось, и что они будут использовать снова. Был целый ряд техник, которые казались полезными, но, когда все было сказано и сделано, общее ощущение заключалось в том, что мы не сможем «позаимствовать» одну из этих внутренних методологий у другой организации.
Почему традиционные методологии не подходят
Не было недостатка в поставщиках, готовых рекламировать свои процессы и связанные с ними инструменты, но после многих презентаций мы не чувствовали себя более мудрыми. Казалось, ничто не отвечает нашим потребностям. Причины были разными, но основная проблема заключалась в том, что ни одна из методологий не учитывала, как все работает в веб-разработке.
По сравнению с традиционной разработкой программного обеспечения временные рамки веб-разработки часто короче, уровни опыта сотрудников сильно различаются, клиенты часто плохо понимают, что возможно, технология быстро меняется, и все сводится к одному пользовательскому интерфейсу (браузеру). , Нельзя сказать, что эти элементы не существуют в традиционной разработке программного обеспечения; однако, ограничения намного более выражены в веб-разработке.
Еще одна проблема с традиционными методологиями заключается в том, что они не приняли во внимание «мягкие» аспекты разработки программного обеспечения. Недавнее исследование наиболее важных факторов в успешных командах разработчиков программного обеспечения (из журнала Cutter Journal, март 2005 г. ) оценило доверие как фактор номер один и технический опыт как последний из 17 факторов. Нигде ни в одной из презентаций или литературы для RUP или Process Mentor не упоминалось о доверии; и при этом не было никаких других мягких навыков, которые очевидно оказывают огромное влияние на успех.
Короткий ответ состоял в том, что мы не могли ни принять, ни адаптировать традиционный подход. Это оставило нам незавидную задачу попытаться создать свою собственную.
Идти проворный
Мы собирались начать определять наш собственный процесс, когда я натолкнулся на упрощенную методологию, которая теперь называется «гибким» движением. Методологией в этом случае была разработка, основанная на функциях (FDD); Некоторые из других популярных гибких методологий — XP, Scrum, Crystal и DSDM. (Подробные сведения о гибких методологиях и FDD выходят за рамки этой статьи, но если вы хотите узнать больше, посетите http://www.agile.org и http://www.featuredrivendevelopment.com )
Было совершенно очевидно, что FDD гораздо лучше подходит для веб-разработки, чем что-либо еще, что мы видели, поэтому мы решили провести дальнейшее расследование, чтобы посмотреть, сможем ли мы принять или хотя бы адаптировать его для веб-разработки. Команда не заняла много времени, чтобы согласиться дать FDD шанс. Однако вскоре мы поняли, что это не серебряная пуля.
Обзор FDD
FDD — это методология гибкой разработки, созданная Джеффом Делукой для:
обеспечить своевременное повторение поставки работающего программного обеспечения с высокой точностью и значимой информацией для всех ключевых ролей внутри и вне проекта.
Для получения дополнительной информации просмотрите обзорную презентацию FDD в формате PDF .
Вкратце, FDD состоит из 5 четко определенных процессов, которые можно зафиксировать на 5 страницах. Ядром FDD является концепция функции, которая является четко определенной клиентской частью функциональности. Процессы, составляющие FDD, структурированы вокруг определения каждого элемента проекта как элемента, а затем итеративного проектирования и создания каждого элемента.
Структура высокого уровня FDD отражена на следующей диаграмме.
Процесс 1: Разработка общей модели
Это начальное проектное мероприятие с членами домена и разработки под руководством опытного объектного модельера в роли главного архитектора.
Процесс 1 вовлекает проектную группу, создающую объектную модель бизнес-сферы — модель, которая больше форма, чем контент. Модель не полностью определена со всеми атрибутами и методами, так как этот шаг больше касается правильного захвата формы бизнес-домена в объектной модели, а не каждой детали.
Это очень совместный процесс, в котором каждый должен работать вместе, чтобы создать общую модель. Требуется итеративный подход. Во-первых, эксперт по домену объясняет часть бизнес-домена. Команда проекта разбита на группы (желательно по 3 на группу) для моделирования этой части домена. Затем группы представляют свои модели, и достигается консенсус в отношении использования. Затем этот процесс повторяется для каждой части домена, пока все не будет покрыто. Конечным результатом является общая модель всего домена.
Процесс 2: создание списка функций
Это начальное мероприятие в рамках всего проекта для определения всех функций, необходимых для поддержки требований проекта.
Создание списка функций является задачей главных программистов, участвующих в процессе моделирования. Клиент и заинтересованные стороны не должны быть частью этого процесса, так как они внесли свой вклад в Процесс 1. Теперь пришло время включить проект в список функций. Это не требует сотрудничества: вовлечение группы людей на этом этапе не будет продуктивным или конструктивным.
Ключом к этому процессу является определение проекта с использованием языка бизнес-сферы. Это означает, что клиент сможет понимать и ценить каждую функцию, но он также применяет общий язык для всей команды проекта и снижает риск недопонимания или допущений.
Плохое общение является основой большинства проблем в области программного обеспечения и веб-разработки. Язык, который мы выбираем, оказывает существенное влияние на эффективность нашего общения. Есть много методов в FDD, которые помогают обеспечить значимое общение. Наиболее мощный из них заключен в процессе 2: определение всего проекта в функциях с использованием языка домена, то есть с использованием языка клиента. Это может показаться простым и очевидным, но его нельзя недооценивать. Фокус, который приносит этот шаг, невероятен и влияет на проект во многих отношениях.
В FDD все описывается как функция, которая, в свою очередь, определяется как:
<действие> <результат> от / для / до <объекта>
Например:
рассчитать сумму для продажи
рассчитать общий объем продаж для кассира
Функция также определяется с точки зрения размера (например, более 2 часов работы, но менее 2 недель работы). Если функция занимает более 2 недель, ее следует разбить на отдельные функции.
Определение всего как функции позволяет избежать проблем, возникающих всякий раз, когда клиент ссылается на концепцию одним способом, программист ссылается на нее другим, а руководитель проекта должен постоянно интерпретировать их. Если руководитель проекта не совсем правильно интерпретирует, возникают ошибки: программисты думают, что они строят одно, а клиент ожидает другого. Использование одного и того же языка не означает, что проблема исчезает, но значительно снижает риск путаницы.
Процесс 3: Планирование
Процесс 3 — это начальная проектная деятельность по разработке плана развития.
Этот процесс расширяет преимущества, предоставляемые процессом 2. Он предоставляет менеджеру проекта средства для планирования фазы разработки значимым образом как для клиента, так и для программистов. Он завершается совместно с менеджером по развитию и главными программистами, которые, в частности, следят за порядком, в котором будут создаваться функции, балансируя нагрузку в команде и предлагая стратегии для обеспечения ранних результатов, чтобы клиент был доволен.
Процесс 4: Дизайн по функциям
Процесс 4 включает в себя действие для каждого элемента для создания пакета дизайна элементов. Этот процесс разбит на три этапа: прохождение, проектирование и проверка.
В этом пошаговом руководстве программисты знакомятся с тем, что собираются построить, прежде чем приступить к детальному проектированию, которое проверяется перед началом сборки. Проверка проекта позволяет обнаруживать и устранять дефекты до того, как для этой функции будет написана единственная строка кода.
Может показаться здравым смыслом проектировать и проверять этот проект перед сборкой, но этот шаг часто игнорируется. Во многих других отраслях идея создания чего-либо до того, как оно будет полностью определено, спроектировано и спланировано, будет считаться небрежным, хотя в веб-разработке это происходит постоянно. Первая реакция многих программистов, особенно тех, кто занимается веб-разработкой, — открыть свой любимый редактор и начать писать код. Количество риска, которому этот подход подвергает любой проект, огромно. Однако обратное также может быть проблематичным: попытка спроектировать все заранее может привести к «параличу анализа».
Точно, сколько дизайна должно произойти заранее — горячо обсуждаемая тема среди сторонников гибких методологий. Подход, принятый FDD, очевиден в различии между Процессом 1 и Процессом 4. Как мы видели, Процесс 1 включает проектирование на раннем этапе жизненного цикла, но это не детальный проект. Детали оставлены для Процесса 4. Помещение детального дизайна на этом более позднем этапе гарантирует, что он будет рассмотрен в нужное время: до написания кода. Это также разбивает дизайн на значимые куски, особенность за особенностью. Это означает, что программисты не чувствуют, что они тратят все свое время на разработку и не тратят время на программирование; сразу после того, как дизайн был завершен и проверен, программист может начать кодирование.
Процесс 5: Построение по функции
Процесс 5 включает в себя действие для каждой функции, чтобы создать завершенную клиентскую функцию (функцию).
Процесс 5 также разбит на три этапа: код, проверка кода и продвижение сборки. Как и в случае с Процессом 4, идея сотрудничества и проверок преимуществ реализуется. То, что делает Process 5 уникальным, является последним шагом, «продвигать, чтобы строить».
Чтобы код был «повышен до сборки», он должен быть закончен. Ключом к этому является определение «готово». Функция не завершена, пока больше ничего не будет сделано. Менеджер проекта может проверить, действительно ли функция завершена, просто спросив, завершена ли работа. Если программист отвечает «да», менеджер проекта спрашивает: «Больше ничего не поделаешь?». Этот вопрос часто вызывает другой ответ. Дело не в том, что программист труден или вводит в заблуждение, просто в том, что, имея такую возможность, многие программисты будут продолжать работать над кодом, настраивая, оптимизируя или пытаясь улучшить его до бесконечности. Если есть время, чтобы сделать это, это не проблема, но если есть сжатые сроки, Менеджер проекта должен сосредоточить программистов на завершении проекта. Этот процесс является отличным способом обеспечения этого фокуса.
Другое преимущество этого процесса заключается в том, что он помогает менеджеру проекта четко видеть, сколько проекта было выполнено и насколько продуктивен каждый программист. По словам Джеральда Вайнберга (Quality Software Management Vol.1), разница в производительности между программистами может достигать 20: 1. Вопрос в том, как оценить эту производительность. Несмотря на то, что размер функций может варьироваться от 2 часов до 2 недель работы, руководитель проекта не займет много времени, чтобы оценить объем работы, который фактически выполняет каждый программист, с учетом различий в размерах функций.
Применение FDD для веб-разработки
Реализация нового способа ведения дел намного сложнее, чем кажется. Людям не нравятся перемены, и даже те, кто говорит, что они хотят попробовать что-то новое, могут быстро изменить свое мнение и вернуться к старому способу ведения дел. Из-за этого мы знали, что мы, как команда разработчиков, сможем только самостоятельно применить FDD. Рано или поздно это затронет руководителей проектов и, в конечном итоге, клиентов. Мы решили, что лучше привлечь всех участников заранее, чтобы увеличить наши шансы.
Следующим шагом было все о внутренней политике и привлечении ключевых лиц, принимающих решения. Поскольку FDD прост для понимания, людям было несложно увидеть, что нам было бы лучше, если бы мы использовали этот подход. На этой основе мы получили финансирование для проведения учебного курса. На курсе присутствовали представители всех групп, которые будут затронуты новой методологией: разработчики, бизнес-аналитики, менеджеры проектов, дизайнер и тестировщик.
В конце курса все заинтересовались. В частности, следующие аспекты FDD выделяются в качестве решения для симптомов, которые мы перенесли:
- Отличная отчетность и планирование
- Дисциплинированный и ясный
- Ориентированных на клиента
- Снижение риска через:
- итерация дизайна и сборки небольшими порциями
- ясность требований
- лучшее понимание системы, которая будет построена
- нет места для маневра, так как будет сделано меньше предположений
Мы также поняли, что FDD не будет полным ответом на наши проблемы. FDD хорошо освещал разработку, но не решал задачи сбора требований, проектирования интерфейса или тестирования. То, что нас касалось применения FDD:
- его высокая зависимость от технических возможностей
- это не касалось дизайна и сборки пользовательского интерфейса
- он был менее мощным на небольших проектах, чем на крупных
- это не охватывало тестирование и развертывание
FDD не был серебряной пулей! В конце концов, нам нужно было адаптировать процесс к нашей ситуации и потребностям.
Управление переходом
Следующим шагом было выяснить, как на самом деле применить FDD к нашей работе. Было много проектов в производстве, и мы не могли просто изменить наш подход на мидстриме. Мы также не могли ожидать, что все новые проекты начнут использовать новую методологию, поскольку не все в команде прошли обучение. Нам нужно было применять поэтапный подход к внедрению методологии.
Мы решили решить эту проблему с разных точек зрения. Во-первых, мы медленно внедряем несколько ключевых аспектов FDD в новые проекты:
- Определите проекты, используя функции (ориентированные на клиента)
- Планирование разработки на основе особенностей
- Внедрить новую структуру команды, дизайн и обзоры кода
- Проводить еженедельные встречи по статусу проекта
Во-вторых, мы бы запустили внутренний тестовый проект. Наша внутренняя сеть нуждалась в доработке, и мы подумали, что это будет хорошей возможностью, чтобы дать FDD шанс, а также попытаться выяснить, как работать с интерфейсом и непроверенными областями тестирования. В-третьих, хотя это и не было запланировано, разработчик и менеджер проекта, прошедшие обучение, решили использовать FDD в своем следующем проекте для продавца бумаги.
Проект интранета не удался по многим причинам, ни одна из которых не имела никакого отношения к FDD. Проект страдал от тех же проблем, с которыми сталкиваются многие внутренние проекты: ему не хватало заинтересованности и преданного заинтересованного лица. Несмотря на то, что мы прошли довольно полный процесс сбора требований, проекту не хватало ясности цели. Неважно, какой процесс разработки был применен, этот проект должен был быть сложным. Но это означает, что FDD работает лучше всего, когда есть четкие требования для начала.
Проект продавца бумаги, с другой стороны, прошел очень хорошо. Разработчик, один из наших лучших, проделал отличную работу по моделированию домена, и менеджер проекта смог легко отследить проект. Однако команда столкнулась с некоторыми проблемами. При определении общей модели в FDD используется метод моделирования, называемый цветовым моделированием (как описано в книге « Java-моделирование в цвете с использованием UML» ).
Обычно моделирование не завершается в сотрудничестве с клиентом; в FDD это вовлекает клиента и, следовательно, клиент должен иметь представление о технике. Это не значит, что они должны быть экспертами UML, но им, по крайней мере, нужно знать, что происходит. Объяснить это клиенту было единственной реальной проблемой. С большинством клиентов мы ожидали, что это будет довольно просто, и как только они это поймут, им действительно будет весело!
Поскольку в проекте работала небольшая команда из одного разработчика, одного дизайнера и одного менеджера проекта, все прошло гладко. Не было необходимости создавать рабочие пакеты, назначать функции отдельным лицам, отслеживать прогресс каждого из них и так далее. Одной из проблем, возникших на семинаре FDD после обучения, была зависимость процесса от главного архитектора. В этом проекте был только один разработчик, который играл главного архитектора, главного программиста и разработчика. Это было рискованно: если бы он не был хорош в своей работе, у проекта были бы большие проблемы. Однако это относится ко всем небольшим проектам: если у вас нет достойного программиста, у вас проблемы!
В целом, мы увидели значительное улучшение прогресса проекта на нескольких уровнях, некоторые из которых были довольно неожиданными. Цель состояла в том, чтобы найти способ более эффективно реализовывать проекты, но мы обнаружили, что влияние на мораль было гораздо более позитивным. Тот факт, что мы решили улучшить нашу работу, имел положительный эффект. Команда была счастливее, потому что мы что-то решали. Новый подход также помог объединить различные дисциплины (в частности, разработку и управление проектами), которые ранее не всегда работали в тесном контакте. Было ощутимое чувство фокуса и направления.
Что касается проектов, было также улучшение. Хотя у большинства проектов все еще были проблемы, проблемы были уменьшены и ими легче управлять. Гораздо проще было составить реальное представление о том, где находится каждый проект и сколько фактически было выполнено работы. Например, если вы спросите программиста о том, как они работают с оптимизацией базы данных, это может привести к одному из многих ответов, некоторые из которых не обязательно отвечают на вопрос, заданный клиентом: когда он будет закончен? Это не значит, что программисты сознательно стараются избегать ответов на вопросы, просто иногда трудно ответить на вопросы: часто нелегко сказать, когда что-то будет закончено.
Это было ключевым преимуществом функционально-ориентированного подхода. Когда проект определяется в терминах «функций», некоторые сложности снимаются с вопросов, которые задает клиент. Функция должна занимать не более двух недель, поэтому, когда ее спросят, сколько времени понадобится разработчику, чтобы завершить функцию (если она запущена!), Разработчик должен ответить цифрой от 1 дня до 2 недель. Этот подход на самом деле помогает разработчикам управлять собой и избегать попыток порадовать руководителей проектов, рассказывая им то, что они хотят услышать, а не правду.
К сожалению, мы не смогли отследить долгосрочное влияние введения FDD. В течение 6 месяцев после тренинга крах доткомов обрушился на компанию, и мы увидели ряд вынужденных увольнений.
FDD для малых команд
Одна из основных критик гибких методологий заключается в том, что они не расширяются. Для веб-разработки часто более важно видеть, может ли методология сокращаться и при этом сохранять свои преимущества. Понятно, что влияние любой методологии будет уменьшаться с уменьшением размера команды, и FDD ничем не отличается. Тем не менее, я смог успешно применить FDD для небольших групп и проектов, например, для проекта, в котором для завершения работали 3 сотрудника (руководитель проекта, разработчик и дизайнер) в течение 3 недель. FDD может уменьшать масштаб и при этом обеспечивать ценность процесса веб-разработки.
Два аспекта FDD, которые имеют наибольшую ценность в небольших проектах:
- определение проекта в функциях
- отслеживание проекта по функциям
Это кажется очень упрощенным, но именно эта простота делает FDD настолько эффективным. Не удается заранее определить проект как функции, и есть вероятность, что клиент и команда будут на другой странице с первого дня. Обычно эта проблема проявляется только после выполнения работы. Для небольших проектов исправление таких ошибок не является большой задачей, однако дополнительная работа нескольких дней над небольшим проектом может означать значительный процент дополнительной работы и может быстро съесть прибыль.
Как и большинство вещей в жизни, начинать с правильной ноги — это лучший способ заставить веб-проекты работать хорошо. Использование простого метода определения проекта в функциях с использованием языка клиента будет иметь большое значение как для небольших, так и для крупных проектов.
FDD для веб-разработки
Начиная с этого первого применения FDD для веб-разработки в 2000 году, я работал над совершенствованием процесса и придумал подход, который эффективно работал над десятками веб-проектов размером от 2 недель до 6 месяцев. Этот усовершенствованный подход использует ядро FDD, но вводит новые элементы для управления некоторыми областями, которые FDD не охватывает. Ниже приведен общий обзор того, как FDD можно успешно применять в веб-разработке.
Обзор проекта
Хотя это явно не указано среди 5 процессов FDD, важно, чтобы у каждого проекта FDD была ясность цели. Это должно быть не более чем простое утверждение, чтобы определить, что представляет собой проект и чего он должен достичь.
Цель организации
Это может показаться избыточным элементом проекта. Цель организации должна быть ясной, но, хотя она может быть очевидной для клиента, она не может быть очевидной для разработчика. Написание одного параграфа, объясняющего, почему организация существует, является важным шагом. Конечно, это часто легче сказать, чем сделать; для небольших клиентов цель не всегда ясна, и иногда этот вопрос может привести к совершенно пустому виду! Тем не менее, стоит спросить, так как эти знания могут действительно помочь, когда дело доходит до следующего этапа разработки цели проекта.
Цель проекта
Опять же, это очень простое утверждение, но зачастую гораздо сложнее определить цель проекта, чем кажется. У большинства клиентов много мыслей, желаний, ожиданий и желаний, заключенных в то, что они называют своим «Веб-сайтом». В действительности, работа должна быть определена как проект с четкой целью, которую все понимают и с которой согласны. Целью должно быть четкое, краткое и измеримое изложение бизнес-результатов, которых должен достичь проект.
Цели проекта
Конкретные цели проекта должны быть четко определены. Ряд пунктов пули в порядке; обдумывание этого и получение согласия клиента является наиболее важным аспектом этой части обзора проекта.
Рассмотрите этот пример, который предлагает цели, которые могут быть определены для ACME, производителя автозапчастей:
«Цели реконструкции следующие:
- Унифицируйте корпоративный имидж ACME по всему миру.
- Создайте коммерчески ориентированный веб-сайт, проектирующий простой, четкий, профессиональный, продвинутый и уверенный тон, который будет на первом месте для удобства пользователей.
- Убедитесь, что дизайн Веб-сайта соответствует Основному руководству веб-сайта ACME Group, версия 1.0.
- Используйте веб-сайт в качестве инструмента позиционирования, чтобы позиционировать ACMO как ведущего мирового поставщика автомобильных запчастей, систем и компонентов.
- Предоставьте ACME возможность самостоятельно обновлять сайт с помощью системы управления контентом (CMS).
»
Объем проекта
Понимание и определение масштаба проекта является сложной задачей. Еще раз, клиенты обычно хотят включить все и ожидают, что все будет сделано для них. Я не плохой клиент — любой, кто знаком с концепцией ползучести области, поймет мою точку зрения здесь.
Ключ в том, чтобы получить представление о том, что находится на сайте, а что нет. Я рекомендую использовать технику, которая была определена много лет назад и в которой просто указано, что входит, что выходит и что можно рассмотреть. Это отличный инструмент для того, чтобы клиенты поняли все элементы проекта. Вот как это может выглядеть для нашего вымышленного бизнеса автозапчастей ACME:
Целевой рынок
Еще раз, это важное соображение. Многие сайты создаются без должного учета целевой аудитории. Сказать, что сайт ориентирован на клиентов клиента, недостаточно. Нам нужно понять демографию этой клиентской базы, и если нам нужно ориентироваться на одну часть этой клиентской базы, нам нужно знать, какая она есть.
На самом деле, большинство сайтов имеют ряд целевых рынков, которые необходимо решить. Что оказывается более практичным подходом, так это думать о нем с точки зрения первичных, вторичных и третичных целевых рынков.
содержание
Основное различие между традиционными программными проектами и проектами веб-разработки заключается в характере контента. Большинство веб-проектов влечет за собой большое количество контента. Веб-сайт может быть приложением или гипертекстовой системой (например, страницами контента). Большинство проектов представляют собой сочетание двух, и в этом случае оба аспекта должны быть рассмотрены. Для проектов с большим объемом контента информационная архитектура и дизайн становятся важными элементами успеха проекта.
Информационная архитектура
В своей самой простой форме информационная архитектура может рассматриваться как карта сайта. IA — это логическое структурирование контента в соответствии с целями сайта. Хотя это кажется простой задачей, важность этого процесса не следует недооценивать.
Хорошо структурированный сайт будет проще для людей, и его будет намного проще поддерживать. Хорошим примером плохо спроектированного веб-сайта является тот, на котором пользователи быстро обращаются к поисковому устройству, чтобы найти нужную им информацию.
Информационный дизайн
Большинство людей теперь понимают концепцию карты сайта, и многие могут составить разумную карту. Следующий уровень, который является гораздо более сложным, заключается в рассмотрении дизайна информации на странице: информационный дизайн. В настоящее время наблюдается тенденция к расположению трех столбцов с верхним и нижним колонтитулами:
функциональность
Именно здесь в игру вступают функции, и где определяется аспект «приложения» веб-сайта. Ключ состоит в том, чтобы разбить проект на куски работы, которые можно записать на языке клиента, и обеспечить, чтобы каждый «кусок» составлял от 2 часов до 2 недель работы.
Функции, которые могут потребоваться для сайта ACME (каждая из которых требует работы не более 2 недель), включают в себя:
- Средство подписки
- Поиск дистрибьютора
- Поиск продукта
- Форма обратной связи
Управление проектом
Неотъемлемой частью FDD является еженедельный отчет, который я адаптировал для небольших проектов. В более крупном проекте FDD в отчете будет представлена подробная информация о том, сколько функций было запущено, не было запущено, выполнялось, было завершено и опоздало. Отсюда можно получить точную цифру «процент завершения».
В небольших проектах не всегда необходимо переходить на этот уровень детализации. Тем не менее, важно отслеживать прогресс и регулярно сообщать об этом клиенту. Я рекомендую сделать это следующими двумя способами.
Ежедневные Обертывания
Daily Wrap — это ежедневная встреча с вашей командой. Это обычная задача среди гибких процессов. Например, в рамках Scrum это называется Daily Scrum или Daily Stand Up Meeting.
На этой короткой встрече каждый человек рассказывает, что он делал в предыдущий день и что он планирует сделать сегодня. Цели этой встречи:
- убедитесь, что никто не отстает
- убедитесь, что все знают, над чем работает остальная часть команды
- убедитесь, что любые барьеры или проблемы были подняты и преодолены
- способствовать развитию сотрудничества в команде
С точки зрения управления проектами, Wrap — чрезвычайно эффективный инструмент, позволяющий следить за развитием событий. Когда люди обещают что-то сделать, и они знают, что завтра их будут спрашивать перед другими, было ли это сделано, это приводит к ответственности. Обертка, безусловно, заставляет членов команды дважды подумать о том, что они обещают, и о невыполнении! Кроме того, Wrap имеет сильный социальный аспект, который имеет огромное значение для командной работы.
Отчеты о проделанной работе
Ключевым моментом здесь является предоставление клиенту обновлений прогресса на еженедельной основе. Для этого есть много причин, первая из которых заключается в том, чтобы обеспечить дисциплину, необходимую для того, чтобы руководитель проекта мог рассмотреть проект на высоком уровне. Отчет о проделанной работе не должен быть сложным или всесторонним; просто нужно указать, что было сделано, и есть ли какие-либо проблемы, которые необходимо решить. Я использую следующий шаблон, который оказался очень эффективным.
достижения
Что было завершено на прошлой неделе? Этот раздел помогает создать ощущение прогресса и удовлетворения.
Зависимости
Этот метод полезен для достижения цели. Часто зависимость — это то, что клиент должен предоставить. Записав это в письменной форме, вы ясно даете понять, кто несет ответственность за задержки.
Предположения
Я не могу не подчеркнуть, насколько важно четко заявить о своих предположениях. Если они не заявлены открыто, они часто могут вызвать серьезные проблемы. Например, разработчик может предположить, что предоставленные данные будут в табличном формате с разделителями, который легко импортировать; клиент может доставить его в виде файла Word или, что еще хуже, в графическом формате, таком как Quark или Pagemaker. Документируйте все предположения!
вопросы
Каждый проект имеет проблемы, которые должны быть отражены в письменном отчете о проблеме.
Решения
Надеемся, что в ходе реализации проекта поставленные вопросы будут решены. Это хорошая форма для записи этих резолюций, так что, если вопросы будут заданы в будущем, вы всегда сможете вернуться к резолюции, отмеченной в отчете о ходе работы. В частности, это помогает клиентам, которые имеют привычку менять свое мнение.
Сайт проекта
Это большая часть всех проектов FDD, и в этих проектах она называется KMS (Система управления знаниями). Вся информация для проекта — вся документация, заметки о собраниях, отчеты о ходе работ и т. Д. — должна храниться в онлайн-хранилище, к которому и команда проекта, и клиент могут получить доступ в любое время. Это помогает обеспечить согласованность путем размещения всей информации в центральном хранилище.
Вывод
Там до сих пор нет серебряной пули!
Адаптация FDD для веб-разработки имеет большое значение для решения многих проблем, возникающих в веб-разработке, но это не полный ответ. Такие области, как сбор требований, визуальное проектирование, тестирование и развертывание, не рассматриваются, даже если они необходимы для каждого проекта. Но, учитывая отсутствие жизнеспособных веб-методологий, наличие чего-то эффективного, хотя и неполного, является большим шагом вперед.