Принципы работы с требованиями к ПО. Леффингуэлл (2002) (Принципы работы с требованиями к ПО. Леффингуэлл (2002).djvu), страница 10

Кто, кроме разработчиков программного обеспечения, мог разработать операциош<ую систему Е'М1Х> Мы увлечены технологией, н зто наша основная мотивация. Возможно, из-за врожденной генстнческ<>й направленности или из-за того, что в колледже мы провстили "ненужные" курсы по психологии, драматическому искусству илн, что сщс хуже, англн«скому, мы в пашей работе, как правило, уделяем меньше внимания человеческому фактору, чем битам и байтам. Мы нс <>чгнь приятны в общсшш>, з многие вообще испытывшот гложностп в отношениях с л<одьмн вне рабюты, когда нет общих технических тем для обсуждения. 1!зпрпмер, в день открьпых лзерей в компаш>н КЕ1 > (1979 гол) олин программист на нр<» тяже>нш всей вс шринкн огтзв.и<я за свои>< рабочим столом, успевшо програмля>руя даже тогда, когда его стол оказался в центре комнаты, где проходила вечеринка. Закончив свою работу, он просто встал, убрал своп бумаги и уя>сл, ш<коиу»е сказзз пн слова.

Что необычно> о в его поведении.' В пашей отрасли!! Рнчсго! 50 Введение Одним из результатов этого, которому также способствовала простая однопользовательская природа используемых средств и достаточно скромные размеры разрабатываемых приложений, явилась тенденция рассматривать разработку программного обеспечения как индивидуальную деятельность.

Программист самостоятельно определял, проектировал, писал и, кзк правило, тестировал свою работу. Возможно, приглашались тестологи для того, чтобы помочь на этапе окончания, но в основном упор делался на индивидуальную деятельность. Программист-герой был основной парадигмой. Разработка программного обеспечения каккоманднаядеятельность "РазРаботка пРогРоммного обгсгмчения паола каиандным видом сгизРта. "1Буч, 1998) Но в некоторый момент правила игры изменились.

Почему) Уаттс Хачфри (азиз НишрЬгеу, 1989) отметил следующее. "История развития разработки программного обеспечения — это история роста ее масштабов." Исэнфия развития рафаботки гфограимного обеспечения — зто испгория росою ее зизсзггнзабов. Первоначально непсолько индивидуально работающих программнстоо могли предложить "хитрые" маленькие зфофамиы; вскоре этого стало недоспшпючно. Начали создаваться команды„состомягие из дюзсины, а то и двух дюзсин человек, но успех бьсе неременным.

Пока многие организации занимались ртиением пронзен не. болыких систем, масштабы наших работ зфодолжоли расти. На сегоднлипшй день кРупные пРоекты, как пРавило, требуют кафдиниРованной Рабоигы л~ногнх команд. Хамфри также заметил. что возрастание сложности снижает способность человека решать задачи интуитивно по мере их возникновения. Например, мы занимаемся проектом разработки требований, который одновременно оказьявает влияние примерно па 30 продуатов, входящих в некую достаточно большую группу. Генерируемые требования воздействуют в реальном времени на программное обеспечение, которое пизн)т более 400 находящихся в разных местах программистов.

Чтобы добиться успеха в этом проекте, необходима четкая координация действий "команды команд", которая должна работать по общей методологии, чтобы решить проблему требований. Процесс управления требованиями, хотя и шьразноььу, затрагивает каждого члена команды. Успенгное управление требованиями может осуществляться только эффективно организованной командой разработчиков. Что необходимо сделать? Очевидно, необходимо заставить работать "командный фактор". Как указывал Бом (ВоеЬш, 1981) в модели оценки стоимости СОСОМО, возможности комшзды оказывают наибольшее влияние на производительность в сфере раз.

Глава 3. Команда разработчиков Ы работки программного обеспечения. Дэвис 1ьгач)г, 1995, Ь) согласился с иим и подчеркнул, что вшяи.чигаиия праизводипмгьпагпш каждого атдгльиога угаг)габатчггка ие абягапмльпа приведет к анпшмгггаигпг нртггвадителъивпаи команды (с.170). Поэтоьгу представляется логичным потратить некоторые усилия на то, чтобы повысить производительность кгь маид разработчиков программного обеспечения. Профессиональные навыки, которыми должна обладать команда для эффективноГо управления требованиями В данной книге выделяются шесть частей, соответствующих шести основным областям, профессиональными приемачи в которых необходимо овладеть современной груп.

