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