Инкрементная разработка является эффективным подходом, а стремление к простому дизайну кажется логичным.
Однако, попытки "на лету" дать определение архитектуры - глупы и тщетны.
Существует причина, по которой никто не придерживается спонтанного проектирования:
оно не работает.
Использование командой метафор (система - это
"конвейер") в качестве замены архитектуры
кажется еще более нелепым. Исследование университета Карнеги-Меллон показало,
что метафоры естественного языка практически не способствуют общению между
участниками проекта или разработке архитектуры.
Так или иначе, почти никто не понимает, что такое метафора системы,
как ее нужно использовать, как выбрать содержательную метафору или как ее
изменить, если вы истолковали ее неправильно (и как об этом узнать) - включая
человека, которому принадлежит следующее высказывание:
"Хорошо, я готов признаться публично: я до сих пор не могу понять, что же это за штука такая, эта метафора. Я видел, как она работает (в проекте C3 она сработала великолепно), однако это вовсе не означает, что я знаю, как это сделать, не говоря о том, чтобы объяснить это другим."
(Мартин Фаулер. "Проектирования больше нет?")
Методы гибкой разработки усовершенствовали процесс и
результаты разработки и представили действенные подходы решения многих проблем
разработки ПО, но не архитектуры и дизайна.
Ежедневные совещания
Когда к вам приходит новая команда и участникам необходимо
узнать друг друга или требуется больше времени, чтобы разобраться в проекте;
или когда команда работает в чрезвычайных, напряженных условиях, пытаясь
исправить или закончить что-нибудь, собирать регулярные совещания - может, даже
чаще раза в день - полезно. Будет ли каждый выступать стоя или сидя и что будут обсуждать
уже зависит от вас.
Если ваша команда работает слажено некоторое время, все друг
друга знают, знают, над чем работают, а разработчики обновляют карточки на
доске задач (Канбан-доске) или статус в электронной системе по мере выполнения
заданий, и являются достаточно взрослыми, чтобы при необходимости попросить о
помощи, то не следует каждое утро организовывать совещание.
Коллективное владение кодом
Не стоит
всегда разрешать всем участникам команды работать над кодом (потому что не все
обладают необходимыми знаниями и опытом), ведь это может негативно повлиять на его качество.
Помните, что не все могут - или должны - работать над каждой частью системы.
Требования в виде пользовательских историй
Идея описания спецификаций требований в виде пользовательских историй на
маленьких карточках, где требования должны быть короткими и использовать шаблон
"Как <роль>, я хочу <цель>, чтобы <деловая выгода>", является бессмысленной.
Она похожа на способ определения требований в сценарии использования в UML
с фигурками человечков и кружочками,
популярный 15 лет назад. Существует много различных способов эффективно
сформулировать требования.
Иногда их нужно описать детально (когда необходимо соблюдать
нормативные требования или придерживаться стандарта, или применить конкретный
алгоритм, или…).
Иногда лучше работать с тестовым случаем, детальным
сценарием варианта использования, каркасной или другой моделью. Поэтому,
выбирайте формат, наиболее подходящий уровню детальности и приступайте к
работе.
Полагаться на заказчика
Полагаться на заказчика
как на единственный "голос клиента"
и человека, ответственного за весь процесс в случае провала проекта, ненадежно
и подвергает риску всю команду вместе с проектом. Такой подход скорее создает
проблемы, чем их решает.
Чтобы добиться успеха команде нужно стабильное
взаимодействие с клиентом на разных уровнях и участники сами должны следить за тем,
есть ли у них все необходимое, а не перекладывать ответственность на другого
человека.
Комментариев нет:
Отправить комментарий