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

 

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

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

Демарко Т., Листер Т., Макменамин С., Робертсон Дж. Балдеющие от алреналина и зомбированные шаблонами. Паттерны поведения проектных команд — Спб.: Символ-Плюс, 2010. — 288 c.
ISBN 978-5-93286-160-8
Скачать (прямая ссылка): baldeushieotadrenalina2010 .djvu
Предыдущая << 1 .. 52 53 54 55 56 57 < 58 > 59 60 61 62 63 64 .. 77 >> Следующая


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

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

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

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

Вот некоторые бросающиеся в глаза особенности таких команд:

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

Спросите у немца. (Единомышленники. - Примеч. перев.) Seelenverwandtschaft

215

• Для записи идей, решений и списков дел всем инструментам они предпочитают белую доску.

• Они работают на основе неполных, высокоуровневых требований. Они часто пропускают создание полноценной документации по проектированию и приступают к написанию кода уже на самых ранних стадиях процесса разработки.

• Они часто выбрасывают и переписывают код. Как только они продемонстрировали работу какой-либо функции, они начинают ее перерабатывать.

И все это они делают крайне быстро. Разработка той или иной функции обычно занимает от одного до трех дней. Очень сложные функции могут потребовать до десяти дней. Многие задачи выполняются и передаются на тестирование менее чем за полдня.

Паттерн не распространенный, но настолько замечательный, что его следует отметить. За неимением лучшего названия мы именуем такие команды «партизанскими». Они чаще встречаются в сообществе гибкой разработки1, но некоторые команды выработали у себя партизанский образ действий, не зависящий от применения тех или иных методов.

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

В основе многих наших действий по разработке ПО лежат простые верования, вроде этого: «Стоимость обнаружения и исправления проблемы радикально увеличивается в ходе разработки». Как следствие, мы стремимся получить правильные требования и архитектурные решения как можно раньше и избежать переделок на после-

Хороший обзор методов гибкой разработки и основополагающих принципов этого подхода можно найти в книге Алистера Коберна «Agile Software Development: The Cooperative Game, 2nd ed.», Boston: Addison-Wesley, 2006. (Перевод первого издания: Коберн А. «Быстрая разработка программного обеспечения». -M.: Лори, 2002.) В качестве отправной точки можно также использовать интернет-ресурс www.agile alliance.org. 216

Seelenverwandtschaft 216

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

Так для чего же годятся партизанские команды? Как минимум, для создания первой версии нового продукта, а иногда и второй. Лучше всего этим командам удается исследовать относительно новые пространства задач и изобретать для них новаторские решения. И хотя партизанские команды способны создавать очень качественный и долгоживущий код, они заточены под инновации.
Предыдущая << 1 .. 52 53 54 55 56 57 < 58 > 59 60 61 62 63 64 .. 77 >> Следующая
Реклама
Авторские права © 2009 AdsNet. Все права защищены.
Rambler's Top100