|
Книга знакомит с новым продуктом компании Microsoft, предназначенным для командной разработки ПО. Автор в живой и доступной форме рассказывает о том, как с помощью Visual Studio 2005 Team System организовать эффективный и гибкий производственный процесс, который соответствовал бы самым современным индустриальным стандартам и обеспечивал бы оптимальный баланс между скоростью разработки и качеством результата. Книга адресована всем, кто так или иначе связан с созданием программных продуктов - от рядовых программистов и тестировщиков до руководителей проектов, менеджеров по маркетингу и даже заказчиков.
Эта глава напоминает нам о том, насколько сложными могут быть наша работа и наши обязанности. Порою кажется, что, несмотря на непрерывное совершенствование компьютеров и программного обеспечения (ПО), нам все сложнее становится создавать интеллектуальные системы, работающие поверх этих низкоуровневых средств. С чем же связаны подобные затруднения? Не с тем ли, что наши возможности значительно расширились и каждый раз приходится делать выбор из множества вариантов решений? Или же мы сталкиваемся со старыми проблемами, существовавшими всегда? Как говорит один хороший консультант: ''It depends''.
Многим знакома такая ситуация. Срок сдачи проекта на носу, ведущие программисты ожесточенно спорят о чем-то с архитекторами, тестировщики скучают в ожидании дела, а рядовые программисты в спешке дописывают недостающие функции, понимая, что они все равно не отвечают требованиям. Ну а заказчики, как водится, в нетерпении обрывают телефон. Не правда ли, знакомая картина?
В наше время разработка программного обеспечения - дело не из легких. Теперь разработчик уже не может просто сгенерировать с помощью Microsoft Visual Basic исполняемый файл и скопировать его на дискету вместе с базой данных Microsoft Office Access. Современное приложение масштаба предприятия состоит из множества программных слоев и сервисов. Разработка подобного продукта требует больших усилий, а сам продукт должен отвечать более высоким стандартам, чем это требовалось еще несколько лет назад. Следует учитывать, что все больше пользователей, директоров по информационным технологиям (chief information officer, CIO) и других заинтересованных лиц читают прессу и веблоги. И пусть они не настолько технически подкованы, как разработчики, но они точно знают, чего хотят, и, что еще важнее, по всей вероятности, знают, чего не хотят: им не нужна простая пара .exe плюс .mdb.
Программное обеспечение масштаба предприятия состоит из значительно большего числа самостоятельных компонентов, чем это было лет 10-15 назад. Использование веб-архитектуры, веб-служб и XML позволяет сделать системы более гибкими, мобильными, расширяемыми и совместимыми, улучшить их потребительские качества. Все это замечательно с точки зрения архитекторов программного обеспечения, прочих лиц, заинтересованных в его успешной продаже, а также его пользователей. Но у данной медали есть и обратная сторона - усложнение процесса разработки программных продуктов. Все эти хваленые (и, по моему мнению, вполне заслуженно) сервисы, слои, версии и интерфейсы прикладного программирования (application programming interface, API), скрывающиеся за названием ''веб-сервисы на базе XML'', для команды любой численности означают только одно: бесконечные сложности с состыковкой компонентов программной системы и обеспечением их эффективного взаимодействия.
Пространственное разделение членов команды разработчиков программного обеспечения отнюдь не является препятствием для эффективной реализации проекта. Как раз наоборот. При использовании правильных методов разработки такое разделение из препятствия может превратиться в преимущество, особенно когда речь идет о создании систем масштаба предприятия. Ведь для создания и тестирования распределенных систем необходима распределенная среда, а между тем отнюдь не каждый член команды имеет доступ к локальной (LAN) или ввиртуальной частной (VPN) сети. Потому-то очень удобно, когда кто-либо из членов команды работает удаленно. В современных условиях, когда коллеги взаимодействуют с использованием средств телекоммуникации и к работе над проектами нередко привлекаются субподрядчики, вероятность наличия в команде таких людей достаточно велика.
Однако, для того чтобы члены команды могли работать удаленно, ''текущие'' между ними информационные потоки, в том числе и передаваемый по сетям программный код, должны беспрепятственно проходить через брандмауэры. Средства наподобие Microsoft Visual SourceSafe 6.0, ориентированные на применение в локальных сетях, для решения указанной задачи не подходят. Кто хоть раз пробовал пользоваться ими в описанных условиях, знает, о чем я говорю. Visual SourceSafe действует, но лишь до тех пор, пока вы не попытаетесь установить VPNподключение к его базе данных. Это хороший продукт, однако он никогда не предназначался для использования в качестве ''тонкого'' клиента при взаимодействии через порт 80 и брандмауэры.
| ПРИМЕЧАНИЕ В Visual SourceSafe 2005 появилась, наконец, возможность удаленного использования этого продукта через порт 80 и веб-сервисы HTTP. |
Вне зависимости от того, разбросаны члены вашей команды по всему земному шару, стране, городу или огромному многоэтажному зданию, обеспечить их эффективное взаимодействие непросто. Каждый член команды желает, фигурально выражаясь, ''жить в собственном доме и глядеть на проект из своего окна''. К счастью, существуют такие средства связи, как электронная почта, телефон и системы обмена мгновенными сообщениями (instant messaging, IM), - последние, к слову сказать, особенно полезны. С их помощью так удобно копировать и вставлять фрагменты кода, передавать файлы и просто быстро получать от коллег ответы на свои вопросы. Когда я только начинал изучать технологию Microsoft .NET, я часто обращался к товарищам через IM программу с простыми вопросами вроде: ''К какому пространству имен относится класс StringBuilder?'' При грамотном использовании программ обмена мгновенными сообщениями заметно повышается эффективность взаимодействия профессионалов, работающих над одним проектом и мыслящих в одном направлении. По-своему полезны и собрания по сети, телефонные конференции; прекрасным архивом для ответов на разнообразные вопросы и для ресурсов, предоставляемых разными членами команды, служит электронная почта. Однако общим недостатком всех этих форм взаимодействия является то, что разработчики вынуждены прибегать к средствам, внешним по отношению к Visual Studio, тогда как именно последняя призвана быть нашим главным инструментом разработки. Многие разработчики проводят в Visual Studio по восемь и более часов в день. Ведь покидать ее при необходимости поработать с каким-то другим средством, например Microsoft Office Outlook или пользовательским приложением типа утилиты для отслеживания ошибок, - недопустимая трата времени. Факт, что руководители и разработчики передают друг другу задания разными способами: по электронной почте, с помощью программы обмена мгновенными сообщениями, ''голосовой почтой'' или даже посредством клейких листочков на двери. На сбор и упорядочение всей этой информации расходуется ценное время.
Для решения данной проблемы Microsoft не стала встраивать в Visual Studio программу Outlook или иное коммуникационное средство. Вместо этого она разработала и интегрировала в ее IDE (integrated development environment - интегрированная среда разработки) мощный инструментарий командной работы Team System, включающий средства для отправки и получения заданий, информации об ошибках и сведений о завершенных задачах. Теперь при необходимости связаться с другими членами команды во время работы над проектом вам больше не потребуется покидать Visual Studio. Если ею пользуются все члены команды, то все они выигрывают от внедрения нового решения.
Члены любой команды разработчиков программного обеспечения применяют немало разнообразных инструментальных средств. Руководители проекта для проверки того, как соблюдаются требования к продукту, для отслеживания итераций, фаз и ключевых этапов его разработки, степени готовности отдельных компонентов используют Microsoft Office Project и Microsoft Office Excel. Архитекторам систем при разработке схем центров данных, сетей, сервисов и классов не обойтись без Microsoft Office Visio и средств сторонних производителей. Проще всего разработчикам - они реализуют все эти сервисы и классы, пользуясь только Visual Studio. Однако и разработчикам, и тестировщикам требуются дополнительные средства для выполнения различных видов тестирования продукта: модульного тестирования, анализа покрытия кода, статического анализа, нагрузочного и веб-тестирования. Если тестировщикам повезет, их инструментальные средства будут интегрироваться в Visual Studio или, по крайней мере, встраиваться в тестируемый код. В результате применения такого количества средств жесткий диск переполняется программным обеспечением различных сторонних производителей, и если на работу нанимаются новые люди, им требуется немало времени на его освоение.
Одним из потенциально слабых мест проекта, разрабатываемого в таких условиях, является отсутствие четкого руководства. И дело вовсе не в том, что руководители проекта или другие ведущие члены команды в недостаточной степени обладают организаторскими способностями и другими личностными качествами. Как раз наоборот. Но вспомните, что говорилось выше о сложности современных систем. Для правильной и эффективной сборки всех этих сервисов и иерархических программных конструкций необходима заранее выработанная схема действий. Формирование команды, определение этапов реализации проекта и состава готового продукта, собственно разработка программного обеспечения требуют особой методологии, разработанной и проверенной специалистами.
Среди разработчиков и архитекторов программного обеспечения как в Microsoft, так и вне ее я встречал немало настоящих асов. Множество таких ребят работает над проектами Microsoft Regional Director и MVP. Но ни один человек не в состоянии знать абсолютно все, хотя при наличии хорошей поисковой машины, страсти к чтению и большого количества свободного времени некоторым удается приобрести довольно внушительный объем знаний. И если среди участников вашего проекта подобного уникума нет, следует руководствоваться опытом и наработками известных экспертов в данной области. С такими ''ремнями безопасности'' можно приступать к написанию кода, будучи уверенным по крайней мере в том, что вы делаете лучшее из придуманного и опробованного до сих пор. При этом важно, чтобы схемы и правила, интегрированные в среду разработки, были гибкими и настраиваемыми - ведь вам необходима возможность объединить собственный опыт и традиции с наработками Microsoft.
| ПРИМЕЧАНИЕ В состав Microsoft входит команда, основной задачей которой является документирование и публикация лучших наработок компании. Эта команда называется Microsoft Patterns and Practices (Модели и практики Microsoft), а ее внутреннее название - PAG (Prescriptive Architecture and Guidance - предписания по архитектуре и управлению проектами). В разрабатываемой этой командой документации можно найти практические советы из любой области: данные, безопасность, конфигурирование, внедрение и т. д. Документацию можно бесплатно загрузить с сайта Microsoft, обратившись по адресу http://www.microsoft.com/patterns. |
Я уже говорил, что при использовании большого количества различных средств возникают проблемы, касающиеся взаимодействия между членами команды. Однако в этом случае приходится сталкиваться с еще одной проблемой взаимодействия - членов команды с проектом. Речь идет о том, что руководители проекта и ряд других заинтересованных лиц постоянно должны быть в курсе всех событий. До сих пор руководителям приходилось полагаться в этом отношении на Project или Excel - средства, позволяющие получать детальную и точную информацию о состоянии дел. Однако точность такой информации определяется тем, насколько аккуратно и регулярно она вводится в документы Project или Excel. Иными словами, все зависит от человеческого фактора, и может возникнуть ситуация, когда срочно нужен отчет, а соответствующие данные еще не введены. В идеале данные о проекте должны быть доступны его руководителям в реальном времени, без дополнительного этапа их подготовки. К числу таких данных относятся сведения о незавершенных и завершенных заданиях, отладке программного кода, эффективности работы команды и обнаруженных ошибках. Они должны быть доступны с удаленных компьютеров и представлены в такой форме, чтобы их можно было просматривать с помощью простейших средств, например браузера.
Очевидно, что далеко не все проблемы разработчиков программного обеспечения решаются с помощью подходящих инструментальных средств и эффективных стратегий. Сколь бы совершенным ни был инструментарий, в проекте все равно будут встречаться сложные места, а вам придется работать в условиях ограниченного бюджета и жестких временных рамок - устранить эти трудности не помогут ни Team System, ни данная книга. Можно лишь попытаться улучшить взаимодействие между людьми, так или иначе причастными к работе над проектом, причем не только в техническом, но и в психологическом, и даже, если хотите, философском отношении.
Ну а теперь вернемся к проблемам, решению которых посвящена оставшаяся часть этой книги. Мы только что их перечислили: неэффективное взаимодействие членов команды, сложности удаленного сотрудничества, плохо интегрированные друг с другом инструментальные средства, отсутствие единой, заранее определенной, стратегии и недостаток актуальной информации о состоянии проекта. Наилучшие шансы на успех обеспечивают такие простые принципы, как адекватное планирование, хорошая конструкторская работа, выбор лучших стратегий разработки и тестирования, эффективное взаимодействие. При подобных условиях хорошо бы иметь средство, помогающее обеспечить соблюдение этих правил и естественным образом интегрирующееся в привычную среду разработки, которой вы пользуетесь от 8 до 18 часов в сутки. Такое средство существует, и называется оно Visual Studio 2005 Team System.
Задумав Visual Studio 2005 Team System, Microsoft совершила нечто уникальное: она ''отступила назад'' и исследовала способы успешной, а также и неудачной разработки программного обеспечения, после чего создала продукт, заметно повышающий предсказуемость успеха проекта. От начала и до конца вашей работы Team System будет координировать ее и управлять ею, направляя к единственной цели. Выпустив Team System, Microsoft кардинально изменила наши представления о Visual Studio. Никогда эта система уже не будет просто хорошей средой разработки - теперь это мощное средство, объединяющее всю команду вокруг единого решения на протяжении всего времени его воплощения в жизнь.
Основу Team System составляет тот же набор средств, которым пользуются в Microsoft для успешного планирования и разработки ее собственного программного обеспечения и внедрения его у таких пользователей, как мы с вами. И хотя ваша компания, скорее всего, не является корпорацией-мультимиллиардером, в Microsoft понимают, что все команды разработчиков сталкиваются, по сути, с одними и теми же проблемами. Специалисты корпорации ''отполировали'' собственный инструментарий, чтобы сделать его пригодным для продажи, поделились с вами своим опытом и своими лучшими стратегиями.
Итак, разработчики Visual Studio 2005 Team System ставили перед собой следующие фундаментальные цели:
Последняя цель предполагает обеспечение возможности для сторонних компаний создавать надстройки для Team System. Если вашей команде придется использовать альтернативные методы разработки или же альтернативные средства проектирования, управления исходным кодом и тестирования, вы без труда сможете интегрировать их с Team System. Кроме того, данная цель отражает обязательства Microsoft перед ее партнерами и сообществами разработчиков, подобные тем, что задекларированы сегодня в программах ISV (Independent Software Vendor - независимый продавец программного обеспечения) и VSIP (Visual Studio Integrator Program - программа интегратора Visual Studio).
| ПРИМЕЧАНИЕ В главе 9 описывается ряд способов настройки и расширения Team System, в том числе коррекции инструкций и шаблонов. |
Управление проектом и методика разработки
Хорошо ли иметь средство, диктующее вам методику разработки программного обеспечения? Многие специалисты, с которыми мне приходилось говорить на эту тему, считали, что Microsoft должна воздержаться от разработки средств, определяющих ''как делать программное обеспечение'', и ограничиться инструментами его создания. Во многом я с ними согласен - люди не любят, когда им навязывают какие бы то ни было методы или правила. И Microsoft учла данный факт при разработке Team System. Возвращаясь к вопросу о расширяемости, я должен сказать, что Team System настраиваема и расширяема настолько, насколько это вообще возможно. Если задаваемые данным средством вопросы относительно управления проектом и методов разработки вас не устраивают, их можно изменить. Если правила контроля версий слишком строги для вас или, напротив, недостаточно строги, их можно изменить. И если количество и типы задач, предлагаемых системой членам команды, вызывают протесты и нарекания, вы опятьтаки можете все изменить.
Я много лет обучал команды разработчиков проектированию и созданию программного обеспечения и должен сказать, что это самые требовательные, разборчивые и критически настроенные группы профессионалов на свете. Они точно знают, чего хотят. Более того, они точно знают, чего не хотят. Эти люди не желают иметь дела с инструментами, получать инструкции и советы, которые хоть каким-то образом ограничивают их действия. Они не признают никаких новых методик, так как слишком много перевидали их на своем веку, встречаемых поначалу с энтузиазмом и уходящих вскоре в небытие. Этим спецам подавай нечто простое и ясное, гарантированно и сразу повышающее производительность. Еще лучше, если новое средство будет генерировать код. Вот из таких людей состоит Microsoft, и они с самого начала знали, что Team System ожидает успех лишь в том случае, если она будет расширяемой.
Предлагаю ненадолго остановиться и обсудить один важный вопрос. Думаю, многие со мной согласятся, что наличие методики очень важно для любого дела. Например, если вы записываете на клейких листочках задачи на день, отмечая их приоритеты разными цветами, клеите листочки на стену и удаляете по мере выполнения, то можно сказать, что у вас есть определенная методика. Правда, термин ''методика'' не совсем конкретен. Под ним часто понимают просто наличие определенного подхода к решению некоторой задачи. Существуют популярные, детально проработанные методики, и существуют другие, нечеткие или малоизвестные. Данный вопрос занимает меня в течение многих лет, поскольку он связан одновременно с гибкими организационными и жесткими техническими средствами.
| ПРИМЕЧАНИЕ Team System сама по себе не является методикой, воплощенной в программном продукте. Это просто инструмент, обеспечивающий управление разработкой и упорядочение доступа к элементам, над которыми вы трудитесь. Он помогает придерживаться любой выбранной вами же методики. Со своей стороны позволю себе полушутливое предостережение: в похвальном стремлении к формализации и упорядочению своей работы важно не переборщить, иначе однажды вы обнаружите, что нуждаетесь в методике для использования выбранной вами методики. |
Мы рассмотрим несколько наиболее популярных методик, включая две методики из описанного в следующем разделе технологического пакета Microsoft Solutions Framework, которые реализованы в составе Team System.
| ПРИМЕЧАНИЕ Подробнее о методиках Microsoft Solutions Framework рассказывается в главе 8. |
Microsoft Solutions Framework
MSF (Microsoft Solutions Framework - комплекс решений Microsoft) - это система стратегий, принципов и проверенных методик, позволяющих достичь успеха в создании программного обеспечения и охватывающих весь жизненный цикл процесса его разработки (software development life cycle, SDLC). В основу MSF положены лучшие достижения программной индустрии. Впервые опубликованный в 1994 году, этот документ стал квинтэссенцией 25летнего опыта разработчиков, выраженного в различных руководствах, которые используются как в компании Microsoft, так и в других компаниях, занимающихся созданием программного обеспечения.
С годами документация MSF менялась, адаптируясь к новым потребностям разработчиков. MSF версии 4.0, поставляемая в комплекте с Team System, выпускается в двух вариантах, представляющих два подхода к разработке программного обеспечения: MSF for Agile Software Development (MSF для гибкой разработки ПО) и MSF for CMMI Process Improvement (MSF для усовершенствования процессов CMMI). MSF for Agile Software Development предназначена для команд, привыкших к быстрой работе в постоянно изменяющихся условиях и в тесном контакте с заказчиком. А MSF for CMMI Process Improvement ориентирована на большие и сложные проекты с многоуровневой отчетностью, когда долгосрочное планирование и эффективное взаимодействие внутри команды разработчиков важнее быстрого исполнения и постоянной двусторонней связи с заказчиками.
MSF for Agile Software Development
Модель процесса MSF for Agile Software Development, который мы далее будем называть гибким процессом (agile process), относительно нова. Она предназначается для небольших компаний с командами разработчиков из 5-20 человек. Была ли данная модель специально разработана для Team System? Пожалуй. Была ли Team System разработана с целью воплощения модели MSF for Agile Software Development? Можно сказать и так. Интеграция процесса и средства - вещь совершенно естественная.
По официальным сведениям, модель гибкого процесса была создана совещательным органом, известным как Agile Alliance. Вот положения, по которым члены этого альянса достигли соглашения:
Основная задача гибкого процесса заключается в предоставлении пользователю согласованного и качественного программного обеспечения. Времена, когда разработка формальных спецификаций была одним из ключевых этапов проекта, ушли в прошлое. Воплощая в своем продукте модель MSF for Agile Software Development, Microsoft демонстрирует понимание того факта, что быстрое составление жесткой спецификации и передача ее разработчикам для реализации часто означают провал проекта.
Модель MSF for Agile Software Development используется в Team System по умолчанию. Придерживаясь ее, вы почувствуете, насколько более тесной станет ваша связь с заказчиками и коллегами. Стандартные артефакты этой модели, к числу которых относятся задачи и ошибки, интуитивно понятны всем разработчикам, использующим Visual Studio.
MSF for CMMI Process Improvement
Напомню, что аббревиатура CMMI в данном названии расшифровывается как Capability Maturity Model Integration - интегрированная возможностнозрелостная модель. Задачей ее разработчиков было создание модели для компаний с непрерывными бизнеспроцессами, которая позволила бы сократить время разработки ПО, добиться максимального соответствия процессов стоимостным и временным требованиям, а также повысить качество программных продуктов. Модель CMMI разработана Институтом программной инженерии Университета КарнегиМеллона (Software Engineering Institute of Carnegie Mellon University) и представляет собой набор формальных методик для произвольных бизнеспроцессов.
Одним из важных достоинств CMMI является то, что это не только модель, но и оценочный стандарт, позволяющий сравнивать возможности компаний, занимающихся разработкой программного обеспечения. Например, Минобороны США и другие крупные потребители программных продуктов часто интересуются индексом CMMI разработчиков и поставщиков ПО, чтобы сделать оптимальный выбор исполнителя очередного заказа.
В Team System реализована часть CMMI, применимая к программной инженерии. Это превосходная модель процесса для тех компаний, которые стремятся достичь определенного уровня эффективности разработки программного обеспечения. Она требует заполнения значительно большего числа документов о состоянии и более детальной отчетности, чем MSF Agile, но при таком более формализованном подходе снижаются риски больших проектов и закладываются основы для получения в будущем сертификатов различных уровней CMMI либо ISO 9000/9001.
eXtreme Programming
eXtreme Programming (XP, экстремальное программирование) - это еще одна гибкая методика разработки программного обеспечения, позволяющая команде (разработчикам, пользователям и руководителям проекта) быстро адаптировать продукт к изменяющимся требованиям. Выше уже упоминалось о том, что постоянное и весьма значительное изменение требований к продукту в процессе его разработки в наше время отнюдь не редкость. Поэтому в XP предполагается, что меняться может буквально все, в том числе состав команд пользователей и разработчиков, а также бизнессреда. Метод водопада и некоторые другие жесткие методы разработки, как известно, не предназначены для быстрой адаптации к изменениям, особенно на поздних стадиях цикла. В то же время XP не только обеспечивает проекту необходимую гибкость, но и позволяет весьма элегантно вносить изменения. Вместо того чтобы пытаться их контролировать, как это было принято раньше, команда, действующая по методике XP, быстро к ним адаптируется.
| ПРИМЕЧАНИЕ В проекте разработки программного обеспечения ничто не стоит на месте. Меняются требования, проектная документация, технологии, состав команды и даже ее члены. Но изменения сами по себе не представляют проблемы, они неизбежны; проблема заключается лишь в нашей неспособности к ним адаптироваться - так писал Кент Бэк в своей книге ''Суть экстремального программирования''. |
Методика XP имеет множество достоинств.
| ПРИМЕЧАНИЕ Выше приведены лишь общие положения XP-подхода. Но он подробно описан во многих замечательных книгах, имеющихся сейчас на рынке. |
Scrum
Так называется гибкая методика разработки, в основе которой лежит принцип инкрементального выпуска продукта. Согласно этой методике, процесс разработки представляет собой серию коротких циклов. Продукт создается небольшой командой, в обязанности одного из членов которой входит помогать команде правильно распределять силы и расставлять приоритеты, а следовательно, работать максимально продуктивно. Рассмотрим эту методику подробнее.
Проект типа scrum разбивается на несколько спринтэтапов - четко определенных циклов длительностью от четырех до шести недель. По завершении стадии начального планирования разработчики и пользователи совместно определяют компоненты продукта, которые должны быть реализованы в течение первого спринтэтапа. Затем эти компоненты реализуются, причем команда концентрируется исключительно на них, временно ''забывая'' об остальных задачах. Незначительная продолжительность спринтэтапа (она не превышает нескольких недель) создает впечатление мгновенности, что положительно сказывается на мотивации команды. Каждый спринтэтап завершается его ретроспективным анализом: члены команды делятся мнением относительно того, что сделано хорошо, а что плохо, и договариваются, какие изменения следует внести на следующем спринтэтапе. Этапы следуют один за другим, без перерывов, вплоть до завершения проекта.
Главным в команде является scrumмастер, человек, чья основная и зачастую единственная обязанность заключается в том, чтобы привести команду к успешному результату. Мастер ежедневно проводит короткое совещание-летучку, в котором принимают участие все члены команды. На повестке дня всегда одни и те же три простых вопроса к каждому:
Любые возникающие при этом дискуссии откладываются до очередного настоящего совещания, в котором будут принимать участие нужные люди. Таким образом, летучки всегда проходят очень быстро и приносят пользу всем участникам.
Scrumмастер отвечает за устранение препятствий, о которых говорилось на летучке. Эта его функция, зачастую не предусмотренная порядком работы в командах других типов, играет ключевую роль в scrumпроцессе. Различного рода затруднения, от аппаратных проблем до нерешенных вопросов, затронутых на предыдущей летучке, могут значительно задерживать разработку. Но когда за их устранение отвечает конкретный человек, остальные могут полностью сконцентрироваться на своих основных задачах.
Выполнение положений этой простой методики позволяет членам команды разработчиков программного обеспечения достичь значительного повышения производительности труда и улучить психологический климат в своем коллективе.
| ПРИМЕЧАНИЕ Слово scrum является сокращенным вариантом термина scrimmage, что в переводе с английского означает ''драка за мяч'' (этот термин используется в регби). |
Сколь бы замечательной ни была ваша методика в теории, наступает момент, когда нужно спустить ее на землю и заставить работать. И вот здесь на сцену выходит Team System - продукт, в котором процесс (process) определяется как набор простых и составных действий. Такая модель прекрасно подходит для реализации большинства методик.
В Team System поддерживаются следующие элементы MSF for Agile Software Development: роли, рабочие элементы, задачи и рабочие потоки. В частности, определены роли (role) бизнесаналитика, руководителя проекта, программного архитектора, разработчика, тестировщика и руководителя выпуска. Рабочими элементами (work item) являются различные сценарии, требования к качеству, риски, задачи и ошибки. Все рабочие элементы могут быть связаны с артефактами (artifacts), такими как документы, электронные таблицы, проектные планы, исходный код и другие материальные результаты действий. Рабочие элементы создаются по завершении тех или иных действий. Кроме того, они могут служить предпосылками к совершению действий. Действиями (activity) называют работы, выполняемые совместно с одной целью. При осуществлении действий могут использоваться либо производиться продукты труда. Действия можно отслеживать с применением рабочих элементов. Объединяясь в группы, действия образуют рабочие потоки (work stream) - действия, состоящие из других действий. Рабочие потоки являются строительными блоками процессов; их можно назначать одной или нескольким ролям.
Сценарий
Сценарий (scenario) - это один из видов рабочих элементов, содержащий описание конкретной последовательности действий пользователя в системе, предпринимаемых им для достижения определенной цели. Причем сценарий может описывать как успешную, так и неудавшуюся попытку достижения этой цели. От человека, пишущего сценарий, требуется максимальная конкретность. Кроме того, поскольку число возможных сценариев для любой нетривиальной системы бесконечно, важно правильно выбрать, какие из них заслуживают описания.
| ПРИМЕЧАНИЕ Сценарий часто сравнивают с вариантом использования (use case) из UML (Unified Modeling Language - унифицированный язык моделирования). |
Требования к качеству
Требованиями к качеству (quality of service, QoS) определяются такие характеристики системы, как производительность (performance), нагрузочная способность (loadability), устойчивость к перегрузкам (stressability), наличие и доступность функций (availability, accessibility), удобство эксплуатации (serviceability) и простота обслуживания (maintainability). Эти требования обычно принимают форму функциональных ограничений системы.
| ПРИМЕЧАНИЕ Требования к качеству - это не то же самое, что функциональные требования. |
Задача
Рабочий элемент задача (task) указывает на необходимость выполнить определенные действия. Например, разработчик использует задачи для назначения задания, описанного сценарием или требованиями к качеству, тестировщик - для назначения задания по подготовке и выполнению тестов. Посредством задачи подается сигнал к выполнению очередного цикла регрессионного или приемочного тестирования. Наконец, задача может использоваться для назначения любой работы в рамках проекта. В форме рабочего элемента ''задача'' некоторые поля заполняются только в тех случаях, когда задача относится к определенной роли.
Риск
Важным аспектом управления проектом является идентификация рисков и их минимизация. Риском (risk) называют любое вероятное событие или условие, которое может негативно сказаться на проекте в будущем. Рабочий элемент ''риск''> содержит информацию о технических и организационных рисках проектов: описания потенциальных проблем и данные об отслеживании соответствующих им событий. Когда в связи с некоей потенциальной угрозой требуется предпринять конкретное действие, на основе рабочего элемента ''риск'' создается задача по ее уменьшению. Например, при наличии технического риска могут быть предприняты шаги по созданию архитектурного прототипа. Идентификация рисков всегда должна рассматриваться командой как позитивный процесс, и ее членам следует прилагать максимум усилий для их выявления. Общий настрой и отношение к этой задаче должны способствовать тому, чтобы каждый, кто может сообщить о риске, делал это свободно, не опасаясь неодобрения или иронических замечаний со стороны коллег, даже в том случае, когда его мнение расходится с мнением большинства. Команды, в которых царит именно такая атмосфера, выявляют и нейтрализуют риски более успешно и на более ранних стадиях разработки.
Ошибка
Ошибкой (bug) называется рабочий элемент, несущий информацию о наличии в системе потенциальной проблемы. Задача человека, создающего такой элемент, - аккуратно задокументировать сведения о проблеме, чтобы те, кому полагается ее анализировать и решать, поняли ее суть и возможные последствия. В частности, в отчете о проблеме должна быть указана последовательность действий, которые привели к обнаружению ошибки, - благодаря этому ее можно будет легко воспроизвести. От того, насколько четким, понятным и исчерпывающим является описание проблемы, зависит вероятность исправления ошибки.
Как уже было сказано, Team System не является универсальным методическим инструментом. Эта система обеспечивает поддержку бизнеспроцессов только для команды разработчиков, она не содержит средств для планирования совещаний, подготовки бюджетов, отправки электронной почты или непосредственного взаимодействия с пользователями и прочими заинтересованными лицами. Если пользователи являются сотрудниками вашей же компании, пусть даже из другого отдела или подразделения, без указанных функций вполне можно обойтись. Но независимому производителю программного обеспечения они просто необходимы.
Team System выполняет много полезной работы: организует рабочие элементы проекта, ожидания и задачи для совместного исполнения. Однако для реализации методики попрежнему нужны реальные люди и реальные встречи, а управление контактами не входит в функции Team System.
Team System - это не просто особая версия Visual Studio, а целая серия версий ролевой ориентации - в каждой из них реализована определенная роль. Данный продукт не предназначен для профессионаловодиночек или независимых консультантов, он ценен в первую очередь тем, что может использоваться для коллективной работы, например командами, в которых имеются роли руководителя проекта, архитектора, разработчика и тестировщика. Но если вы, работая в одиночку, по образному английскому выражению, ''носите все эти шляпы'', в таком случае Team System может пригодиться и вам.
| ПРИМЕЧАНИЕ Team System оптимизирована для работы команд, насчитывающих от 5 до 500 членов. |
Это издание предназначено для архитекторов инфраструктуры и приложений. К их числу относятся лица, называемые проектировщиками распределенных приложений (distributed application designer) и проектировщиками архитектуры, ориентированной на сервисы (serviceoriented architecture designer, SOA designer).
Работа архитекторов, в ее внешнем проявлении, заключается в составлении диаграмм, представляющих логические центры данных, приложения, прикладные системы и схемы развертывания готовых продуктов. При этом архитектор пользуется такими базовыми операциями, как перетаскивание и связывание, давно и широко применяемыми в Visual Studio. Диаграммы - это не просто аккуратненькие картинки, они обладают определенной интеллектуальностью и содержат метаданные, которые можно проверять на соответствие стандартным и пользовательским ограничениям, а затем одним щелчком мыши превращать в программный код. Microsoft хранит всю заложенную в диаграмме информацию в особых SDMфайлах (System Definition Model - модель определения системы), реализуя стратегию DSI (Dynamic Systems Initiative - инициатива в области динамических систем).
| ПРИМЕЧАНИЕ Подробнее о Visual Studio 2005 Team Edition for Software Architects рассказывается в главе 5. |
Данное издание предназначено для разработчиков и программистов. Пожалуй, оно является наиболее востребованным из всех изданий Team System. В дополнение к базовым функциям Visual Studio 2005 разработчики получают статический анализатор кода (подобный FxCop), средство модульного тестирования (подобное NUnit) и средство анализа покрытия кода и профилирования системы. Некоторые из перечисленных компонентов входят также в состав Visual Studio 2005 Team Edition for Software Testers. В Microsoft понимают, что полностью разделить роли разработчика и тестировщика невозможно, что указанными средствами может пользоваться и тот и другой, поэтому данные средства включены в оба издания.
| ПРИМЕЧАНИЕ Подробнее о Team Edition for Software Developers рассказывается в главе 6. |
Это издание предназначено как для разработчиков, так и для тестировщиков программного обеспечения. Оно содержит все, что необходимо для тщательного и всестороннего тестирования продукта, в том числе для анализа покрытия кода, тестирования качества продукта и его нагрузочного тестирования. К вашим услугам функции Web Testing (функция веб-тестирования, похожая на Application Center Test), Unit Testing (модульное тестирование), Code Coverage (анализ покрытия кода) и средства управления тестированием, позволяющие составлять тесты, выполнять их и централизованно отслеживать данный процесс. Кроме того, имеется возможность подключать любые тесты, созданные вручную. Некоторые из перечисленных функций предусмотрены и в Team Edition for Developers.
| ПРИМЕЧАНИЕ Подробнее о Team Edition for Software Testers рассказывается в главе 7. |
Это издание Visual Studio содержит базы данных и веб-сервисы, позволяющие членам команды плодотворно сотрудничать, совместно используя рабочие элементы, исходный код, сборки и другие артефакты. Если вы намерены применять Team System для командной работы, все эти элементы вам обязательно понадобятся. Team Foundation Server - не просто еще одно издание Visual Studio 2005 Team System. Это движущий механизм процесса разработки программного обеспечения.
В состав Team Foundation Server входит независимый клиент Team Explorer - облегченный вариант Visual Studio 2005. Он является альтернативой Excel, Project и различным выпускам Visual Studio в части создания рабочих элементов и управления ими. Данная программа предназначена для ''временно заинтересованного лица'' - члена команды, проверяющего документацию, управляющего графикой для веб-проекта и т. п.
| ПРИМЕЧАНИЕ Подробнее о Team Foundation Server рассказывается в главе 2, а о различных его клиентах вы узнаете из главы 3. |
Visual Studio 2005 Team Suite
Для членов команды, выполняющих в ней более одной роли, или же для консультантов, способных выполнять любые роли, предназначен продукт Team Suite. Microsoft включила в его состав все три ролевых издания Visual Studio 2005 Team System - архитектора, разработчика и тестировщика.
| ПРИМЕЧАНИЕ После выпуска Visual Studio 2005 Microsoft перестанет предлагать своим пользователям MSDN Universal и MSDN Enterprise. Подписчикам MSDN Universal будет предложено бесплатное обновление до MSDN Premium Subscription, а также, по их выбору, Visual Studio 2005 Team Edition for Software Architects, Visual Studio 2005 Team Edition for Software Developers или Visual Studio 2005 Team Edition for Software Testers. Тем подписчикам MSDN Universal, которые захотят получить все ролевые издания Visual Studio 2005 Team System, будет предложен пакет Visual Studio 2005 Team Suite по специальной цене. Последнюю информацию по данному вопросу вы найдете на веб-сайте Team System в MSDN. |
Следует запомнить, что под ролью не обязательно подразумевается конкретный человек, который выполняет только ее. На самом деле едва ли хоть одна реальная команда в точности соответствует ролевой модели Team System, с полным охватом ролей и без их пересечения. Вспомните, что говорилось ранее о гибкости Team System. В этой системе определены следующие четыре роли:
Если вы - человек творческий, то легко можете придумать еще несколько полезных ролей. Например, роль архитектора можно разделить на две:
Еще одна роль, поддерживаемая Team System, а именно ИТспециалист (IT Pro), предполагает наличие в команде людей, которые будут развертывать готовый продукт на площадке заказчика. С учетом этого вы можете предложить еще несколько производных ролей:
Team System входит не во все издания Visual Studio 2005. Для новичков, любителей, студентов и профессиональных разработчиков предлагаются издания Visual Studio классов Express, Standard и Professional:
Все издания, которые включают Team System, основаны на Visual Studio 2005 Professional Edition.
Продукты семейства Visual Studio 2005 Express Edition рассчитаны в первую очередь на детей, любителей, студентов, новичков и прочих энтузиастовнепрофессионалов. Вы можете выбирать между Microsoft Visual C# Express, Visual Basic Express, Visual C++, Visual J# и Web Developer Express. Expressиздания доступны практически каждому, цель их выпуска - популяризация Visual Studio 2005.
Подобно изданиям Standard предыдущих версий Visual Studio, это издание начального уровня предназначено для тех, кто собирается всерьез заниматься разработкой приложений. Оно адресовано веб-профессионалам, разработчикам приложений Visual Basic 6.0, а также людям, желающим создавать независимые приложения на Visual Basic .NET или C#, несмотря на то что программирование не является их основным занятием.
Это издание, опятьтаки подобно изданиям Professional предыдущих версий Visual Studio, предназначено для серьезных разработчиков, пользующихся данным продуктом. Оно адресовано консультантам, профессионаламодиночкам, а также тем, кто работает маленькими командами, не применяя средств Team System. В состав Professional, в отличие от издания Standard, входят инструменты, предназначенные для создания распределенных приложений.
Team System состоит из множества компонентов. Клиентские издания данного продукта представляют собой просто надстройки для Visual Studio 2005 Professional Edition. Что касается Team Foundation Server, то это целая сервисная архитектура.
Ниже перечислены некоторые другие продукты Microsoft и указано, как они интегрируются с Team System.
| ПРИМЕЧАНИЕ Вскоре после выпуска Visual Studio 2005 Microsoft планирует выпустить надстройку MSSCCI (Microsoft Source Code Control Interface - интерфейс Microsoft для управления исходным кодом). Она обеспечит базовую интеграцию функций управления исходным кодом нового компонента Team Foundation Version Control и предыдущих версий Visual Studio. До этого времени, равно как и в случае применения ряда программных пакетов и платформ, для расширения функций управления исходным кодом и интеграции с другими средами разработки можно пользоваться любыми API и утилитами с интерфейсом командной строки. |
В дополнение к перечисленным средствам Microsoft и ее партнеры анонсировали выпуск множества интегрированных инструментов и сервисов Team System. Microsoft планирует включить в состав продукта миграционные утилиты для Microsoft Visual SourceSafe, а ее партнеры обещают поддержку дополнительных средств моделирования, сбора требований и тестирования.
Team System создана компанией Microsoft, которая кое-что понимает в проектировании, разработке и реализации крупномасштабных программных продуктов. Используя Team System для разработки собственных сервисноориентированных решений, вы сможете повысить предсказуемость успеха проекта, чему в немалой степени способствуют оптимизация процесса взаимодействия членов команды и рост производительности их труда за счет использования интегрированных средств, независимо от того, работает команда в локальной сети или в распределенной системе, разбросанной по всему миру. Вы получите готовую методику и соответствующие средства управления, а также возможность настраивать и расширять Team System многими способами.
Версия для печати