Основные задачи, которые приходится решать специалистам по инженерной психологии во время исполнения проекта таковы:
• контроль хода работы над пользовательским интерфейсом, как текущий, так и по завершении каждого существенного этапа работы над проектом;
• консультации и санкционирование мелких изменений пользовательского интерфейса;
• создание или поиск элементов графического оформления продукта;
• надзор за созданием упаковки, лицензионного соглашения и формирование первоначального впечатления от продукта (см. выше);
• внутренняя и внешняя проверка ПО: хотя для крупных изменений может не остаться времени, небольшие изменения могут быть вполне возможны — это поможет лучше подготовиться к работе над следующим выпуском;
• визуальный контроль за ПО для обеспечения соответствия стандартам платформы, для которой ПО создано.
Типичные проблемы и их решение
Далее обсуждается ряд типичных проблем и вопросов, возникающих при использовании описываемых здесь методик, а также их решения.
Излишняя доводка кода
Одна из наиболее распространённых причин срыва планов разработки ПО заключается в том, что команда пытается воплотить в программном коде каждое улучшение прототипа пользовательского интерфейса. Если излишняя доводка имеет место во время разработки настоящей программы, создание хорошего прототипа заметно замедляется, и дата завершения продукта становится абсолютно непредсказуемой. Второй или третий вариант интерфейса, как правило, принимается независимо от того, хорош он или нет, чтобы наверстать упущенные сроки реализации проекта или из-за того, что вышло отведённое на доводку время. Не устану повторять, что важно как можно скорее довести дизайн интерфейса, не зацикливаясь на совершенствовании его кода, и утвердить окончательный вариант прежде, чем переходить к составлению плана.
Отсутствие отзывов извне
Если спросить у разработчиков, нужны ли им внешние отзывы при разработке пользовательского интерфейса, в ответ почти всегда можно услышать «Да». И всё же в жизни совсем мало команд получает внешние отзывы о своих проектах, особенно в начале работы. Дело в том, что трудно дать отзыв о том, чего ещё нет. Описанная в этой главе методика позволяет более успешно собирать внешние отзывы.
Лишние нововведения
Представленные в этой главе идеи чаще всего критикуют за то, что они, якобы, «душат» инновации. А что, если спустя несколько месяцев работы над продуктом возникла замечательная новая идея? Стоит ли вносить изменения, если есть возможность?
Фундаментальная идея этой главы в том, что основные элементы пользовательского интерфейса должны быть «на местах» уже в начале работы над проектом. Их нельзя существенно изменять, если мы хотим уложиться в первоначальный план. Бесспорно, инновации не только возможны, но и необходимы, однако работу с ними нужно завершить на этапе работы с прототипом. Именно поэтому следует быстро проверять и отрабатывать разные варианты. Протестировав прототип заранее, вы избавляете себя от необходимости вносить значительные изменения в будущем. Даже при возникновении новой идеи, представляющей прорыв в данной области, сохранится уверенность в том, что текущие идеи в состоянии удовлетворить потребности рынка, что позволит уложиться в план. Я не говорю, что во время реализации проекта нельзя вносить небольшие изменения. Как правило, во время разработки возникает масса полезных идей, существенно повышающих ценность программы с очень небольшими затратами. Многие из них вполне могут быть реализованы без риска срыва плана или возникновения серьёзных проблем.
Глава 11
Планирование
Создание плана часто оказывается одним из наиболее затруднительных и насыщенных политикой аспектов проекта. Правильно составленный план становится эффективным средством управления проектом. Как бы усердно ни трудилась команда, при плохом планировании вся работа пойдёт насмарку, если опоздать с выпуском ПО. Сложность планирования проектов общеизвестна, однако именно понимание принципов рационального планирования часто отличает реалистичную оценку сроков реализации проекта от планов «с потолка».
В этой главе мы подробно рассмотрим сведения, необходимые для составления плана, и обсудим важнейшие понятия планирования. Кроме того, я покажу, как создать точный и реалистичный план.
Предпосылки
Прежде чем приступать к планированию, нужно уяснить требования к проекту, особенности технологии, намеченной для использования в нём, и конструкцию пользовательского интерфейса программы (рис. 11-1). Разобравшись в фундаментальных аспектах проекта, можно получить чёткое представление о том, что будет создано и как это будет работать.
Рис. 11-1. Исходные данные, критически важные для процесса планирования.
Однако если основные требования не определены, а самые рискованные фрагменты программы не отработаны на прототипах или моделях интерфейса, то для разработки точного плана просто не хватит данных. Тогда сформулировать все задачи проекта и точно оценить время, необходимое для выполнения каждой из них, будет невозможно. Поэтому весь проект будет составлен из расплывчатых задач, у которых слишком общая формулировка, препятствующая мониторингу и контролю их выполнения. При этом получится нереалистичный план, от которого придётся отказаться при первых признаках трудностей. В результате вы останетесь без средства управления реализацией проекта.
Основные понятия и трудности планирования
Чтобы создать план проекта или оценить план, созданный другими, нужно хорошо разбираться в основных понятиях планирования. В этом разделе мы обсудим основные понятия, которые должен знать каждый участник процесса планирования. Затем я опишу наиболее серьёзные трудности работы с людьми, возникающих при создании плана. И в завершение мы рассмотрим ряд наиболее распространённых проблем, с которыми сталкиваются команды разработчиков при планировании.
Основные понятия
Следующие понятия являются фундаментальными для создания надёжных планов.
Равновесие
Объём предстоящей работы, количество доступных ресурсов и время, отведённое на реализацию проекта, должны быть сбалансированы — вот старейшее и самое важное правило планирования. Если хоть один из этих параметров начинает перевешивать или, хуже того, наложены ограничения, которые нельзя сбалансировать, создать ПО вовремя будет невозможно. Даже если в начале работы проект был сбалансирован, велика вероятность, что в дальнейшем равновесие будет нарушено. В цикле разработки возникает достаточно препятствий, чтобы вывести из равновесия даже самый лучший план. По ходу работы менеджер проекта должен регулярно проверять план и всемерно поддерживать его равновесие. Способы мониторинга проекта и внесения изменений в процессе его реализации мы обсудим в главе 12.
Задачи и оценка времени для их выполнения
Задачи — это основные строительные блоки плана, они являются представлением конкретной работы, которую нужно сделать. В общем верно, что легче следить за ходом выполнения небольших задач. Кратко и точно сформулированные задачи позволяют быстро обнаружить отставание от плана. Если задачу нельзя завершите за 1-2 недели, её следует разбить на две или больше меньших задач. Исполнение плана, составленного из долгосрочных задач, труднее контролировать.
При составлении списка задач обязательно нужно учитывать их взаимосвязи в рамках проекта. Например, зная, как одни задачи зависят от других, можно расположить их в нужной последовательности, причём ключевые задачи всегда должны завершаться в первую очередь. Нужно выяснить, сколько времени займёт каждая задача. Это можно сделать, оценив время, необходимое для выполнения некоторой задачи (т.е. выдвинув обоснованное предположение о сроках). Поскольку для формулирования требований, конструирования интерфейса и реализации выбранной технологии сделано уже довольно много, должно быть накоплено достаточно информации, чтобы точно и без особых затруднений оценить срок для выполнения той или иной задачи. Если точно оценить время исполнения ключевых задач невозможно, вы, вероятно, провели недостаточно экспериментов, исследований и работы с прототипом.
Оценка должна учитывать всю работу, необходимую для выполнения задачи. Например, специалисты по ПО должны оценить суммарное время конструирования низкоуровневой структуры, а также реализации, отладки и блочного тестирования программы. Специалисты по обучению пользователей должны оценить, какое время потребуется на написание, рецензирование, редактирование и правку их материалов. Хотя каждый участник команды самостоятельно оценивает срок завершения своей части работы, его оценку всегда должен проверить ведущий специалист в соответствующей области. На основе этих оценок рассчитывается время реализации проекта, поэтому следует быть уверенным в цифрах.
Со временем вы увидите, что ваши оценки становятся все точнее, особенно при работе над аналогичным продуктом с использованием те же самых технологий. Обязательно проанализируйте задачи, на которые ушло значительно больше времени, чем ожидалось. чтобы понять, почему в оценку вкралась ошибка.
Полнота плана
Не совершайте ошибку, планируя лишь разработку самой программы: план должны отражать все аспекты проекта.
• Разработка
Часть плана, регламентирующая разработку ПО, должна отводить достаточно времени на разработку, блочное тестирование и отладку всех функций программы. Команде разработчиков следует выделить дополнительное время на анализ результатов работы тестировщиков и материалов, подготовленных группой по обучению пользователей. Не исключено, что разработчикам также понадобиться время для анализа результатов специалистов по инженерной психологии и технологов.
• Тестирование
Этот раздел должен давать достаточно времени для создания планов и сценариев испытаний, а также для тестирования самой инфраструктуры. План испытаний должен выделять добавочное время на тестирование ПО после окончания каждого промежуточного этапа работы.
• Обучение пользователей
Здесь должно даваться достаточно времени на создание документации, электронной справки и учебника по работе с программой. На редактирование потребуется дополнительное время, которое также нужно учесть. И не забывайте проводить разбор технических особенностей ПК с участниками команды.
• Работа инженерных психологов
Отведённого здесь времени должно быть достаточно для разработки детальной конструкции пользовательского интерфейса и его оценки. Выделите также время на оценку графических материалов продукта, внутренние и внешние испытания пользовательского интерфейса, и проверку документации. Кроме того, в плане должно быть время для проверки первоначального впечатления от продукта.
• Работа над выпуском
Времени, запланированного в этом разделе, должно хватить для создания системы сборки ПО, разработки установочной процедуры, для конфигурирования и сопровождения системы управления исходным текстом.
• Зависимость от внешних факторов
План должен в полной мере учитывать возможную зависимость проекта от внешних факторов и предусматривать выделение дополнительного времени в случае необходимости. К таким факторам относятся поставки и использование ПО от сторонних разработчиков, доступность оборудования и даже расширение штата или получение поддержки от других групп.
Параллельная разработка
Одна из основных идей этой книги может быть сформулирована так: параллельная реализация всех аспектов проекта повышает эффективность цикла разработки. Для её воплощения прекрасно подходит план проекта. При этом целью является реализация функций ПО путём интеграции различных задач по разработке, тестированию, обучению пользователей, инженерной психологии и работе над выпуском ПО.
Рассмотрим пример. Разработчики должны реализовать функции, соответствующие командам «Создать клиента», «Изменить клиента», «Удалить клиента». Как только эти функции станут готовы и появятся в ежедневной сборке ПО, команда тестировщиков должна испытать их и дать отзыв о качестве реализации этих функций. В то же время группа специалистов по инженерной психологии должна оценить пользовательский интерфейс с точки зрения его соответствия стандартам эргономики, практичности и задачам разработки. Группа по обучению пользователей должна привести описание этих функций к окончательному виду и дать отзыв о качестве их реализации и интеграции.
У параллельной разработки масса преимуществ. Во-первых, она концентрирует усилия всей команды, что позволяет как можно скорее завершить разработку набора функций. Это создаёт у участников команды ощущение срочной целенаправленной работы и (я на это надеюсь) успеха проекта уже на ранних стадиях его реализации. Кроме того, она позволяет сохранять синхронность работы команды в течение всего процесса разработки, так как все её члены обсуждают и решают одни и те же проблемы. Во-вторых, поскольку вся команда сосредоточена на разработке одних и тех же функций, можно будет намного раньше понять, действительно ли завершена функция или пока написан только её исходный текст, страдающий от недостатка качества интеграции и мало пригодный к использованию. Задача в том, чтобы заставить команду как можно скорее создавать надёжно работающие функции, чтобы не возвращаться к проблемам, давно считавшимся решёнными. Не правда ли, было бы очень неприятно получить сюрприз в виде плохого качества или недостатков в реализации функций, считавшихся законченными уже несколько недель, или месяцев тому назад.
Баланс ширины и глубины охвата в работе над проектом
Следует так упорядочивать задачи при создании плана, чтобы группы работали по всему фронту проекта, а не над отдельными его частями. Короче, не ограничивайтесь реализацией какой-либо одной части системы, игнорируя остальные. Например, работая над приложением для размещения заказов через Web, не составляйте план так, чтобы сначала был разработан пользовательский интерфейс, затем реализована прикладная логика, и лишь потом — весь код для работы с базой данных. Даже при наличии детальных спецификаций структуры, поочерёдное решение всех задач обернётся кошмаром при их интеграции, поэтому надо работать над всеми частями системы одновременно. Сосредоточьтесь на решении задачи, которая позволит ввести простой заказ, сохранить его и вывести подтверждение. Такой подход позволит сразу создать комплексное решение, пригодное для тестирования и объединяющее все необходимые программные подсистемы проекта.
Контекст функций
Часто в ответ на вопрос о планах от разработчика можно услышать такое: «Сначала нужно обновить менеджер ресурсов поддержкой 32-разрядных идентификаторов, потом изменить алгоритм анализа индекса PRODUCT ID, чтобы разрешить дублирование записей, а затем переписать обработчик ошибок, чтобы поддерживалась многопоточностъ». Каждый из этих пунктов вполне допустим, как элемент работы программиста, однако следует удостовериться, что все они находятся в контексте функций программы или не выходят за рамки её требований. В контексте некоторой функции задачу разработчика можно сформулировать, например, так: «организовать поддержку печати из диалогового окна ввода заказа» или «обеспечить возможность ввода нескольких заказов одновременно». Более узкая сосредоточенность также полезна для других разработчиков команды, поскольку им важно знать, когда некоторые функции станут доступны, а не срок завершения задач, необходимых для реализации этих функций. Когда план чётко определяет срок завершения всех функций или требований, остальные участники команды могут быть уверены, что их работа завершится в параллели с другими задачами.
Трудности в работе с людьми
Ниже описан ряд трудностей при составлении плана, имеющих отношение к работе с людьми.
Распределение работы
Не все разработчики от рождения наделены равными способностями. Некоторые лучше всего программируют интерфейсы, другие — системную логику. У одних опыта больше, у других — меньше. У некоторых производительность труда очень высока, у других средняя или даже низкая. Нельзя назначать задания случайным образом, полагая, что все люди обладают «типовыми» способностями. Распределяя задания между разработчиками, тестировщиками, технологами и другими членами команды, следует быть очень осторожным. В каждом случае надо учитывать уровень мастерства, индивидуальную производительность, опыт практической работы над проектами и привычки.
Балансировка нагрузки
Задача состоит в равномерном распределении рабочей нагрузки по реализации проекта на основе индивидуальных способностей участников команды.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30
• контроль хода работы над пользовательским интерфейсом, как текущий, так и по завершении каждого существенного этапа работы над проектом;
• консультации и санкционирование мелких изменений пользовательского интерфейса;
• создание или поиск элементов графического оформления продукта;
• надзор за созданием упаковки, лицензионного соглашения и формирование первоначального впечатления от продукта (см. выше);
• внутренняя и внешняя проверка ПО: хотя для крупных изменений может не остаться времени, небольшие изменения могут быть вполне возможны — это поможет лучше подготовиться к работе над следующим выпуском;
• визуальный контроль за ПО для обеспечения соответствия стандартам платформы, для которой ПО создано.
Типичные проблемы и их решение
Далее обсуждается ряд типичных проблем и вопросов, возникающих при использовании описываемых здесь методик, а также их решения.
Излишняя доводка кода
Одна из наиболее распространённых причин срыва планов разработки ПО заключается в том, что команда пытается воплотить в программном коде каждое улучшение прототипа пользовательского интерфейса. Если излишняя доводка имеет место во время разработки настоящей программы, создание хорошего прототипа заметно замедляется, и дата завершения продукта становится абсолютно непредсказуемой. Второй или третий вариант интерфейса, как правило, принимается независимо от того, хорош он или нет, чтобы наверстать упущенные сроки реализации проекта или из-за того, что вышло отведённое на доводку время. Не устану повторять, что важно как можно скорее довести дизайн интерфейса, не зацикливаясь на совершенствовании его кода, и утвердить окончательный вариант прежде, чем переходить к составлению плана.
Отсутствие отзывов извне
Если спросить у разработчиков, нужны ли им внешние отзывы при разработке пользовательского интерфейса, в ответ почти всегда можно услышать «Да». И всё же в жизни совсем мало команд получает внешние отзывы о своих проектах, особенно в начале работы. Дело в том, что трудно дать отзыв о том, чего ещё нет. Описанная в этой главе методика позволяет более успешно собирать внешние отзывы.
Лишние нововведения
Представленные в этой главе идеи чаще всего критикуют за то, что они, якобы, «душат» инновации. А что, если спустя несколько месяцев работы над продуктом возникла замечательная новая идея? Стоит ли вносить изменения, если есть возможность?
Фундаментальная идея этой главы в том, что основные элементы пользовательского интерфейса должны быть «на местах» уже в начале работы над проектом. Их нельзя существенно изменять, если мы хотим уложиться в первоначальный план. Бесспорно, инновации не только возможны, но и необходимы, однако работу с ними нужно завершить на этапе работы с прототипом. Именно поэтому следует быстро проверять и отрабатывать разные варианты. Протестировав прототип заранее, вы избавляете себя от необходимости вносить значительные изменения в будущем. Даже при возникновении новой идеи, представляющей прорыв в данной области, сохранится уверенность в том, что текущие идеи в состоянии удовлетворить потребности рынка, что позволит уложиться в план. Я не говорю, что во время реализации проекта нельзя вносить небольшие изменения. Как правило, во время разработки возникает масса полезных идей, существенно повышающих ценность программы с очень небольшими затратами. Многие из них вполне могут быть реализованы без риска срыва плана или возникновения серьёзных проблем.
Глава 11
Планирование
Создание плана часто оказывается одним из наиболее затруднительных и насыщенных политикой аспектов проекта. Правильно составленный план становится эффективным средством управления проектом. Как бы усердно ни трудилась команда, при плохом планировании вся работа пойдёт насмарку, если опоздать с выпуском ПО. Сложность планирования проектов общеизвестна, однако именно понимание принципов рационального планирования часто отличает реалистичную оценку сроков реализации проекта от планов «с потолка».
В этой главе мы подробно рассмотрим сведения, необходимые для составления плана, и обсудим важнейшие понятия планирования. Кроме того, я покажу, как создать точный и реалистичный план.
Предпосылки
Прежде чем приступать к планированию, нужно уяснить требования к проекту, особенности технологии, намеченной для использования в нём, и конструкцию пользовательского интерфейса программы (рис. 11-1). Разобравшись в фундаментальных аспектах проекта, можно получить чёткое представление о том, что будет создано и как это будет работать.
Рис. 11-1. Исходные данные, критически важные для процесса планирования.
Однако если основные требования не определены, а самые рискованные фрагменты программы не отработаны на прототипах или моделях интерфейса, то для разработки точного плана просто не хватит данных. Тогда сформулировать все задачи проекта и точно оценить время, необходимое для выполнения каждой из них, будет невозможно. Поэтому весь проект будет составлен из расплывчатых задач, у которых слишком общая формулировка, препятствующая мониторингу и контролю их выполнения. При этом получится нереалистичный план, от которого придётся отказаться при первых признаках трудностей. В результате вы останетесь без средства управления реализацией проекта.
Основные понятия и трудности планирования
Чтобы создать план проекта или оценить план, созданный другими, нужно хорошо разбираться в основных понятиях планирования. В этом разделе мы обсудим основные понятия, которые должен знать каждый участник процесса планирования. Затем я опишу наиболее серьёзные трудности работы с людьми, возникающих при создании плана. И в завершение мы рассмотрим ряд наиболее распространённых проблем, с которыми сталкиваются команды разработчиков при планировании.
Основные понятия
Следующие понятия являются фундаментальными для создания надёжных планов.
Равновесие
Объём предстоящей работы, количество доступных ресурсов и время, отведённое на реализацию проекта, должны быть сбалансированы — вот старейшее и самое важное правило планирования. Если хоть один из этих параметров начинает перевешивать или, хуже того, наложены ограничения, которые нельзя сбалансировать, создать ПО вовремя будет невозможно. Даже если в начале работы проект был сбалансирован, велика вероятность, что в дальнейшем равновесие будет нарушено. В цикле разработки возникает достаточно препятствий, чтобы вывести из равновесия даже самый лучший план. По ходу работы менеджер проекта должен регулярно проверять план и всемерно поддерживать его равновесие. Способы мониторинга проекта и внесения изменений в процессе его реализации мы обсудим в главе 12.
Задачи и оценка времени для их выполнения
Задачи — это основные строительные блоки плана, они являются представлением конкретной работы, которую нужно сделать. В общем верно, что легче следить за ходом выполнения небольших задач. Кратко и точно сформулированные задачи позволяют быстро обнаружить отставание от плана. Если задачу нельзя завершите за 1-2 недели, её следует разбить на две или больше меньших задач. Исполнение плана, составленного из долгосрочных задач, труднее контролировать.
При составлении списка задач обязательно нужно учитывать их взаимосвязи в рамках проекта. Например, зная, как одни задачи зависят от других, можно расположить их в нужной последовательности, причём ключевые задачи всегда должны завершаться в первую очередь. Нужно выяснить, сколько времени займёт каждая задача. Это можно сделать, оценив время, необходимое для выполнения некоторой задачи (т.е. выдвинув обоснованное предположение о сроках). Поскольку для формулирования требований, конструирования интерфейса и реализации выбранной технологии сделано уже довольно много, должно быть накоплено достаточно информации, чтобы точно и без особых затруднений оценить срок для выполнения той или иной задачи. Если точно оценить время исполнения ключевых задач невозможно, вы, вероятно, провели недостаточно экспериментов, исследований и работы с прототипом.
Оценка должна учитывать всю работу, необходимую для выполнения задачи. Например, специалисты по ПО должны оценить суммарное время конструирования низкоуровневой структуры, а также реализации, отладки и блочного тестирования программы. Специалисты по обучению пользователей должны оценить, какое время потребуется на написание, рецензирование, редактирование и правку их материалов. Хотя каждый участник команды самостоятельно оценивает срок завершения своей части работы, его оценку всегда должен проверить ведущий специалист в соответствующей области. На основе этих оценок рассчитывается время реализации проекта, поэтому следует быть уверенным в цифрах.
Со временем вы увидите, что ваши оценки становятся все точнее, особенно при работе над аналогичным продуктом с использованием те же самых технологий. Обязательно проанализируйте задачи, на которые ушло значительно больше времени, чем ожидалось. чтобы понять, почему в оценку вкралась ошибка.
Полнота плана
Не совершайте ошибку, планируя лишь разработку самой программы: план должны отражать все аспекты проекта.
• Разработка
Часть плана, регламентирующая разработку ПО, должна отводить достаточно времени на разработку, блочное тестирование и отладку всех функций программы. Команде разработчиков следует выделить дополнительное время на анализ результатов работы тестировщиков и материалов, подготовленных группой по обучению пользователей. Не исключено, что разработчикам также понадобиться время для анализа результатов специалистов по инженерной психологии и технологов.
• Тестирование
Этот раздел должен давать достаточно времени для создания планов и сценариев испытаний, а также для тестирования самой инфраструктуры. План испытаний должен выделять добавочное время на тестирование ПО после окончания каждого промежуточного этапа работы.
• Обучение пользователей
Здесь должно даваться достаточно времени на создание документации, электронной справки и учебника по работе с программой. На редактирование потребуется дополнительное время, которое также нужно учесть. И не забывайте проводить разбор технических особенностей ПК с участниками команды.
• Работа инженерных психологов
Отведённого здесь времени должно быть достаточно для разработки детальной конструкции пользовательского интерфейса и его оценки. Выделите также время на оценку графических материалов продукта, внутренние и внешние испытания пользовательского интерфейса, и проверку документации. Кроме того, в плане должно быть время для проверки первоначального впечатления от продукта.
• Работа над выпуском
Времени, запланированного в этом разделе, должно хватить для создания системы сборки ПО, разработки установочной процедуры, для конфигурирования и сопровождения системы управления исходным текстом.
• Зависимость от внешних факторов
План должен в полной мере учитывать возможную зависимость проекта от внешних факторов и предусматривать выделение дополнительного времени в случае необходимости. К таким факторам относятся поставки и использование ПО от сторонних разработчиков, доступность оборудования и даже расширение штата или получение поддержки от других групп.
Параллельная разработка
Одна из основных идей этой книги может быть сформулирована так: параллельная реализация всех аспектов проекта повышает эффективность цикла разработки. Для её воплощения прекрасно подходит план проекта. При этом целью является реализация функций ПО путём интеграции различных задач по разработке, тестированию, обучению пользователей, инженерной психологии и работе над выпуском ПО.
Рассмотрим пример. Разработчики должны реализовать функции, соответствующие командам «Создать клиента», «Изменить клиента», «Удалить клиента». Как только эти функции станут готовы и появятся в ежедневной сборке ПО, команда тестировщиков должна испытать их и дать отзыв о качестве реализации этих функций. В то же время группа специалистов по инженерной психологии должна оценить пользовательский интерфейс с точки зрения его соответствия стандартам эргономики, практичности и задачам разработки. Группа по обучению пользователей должна привести описание этих функций к окончательному виду и дать отзыв о качестве их реализации и интеграции.
У параллельной разработки масса преимуществ. Во-первых, она концентрирует усилия всей команды, что позволяет как можно скорее завершить разработку набора функций. Это создаёт у участников команды ощущение срочной целенаправленной работы и (я на это надеюсь) успеха проекта уже на ранних стадиях его реализации. Кроме того, она позволяет сохранять синхронность работы команды в течение всего процесса разработки, так как все её члены обсуждают и решают одни и те же проблемы. Во-вторых, поскольку вся команда сосредоточена на разработке одних и тех же функций, можно будет намного раньше понять, действительно ли завершена функция или пока написан только её исходный текст, страдающий от недостатка качества интеграции и мало пригодный к использованию. Задача в том, чтобы заставить команду как можно скорее создавать надёжно работающие функции, чтобы не возвращаться к проблемам, давно считавшимся решёнными. Не правда ли, было бы очень неприятно получить сюрприз в виде плохого качества или недостатков в реализации функций, считавшихся законченными уже несколько недель, или месяцев тому назад.
Баланс ширины и глубины охвата в работе над проектом
Следует так упорядочивать задачи при создании плана, чтобы группы работали по всему фронту проекта, а не над отдельными его частями. Короче, не ограничивайтесь реализацией какой-либо одной части системы, игнорируя остальные. Например, работая над приложением для размещения заказов через Web, не составляйте план так, чтобы сначала был разработан пользовательский интерфейс, затем реализована прикладная логика, и лишь потом — весь код для работы с базой данных. Даже при наличии детальных спецификаций структуры, поочерёдное решение всех задач обернётся кошмаром при их интеграции, поэтому надо работать над всеми частями системы одновременно. Сосредоточьтесь на решении задачи, которая позволит ввести простой заказ, сохранить его и вывести подтверждение. Такой подход позволит сразу создать комплексное решение, пригодное для тестирования и объединяющее все необходимые программные подсистемы проекта.
Контекст функций
Часто в ответ на вопрос о планах от разработчика можно услышать такое: «Сначала нужно обновить менеджер ресурсов поддержкой 32-разрядных идентификаторов, потом изменить алгоритм анализа индекса PRODUCT ID, чтобы разрешить дублирование записей, а затем переписать обработчик ошибок, чтобы поддерживалась многопоточностъ». Каждый из этих пунктов вполне допустим, как элемент работы программиста, однако следует удостовериться, что все они находятся в контексте функций программы или не выходят за рамки её требований. В контексте некоторой функции задачу разработчика можно сформулировать, например, так: «организовать поддержку печати из диалогового окна ввода заказа» или «обеспечить возможность ввода нескольких заказов одновременно». Более узкая сосредоточенность также полезна для других разработчиков команды, поскольку им важно знать, когда некоторые функции станут доступны, а не срок завершения задач, необходимых для реализации этих функций. Когда план чётко определяет срок завершения всех функций или требований, остальные участники команды могут быть уверены, что их работа завершится в параллели с другими задачами.
Трудности в работе с людьми
Ниже описан ряд трудностей при составлении плана, имеющих отношение к работе с людьми.
Распределение работы
Не все разработчики от рождения наделены равными способностями. Некоторые лучше всего программируют интерфейсы, другие — системную логику. У одних опыта больше, у других — меньше. У некоторых производительность труда очень высока, у других средняя или даже низкая. Нельзя назначать задания случайным образом, полагая, что все люди обладают «типовыми» способностями. Распределяя задания между разработчиками, тестировщиками, технологами и другими членами команды, следует быть очень осторожным. В каждом случае надо учитывать уровень мастерства, индивидуальную производительность, опыт практической работы над проектами и привычки.
Балансировка нагрузки
Задача состоит в равномерном распределении рабочей нагрузки по реализации проекта на основе индивидуальных способностей участников команды.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30