Время — деньги. Создание команды разработчиков программного обеспечения
Добавить в закладки К обложке
- Предисловие - Страница 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
• транслировать формулировки требований в ключевые задачи;
• разрабатывать дизайн пользовательского интерфейса (макеты диалоговых окон и т.д.) для решения этих задач;
• тестировать разработанный дизайн и согласовывать его с командой;
• определять, как сформировать положительное первоначальное впечатление от продукта;
• проводить подгонку и доводку пользовательского интерфейса;
• работать с заказчиком после выпуска ПО.
Технологи по разработке ПООбеспечивают работу базовых служб, необходимых для поддержания работоспособности принятой модели разработки ПО. Эту работу должны выполнять соответствующие специалисты или сами разработчики, даже если для этого придётся продлить календарный план. Не впадайте в самообман, думая обойтись без этой работы: выпустить ПО вовремя без неё не получится. Подробнее о работе технологов по разработке ПО см. главу 7.
В общем случае у технолога по созданию ПО три основные обязанности:
• Создание и сопровождение подходящей среды для сборки продукта
Сборка программы — необходимый первый шаг, который должен быть завершён как можно раньше. Ежедневная сборка программы — ключ к успеху проекта, без неё невозможно воплотить многие концепции, изложенные в этой книге.
• Создание и сопровождение процедуры установки
Чтобы извлечь все выгоды частой сборки программы, нужно, чтобы каждая новая сборка устанавливалась автоматически. Кроме того, установочную процедуру требуется сопровождать и обновлять по ходу цикла разработки, а также следить, чтобы для выполнения этой задачи было выделено достаточно ресурсов.
• Сопровождение и администрирование систем управления исходным текстом
Важно, чтобы за сопровождение системы управления исходным текстом постоянно отвечал один и то же специалист. Об инструментах для управления исходным текстом см. главу 4.
Группа менеджмента и маркетинга продуктаС точки зрения технических подразделений, эта группа играет две роли; первая — сбор информации, а вторая — её выдача.
В рамках первой роли группа менеджмента и маркетинга продукта определяет приоритетные сегменты рынка, экономические и потребительские требования к продукту. Наличие у разработчиков ясных, сжатых, реальных и обоснованных экономических требований к продукту имеет решающее значение для его успеха. В дополнение к сбору сведений о необходимой функциональности продукта в обязанности этой группы входит формулирование требований к комплектности продукта, установочной программе, лицензированию и документированию.
С другой стороны, группа менеджмента и маркетинга помогает техническим подразделения представить продукт за пределами компании. Сюда относится реклама, обучение и оснащение необходимыми средствами специалистов по сбыту, аналитические совещания, пресс-релизы и брифинги, а также новости, публикуемые в Web.
Технические группы полагаются на группу менеджмента и маркетинга в распространении информации о своей работе; поддержка этой группы необходима, чтобы начать проект и обеспечить его успех на рынке. Вся работа технических специалистов пойдёт прахом, если специалисты по маркетингу не смогут сделать так, чтобы программный продукт заметили на рынке. Сотрудничество и командный дух в работе этих подразделений имеет решающее значение. Чем теснее они сотрудничают, чем в большей степени они единомышленники и чувствуют себя единым целым, тем больше шансов, что коррективы будут вноситься быстро и эффективно, повышая тем самым шансы на успех.
Между прочим, с отправкой программы заказчику работа над проектом не заканчивается. Проект можно считать завершённым, лишь когда продукт принесёт запланированную прибыль и решит поставленные перед ним экономические задачи. В конечном счёте успех определяется не фактом сдачи проекта, но завоеванием рынка.
Группа технической поддержкиСпециалисту по технической поддержке, наверное, приходится чаще всех контактировать с клиентами после выхода продукта. Он изо дня в день является представителем группы разработчиков перед клиентами. Этот специалист играет очень важную и ценную роль не только для клиентов, но и для разработчиков. В частности, разработчики рассчитывают на помощь группы технической поддержки в решении следующих задач:
• формулирование требований к функциям программы с целью облегчения её технической поддержки в дальнейшем;
• привлечение внимания разработчиков к важным проблемам с качеством и реализацией функций во время бета-тестирования продукта и после его выхода;
- 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.