Гибкая методология разработки программного обеспечения
Общие определения.
В гибкой методологии MSF разработки ПО все лица, участвующие в производстве, использовании и сопровождении продукта, обладают равными полномочиями. Участники команды имеют разные роли, связанные с их функциями, при этом ни одна из ролей не считается важнее другой: такое деление гарантирует реализацию качественного решения. Члены команды могут выступать в одной или нескольких ролях.
Действия и операции
Роли выполняют операции (activity), которые могут быть сгруппированы в действия (workstream). Другими словами, действие – это набор операций. Операции приводят к возникновению конечных продуктов и могут требовать для своего выполнения конечные продукты как результаты предыдущих операций.
Конечные продукты
Конечные продукты (deliverables) – это документы, электронные таблицы, проектные планы, исходные тексты программ и другие результаты операций.
Циклы и итерации
С помощью циклов описывается периодичность выполнения различных действий, а также частота выпуска и обновления конечных продуктов. Выполнение проектов и входящих в них задач производится циклично.
Тесная интеграция гибкой методологии MSF разработки ПО с Visual Studio Team System обеспечивает ускоренную итеративную разработку с постоянным уточнением деталей и совершенствованием конечного продукта. Определение требований к продукту, разработка и тестирование – это перекрывающиеся между собой, повторяющиеся действия, ведущие к постепенному завершению проекта.
Вклад тех или иных итераций в завершение проекта различен. Например, короткие итерации позволяют снизить погрешность предварительных оценок и предоставляют оперативные сводки о точности проектных планов. В результате каждой итерации должна появляться стабильно работающая часть системы.
Качество
Качество работ является одним из основополагающих принципов в гибкой методологии MSF разработки ПО. Все участники проекта должны осознавать важность качественной работы и руководствоваться этим принципом при проектировании, реализации, тестировании и внедрении системы. Особое внимание следует уделять качеству в таких областях, как безопасность, производительность и интерфейс пользователя.
Треки служат для группировки операций, завершающихся контрольными точками, то есть имеющих определенный бюджет и график. Треки не всегда связаны с задачами или работами, выполняемыми в циклах. Треки могут накладываться друг на друга, а между операциями, выполняемыми в разных треках, происходит постоянный обмен информацией.
Дисциплины
Дисциплины – это относящиеся к проекту в целом треки, в которых задействованы все участники команды.
Руководство
Руководство (governance) – это контроль бюджета и графика выполнения проекта в привязке к текущим результатам. В гибкой методологии MSF разработки ПО определены пять контрольных точек руководства, в каждой из которых дается ответ на определенный вопрос. Не следует путать треки руководства с упорядочиванием работ посредством их группирования в итерации с циклами внутри.
Описатели
Описатель (work item) – это запись в базе данных, которая используется в Visual Studio Team Foundation для отслеживания назначения определенной операции или действия исполнителям, а также для мониторинга состояния этого задания. В гибкой методологии MSF разработки ПО определены пять типов описателей для назначения и отслеживания работ. Данные, хранящиеся в общей базе данных описателей и в хранилище показателей, позволяют в реальном времени отслеживать состояние проекта.
Описатели характеризуются состоянием (state), например состояния «новый дефект» и «закрытый дефект». При переходе (transition) из одного состояния в другое требуется основание (reason): например, от состояния «новый дефект» сразу к состоянию «закрытый дефект» на основании того, что это дубликат уже существующего дефекта.
Аспекты
Методология MSF – больше чем набор правил, которым вы должны слепо следовать. Она призвана привить культуру, способствующую реализации успешных проектов. Аспект – это совокупность показателей, определяющая, как отдельный участник проекта оценивает ту или иную ситуацию и реагирует на нее. Участники проекта от его начала до завершения должны принимать во внимание аспекты при принятии решений, расстановке приоритетов, представлении своих интересов и при взаимодействии с другими участниками команды и прочими заинтересованными лицами. В MSF представлено девять аспектов.
Понимание практической ценности
Первый аспект акцентирует внимание участников проекта на его практических результатах. Каждая программная система создается с конкретной целью: например, для решения некоторой проблемы в бизнесе. При построении программных систем, особенно крупных, они испытывают на себе множество воздействий, часть из которых требует в ответ приложения значительных усилий. В конечном же счете программный проект оценивается по его полезности для бизнеса. Каждый участник должен всегда помнить о практических результатах и должен быть нацелен на их достижение.
Представление интересов
С программными проектами обычно связаны многие заинтересованные лица со своими интересами: например, заказчикам нужна хорошо работающая система. Можно также представить неодушевленные «заинтересованные лица», например саму разрабатываемую систему. Система может быть рассчитана на работу в течение тридцати лет, а может использоваться только тридцать минут. Системы, рассчитанные на длительное использование, разрабатываются дольше. Каждая из заинтересованных сторон (будь то люди или нет) в проекте должна быть представлена защитником своих интересов. Каждому участнику проекта важно понимать, чьи интересы он представляет. Следует помнить, что модель представления интересов – это совокупность ограничений, поэтому для получения оптимальных результатов зачастую неизбежны компромиссы.
Гордость за участие в проекте
Чувство гордости за участие в проекте – важный фактор для получения качественного продукта. Из чувства гордости вырастает мотивация и ответственность за выполнение проекта. Разработка ПО сродни искусству, и качественные системы – любимые детища их создателей. Комфортные условия труда, доверие, возможности роста, мотивированные, профессиональные люди – все это составляющие, необходимые для создания качественного ПО. Поддержание чувства гордости за участие в проекте – задача и участников проекта, и организации. Применяйте определение общих затрат в проекте по принципу «от частного к общему», дайте проекту кодовое имя и четко идентифицируйте команду проекта – это поможет поддерживать чувство гордости. В MSF представители всех ролей ответственны за создание продукта самого высокого качества.
Своевременное выполнение своих обязанностей
Многие задачи при разработке ПО связаны между собой. Бывают моменты, когда мы не можем выполнить свою работу самостоятельно, без участия коллег. Для эффективной работы нужно своевременно решать задачи, от которых зависит деятельность других участников проекта, и держать их в курсе текущего состояния дел. Вы должны быть надежным и заслуживающим доверия партнером для своих коллег.
Видение системы в целом
При работе над конкретной частью системы есть риск «не увидеть за деревьями леса». Важно не только представлять свой отрезок работы, но и понимать, как ваша деятельность отражается на конечном продукте. Надо уделять больше внимания итогу, а не процессу. Это не значит, что процесс плох или не важен: процесс не самоцель, а средство достижения конечного результата. Нужно четко понимать, зачем вы выполняете то или иное действие и как результаты вашей работы интегрируются в общее решение. Думайте о том, что нужно для реализации системы, не вдаваясь в мелкие детали. Регулярно – не только во время плановых встреч – общайтесь с другими участниками команды.
Равнозначность участников
Аспект равнозначности участников команды означает их равноправие и равноценность, независимо от их ролей и представляемых ими интересов. Он может быть обеспечен за счет отсутствия ограничений в коммуникациях и прозрачности проекта. Этот аспект также предполагает взаимоуважение и заботу о каждом члене коллектива. Атмосфера взаимоуважения – необходимое условие максимальной эффективности в работе любой команды: она обеспечивает высокую коллективную ответственность, эффективные коммуникации и командный дух. Для успешной работы в команде равнозначных участников представители всех ролей должны заботиться о качестве создаваемого продукта, действовать как представители интересов заказчика и понимать решаемую бизнес-проблему.
Хозяйский подход
К ресурсам проекта, корпоративным и вычислительным ресурсам нужно относиться по-хозяйски. Такой подход нужно применять во всем – от использования эффективных методов управления проектом до оптимизации системных ресурсов. Дальновидным шагом будет снабжение описателей ошибок подробнейшими данными, которые помогут кому-то в дальнейшем. Также полезно давать точную оценку трудозатрат на выполнение задач разработки и тестирования. Существующие ресурсы должны использоваться везде, где это возможно.
Непрерывное обучение
Готовность к обучению включает в себя постоянное самосовершенствование участника команды путем накопления знаний и обмена ими с другими. Надо учиться на чужом опыте: не повторять ошибок и применять успешные подходы. В графике проекта нужно предусмотреть время для обучения членов команды, анализа текущего состояния дел и проделанной работы. Кроме того, важной индивидуальной чертой каждого участника команды должно быть стремление к обмену знаниями с другими.
Приверженность качеству
Аспект приверженности качеству предполагает такой подход к планированию и реализации решения, который учитывает все потребности конечного пользователя. При этом качество в таких областях, как производительность или безопасность, должно учитываться на всех этапах разработки. Без такого подхода к обеспечению качества систему, как правило, создают, делая неявные допущения о ее поведении. В результате функционирование системы не удовлетворяет заказчика. Для обеспечения качества нужно видеть систему в целом и не полагаться на неявные допущения, а руководствоваться явно сформулированными требованиями к качеству.
Принципы
Microsoft Solutions Framework (MSF) for Agile Software Development – это методология построения. NET-приложений и другого объектно-ориентированного ПО. В ее основе лежит гибкий, управляемый, адаптируемый к контексту проекта процесс разработки. Непосредственно в гибкую методологию MSF разработки ПО включены нормы работы с требованиями к качеству в таких областях, как производительность и безопасность. В данной методологии также учитываются конкретные условия для реализации каждого проекта. При таком подходе создается адаптивный процесс, обеспечивающий преодоление ограничений большинства гибких процессов разработки ПО и достижение целей, установленных концепцией проекта.
Партнерство с заказчиками
В модели команды MSF, основанной на представлении интересов, ключевое внимание уделяется пониманию потребностей заказчика и участию представителей заказчика в реализации проекта. Главный приоритет для любой профессиональной команды – действовать так, чтобы клиенты были довольны результатами. Ориентироваться на клиента – значит понимать его проблемы. Разобравшись в решаемой проблеме клиента, надо вовлечь его в работу в том объеме, который соответствует его ожиданиям. На всех фазах проекта нужно поддерживать открытое, активное, регулярное общение с заказчиком. Это важно потому, что зачастую только заказчик видит разницу между действительными и мнимыми проблемами бизнеса.
Единая точка зрения
В MSF настойчиво рекомендуется выработать единую точку зрения на подходы к реализации решения. Общий взгляд всех участников команды гарантирует, что они одинаково понимают, каков будет результат их работы; они сплачиваются вокруг единой цели и одинаково трактуют потребности заказчика. Совместная работа единомышленников всегда эффективнее, поскольку решения принимаются не произвольно, а основываясь на общем видении проблемы. Без единой точки зрения участники команды могут иметь противоречивые представления о целях работы, а достигнуть нужных результатов в этом случае сложнее. Даже после того как результат получен, не все участники могут согласиться с тем, что он оказался успешен. Понимание достоинств выработанного решения и умение их сформулировать зачастую являются ключевыми факторами успеха.
Инкрементная выдача результатов
Ничто так не завоевывает доверие заказчика, как частая выдача результатов. Очень выгодно постоянно иметь «практически готовый» продукт. Реагирование на потребности заказчика регулярной выдачей небольших работоспособных дополнений наглядно демонстрирует прогресс разработки. При частой выдаче результатов для заказчика существует гарантия работоспособности команды и развития процесса и инфраструктуры. При этом риски, ошибки и упущенные требования выявляются на ранних стадиях. Инкрементный подход подтверждает правильность проектных решений и обеспечивает их корректировку благодаря эффективной обратной связи.
Для частой выдачи результатов работа должна быть разбита на небольшие фрагменты, результаты должны выдаваться точно по графику, а в случае нескольких вариантов решения должны предоставляться они все, а не один успешно выбранный.
Планируйте, выполняйте планы, оценивайте прогресс и темп работы команды на основе инкрементной выдачи результатов – и вы увеличите рентабельность. Минимизируйте деятельность, не приносящую понятных заказчику конкретных результатов. Применяйте итерации для поддержания ритма выдачи тех результатов, которые ваш клиент способен оценить. Внимательно оценивайте эффективность передачи работ от одного участника команды другому. Разработчики должны постоянно проверять создаваемый продукт, а ваша компания – испытывать новые версии.
Инвестиции в качество
В успешной команде каждый участник должен чувствовать свою ответственность за разрабатываемый продукт и быть представителем интересов заказчика, заботясь о качестве на протяжении всего жизненного цикла разработки. Качество должно учитываться в планах и графиках. Используйте ассигнования на исправление дефектов (запланированные итерации для устранения неисправностей) для снижения общих затрат на ошибки. Таким образом вы несколько снизите темпы разработки, обеспечив резерв времени в последующих итерациях для уменьшения числа дефектов.
Широкие полномочия участников проекта
Команда работает эффективно, когда каждому участнику предоставлены все необходимые полномочия для выполнения его обязанностей и он уверен, что если его работа зависит от коллег, она будет выполнена. В свою очередь, заказчик вправе считать, что команда выполнит свои обязательства, и может строить свои планы исходя из этого предположения. В случае возможной задержки или изменения функций необходимо своевременно уведомить об этом клиента.
Модель команды
Модель команды MSF описывает подход компании Microsoft к структуризации участников команды и их действий, приводящих к успеху проекта. Фундаментальными принципами модели команды MSF являются:
· команда – это группа равнозначных сотрудников с четкой подотчетностью, разделяемой ответственностью и свободным общением;
· защита интересов каждого ключевого представителя, вовлеченного в проект, голос которого может повлиять на успех;
· необходимая гибкость в масштабировании команды.
