Время — деньги. Создание команды разработчиков программного обеспечения
Добавить в закладки К обложке
- Предисловие - Страница 1
- Благодарности - Страница 3
- Введение - Страница 4
- Часть 1Люди, организация и методы - Страница 8
- Определение «замечательных» - Страница 9
- Поиск и привлечение достойных кандидатов - Страница 12
- Общие проблемы и решения - Страница 15
- Глава 2Резюме, собеседование и удерживание сотрудников - Страница 16
- Анализ резюме - Страница 17
- Собеседование с кандидатом - Страница 19
- Удерживание сотрудников - Страница 23
- Типичные проблемы и их решение - Страница 24
- Глава 3Организация проекта - Страница 25
- Модель организационной структуры компании NuMega - Страница 26
- Управление проектом - Страница 27
- Роли и обязанности - Страница 29
- Типичные проблемы и их решение - Страница 35
- Глава 4Ранжирование сотрудников и корпоративная культура - Страница 36
- Ранжирование - Страница 37
- Корпоративная культура - Страница 40
- Типичные проблемы и их решение - Страница 43
- Глава 5Инструментальные программы - Страница 44
- Средства управления исходным кодом - Страница 45
- Устранение проблем и неисправностей - Страница 49
- Дополнительные средства - Страница 53
- Типичные проблемы и их решение - Страница 54
- Глава 6Основы системы контроля качества - Страница 56
- Основные принципы - Страница 57
- Что, когда и как тестировать - Страница 60
- Кто должен тестировать? - Страница 64
- Другие критичные моменты для контроля качества - Страница 66
- Типичные проблемы и их решение - Страница 68
- Глава 7Основы технологии разработки программ - Страница 70
- Технологи по разработке ПО - Страница 71
- Сборки - Страница 72
- Процедура установки - Страница 74
- Сбор всего вместе - Страница 76
- Типичные проблемы и их решение - Страница 77
- Часть 2Формулирование и планирование проекта. - Страница 78
- Центральная идея проекта - Страница 79
- Формулирование требований - Страница 80
- Анализ требований - Страница 83
- Определение приоритетов - Страница 85
- Утверждение требований - Страница 86
- Управление внесением изменений - Страница 87
- Общие проблемы и решения - Страница 88
- Глава 9Исследования, оценка технологий и моделирование - Страница 89
- Чем полезны исследования и прототипы - Страница 90
- Исследования - Страница 91
- Оценка технологий - Страница 94
- Моделирование - Страница 95
- Типичные проблемы и их решение - Страница 97
- Глава 10Пользовательский интерфейс - Страница 98
- Прототип пользовательского интерфейса - Страница 99
- Роль специалиста по инженерной психологии - Страница 103
- Типичные проблемы и их решение - Страница 105
- Глава 11Планирование - Страница 106
- Предпосылки - Страница 107
- Основные понятия и трудности планирования - Страница 108
- Как составить хороший план - Страница 112
- Типичные проблемы и их решение - Страница 115
- Часть 3Исполнение проекта - Страница 116
- Анология с самолётом - Страница 117
- Процесс измерений и мониторинга состояния проекта - Страница 118
- Внесение изменений - Страница 121
- Общие проблемы и решения - Страница 125
- Глава 13Бета-тестирование - Страница 126
- Ценность бета-тестирования - Страница 127
- Самая распространённая ошибка при проведении бета-тестирования - Страница 128
- Типы программ бета-тестирования - Страница 129
- Элементы программы бета-тестирования - Страница 130
- Набор бета-тестеров - Страница 131
- Менеджер бета-тестирования - Страница 134
- Общие проблемы и решения - Страница 135
- Глава 14Кандидат на выпуск - Страница 136
- Начальные требования - Страница 137
- Тестирование кандидата на выпуск - Страница 138
- Общие проблемы и решения - Страница 141
- Глава 15Закрытие проекта - Страница 142
- Почему это так важно? - Страница 143
- Как это делается? - Страница 144
- Что дальше? - Страница 146
- Общие проблемы и решения - Страница 148
- Об авторе - Страница 149
— Работа над бета-версией 1 займёт 1 месяц. Функции 14 и 15 будут добавлены во время работы над бета-версией 1, а оставшееся время будет потрачено на тестирование, настройку и исправление ошибок. У каждого участника группы есть некоторый список действий на время работы над бета-версией 1.
— В бета-версии 2 не будет новых функций по сравнению с бета-версией 1. Внесение значительных изменений в главные функции не допускается, разрешено лишь тестирование, настройка и исправление ошибок. У каждого члена группы есть список задач на это время.
• Кандидат на выпуск.
Версия — кандидат на выпуск будет готова к концу работы над бета-версией №2, если её тестирование пройдёт успешно и не будет обнаружено серьёзных ошибок.
• Контрольные собрания.
— Проведение собраний для контроля за состоянием проекта запланировано на каждый понедельник. Если достигнуть базового уровня вовремя не удалось (или все говорит об этом), придётся вносить изменения, чтобы наверстать упущенное.
Табл. 11. Примерный план.Цифрами обозначены функции, состояние функций обозначено следующими буквами:
Ф — функция запрограммирована, выполнено блочное тестирование и завершены все связанные с ней технические задачи;
А — тестирование функции автоматизировано:
Р — функция протестирована вручную;
Д — функция документирована:
И — проверена простота использования функции.
Добавления в бета-версииЛегко заметить, что реализация двух задач в этом примере запланирована на период работы над бета-версией 1. Во время работы над любой бета-версией надо воздерживаться от добавления новых функций, особенно важных и сложных. Однако иногда есть смысл планировать включение в первую бета-версию функций, реализация которых не требует больших затрат и не вносит особого риска. Чем дольше задерживается передача программы в руки бета-тестеров, тем больше времени займёт сбор отзывов о качестве реализации и работе функций программы. Часто польза от раннего цикла бета-тестирования превышает риск включения небольших функций после начала программы бета-тестирования.
Хотя включить несколько дополнительных функций время работы над первой бета-версией ещё допустимо, в период работы над последней бета-версией реализацию дополнительных функции лучше не планировать. При работе над последней бета-версией функции остаются неизменными, и усилия команды концентрируется на качестве, производительности и интеграции. (О тестировании бета-версий см. главу 13.)
Неожиданные проблемыСоздавая план согласно описанным в этой главе принципам, вы, вероятно, будете планировать проект, как обычно. Однако разработка ПО — это не точная наука, и до проблем всегда рукой подать. Чтобы заметить малейшее отклонение проекта от намеченного пути, нужно регулярно проверять ход выполнения плана и после завершения каждого промежуточного этапа сравнивать фактическое состояние проекта с планом. Если работа отстаёт от плана, надо определить проблему, изменить план и постараться завершить очередной промежуточный этап в срок. Все так просто? Однако это та самая ситуация, когда от менеджера проекта и ведущих специалистов требуется полная самоотдача. Поскольку очень сложно вести работу над проектом, не отставая от графика, в третьей части основное внимание уделено именно этому вопросу.
- 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
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 40
- 41
- 42
- 43
- 44
- 45
- 46
- 47
- 48
- 49
- 50
- 51
- 52
- 53
- 54
- 55
- 56
- 57
- 58
- 59
- 60
- 61
- 62
- 63
- 64
- 65
- 66
- 67
- 68
- 69
- 70
- 71
- 72
- 73
- 74
- 75
- 76
- 77
- 78
- 79
- 80
- 81
- 82
- 83
- 84
- 85
- 86
- 87
- 88
- 89
- 90
- 91
- 92
- 93
- 94
- 95
- 96
- 97
- 98
- 99
- 100
- 101
- 102
- 103
- 104
- 105
- 106
- 107
- 108
- 109
- 110
- 111
- 112
- 113
- 114
- 115
- 116
- 117
- 118
- 119
- 120
- 121
- 122
- 123
- 124
- 125
- 126
- 127
- 128
- 129
- 130
- 131
- 132
- 133
- 134
- 135
- 136
- 137
- 138
- 139
- 140
- 141
- 142
- 143
- 144
- 145
- 146
- 147
- 148
- 149