Информационный сайт

 

Реклама
bulletinsite.net -> Книги на сайте -> Бизнесмену -> Демарко Т. -> "Балдеющие от алреналина и зомбированные шаблонами. Паттерны поведения проектных команд" -> 40

Балдеющие от алреналина и зомбированные шаблонами. Паттерны поведения проектных команд - Демарко Т.

Демарко Т., Листер Т., Макменамин С., Робертсон Дж. Балдеющие от алреналина и зомбированные шаблонами. Паттерны поведения проектных команд — Спб.: Символ-Плюс, 2010. — 288 c.
ISBN 978-5-93286-160-8
Скачать (прямая ссылка): baldeushieotadrenalina2010 .djvu
Предыдущая << 1 .. 34 35 36 37 38 39 < 40 > 41 42 43 44 45 46 .. 77 >> Следующая


Свидетельством использования этого паттерна является ситуация, когда команда совершает обзор (дыхательная трубка) параллельно с точечными исследованиями (акваланг), а не вместо них. Ключевым моментом здесь является способность применять навыки «горизонтального» и «вертикального» исследования в ходе всего проекта. «Горизонтальные» исследования выявляют людей, организации, аппаратное обеспечение и программные системы, которые могут оказать какое-либо влияние на проект. Растущий объем таких «горизонтальных» знаний обнажает области наивысшего риска и наибольших выгод, более глубокое исследование которых принесет проекту пользу.

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



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

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

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

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

Иногда достаточно просто потрогать воду пальцем, чтобы понять, что здесь нырять не стоит. 43 I Эти чертовы интерфейсы

Члены проектной команды неотступно концентрируются на интерфейсах - как автоматизированных, так и человеческих.

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

Что происходит в проектировании после того, как достигнуто согласие по поводу функциональности? Мы разбиваем большую и сложную систему на подсистемы, а подсистемы делим на компоненты. Эти чертовы интерфейсы

147

И снова, для того чтобы ограничить эти подсистемы и компоненты, необходимо в каждом случае определить все уникальные входы и выходы.

Как мы фрагментируем деятельность по реализации? По подсистемам и/или компонентам. Команда может взяться за работу над подсистемой, при этом отдельные люди будут создавать и тестировать компоненты. Границы подсистемы и компонента задают фронт работ, определяя конкретную область ответственности каждого разработчика. Интерфейсы играют роль контрактов между компонентами; один компонент говорит другому: «Ты передаешь мне именно такие данные и только при таких условиях, а я создам именно такой результат, который будет храниться точно в указанном месте».

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

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

Знакомые с этим паттерном команды начинают штурмовать интерфейсы как можно раньше. Они создают фрагменты кода для работы интерфейсов еще до того, как начнут писать код компонентов. Они рано начинают интеграцию кода отдельных разработчиков и часто проводят тестирование.
Предыдущая << 1 .. 34 35 36 37 38 39 < 40 > 41 42 43 44 45 46 .. 77 >> Следующая
Реклама
Авторские права © 2009 AdsNet. Все права защищены.
Rambler's Top100