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

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

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

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

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

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

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

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

Интервал:

Закладка:

Сделать

Типичные проблемы и их решение

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

Не торопитесь

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

Не увлекайтесь моделированием отдельных функций

Часто возникает искушение создать прототип какого-либо компонента без учёта контекста, не принимая во внимание характер его применения. Хотя сосредоточиться на узкой задаче много проще, в этом таится большая опасность. Моделирование не должно концентрироваться на отработке какого-то одного компонента, важно отработать совместную работу всех критически важных компонентов. Я очень рекомендую создавать общесистемные прототипы, в которых собраны воедино все критически важные фрагменты системы, даже если при этом приходится использовать искусственные данные, жёстко прошивать вызовы API или подменять их заглушками. Тем не менее в этом случае удастся составить хорошее представление о проблемах с интеграцией компонентов и убедиться в проектных решений на уровне системы.

Не оставляйте анализ производительности напоследок

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

Необходимо заранее проанализировать производительность на макроуровне: сначала на прототипе, а затем после сборки всех основных фрагментов программы.

Глава 10

Пользовательский интерфейс

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

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

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

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

Интервал:

Закладка:

Сделать

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

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


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

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

x