Жизнь без технического задания

05.04.07

Архитектура

Этой статьей я не хочу доказать, что написание технического задания - зло и корень всех бед, нет, ни в коем случае. Все и всегда относительно, а в нашем случае - зависит от задачи. Я хочу показать, что классические схемы разработки программного обеспечения работают не всегда, не всегда эффективны, часто приводят к ненужным конфликтам между менеджерами и исполнителями. Особенно это касается разработки веб-приложений. Я расскажу об экстремальном программировании, но не так, как пишут в книжках, а исходя из реалий - из того, что попробовали команды под моим руководством. О тех методиках, которые работают.

Этой статьей я не хочу доказать, что написание технического задания - зло и корень всех бед, нет, ни в коем случае. Все и всегда относительно, а в нашем случае - зависит от задачи. Я хочу показать, что классические схемы разработки программного обеспечения работают не всегда, не всегда эффективны, часто приводят к ненужным конфликтам между менеджерами и исполнителями. Особенно это касается разработки веб-приложений. Я расскажу об экстремальном программировании, но не так, как пишут в книжках, а исходя из реалий - из того, что попробовали команды под моим руководством. О тех методиках, которые работают.

Изменчивый мир

Когда я слышу о техническом задании на разработку веб-сайта, я внутренне улыбаюсь - еще один продукт, устаревший уже в момент выхода. Это первая проблема всех технических заданий - предположение, что внешняя среда не меняется.

Вторая проблема хорошо известна и отражена в древней мудрости: чтобы задать правильный вопрос, надо знать половину ответа. В ситуации, когда каждый новый сайт вы разрабатываете с использованием только что появившихся технологий (новые модули, новая версия собственного движка, новая версия базы данных), - фактически вы каждый раз многое делаете заново. Это значительно осложняет процесс разработки, потому что вы не знаете, как будете это разрабатывать.

Третья проблема классическая - заказчик не всегда точно знает, чего он хочет. И когда подходит срок сдачи проекта, вы слышите, что вот здесь хорошо бы подправить, вот здесь изменить, а вот здесь добавить. Частично эту проблему решает моделирование конечного продукта, но, повторюсь, лишь частично.

Выпуск конкурентами нового продукта, появление нового брэнда, новой технологии, нового браузера, изменение предпочтений потребителей - все это требует немедленной реакции, изменяет предметную область, описанную в ТЗ. Заказчик увидел сайт конкурирующей компании и хочет такую же "штуку". При этом вы не знаете заранее, как будете реагировать и сколько времени потребует реализация той или иной вашей реакции. Одним словом - хаос…

Экстремальное программирование

Ниже я опишу простейшие методы, которые позволят компании постепенно уйти от классической каскадной модели цикла разработки программного обеспечения. Каскадную модель вкратце можно описать так: сначала мы просим пользователей или заказчика сформулировать свои требования, затем разрабатываем проект системы, составляем техническое задание. Затем пишем код, тестируем его. Увы… Эта модель не годится для большинства проектов по разработке веб-приложений.

Что же делать? Ответ прост: принять окружающую действительность, принять изменчивый мир, принять хаос. Стать гибким и разрабатывать свою стратегию с учетом того, что нас окружает хаос. Это нормально. И убедиться при этом, что уже существуют инструменты, позволяющие успешно действовать в условиях хаоса. Например, инструменты экстремального программирования. Все они создавались исходя из того, что окружающая среда гибко и динамично меняется, и не пытаются зафиксировать ее, а наоборот - приспосабливают производственные процессы под подобную среду.

Итерации

Итак, мы приняли концепцию изменчивого мира. Что это меняет? Сразу становится ясно, что писать подробнейшее техническое задание не имеет смысла - оно стремительно устаревает. Ограничимся описанием функций, причем так, как их видит пользователь системы. Как правило, заказчик достаточно хорошо их представляет.

На основе такого описания команде разработчиков, дизайнеров, верстальщиков становятся ясны их ближайшие шаги. Основные архитектурные решения, общие рамки будущего сайта, общее устройство. Но я подчеркиваю - ближайшие шаги. Достаточно одного-двух. Шаги должны быть небольшие (неделя, несколько дней). После каждого шага - пересмотр всех условий, учет всех изменений. В экстремальном программировании такие шаги называют итерациями.

Итак, если мы на каком-то этапе работы пошли по неверному пути, мы очень быстро это поймем - одна-две итерации, и ошибка будет исправлена.

Общение с заказчиком

И все же нам нужно чем-то заменить отсутствие формального технического задания, - ведь мы должны сделать то, что требуется заказчику. Выход - тесное общение с представителем заказчика и пользователями на всех этапах работ (не только в точках проверки, не только в начале и конце работ, а в течение всего времени работы над проектом).

Постоянное сотрудничество с заказчиком, когда его представители присутствуют на планерках, видят все процессы "изнутри", позволяет не делать лишних предположений и, соответственно, не писать лишнего кода. Те, кто имеет отношение к разработке ПО, хорошо знают, как часто даже на начальном этапе возникают вопросы к заказчику. Если эти вопросы будут немедленно разрешаться, мы получим значительную экономию ресурсов.