пе разработчиков программного обеспечения, чтобы справиться с задачами управления требованиями. ° В части 1, "Лнализ проблемы", предлагается ряд методов, применяемых для достижения правильного понимания л)габггмм, решить которую призвана новая система программного обеспечения. ° В части 2, "Понимание потребностей пользователей", представлены разнообразные приемы выявления требований посредством общения с пользователями системы н другими заинтересованными лицами. Невозможно указать набор методов, подходящий для всех ситуаций, также нет необходимости применять все методы.

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

которая будет удовлетворять эти потребности. ° В части 4, "Управление масштабом", мы научим команду более успешно управлять масштабом проекта. В конце концов, насколько бы хорошо потребности не были осознаны, команда не может сделать невозможное, и нам часто придется вести переговоры о том, что считать приемлемым, прежде чем будет достигнут успех. ° В части 5, "Уточнение определения системы", описывается, как а)ггаиигавать информацию о требованиях.

Затем предлагается ряд методов утачпеиия определения системы до уровня детализации, пригодного для проведения проектирования и реализации, чтобы вся расширенная команда точно знала, какую систему она разрабатывает. ° Наконец, в части 6, "Построение правильной системы", рассматриваются некого. рые более формальные аспекты достоверности пикнического проекта, вг)гиугикаиии, гфовгрки гфавильиогпги сигггемм и уггравлеггия изменениями. Мы покажем, как можно с помощью юфассп)гапки удостоверитыя в качестве результата. 52 Введение Члены команды имеют различные профессиональные навыки Одним из наиболее важных фактов является то, что члены команды имеют различные профессиональные навыки. В конце концов, именно это делает команду командой.

Уолкер 1'ойс (ьта))гсг Воусе, 1998) отмечал следующее. Баланс и разнообразие навьтов - вот две наиболее важные составляющие отличной команды... Как в футбольной команде существует потребность в разнообразных навыках, пючно нтк зке происходит и в команде, рафабатмвающей программное обеспечение... ВРядли мозкно гфедсзтюнть себе хоРонгую фупгбольную командуя, в котоРой нет профессионалов раыичного про(биля. нападающих, защитников, тренфов, игра. ков первого состава, запасньлх, разводящих и бтущих, Хорошей команде необходимо, чтобы все ключевые позищии занималн сильные ифоки.

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

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

По. этому нам кажется важным предложить некую гипотетическую структуру команды. 11о вместо того, чтобы рассматривать идеальную команду, слишком простую и академичную, мы решили взять за образец реальную команду разраоотчиков. Прототипом комшщы, которую мы будем ьюделировать, послужила реальная команда разработчиков програмьпюго обеспечения, добившаяся успеха в двух важнейших областях: (1) управлении требованиями и (2) предоставлении программного продукта в рамках отведению го времени н бюджета. (Мы надеемся, что это очевидная причинноследственная взаимо. связь!) Безусловно, колтнда должна также облздать мпоппли другими навьтами, чтобы действительно успешно работать из года в год, В пашем рабочем примере команда работает для компании (мпзспагюпз, Елд., рззрабатывюощей "автоматизированную систему освсгцеиия жи.

лища" нового поколения для оснащения жилья самого высокого класса. г Речь идет об американском футболе. — Ирин, перев. Глава 3. Команда разработчиков 33 Рабочий пример Мы сможем попутно догтнп|утычцг одной цсли в данной кингс, осли разработаем иский рабочий примср, который сможсм нроглсдить от начала разработки трсбований до коша. таким образол| мы сможсм цс только ирнмс|нгть рассматривасмыс методы к цаюсму иримсру, цо и црсдложить образцы рабо шх продуктов (артсфакты) лля болсс полной иллюстрации основных ноложсиий.

Эти артсфакты вы можстс использовать в качсствс образцов в ваших просктах (онн содсржа гся в црнложсцин Л). Предварительная информация для рабочего примера Компания !лицсна||ош, Елг(., болсс !О лот являлась всемирно извсстцым поставщиком коммсрчсскнх освститслы|ых систем для тсатра. В 1999 году сс годовой доход соста. вил нриблнзитсльно 120 миллионов долларов, а обьсм продаж стаонлнзировалгя. 1.ц. щспацоцз — открытая комнация, и нсдостато*шын рост продаж и, |то сщс хуже, отгугствнс рсальиых прсдложсний ио сго новьнвснию оказали крайнс нсгативнос влнянис на коашанию и сс акциоисров. Последнее ежегодное собранцс акционсров оыло вссьмз нснрнятным, так как ис было сказано ничсго нового о нсрсцсктивах роста компании.