Предисловие
Чтобы создать что-либо, сохраняющее свою ценность в течение продолжительного времени, - будь-то программы, системы или компании - создатели должны все делать с душой. Понятие "процесс" означает реализацию способов совместной деятельности людей. Процесс является "семейным рецептом", "секретным соусом", конкурентным преимуществом.
У каждого есть своя коллекция процессов. Так делают все команды. Реализация процесса - плохо или хорошо, - очевидно, является первым шагом к пониманию того, что в данный момент происходит, к оценке того, что делается, а что, наоборот, не делается, и является первым шагом к собственному взгляду на то, что именно происходит в одной из жизненных ситуаций. Рассмотрение процесса - как способа совместной деятельности - поднимает мышление и действия на более высокий уровень. Если чувствуется давление, нужно лишь поднять свое мышление на уровень выше и оглянуться: все начинает налаживаться прямо сейчас; все вокруг становится более отчетливым. Возникает беспокойство о том, что делать, или о том, что является более важным? Нужно поднять мышление на уровень выше. Проблемы с партнером и непонятно, где уступить? Нужно поднять мышление на уровень выше. Возникает беспокойство из-за того, что программное обеспечение, выпускаемое другими, лучше? Опять же, нужно поднять свое мышление на уровень выше.
Понятие "процесс" подразумевает подъем на более высокий уровень, приобретение новых точек зрения и приглашение других на этот более высокий уровень. Это дает возможность осуществлять стратегические решения, призванные делать повседневную реальность максимально эффективной, и, можно даже сказать, интересной, полезной и насыщенной.
Процесс, подъем мышления и действий на более высокий уровень проявляется тогда, когда кто-то понимает, что делает он сам, что делают другие, в чем состоит динамика и разногласия между людьми, что является катализатором и узким местом, что такое общий контекст, что такое расширенный контекст и что со всем этим делать. Всего один уровень.
Появились сложности? Нужно поднять мышление на более высокий уровень и выяснить, что можно предпринять. Пришел успех? Нужно поднять мышление на более высокий уровень и найти способы закрепить его.
В принципе этого более высокого уровня мышления и действий способны достичь все, и этот шаг дает возможность более успешного общения с другими людьми, формирования значимых отношений, формирования людей, формирования долговременных продуктов, - а это означает стопроцентный успех.
Все сказанное ранее подводит к теме этой книги, теме функционально-ориен-тированной разработки ПО (Feature-Driven Development, FDD). Функционально-ориентированная разработка ПО состоит из набора практических действий, включаемых в контекст глобального процесса, на более высоком уровне повседневной необходимости, людьми, имеющими опыт в бизнесе, и разработчиками, которые вместе работают над критически важными проектами по разработке ПО.
В книге Практическое руководство по функционально-ориентированной разработке ПО описан процесс, который компания TogetherSoft совместно со своими клиентами использует для создания программного обеспечения мирового класса. Нами совместно с Джефом де Лукой эта схема впервые была описана более двух лет назад в небольшой главе книги Java Modeling in Color with UML. Авторы книги вышли далеко за рамки того начального описания. Они, как можно будет увидеть здесь, значительно развили идеи FDD. Больше всего я благодарен им за проделанную работу и глубокое понимание того, о чем они пишут.
FDD сама по себе является более высоким уровнем мышления и действий.
Читайте эту книгу. Изучайте рецепт. Пробуйте его применить. Переделывайте его, как это было бы с любым семейным рецептом, делая его своим, пытайтесь наилучшим образом использовать те ингредиенты, которые у вас имеются. Читайте. Пользуйтесь. И берегите идеи Палмера и Фелсинга.
Искренне ваш
Питер Код (Peter Coad)
Генеральный директор и президент компании
ogetherSoft Corporation
[email protected]
Вступление
Чем FDD не является
FDD абсолютно не является таким процессом, который лишь отнимает ресурсы, время и деньги и не дает ничего полезного взамен. Он не относится к категории методов, посредством которых администраторы, бюрократы и фанатики централизации управления могут отнимать общее время и силы на создание кип ничего не отражающих отчетов и сигнатур. FDD не является еще одним сборником описаний процесса, занимающим место на полке, собирающим пыль и поражающим инспекторов, сотрудников и прочих важных людей познаниями владельца в еще одном не очень полезном направлении производства систем.
Что полезного в этой книге
Если задать себе любой из перечисленных ниже вопросов, то найти ответы на них можно на страницах этой книги.
- Вы отвечаете за работу группы, которая должна выпустить критически важную систему, причем ресурсы ограничены и сроки предельно коротки, и вам нужна помощь в организации проекта?
- Вы устали заполнять огромное количество процессуальных форм и просматривать горы документов, так что у вас не остается времени на действительно полезную деятельность?
- Вы разочарованы невыполненными обещаниями о проведении инициатив, которые должны были дать возможность неоднократного получения качественных результатов?
- Вы подыскиваете более эффективный способ организации вашей команды для повышения производительности, сокращения ненужных задержек и повышения точности отчетов в вашем проекте?
- В данный момент вы работаете над проектом, который находится в трудном положении, из-за того что команда потерпела неудачу при создании системы?
- Вы хотите обзавестись дополнительными инструментами и методиками для управления проектом или инструментарием руководителя проекта?
В этой книге
Несмотря на то, что FDD впервые была описана в книге Java Modeling in Color with UML (Coad 99), здесь эта тема будет освещена более подробно. Также будут затронуты важные для достижения успеха моменты и указаны "подводные камни", которые могут на первый взгляд оказаться незаметными. Следовательно, содержимое этой книги выглядит следующим образом.
- Кому может понадобиться FDD
- Роли, артефакты, цели и временные последовательности
- Зачем в FDD нужны те практики и методы, которые в ней применяются
- Основные факторы развития FDD
- Применение FDD в проектах разной направленности
FDD состоит из большого числа наилучших из известных в производстве практических методов, которые успешно использовали Питер Код, Джеф де Лука и др. Все эти практические методы опираются на клиентскую оценку перспективных функций. Это действенная комбинация методик, которая и делает FDD такой эффективной.
Джон М. Фелсинг ([email protected])
Стивен Р. Палмер ([email protected])
Декабрь, 2001 г.
Введение
В опубликованной в 1999 году книге Java Modeling in Color with UML (Coad 99), часто называемой "книгой красок", пять из шести глав посвящены обсуждению реального значения новой методики объектного моделирования, которая называется цветным моделированием. Эти пять глав не относятся к остальной части этой книги. Более явное отношение к оставшейся части этой книги имеет последняя шестая глава. В этой главе предпринимается попытка описать конкретный способ успешного создания системы ПО в условиях очень большой команды разработчиков, имеющих разные способности и опыт. Процесс разработки ПО, который описывается там, называется функционально-ориентированной разработкой ПО (Feature-Driven Development, FDD).
Сложности проекта
Нужно начать с того, что FDD возникла в ходе работы над большим проектом по разработке ПО в Сингапуре, где Джеф де Лука (Jeff De Luca) занимал должность менеджера проекта, Питер Код (Peter Coad) - должность главного архитектора, а Стивен Палмер (Stephen Palmer) - должность менеджера команды разработчиков. Проект был амбициозным, с очень сложной проблемной областью, охватывающей разные направления в бизнесе: от автоматизации управления до прикладной интеграции существующих систем.
Банк уже предпринимал одну попытку создания такого проекта, и она оказалась неудачной. Проекту в наследство досталось скептически настроенное сообщество пользователей, осторожное высшее руководство и то, что осталось от деморализованной команды разработчиков.
Одним из ключевых факторов риска, по мнению Джефа де Луки, являлась сложность проблемной области. Это требовало возможностей и опыта в области объектного моделирования, который значительно превышал уровень имеющейся команды. Чтобы устранить этот риск, Джеф де Лука убедил Питера Кода приехать в Сингапур и приступить к совместной работе с командой над проектом для создания гибкой и устойчивой объектной модели предметной области.
В результате совместных усилий Джефа де Луки, Питера Кода и остальных участников в этом проекте была разработана техника цветного моделирования и создан процесс FDD - быстрый, адаптируемый процесс разработки, который обладает следующими характерными чертами.
- Процесс является сильно итеративным
- На каждом этапе процесса делается акцент на качество
- Процесс дает частые, явные и практичные результаты
- Процесс позволяет получать точные и существенные сведения о развитии и состоянии дел с минимальным количеством издержек и неудобств для разработчиков
- Процесс нравится клиентам, менеджерам и разработчикам
Клиентам он нравится потому, что они сразу видят реальные результаты, а отчеты составляются на понятном для них языке.
Менеджерам он нравится потому, что дает им полную и точную картину развития и состояния проекта, - той информации, которая нужна для соответствующего управления проектом.
Разработчикам он нравится, поскольку они могут работать небольшими командами с небольшими итерациями и часто пользоваться словом готово; чем-то новым они могут заниматься каждые несколько дней. В этом процессе они вовлечены в анализ, проектирование и реализацию. Анализ и проектирование не диктуются одним-двумя элитными аналитиками или архитекторами. FDD нравится разработчикам также и потому, что они могут обеспечивать своих менеджеров необходимой информацией о состоянии дел, затрачивая минимальные усилия.
Пол Жего (Paul Szego), главный программист сингапурского проекта, подписываясь на авторском экземпляре "книги красок" Стивена Палмера, написал: "Кто сказал, что программирование это скучно? Это лучшее время, которое у меня было".
FDD утвердительно отвечает на вопрос "есть ли здесь что-то и для меня?" каждой роли в проекте. Такая ситуация резко выделяется на фоне некоторых процессов, используемых менеджерами для контроля над разработчиками, так как им кажется, что разработчики недостаточно компетентны, чтобы им можно было доверять.
Со времени своего первого представления в "книге красок" FDD была эффективно проверена в большом количестве организаций, занимающихся разработкой ПО, перечень которых непрерывно увеличивается. Ее значение не ограничивается "спасением" проекта от проблем; она обоснованно применима в проектах, которые уже стартовали, проектах, которые расширяют имеющийся код, и проектах, работающих над созданием второй версии системы, которая была составлена наспех в последний момент.
Описание FDD фокусируется на получении частых, четких и практичных результатов на каждом уровне проекта (от разработчиков до главного программиста, главного архитектора, менеджера проекта, инвесторов проекта и конечных пользователей), что обеспечивает их значимость при серьезном рассмотрении в любой организации, занимающейся разработкой ПО, которой вовремя нужно представлять качественные, критичные для бизнеса системы ПО.
Кто виноват
Хотя вклад в развитие FDD сделали разработчики, задействованные в сингапурском проекте, несомненно, что основные "виновники" - Джеф де Лука и Питер Код.
Питер Код - известный разработчик объектных моделей, консультант, автор, лектор, преподаватель и человек в "гавайке". Питер спроектировал сотни компонентов и объектных систем в различных отраслях промышленности.
Джеф де Лука, со своей стороны, обучался "глубокому, темному искусству" разработки операционных систем для серверов AS/400 в лаборатории фирмы IBM, в Рочестере, штат Миннесота, и сейчас он опытный технический консультант и менеджер проекта. Питер Код так сказал о нем: "лучший менеджер проекта, с которым я когда-либо работал".
Почему они сами не написали эту книгу? Ответ очень прост. Они слишком заняты развитием компаний, которые производят успешные программные приложения. Джеф де Лука возглавляет компанию Nebulon Pty. Ltd. (www.nebulon.com) и успешно использует FDD в производстве коммерческих систем для крупных клиентов в Мельбурне (Австралия) и его окрестностях. Питер Код - президент компании TogetherSoft (www.togethersoft.com), которая производит платформу для разработки приложений TogetherSoft, неоднократно отмеченную наградами. Все диаграммы унифицированного языка моделирования (Unified Modeling Language, UML), представленные в этой книге, были построены с помощью платформы для разработки приложений Together ControlCenter компании TogetherSoft.
До теперешнего момента все, кто хотели больше узнать о FDD, были ограничены лишь введением к главе 6 "книги красок" (Coad 99), небольшим обсуждением на Web-узле компании Nebulon и несколькими выпусками ежемесячного бюллетеня Coad Letter (Palmer), который есть в архиве на www.togethersoftcommunity.com, а в данный момент редактируется Стивом Палмером. Поэтому эта книга имеет следующие цели.
- Обеспечить всесторонней информацией, которая может понадобиться при изучении FDD
- Предоставить большое количество советов и практических рекомендаций по применению FDD
- Обсудить развитие FDD, начиная с момента публикации "книги красок"
Если читатель является разработчиком или руководителем команды, в любом виде принимающим участие в управлении разработкой ПО и нуждается в использовании FDD, или просто интересуется тем, какие вопросы и ответы стоят за FDD, то эта книга предназначена для него.
Несколько, если это действительно так, обсуждаемых идей являются привилегией авторов. Многие идеи родились из замечаний, сделанных Джефом и Питером. Многие идеи вызваны к жизни работами Фреда Брукса (Fred Brooks) [Brooks], Тома де Марко (Tom De Marco) [De Marco], Люка Хохмана (Luke Hohmann) [Hohmann] и Джеральда Вейнберга (Gerald Weinberg) [Weinberg 92, Weinberg 98]. И, в свою очередь, многие из их работ основываются на работах Харлана Миллза (Harlan Mills) [Mills], Вирджинии Сатир (Virginia Satir) [Satir], Филипа Кросби (Philip Crosby) [Crosby] и др.
Присвоить идею одному человеку - наивность; присвоить идею самому себе - самомнение.
Принцип присвоения авторства хорошей идеи многим и превращение этого в большой результат распространяется как на эту книгу, так и на FDD.
Как читать эту книгу
Книга состоит из трех частей.
1. В части I освещаются некоторые основные принципы и важные характеристики любого процесса разработки ПО, а также поднимаются вопросы о значении всего этого. Далее вводятся люди, прикладные методы и процессы, составляющие собственно FDD. Разделы заканчиваются введением в мониторинг и созданием рабочих отчетов, а также предположениями о формате отчетов, проектировании и рабочих пакетах.
2. В части II отдельно рассматривается каждый процесс в FDD и даются дополнительные рекомендации, описываются методики, используемые в FDD.
3. В части III дискуссия расширяется для ответа на наиболее часто задаваемые вопросы о FDD, и анализируется ее влияние на другие важные виды деятельности в проекте по разработке ПО, которые не входят в круг рассматриваемых задач.
О примерах
Написание книги о процессе - почти такая же пытка, как и чтение такой книги. Пытаясь сохранить у читателя интерес к книге до самого конца, авторы иногда неожиданно бросаются в бурные персонифицированные обсуждения, основанные на различных точках зрения. Авторы официально приносят извинения - ведь могло получиться еще хуже! Один из авторов, Мак Фелсинг (Mac Felsing), - любитель оперного пения; но, к счастью, печатные средства не позволяют ему внезапно разразиться на этих страницах песней J.
Разыгрывание ролей в обсуждениях призвано проиллюстрировать некоторые моменты в контексте специфического, небольшого, но реального примера проекта компании Gary's Garage, которая занимается продажей автомобилей и владеет станцией сервисного обслуживания автомобилей.
Этот пример был выбран по двум следующим причинам.
1. Он достаточно велик, чтобы представлять убедительную, реальную задачу.
2. Авторам хотелось представить содержимое этой книги в ясной, правдоподобной обстановке, - такой, которую легко понять.
Итак, добро пожаловать в компанию Gary's Garage! Гэри владеет лицензией на продажу от известного производителя автомобилей. В компании Gary's Garage можно купить новый или неплохой подержанный автомобиль, получить сервисное обслуживание и, если необходимо, ремонт. Как главный дилер в этом регионе Гэри также занимается продажей фирменных комплектующих, запчастей и аксессуаров другим авторемонтным мастерским и частным заказчикам. Гэри и его сотрудники вызвались помочь во внедрении и сопровождении новой системы программного обеспечения по управлению продажами и обслуживанию клиентов, предназначенной для авторизованных представительств производителей автомобилей.
Действующие лица
Команда разработчиков
- Лайза, менеджер проекта. Она опытный менеджер проекта в небольшой фирме, занимающейся интеграцией малых систем и заказным программированием.
- Стив, главный программист. Это опытный, интеллигентный, эрудированный англичанин.
- Мак, главный программист. Он так же опытен и интеллигентен, как и Стив, но более красив.
- Прочие сторонние сотрудники, появляющиеся по мере необходимости. Разве не жаль, что комплектация проектов персоналом в действительности не такая уж и простая задача?
Специалисты со стороны заказчика
Техник Майк. Как главный техник Майк занимается обслуживанием и работой в мастерской, а также руководит группой механиков.
Продавец Стюарт. Он отвечает за группу продавцов из отделов новых и подержанных автомобилей, а также за работу демонстрационных залов.
Кладовщик Сэнди (менеджер службы снабжения). Он является менеджером службы снабжения и отвечает за своевременное пополнение перечня запчастей.
Менеджер службы сервиса Рэчел. Она отвечает за регулярное обслуживание и ремонт, также в ее обязанности входят контакты с заказчиками.
Бухгалтер Анита. Она руководит сотрудниками вспомогательного офиса, занимается счетами и платежными документами, а также управляет административной частью дилерского франчайзинга.
Стив: Послушай, Мак, я уже говорил, что буду работать с тобой над тем автомобильным дилерским проектом, который начнется на следующей неделе. Что ты скажешь об этом?
Мак: Да! С самого начала я говорил менеджеру проекта, Лайзе, что это не такая уж и простая задача, как могло показаться на первый взгляд, так что учти это; они хотят начать и завершить его за 9 месяцев. По крайней мере, они должны доверить нам подбор разработчиков и членов команды. Лайза говорила мне, что хочет использовать "оптимальный процесс". Я думаю, она не захочет экспериментировать с чем-то, напоминающим экстремальное программирование, в таком заметном проекте. В любом случае для экстремального программирования, скорее всего, потребуется слишком большая команда, да и рассчитать расходы для большегрузного процесса будет невозможно. Ты ведь знаешь хороший облегченный процесс, не так ли?
Стив: Ты имеешь в виду функционально-ориентированный метод? Да, я был менеджером разработки важного проекта и там этот метод показал себя с наилучшей стороны. Несомненно, мы можем использовать FDD. Как насчет того, чтобы пойти в один из конференц-залов, тогда я смог бы подробно рассказать тебе об идеях и понятиях FDD.
Мак: Отлично. Я знаю N8 сейчас свободен. Только по дороге нужно будет взять кофе?
Мак: ?Как я уже говорил кабинет N8 свободен. Это тихий, хороший кабинет для совещаний, с белой доской, диаграммами, проектором и экраном. Имеется стол подходящего размера и удобные стулья. Там есть все, что нам потребуется.
Стив: Более чем достаточно! Я не думаю, что нам понадобится проектор; а белая доска будет кстати. Я прихватил пару моих любимых книжек по этой теме, на тот случай, если ты спросишь о чем-нибудь сложном, а если потребуется еще что-либо, то можно будет прихватить и его. Верно! С чего начнем?
Мак: Сначала я хотел бы получить некоторое общее представление, так чтобы мы могли определить некоторую теоретическую структуру, в которой можно было бы воссоздать то, как мы работаем над проектом. Тогда я буду хорошо понимать, как и почему работает FDD и что можно будет сделать, чтобы упростить ее применение в нашем проекте.
Стив: Эээ? Ладно!
Благодарности
Мы хотим поблагодарить всех наших друзей, семьи, а также бывших и теперешних коллег за их вклад в написание книги.
Особую благодарность хочется выразить Джефу де Луке (Jeff De Luca) и Питеру Коду (Peter Coad) за первое упоминание функционально-ориентированной разработки ПО в их книге Java Modeling in Color with UML. Мы также благодарим Джефа де Луку за его квалификацию и смелость, проявленные при создании среды проекта, в которой такого рода новшества должны процветать. Спасибо Питеру за то огромное количество обзоров, схем, стратегий и методик, которые сделали анализ и проектирование объектно-ориентированного ПО таким доступным.
Выражаем благодарность исходному составу команды разработчиков ПО PowerLender в Сингапуре, в частности Тан Сьеу Буну (Tan Siow Boon), Йео Саи Ченгу (Yeo Sai Cheong), Аджаю Кумар Ране (Ajay Kumar Rana), Ю-Лиа Тан (Ju-Lia Tan) и Джеймсу Тану (James Tan), во-первых, за их готовность воспользоваться новыми методами работы и, во-вторых, за их помощь в изучении методов применения FDD, которое продолжалось в течение многих месяцев. Перечислить всех было бы затруднительно, но они знают, о ком идет речь.
Также благодарим всех лекторов компании TogetherSoft, которые способствовали внесению в бесконечных дискуссиях, электронных посланиях и телеконференциях новых мыслей, идей и предложений. Отдельную благодарность выражаем Лайзе Джулиани (Lisa Juliani), нашему руководителю лекторского отдела, за ее помощь в подготовке к изданию книги, а также Кену Ритчи (Ken Ritchie), Грегу Кеткарту (Greg Cathcart), Дену Месси (Dan Massey) и Скотту Шнаеру (Scott Schnier) за их критические отзывы и энтузиазм.
Выражаем благодарность Полу Петралиа (Paul Petralia), Донне Каллен-Дольче (Donna Cullen-Dolce) и остальным сотрудникам издательства Prentice Hall за огромное количество проверок, а также за их квалифицированную помощь и советы. (Так же, как и за снисходительное отношение к капризам, слабостям и опозданиям, связанным с работой двух перегруженных творческих личностей.)
