Время — деньги. Создание команды разработчиков программного обеспечения
Добавить в закладки К обложке
- Предисловие - Страница 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
Кто должен тестировать?
За тестирование должны отвечать все участники проекта, невзирая на лица и отведённые им роли. При использовании продукта с любой целью и в любой форме делать это надо с критической точки зрения. Кем бы вы ни были: менеджером проекта, радостно рассматривающим новую функцию, автором руководства пользователя, проверяющим, как будет работать пример, или специалистом по инженерной психологии, устанавливающим продукт для проверки пользовательского интерфейса — вы должны отслеживать, искать и сообщать о проблемах качества.
Имея сжатые сроки и ограниченные ресурсы, трудно ожидать, что одна группа сможет провести всю работу по тестированию, особенно если учитывать, что в командах тестировщиков дефицит кадров проявляется чаще всего. Так что убедитесь в том, что ваши разработчики, технические писатели, инженерные психологи, менеджер продукта, менеджер проекта, вице-президент или студенты, проходящие летнюю практику, будут искать проблемы каждый раз, когда они используют продукт для своих нужд. Любой ценой заставьте их сообщать о найденных проблемах.
В период стабилизации и интеграции к тестированию приступает вся команда разработчиков — это коллективная работа. Появляется шанс увидеть, где команда находится в данный момент и сколько ещё нужно сделать. Обычно руководитель группы контроля качества выполняет задачу, распределяя ответственность за тестирование между всеми членами команды. Большую часть времени работа проводится в областях, где автоматические тестовые задания справляются плохо. Также сотрудников просят «сыграть роль пользователя» для ключевых частей продукта. Итак, команда, работавшая над продуктом в течение всего цикла разработки, просто незаменима. Это то, что должно стать частью вашей культуры и одним из ваших основных технологических процессов.
Эту идею можно развить ещё дальше — самим использовать собственные программы. Такой подход называют «питаться кормом своей собачки», он хорошо известен в нашей отрасли и может оказаться очень ценным. Для определения и разрешения проблем с качеством не нужно делать ничего, кроме как задействовать свои программы в реальной работе. Даже если в рамках вашей команды разработчиков продукт применить нельзя, попробуйте попросить нескольких опытных пользователей поэкспериментировать с программой. То, что они найдут, может оказаться для вас сюрпризом.
В определённый момент крайне необходимо чётко разграничить обязанности тестировщиков от обязанностей других членов команды (прежде всего разработчиков) в том, что касается тестирования. Чтобы люди концентрировались на своих прямых задачах, необходимо разделение труда.
Разработчики влияют на качество продукта больше всего. В конце концов они находятся ближе всего к коду, и риск внесения ошибок исходит прежде всего от них. Чтобы гарантировать отлов «жучков» до того, как команда тестировщиков увидит функциональный блок, они должны его тестировать в процессе написания. Хороший разработчик ускорит работу тестировщиков, предоставляя им надёжные функции. И наоборот, плохой разработчик затормозит работу тестировщиков, выдавая им компоненты с таким количеством ошибок, что о тестировании уже и речи не будет. Для тестировщика нет ничего более неприятного, чем находить массу очевидных проблем, которые разработчик мог найти сам всего за несколько минут работы.
Из собственного опыта
В NuMega мы готовили вторую бета-версию BoundsChecker 3. Для оценки продвижения проекта мы устраивали ежедневные совещания. Кэрол, наш ведущий специалист по контролю качества (в то время команда тестировщиков состояла из неё одной), настойчиво повторяла, что сборка была крайне неудачной. Она сказала, что больше не будет зря тратить время на её тестирование и останется дома до тех пор, пока разработчики не приведут все в порядок, и быстро ушла.
Я готов был зааплодировать. Не потому, что мне нравилось состояние бета-версии. Кэрол дала понять разработчикам, что в их обязанности входит базовое тестирование программ и самостоятельная работа над проблемами кода. До команды разработчиков это дошло. Мы согласились и занимались тестированием и исправлениями в программе, пока не почувствовали, что готовы позвать Кэрол. Это заняло около двух дней.
В отношении тестирования разработчики имеют ряд обязанностей:
• анализ плана тестирования;
• тестирование на уровне модулей (работает ли функция в большинстве ситуаций);
- 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
В конце февраля 2009 года в продаже на Amazon появилось долгожданное устройство для чтения электронных книг Kindle 2. Это событие вызвало бурю негодов
Электронная читалка - вещь очень хрупкая. Если с ней обращаться не правильно - она может сломаться. Чтобы этого не случилось, нужно придерживаться лиш
Большинство книг в сети интернет распространяется в формате FB2 (Fiction Book). Этот формат очень удобен для чтения. Файлы, в нем созданные, отличаютс
Популярность электронных книг у читателей неуклонно растет. Для доказательства этого мы провели маленький эксперимент. Из 10 людей, читающих в метро,
Файлы формата FB2 часто можно увидеть среди огромнейшего разнообразия текстовых форматов. Такая высокая популярность объясняется его предназначением.
Первую версию формата PDF (Portable Document Format) еще в 1993 году разработала фирма Adobe Systems. В 2006 году она уже разработала версию 1.7, а с
Фирма Apple порадовала пользователей iPad, выпустив под него красивую и удобную читалку iBooks.