Ежедневные релизы

Еще один прием, который позволит частично компенсировать отсутствие подробного технического задания, - частые релизы. Покажите заказчикам вашу работу как можно раньше.

Отсюда, кстати, известное выражение "вечная бета" - веб-сайт выкладывается "в бой", программа становится доступной пользователям как можно раньше. И далее проектная команда корректирует процесс разработки (вплоть до концепции самого проекта) "на лету", наблюдая за реакцией пользователей.

Творчество, а не копирование

Подобный подход, движение вперед маленькими шагами требует от исполнителей гораздо более высокой ответственности, нежели простое кодирование. Вам потребуются креативные специалисты, способные самостоятельно находить оптимальные решения. В подобном процессе разработчикам не раз приходится переписывать код, поэтому для облегчения их работы в экстремальном программировании есть несколько практик. Я не буду описывать их подробно, это тема отдельной статьи, но упомяну:

  • Тестирование до начала разработки.
  • Парное программирование.
  • Постоянный рефакторинг.
  • Простота разработки.
  • Коллективное владение кодом.
  • Быстрый выпуск версий.
  • Постоянная интеграция.
  • Стандарты кодирования.

Тестирование до начала разработки предполагает написание тестов, в том числе приемочных, до того как будет написан сам код. Это дает значительные преимущества, особенно в сложных системах, где изменение одного компонента неизбежно влияет на работу других. В таких случаях приемочные тесты жизненно необходимы.

Парное программирование я рекомендую использовать только в случаях, когда вам нужен очень качественный результат. Мой опыт говорит о том, что двое программистов за одним компьютером программируют медленнее, чем двое за двумя, но программный код, который получается в экстремальном варианте, содержит на порядок меньше ошибок.

Постоянный рефакторинг заключается в регулярном пересмотре того, что уже написано, уже разработано. И в постоянном его улучшении.

Простота разработки - из двух вариантов выбирается более простой и быстро реализуемый.

Коллективное владение кодом означает, что все участники проекта свободно читают и знают любой участок программы. Это достигается путем введения стандартов кодирования - некоторых правил написания программного кода, обязательных для всех, что облегчает чтение кода, поскольку он становится однородным в рамках проекта.

Постоянная интеграция - мы пробуем запустить вместе даже недописанные и не до конца отработанные компоненты системы, чтобы как можно раньше увидеть разного рода несовместимости и ошибки в проектировании. Для этих же целей служит быстрый выпуск версий - постоянная корректировка процесса разработки с учетом мнений пользователей и заказчика.

Сотрудничество, а не конфликтование

Одно из важных следствий принятия концепции хаотичности окружающего мира - исчезновение конфликтов между менеджерами и исполнителями. Эти, казалось бы, вечные "грабли" хорошо знакомы всем, кто имеет отношение к разработке веб-сайтов. В традиционной (каскадной) модели разработки пик конфликта приходится на самый важный этап - предвыпуск или выпуск проекта. Главная причина - разработчики сделали не совсем то, что хотел менеджер или заказчик.

Как вы понимаете, эта проблема исчезает, если мы априори принимаем, что мнение заказчика может измениться, но и мы сможем своевременно на это отреагировать: ведь наши рабочие процессы построены так, что нам не придется переписывать заново половину программного кода, соответственно, изменение задачи не приведет к психологическому "напрягу" разработчиков.

Спиральная модель жизненного цикла разработки ПО

Специалисты по управлению проектами справедливо заметят, что описываемые мною приемы напоминают спиральную модель жизненного цикла разработки программного обеспечения. Почему же эта модель, несмотря на очевидные достоинства (снижение рисков, повышение качества продукта и степени удовлетворенности заказчиков и разработчиков), не используется повсеместно в разработке ПО и веб-приложений?

Потому, что это сложно. Потому, что требует большей ответственности от всех участников процесса, большей гибкости, большей сознательности и даже храбрости - в экстремальном программировании это качество в почете.

- Из журнала "Компьютерра"

См. также

Как мы автоматизировали башню раздачи воды

Кейсы автоматизации Платформа 1С v8.3 Энергетика и ЖКХ Россия Бесплатно (free)

Делимся опытом автоматизации учета башни раздачи воды.

27.12.2023    1386    0    slavik27    4    

14

Управленческие аналитики для 1С:Бухгалтерии – отчеты для принятия верных решений

Отчеты и дашборды Платформа 1С v8.3 Бухгалтерский учет 1С:Бухгалтерия 3.0 Бухгалтерский учет Бесплатно (free)

Если вы привыкли выгружать бухгалтерские операции в Excel и дополнять их там управленческой информацией, вы сможете значительно сэкономить время, получая нужные управленческие отчеты в бухгалтерской программе сразу, без лишних движений. Представляем решение для самостоятельного внедрения управленческого учета в 1С:Бухгалтерии.

11.12.2023    1598    0    Serg_Tangatarov    2    

15

Архитектурное ревью. Процесс разработки

Архитектура решений Бесплатно (free)

