Учебник. Московский финансовопромышленный университет Синергия Кафедра Системного программирования
 Скачать 3.83 Mb.
|
|
Московский финансово-промышленный университет «Синергия» Кафедра Системного программирования Нестеров И.А. Handbook по дисциплине «Коллективная разработка приложений» Москва 2011 2 Содержание Тема 1. Гибкая методология разработки программного обеспечения ........................... 3 Вопрос 1. Общие определения. ...................................................................................... 3 Вопрос 2. Начало работы. ............................................................................................. 14 Тема 2. Роли ....................................................................................................................... 17 Вопрос 1. Бизнес-аналитик. .......................................................................................... 17 Вопрос 2. Менеджер проекта. ....................................................................................... 18 Вопрос 3. Архитектор. ................................................................................................... 19 Вопрос 4. Разработчик. .................................................................................................. 20 Вопрос 5. Тестировщик. ................................................................................................ 22 Вопрос 6. Релиз-менеджер. ........................................................................................... 23 Вопрос 7. Администратор баз данных. ........................................................................ 23 Вопрос 8. Разработчик баз данных. ............................................................................. 24 Тема 3. Действия ................................................................................................................ 25 Вопрос 1. Контроль итерации. ...................................................................................... 25 Вопрос 2. Планирование итерации. ............................................................................. 27 Вопрос 3. Разработка архитектуры решения. ............................................................. 34 Вопрос 4. Формулирование концепции проекта. ....................................................... 39 Вопрос 5. Разработка требований к качеству.............................................................. 41 Тема 4. Знакомство с Team Environment ......................................................................... 44 Вопрос 1. Логическая организация работы в Team Foundation Server. .................... 44 Вопрос 2. Физические среды разработки и тестирования. ........................................ 47 Вопрос 3. Архитектура Team Foundation Server. ........................................................ 49 Вопрос 4. Топология развертывания. .......................................................................... 52 Вопрос 5. Стратегии структурирования решения и проекта. .................................... 54 Тема 5. Шаблоны процессов ............................................................................................ 61 Тема 6. SharePoint .............................................................................................................. 76 Тема 7. Администрирование служб SharePoint и веб-узлов .......................................... 96 3 Тема 1. Гибкая методология разработки программного обеспечения Вопросы темы: 1 Общие определения. 2 Начало работы. Вопрос 1. Общие определения. В гибкой методологии MSF разработки ПО все лица, участвующие в производстве, использовании и сопровождении продукта, обладают равными полномочиями. Участники команды имеют разные роли, связанные с их функциями, при этом ни одна из ролей не считается важнее другой: такое деление гарантирует реализацию качественного решения. Члены команды могут выступать в одной или нескольких ролях. Действия и операции Роли выполняют операции (activity), которые могут быть сгруппированы в действия (workstream). Другими словами, действие – это набор операций. Операции приводят к возникновению конечных продуктов и могут требовать для своего выполнения конечные продукты как результаты предыдущих операций. Конечные продукты Конечные продукты (deliverables) – это документы, электронные таблицы, проектные планы, исходные тексты программ и другие результаты операций. 4 Циклы и итерации С помощью циклов описывается периодичность выполнения различных действий, а также частота выпуска и обновления конечных продуктов. Выполнение проектов и входящих в них задач производится циклично. Тесная интеграция гибкой методологии MSF разработки ПО с Visual Studio Team System обеспечивает ускоренную итеративную разработку с постоянным уточнением деталей и совершенствованием конечного продукта. Определение требований к продукту, разработка и тестирование – это перекрывающиеся между собой, повторяющиеся действия, ведущие к постепенному завершению проекта. Вклад тех или иных итераций в завершение проекта различен. Например, короткие итерации позволяют снизить погрешность предварительных оценок и предоставляют оперативные сводки о точности проектных планов. В результате каждой итерации должна появляться стабильно работающая часть системы. 5 Качество Качество работ является одним из основополагающих принципов в гибкой методологии MSF разработки ПО. Все участники проекта должны осознавать важность качественной работы и руководствоваться этим принципом при проектировании, реализации, тестировании и внедрении системы. Особое внимание следует уделять качеству в таких областях, как безопасность, производительность и интерфейс пользователя. Треки служат для группировки операций, завершающихся контрольными точками, то есть имеющих определенный бюджет и график. Треки не всегда связаны с задачами или работами, выполняемыми в циклах. Треки могут накладываться друг на друга, а между операциями, выполняемыми в разных треках, происходит постоянный обмен информацией. Дисциплины Дисциплины – это относящиеся к проекту в целом треки, в которых задействованы все участники команды. Руководство Руководство (governance) – это контроль бюджета и графика выполнения проекта в привязке к текущим результатам. В гибкой методологии MSF разработки ПО определены пять контрольных точек руководства, в каждой из которых дается ответ на определенный вопрос. Не следует путать треки руководства с упорядочиванием работ посредством их группирования в итерации с циклами внутри. 6 Описатели Описатель (work item) – это запись в базе данных, которая используется в Visual Studio Team Foundation для отслеживания назначения определенной операции или действия исполнителям, а также для мониторинга состояния этого задания. В гибкой методологии MSF разработки ПО определены пять типов описателей для назначения и отслеживания работ. Данные, хранящиеся в общей базе данных описателей и в хранилище показателей, позволяют в реальном времени отслеживать состояние проекта. Описатели характеризуются состоянием (state), например состояния «новый дефект» и «закрытый дефект». При переходе (transition) из одного состояния в другое требуется основание (reason): например, от состояния «новый дефект» сразу к состоянию «закрытый дефект» на основании того, что это дубликат уже существующего дефекта. 7 Аспекты Методология MSF – больше чем набор правил, которым вы должны слепо следовать. Она призвана привить культуру, способствующую реализации успешных проектов. Аспект – это совокупность показателей, определяющая, как отдельный участник проекта оценивает ту или иную ситуацию и реагирует на нее. Участники проекта от его начала до завершения должны принимать во внимание аспекты при принятии решений, расстановке приоритетов, представлении своих интересов и при взаимодействии с другими участниками команды и прочими заинтересованными лицами. В MSF представлено девять аспектов. Понимание практической ценности Первый аспект акцентирует внимание участников проекта на его практических результатах. Каждая программная система создается с конкретной целью: например, для решения некоторой проблемы в бизнесе. При построении программных систем, особенно крупных, они испытывают на себе множество воздействий, часть из которых требует в ответ приложения значительных усилий. В конечном же счете программный проект оценивается по его полезности для бизнеса. Каждый участник должен всегда помнить о практических результатах и должен быть нацелен на их достижение. Представление интересов С программными проектами обычно связаны многие заинтересованные лица со своими интересами: например, заказчикам нужна хорошо работающая система. Можно также представить неодушевленные «заинтересованные лица», например саму разрабатываемую систему. Система может быть рассчитана на работу в течение тридцати лет, а может использоваться только тридцать минут. Системы, рассчитанные на длительное использование, разрабатываются дольше. Каждая из заинтересованных сторон (будь то люди или нет) в проекте должна быть представлена защитником своих интересов. Каждому участнику проекта важно понимать, чьи интересы он представляет. Следует помнить, что модель представления интересов – это совокупность ограничений, поэтому для получения оптимальных результатов зачастую неизбежны компромиссы. 8 Гордость за участие в проекте Чувство гордости за участие в проекте – важный фактор для получения качественного продукта. Из чувства гордости вырастает мотивация и ответственность за выполнение проекта. Разработка ПО сродни искусству, и качественные системы – любимые детища их создателей. Комфортные условия труда, доверие, возможности роста, мотивированные, профессиональные люди – все это составляющие, необходимые для создания качественного ПО. Поддержание чувства гордости за участие в проекте – задача и участников проекта, и организации. Применяйте определение общих затрат в проекте по принципу «от частного к общему», дайте проекту кодовое имя и четко идентифицируйте команду проекта – это поможет поддерживать чувство гордости. В MSF представители всех ролей ответственны за создание продукта самого высокого качества. Своевременное выполнение своих обязанностей Многие задачи при разработке ПО связаны между собой. Бывают моменты, когда мы не можем выполнить свою работу самостоятельно, без участия коллег. Для эффективной работы нужно своевременно решать задачи, от которых зависит деятельность других участников проекта, и держать их в курсе текущего состояния дел. Вы должны быть надежным и заслуживающим доверия партнером для своих коллег. Видение системы в целом При работе над конкретной частью системы есть риск «не увидеть за деревьями леса». Важно не только представлять свой отрезок работы, но и понимать, как ваша деятельность отражается на конечном продукте. Надо уделять больше внимания итогу, а не процессу. Это не значит, что процесс плох или не важен: процесс не самоцель, а средство достижения конечного результата. Нужно четко понимать, зачем вы выполняете то или иное действие и как результаты вашей работы интегрируются в общее решение. Думайте о том, что нужно для реализации системы, не вдаваясь в мелкие детали. Регулярно – не только во время плановых встреч – общайтесь с другими участниками команды. Равнозначность участников Аспект равнозначности участников команды означает их равноправие и равноценность, независимо от их ролей и представляемых ими интересов. Он может быть обеспечен за счет отсутствия ограничений в коммуникациях и прозрачности проекта. Этот 9 аспект также предполагает взаимоуважение и заботу о каждом члене коллектива. Атмосфера взаимоуважения – необходимое условие максимальной эффективности в работе любой команды: она обеспечивает высокую коллективную ответственность, эффективные коммуникации и командный дух. Для успешной работы в команде равнозначных участников представители всех ролей должны заботиться о качестве создаваемого продукта, действовать как представители интересов заказчика и понимать решаемую бизнес-проблему. Хозяйский подход К ресурсам проекта, корпоративным и вычислительным ресурсам нужно относиться по-хозяйски. Такой подход нужно применять во всем – от использования эффективных методов управления проектом до оптимизации системных ресурсов. Дальновидным шагом будет снабжение описателей ошибок подробнейшими данными, которые помогут кому-то в дальнейшем. Также полезно давать точную оценку трудозатрат на выполнение задач разработки и тестирования. Существующие ресурсы должны использоваться везде, где это возможно. Непрерывное обучение Готовность к обучению включает в себя постоянное самосовершенствование участника команды путем накопления знаний и обмена ими с другими. Надо учиться на чужом опыте: не повторять ошибок и применять успешные подходы. В графике проекта нужно предусмотреть время для обучения членов команды, анализа текущего состояния дел и проделанной работы. Кроме того, важной индивидуальной чертой каждого участника команды должно быть стремление к обмену знаниями с другими. Приверженность качеству Аспект приверженности качеству предполагает такой подход к планированию и реализации решения, который учитывает все потребности конечного пользователя. При этом качество в таких областях, как производительность или безопасность, должно учитываться на всех этапах разработки. Без такого подхода к обеспечению качества систему, как правило, создают, делая неявные допущения о ее поведении. В результате функционирование системы не удовлетворяет заказчика. Для обеспечения качества нужно видеть систему в целом и не полагаться на неявные допущения, а руководствоваться явно сформулированными требованиями к качеству. 10 Принципы Microsoft Solutions Framework (MSF) for Agile Software Development – это методология построения. NET-приложений и другого объектно-ориентированного ПО. В ее основе лежит гибкий, управляемый, адаптируемый к контексту проекта процесс разработки. Непосредственно в гибкую методологию MSF разработки ПО включены нормы работы с требованиями к качеству в таких областях, как производительность и безопасность. В данной методологии также учитываются конкретные условия для реализации каждого проекта. При таком подходе создается адаптивный процесс, обеспечивающий преодоление ограничений большинства гибких процессов разработки ПО и достижение целей, установленных концепцией проекта. Партнерство с заказчиками В модели команды MSF, основанной на представлении интересов, ключевое внимание уделяется пониманию потребностей заказчика и участию представителей заказчика в реализации проекта. Главный приоритет для любой профессиональной команды – действовать так, чтобы клиенты были довольны результатами. Ориентироваться на клиента – значит понимать его проблемы. Разобравшись в решаемой проблеме клиента, надо вовлечь его в работу в том объеме, который соответствует его ожиданиям. На всех фазах проекта нужно поддерживать открытое, активное, регулярное общение с заказчиком. Это важно потому, что зачастую только заказчик видит разницу между действительными и мнимыми проблемами бизнеса. Единая точка зрения В MSF настойчиво рекомендуется выработать единую точку зрения на подходы к реализации решения. Общий взгляд всех участников команды гарантирует, что они одинаково понимают, каков будет результат их работы; они сплачиваются вокруг единой цели и одинаково трактуют потребности заказчика. Совместная работа единомышленников всегда эффективнее, поскольку решения принимаются не произвольно, а основываясь на общем видении проблемы. Без единой точки зрения участники команды могут иметь противоречивые представления о целях работы, а достигнуть нужных результатов в этом случае сложнее. Даже после того как результат получен, не все участники могут согласиться с тем, что он оказался 11 успешен. Понимание достоинств выработанного решения и умение их сформулировать зачастую являются ключевыми факторами успеха. Инкрементная выдача результатов Ничто так не завоевывает доверие заказчика, как частая выдача результатов. Очень выгодно постоянно иметь «практически готовый» продукт. Реагирование на потребности заказчика регулярной выдачей небольших работоспособных дополнений наглядно демонстрирует прогресс разработки. При частой выдаче результатов для заказчика существует гарантия работоспособности команды и развития процесса и инфраструктуры. При этом риски, ошибки и упущенные требования выявляются на ранних стадиях. Инкрементный подход подтверждает правильность проектных решений и обеспечивает их корректировку благодаря эффективной обратной связи. Для частой выдачи результатов работа должна быть разбита на небольшие фрагменты, результаты должны выдаваться точно по графику, а в случае нескольких вариантов решения должны предоставляться они все, а не один успешно выбранный. Планируйте, выполняйте планы, оценивайте прогресс и темп работы команды на основе инкрементной выдачи результатов – и вы увеличите рентабельность. Минимизируйте деятельность, не приносящую понятных заказчику конкретных результатов. Применяйте итерации для поддержания ритма выдачи тех результатов, которые ваш клиент способен оценить. Внимательно оценивайте эффективность передачи работ от одного участника команды другому. Разработчики должны постоянно проверять создаваемый продукт, а ваша компания – испытывать новые версии. Инвестиции в качество В успешной команде каждый участник должен чувствовать свою ответственность за разрабатываемый продукт и быть представителем интересов заказчика, заботясь о качестве на протяжении всего жизненного цикла разработки. Качество должно учитываться в планах и графиках. Используйте ассигнования на исправление дефектов (запланированные итерации для устранения неисправностей) для снижения общих затрат на ошибки. Таким образом вы несколько снизите темпы разработки, обеспечив резерв времени в последующих итерациях для уменьшения числа дефектов. 12 Широкие полномочия участников проекта Команда работает эффективно, когда каждому участнику предоставлены все необходимые полномочия для выполнения его обязанностей и он уверен, что если его работа зависит от коллег, она будет выполнена. В свою очередь, заказчик вправе считать, что команда выполнит свои обязательства, и может строить свои планы исходя из этого предположения. В случае возможной задержки или изменения функций необходимо своевременно уведомить об этом клиента. Модель команды Модель команды MSF описывает подход компании Microsoft к структуризации участников команды и их действий, приводящих к успеху проекта. Фундаментальными принципами модели команды MSF являются: команда – это группа равнозначных сотрудников с четкой подотчетностью, разделяемой ответственностью и свободным общением; защита интересов каждого ключевого представителя, вовлеченного в проект, голос которого может повлиять на успех; необходимая гибкость в масштабировании команды. 13 Четкая подотчетность Модель команды MSF основывается на предпосылке, что цели всех участников равноценны, сегменты деятельности в рамках проекта уникальны и при этом нет единого представителя всех разнообразных целей. При таком подходе в команде равнозначных участников целесообразно совмещать четкую подотчетность перед заинтересованными сторонами с коллективной ответственностью за конечный результат. Каждый участник подотчетен коллективу (и организации, которая за ним стоит) за достижение целей, установленных для его роли. Другими словами, представитель каждой роли обязан отчитываться за свой вклад в конечный результат. Ответственность же в команде равнозначных участников распределяется равномерно. На то есть причины: во-первых, невозможно выделить результат работы отдельного участника из общего решения, во-вторых, команда работает эффективнее, когда каждый ее участник, исполняющий любую роль, видит картину в целом. Такая взаимозависимость членов коллектива должна стимулировать их интерес к областям, за которые они не подотчетны, обеспечивая полноценное использование всего спектра знаний, компетенции и опыта команды. Достижения проекта относятся ко всем участникам: они разделяют всеобщее уважение и заслуженное вознаграждение в случае удачных решений. Вместе с тем каждый участник проекта должен задумываться над повышением своего профессионального уровня, извлекая уроки из менее удачных проектов. Учет любого опыта Каждый проект, среда и команда уникальны, следовательно, любой проект и всякая его итерация – это потенциальный источник дополнительного опыта. Однако нельзя узнать ничего нового без обратной связи и открытости в коллективе. Если не заботиться об участниках команды, не давать им почувствовать себя раскрепощенными, обратная связь будет ограниченной и неэффективной. Если же обеспечить людям психологический комфорт, каждый участник и команда в целом будут нацелены на самосовершенствование, углубление своих знаний и обмен ими с коллегами. Как уже отмечалось, в графике проекта нужно учесть время на обучение, в том числе на основе предыдущего и чужого опыта. Подробный анализ того, что было сделано в доброжелательной 14 атмосфере, – ключевой принцип MSF, обеспечивающий эффективные коммуникации между членами команды. Свободное общение Исторически во многих организациях и проектах применялся принцип необходимого знания, в соответствии с которым сотрудники получали доступ только к тем сведениям, которые были нужны для выполнения конкретных функций. Зачастую такой подход приводит к недоразумениям и снижает шансы команды на достижение успеха. В MSF предлагается открытый и честный обмен информацией как внутри команды, так и с ключевыми заинтересованными сторонами вне ее. Свободный обмен информацией не только сокращает риск возникновения недоразумений и неоправданных затрат, но и обеспечивает максимальный вклад всех участников команды в снижение существующей в проекте неопределенности. Гибкость и готовность к переменам Чем большую отдачу для бизнеса от внедрения новых технологий хотят получить организации, тем больше они должны быть готовы вкладывать в новые области. Нельзя рассчитывать на успех, не осваивая новые территории. В MSF предполагается, что все вокруг непрерывно меняется и оградить проект от этих перемен невозможно. Применение модели проектной группы MSF гарантирует участие всех ролей и их вовлеченность в процесс принятия решений, обусловленных происходящими переменами. Эта модель поощряет гибкость (agility) при работе в меняющейся среде. Участие всех ролей в процессе принятия решений обеспечивает рассмотрение вопросов с учетом полного спектра точек зрения. Вопрос 2. Начало работы. После создания проекта на базе гибкой методологии MSF разработки ПО в Team Foundation Server следует изучить последовательность дальнейших действий для организации работы над проектом и найти необходимые дополнительные сведения, которые позволят оптимально использовать процесс MSF. Первые задачи При создании проекта формируются описатели задач, которые позволяют распределить задания и сразу приступить к работе. Эти задачи вы можете просмотреть в электронной таблице Project Checklist. 15 xls на портале проекта или с помощью Team Explorer (Проводника команды). Project Checklist. xls находится в папке Project Management (Управление проектом) портала проекта или в папке Documents (Документы) при просмотре в Team Explorer. Эти задачи вы также можете увидеть, выполнив запрос Project Checklist (Контрольный список проекта) в Team Explorer. Условия завершения В контрольном списке проекта содержатся все описатели, помеченные как содержащие условия завершения для данной итерации. Например, в описателе задачи есть поле Exit Criteria (Условия завершения). Задачи, у которых в данном поле содержится значение Yes (Да), представлены в контрольном списке. Контрольный список проекта используется для отслеживания всех критически важных работ, которые должны быть выполнены для успешного завершения итерации. Начальные задачи Начальные задачи в контрольном списке проекта – это задания, которые должны быть завершены до начала первой итерации. В первую очередь идут подготовительные действия по информированию участников проекта о его начале, а заканчивается список задачами планирования первой итерации. Актуализация данных проекта Обычно проектные работы начинаются до создания проекта команды на Team Foundation Server. Если у вас уже есть концепция проекта, какие-либо требования, а также назначенные или требующие отслеживания задачи, вам нужно сразу обновить проектные данные. Конечные продукты Просмотрите все шаблоны конечных продуктов в папке Documents в Team Explorer или на портале проекта. Если у вас уже есть конечные продукты или сопутствующая информация, вы можете актуализировать проект команды, загрузив на его портал внешние документы или обновив существующие документы MSF на портале проекта. 16 Описатели В MSF используются описатели дефектов, рисков, задач, сценариев и требований к качеству. Если у вас уже есть описатели, применимые в данном проекте, импортируйте их. Например, если вы уже определили какие-либо риски, задокументируйте их в виде описателей рисков с помощью Team Explorer. Начало действий Работа над проектом начинается с того, что бизнес-аналитик формулирует концепцию проекта. Этот этап является частью выполнения действия «Формулирование концепции проекта» (Capture Project Vision). Кроме того, менеджер проекта начинает планировать первую итерацию в рамках выполняемого им действия «Планирование итерации» (Plan an Iteration). После запуска этих двух действий естественным образом начинаются и другие действия, в которые вовлечены участники проекта с другими ролями. Типы описателей В MSF используется пять типов описателей. В описателях каждого типа содержатся данные для формирования различных отчетов. Чтобы отчеты отвечали своему назначению и выполнение работ отслеживалось адекватно, участники проекта должны корректно использовать типы описателей. Запросы Состояние работ над проектом можно узнать с помощью запросов, выдаваемых из папки Work Items (Описатели) в Team Explorer. Для получения дополнительных сведений о запросах щелкните вкладку Index (Указатель), а затем – Queries (Запросы). Отчеты В начале работы над проектом нет значимых показателей для создания полезных отчетов, но с каждым днем появляется все больше данных, по которым можно судить о прогрессе проекта. Прежде всего следует разобраться с отчетом Remaining Work (Оставшаяся работа). В первой и последующих итерациях этот отчет позволит вам следить за ходом проекта. Для получения дополнительных сведений об отчетах щелкните вкладку Index (Указатель), а затем – Reports (Отчеты). 17 |