Эд Салливан - Время — деньги. Создание команды разработчиков программного обеспечения

Здесь есть возможность читать онлайн «Эд Салливан - Время — деньги. Создание команды разработчиков программного обеспечения» весь текст электронной книги совершенно бесплатно (целиком полную версию без сокращений). В некоторых случаях можно слушать аудио, скачать через торрент в формате fb2 и присутствует краткое содержание. Город: М., Год выпуска: 2002, ISBN: 2002, Издательство: Русская Редакция, Жанр: Программирование, Деловая литература, на русском языке. Описание произведения, (предисловие) а так же отзывы посетителей доступны на портале библиотеки ЛибКат.

Время — деньги. Создание команды разработчиков программного обеспечения: краткое содержание, описание и аннотация

Предлагаем к чтению аннотацию, описание, краткое содержание или предисловие (зависит от того, что написал сам автор книги «Время — деньги. Создание команды разработчиков программного обеспечения»). Если вы не нашли необходимую информацию о книге — напишите в комментариях, мы постараемся отыскать её.

В этой книге ветеран индустрии программных средств Эд Салливан делится найденными в результате нелёгкого труда принципами, приёмами и методиками разработки коммерческого ПО. В книге раскрыты фундаментальные принципы, позволяющие выпускать качественные программы в срок в любых обстоятельствах. Вы узнаете о реальном опыте успешной разработки коммерческого ПО в начинающей компании, о том, как выбрать нужных специалистов, инструментальные средства разработки, настроить технологию, планировать и выполнять проект, своевременно обнаруживая и решая возникающие проблемы.
Книга состоит из 15 глав и предметного указателя.

Время — деньги. Создание команды разработчиков программного обеспечения — читать онлайн бесплатно полную книгу (весь текст) целиком

Ниже представлен текст книги, разбитый по страницам. Система сохранения места последней прочитанной страницы, позволяет с удобством читать онлайн бесплатно книгу «Время — деньги. Создание команды разработчиков программного обеспечения», без необходимости каждый раз заново искать на чём Вы остановились. Поставьте закладку, и сможете в любой момент перейти на страницу, на которой закончили чтение.

Тёмная тема
Сбросить

Интервал:

Закладка:

Сделать

Однажды, в очередной раз сообщив боссу о продвижении проекта и заверив его в том, что всё в порядке, я установил сборку и нажал на кнопку «выполнить наиболее критичную функцию проекта». Она не работала. Выяснилось, что уже много дней сборка была сломанной, хотя большинство об этом не знало. По нашему графику мы уже давно прошли период разработки и тестирования этой функции, и коль уж однажды она работала как часы, то должна была работать и сейчас. Сейчас мы поняли, что если наиболее критичная функция продукта была нестабильна, то состояние остальных функций, которые тогда работали, сейчас также неизвестно. Все были так заняты написанием нового кода и тестированием новых дополнительных функций, что никто не заметил того, что продукт больше не работал. Бета-версия была отложена на несколько недель.

В тот момент я и моя команда поняли всю важность автоматизации тестирования для нашего проекта. Мы начали писать автоматизированные регрессивные тесты для ключевых функций, запускать их каждый день и немедленно устранять серьёзные неполадки.

Чаще всего автоматизацию критикуют из-за времени, необходимого для создания хороших тестовых заданий. Да, тестовые задания требуют материальных и трудовых затрат, но, созданные на совесть, они приносят большие дивиденды. Я рекомендую выделить нескольких специалистов по автоматизации, чьей задачей в цикле разработки будет только написание автоматизированных тестовых заданий.

Время, необходимое для поддержания адекватности тестов будущим выпускам, также является объектом нападок. Особенно это относится к автоматизации тестирования пользовательского интерфейса. Если между выпусками в вашем пользовательском интерфейсе происходят серьёзные изменения, то тестовые сценарии могут не работать и потребовать больших усилий для их совершенствования. По этой причине при автоматическом тестировании следует сосредоточиться на функциях, не относящихся к пользовательскому интерфейсу. Автоматизируйте тестирование ключевых функций, а не деталей пользовательского интерфейса.

Отличная идея — строить продукт, изначально рассчитанный на тестирование. Если вы минимизируете свою зависимость от пользовательского интерфейса и создадите альтернативные способы ввода данных и просмотра выходных данных, то будете защищены от изменений в интерфейсе. Например, рассмотрите возможность использования файлов, записей реестра, параметров командной строки и СОМ-интерфейсов передачи входных данных. Для вывода данных вы можете использовать текстовые файлы, распечатку значений переменных или готовые компоненты, специально предназначенные для этой цели. Я не говорю о том, что пользовательский интерфейс не должен быть протестирован, — просто приоритетным должно быть автоматизированное тестирование ключевых функций продукта. Однако если вы решили автоматизировать тестирование пользовательского интерфейса, начните с «контактного» тестирования. При этом, чтобы проверить функциональность всего интерфейса, вызываются и закрываются все диалоговые окна.

Из собственного опыта

Работая в NuMega над BoundsChecker 5, мы знали, что команда, создающая внутренние компоненты, значительно опережает команду, занятую пользовательским интерфейсом. И мы должны были быть уверены в том, что сможем тестировать продукт, даже если у нас не будет пользовательского интерфейса месяц или больше. Команда, отвечающая за внутренние компоненты, разрабатывала простые драйверы, вызывавшие подсистему с данными, необходимыми для работы. Используя эти драйверы, мы могли тестировать продукт и убедиться, что он твёрд, как скала, задолго до того, как пользовательский интерфейс был готов. Помимо раннего тестирования продукта, эти драйверы предоставляли надёжный и простой способ автоматизированного тестирования подсистем разных выпусков.

Команды, процессы и культура

У вас есть опыт создания качественного ПО? Ваши технологические процессы производительны и эффективны или они обычно занимают кучу времени и ресурсов? Учитывается ли вопрос качества каждым человеком, участвующим в разработке ПО? Как далеко вы готовы пойти, чтобы обеспечить качество? О качестве заботится каждый или есть такие, которые говорят: «это не мой участок»?

Эти вопросы могут определить, насколько группа успешна в разработке качественного ПО. Иногда говорят, что высшее руководство не желает брать на себя обязательства, необходимые для создания качественных продуктов. С другой стороны, они, может быть, и хотят поставлять качественный продукт, но не уверены в том, что у команды есть для этого эффективная система. Они считают, что увеличение количества процессов контроля качества всего лишь приведёт к дополнительным затратам времени и повысит расходы без улучшения продукта. Одной из задач этой книги является определение конкретного набора процессов контроля качества, которые позволят поставлять лучшие продукты в кратчайшие сроки, насколько это возможно. Однажды обзаведясь системой, в которой вы уверены, вы вероятнее всего станете поддерживать и постоянно использовать именно её.

Читать дальше
Тёмная тема
Сбросить

Интервал:

Закладка:

Сделать

Похожие книги на «Время — деньги. Создание команды разработчиков программного обеспечения»

Представляем Вашему вниманию похожие книги на «Время — деньги. Создание команды разработчиков программного обеспечения» списком для выбора. Мы отобрали схожую по названию и смыслу литературу в надежде предоставить читателям больше вариантов отыскать новые, интересные, ещё непрочитанные произведения.


Отзывы о книге «Время — деньги. Создание команды разработчиков программного обеспечения»

Обсуждение, отзывы о книге «Время — деньги. Создание команды разработчиков программного обеспечения» и просто собственные мнения читателей. Оставьте ваши комментарии, напишите, что Вы думаете о произведении, его смысле или главных героях. Укажите что конкретно понравилось, а что нет, и почему Вы так считаете.

x