Рассмотрим применение архитектурной проверки задач в процессе разработки.

30.10.2023    3751    0    ivanov660    10    

28

Технология разработки Рабочих мест для автоматизации производственных процессов и управленческого учета

Кейсы автоматизации Работа с требованиями Анализ бизнес-процессов Бесплатно (free)

Автоматизировать производственные процессы в 1С:ERP без доработки типовых механизмов очень сложно. А дорабатывать типовые механизмы 1С:ERP не всегда оправданно. Решением может стать технология разработки Рабочих мест, которая позволяет автоматизировать самые сложные участки последовательно – шаг за шагом, процесс за процессом. Расскажем о том, как помочь пользователям вводить большое количество данных, не нарушая порядок ввода и полноту заполнения всех необходимых реквизитов, и как вовлечь сотрудников Заказчика в разработку и тестирование функционала Рабочих мест.

26.10.2023    1784    0    user1754524    15    

15

Опыт оптимизации системы ERP на примере железнодорожного холдинга численностью 10 тыс. человек

Кейсы автоматизации Платформа 1С v8.3 1С:ERP Управление предприятием 2 Бесплатно (free)

Когда проект внедрения ERP в крупном холдинге захлебывается в проблемах производительности и в отчаянии пользователей, нужен комплексный подход. Расскажем о битве за производительность и об организационных мероприятиях по наведению порядка в системе и коллективе.

29.08.2023    2837    0    ke_almaty    0    

14

5 подходов при доработке конфигурации 1С, чтобы в будущем не было мучительно больно её обновлять

Архитектура Рефакторинг и качество кода Обновление 1С Платформа 1С v8.3 Бесплатно (free)

Нашей компании часто приходится сталкиваться с обновлением конфигураций разной степени переписанности. Какие-то из них обновляются легко, какие-то — не очень. Расскажем о некоторых принципах модификации программы, которые помогут сделать последующий процесс обновления легче. Или тяжелее, если стараться их не соблюдать.

10.08.2023    9517    0    1c-izhtc    37    

21

Внедрение системы технологического контроля (практический кейс)

Кейсы автоматизации Платформа 1С v8.3 1С:Управление нашей фирмой 3.0 Управленческий учет Бесплатно (free)

Стабильное качество выпускаемой продукции и ее соответствие нормативным документам (ТУ, ГОСТам, СМК) для активного предприятия является конкурентным преимуществом, так как оно подчеркивает, что на предприятии отлажены контрольные процедуры на входящее сырье, производство полупродуктов и готовой продукции, доставки. В своей практике я принимал участие во внедрении цифровых инструментов в сельском хозяйстве, где показателями зерна служат влажность, засоренность, крупность и т.д.; в металлургии — перед литьем в формы надо проверить сплав на содержания железа, алюминия, магния и т.д.; в кабельной промышленности в дополнение к физическим свойствам типа геометрии, длины, шероховатости, надо выдерживать и электротехнические показатели. 

22.05.2023    1352    0    Ingraf    0    

14
Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. KosmoSTAR 03.02.10 18:33 Сейчас в теме
Я вот только не понял одного. С таким методом трудозатраты и время на проект или заказ увеличивается, значит должен быть увеличен и бюджет проекта. А заказчик чаще всего против его увеличения. Что делать в таком случаи???
2. tango 506 03.02.10 18:49 Сейчас в теме
угумс. все хорошо, прекрасная маркиза, а кто платить будет за новые рюшечки?
самое дерьмо - это когда рук.проекта со стороны исполнителя просто прогибается "чего изволите", даже если платят за время.
www - это, может, и не заметно, а вот в учетной системе рождает чудовищ
3. fastwriter 6 29.03.10 11:34 Сейчас в теме
Экстремальное программирование - совсем не панацея, и часто на 100% не применимо именно в реальной жизни.

Например, оно требует парной разработки. То есть: один программист кодирует, а второй сидит рядом с ним все это время, читает код и, когда не согласен - поправляет его. Люди, которые пробовали - говорят, что это себя оправдывает полностью, т.к. получается гораздо меньше ошибок и код более высокого качества. Но вот вопрос: какой франчайзи пойдет на подобное? И какой клиент согласится платить в 2 раза больше за почасовую работу программистов?

Кроме того, у каждой гибкости есть разумные пределы. Если требования будут перекраиваться быстрее, чем программисты будут успевать их реализовывать - сами понимаете, что получится.

Ну и т.д. В гугле и другие недостатки можно найти.
4. kirmancino 27.11.13 19:58 Сейчас в теме
При создании АИС такая работа создает не хаос, а пробку.
Создавать подробнейшее ТЗ возможно и нет необходимости, но рабочее ТЗ обязательно должно быть, т.к. именно к нему аппелируют Заказчик, Аналитик, Разработчик. И именно в рабочем ТЗ описаны различные опции, свойства, параметры и то как они работают надо не в ежедневных бета-версиях выяснять, а описывать заранее, оставляя возможность для расширения возможностей системы.

У дизайнеров есть фраза "Какой бриф, такой и креатив". И у нас - похожая история.
Оставьте свое сообщение