Добавлен: 15.07.2023
Просмотров: 56
Скачиваний: 3
При всем этом команда ограничена во временных, финансовых и человеческих ресурсах - их просто не хватит на то, чтобы идеальным образом справиться с обеими задачами. Большинство разработчиков остаются довольны тем, что сумели достичь первой цели и сделать хоть что-то для достижения второй. Даже те компании, которые обладают достаточным количеством ресурсов, едва ли могут позволить себе уделять второй цели большое внимание, так как она воистину безгранична. В целом же, лучшим из реалистичных вариантов будет поставить заказчику систему приемлемого качества в оговоренное время и сделать хоть какие-то приготовления к следующим играм.
Ориентация на отсутствие дефектов
Ориентация на отсутствие дефектов — это требование соблюдения качества продукта. Оно вовсе не подразумевает, что продукт должен быть выпущен без дефектов; достаточно, чтобы дефектов было не больше нормы, установленной группой на ранних стадиях разработки. Кроме того, это означает, что группе придется постоянно контролировать качество на всех стадиях: если завтра потребуется выпустить готовый продукт, группа должна быть готова выполнить это обязательно. Таким образом, с точки зрения качества продукт всегда должен быть практически готов.
В успешных группах все отвечают за качество продукта — эту обязанность нельзя переложить на других. В этом смысле все члены группы являются представителями заказчика.
Понимание целей бизнеса
Чтобы выпустить успешный продукт, группе недостаточно разбираться только в технической стороне проекта. Создано множество технически совершенных и безупречно написанных продуктов, не способных выполнять задачи, поставленные заказчиком. Чтобы избежать такой ситуации, члены группы должны ясно представлять себе решаемую задачу.
И здесь необходимо активное участие заказчика в процессе разработки. Его обязательно нужно привлекать к созданию концепции проекта, к принятию решений по продукту и его использованию и к анализy промежуточных версий.
Ответственность в равной мере
Чтобы добиться согласованной работы всех членов группы, вы должны сделать их роли взаимозависимыми и перекрывающимися, они все в одинаковой мере должны разделять ответственность за выпуск нужного продукта в запланированные сроки. Таким образом разрушается узкая специализация членов группы, которая ведет к изолированности, а не к совместной работе.
Совместное проектирование
В создании функциональных спецификаций должны участвовать представители всех направлений, так как у каждого из них свое представление о проекте. Они должны убедиться, что в проекте учтены не только требования всей группы, но и требования каждой роли.
Обучение на опыте других проектов
Чтобы не полагаться на удачу, стоит воспользоваться опытом работы над другими проектами, как успешными, так и провалившимися. Изучение опыта — основа совершенствования. Один из методов структурирования и накопления опыта — подведение итогов каждого этапа, зафиксированное в обзоре. Обзор, основа которого — сопоставление планов с результатами, помогает скорректировать дальнейший ход работы и избежать ошибок в дальнейшем. Кроме того, при этом можно выявить хорошо зарекомендовавшие себя методы, чтобы применять их в будущем.
Обучение группы
Работа группы эффективна, если все ее члены понимают, что они делают. Однако во многих случаях это простое правило реализуется недостаточно полно. Выпустить же нужный продукт в срок удастся только при наличии формального и неформального планов обучения проектной группы.
Изучение методологии
Разработка программного обеспечения — это не только создание кода. Поэтому изучение методологии разработки руководителями групп и основными участниками проекта сократит затраты и время выполнения проекта.
Целью любого проекта должно стать улучшение обмена информацией. Для этого в MSF и других моделях разработки применяется общий язык передачи информации о состоянии продукта. Основные элементы этого процесса существуют не один год, и многие разработчики применяют их на практике. Используя универсальный язык MSF, опытные разработчики смогут поделиться своим опытом с другими членами группы.
Изучение технологий
Создать хороший продукт очень сложно. Поэтому группам разработчиков, логистиков и, по возможности, менеджеров программы надо изучать существующие технологии. Каждый день появляются новые формы обучения современнейшим технологиям, однако для успешной реализации таких технологий недостаточно только знания их основ, необходимо понимать способы их применения.
Часто при обучении упускают из вида сопровождение приложения в существующей информационной инфраструктуре. Однако успех проекта зависит не только от качества созданного кода. Проектная группа должна исследовать взаимное влияние инфраструктуры и приложения друг на друга. Как скажется на приложении появление новых операционных систем, новых версий существующих операционных систем или новых базовых приложений, используемых продуктом?
Кроме того, проектной группе придется учесть то обстоятельство, что во время работы над проектом могут появиться новые технологии или новые версии приложений. Нужно уметь оценивать влияние новых функциональных возможностей таких продуктов на жизненный цикл проекта. Поэтому время на обучение следует включать в график проекта еще до определения даты выпуска приложения.
Координация работы с внешними группами
Проектная группа, рассчитывающая на успех, должна взаимодействовать с внешними группами — как с заказчиком и пользователями, так и с другими разработчиками. Этим занимаются менеджер программы, менеджер продукта, инструктор и логистик. В обязанности этих ролей входят как внутренние, так и внешние контакты, в то время как разработчики и тестеры изолированы от общения с внешним миром. (Такая изоляция приводит к повышению эффективности труда этих двух групп.)
Важно, чтобы взаимодействие с внешними группами было явным и понятным. Проектным группам, как правило, приходится взаимодействовать с большим количеством внешних организаций, включая финансовые и юридические подразделения и отделы контроля качества продукта.