Не так давно я наткнулся на эту книгу. Правда читал я ее в электровиде. Эта книга о создании команды разработчиков ПО. На мой взгляд очень понятная и доходчивая книга о том, с какими трудностями придётся столкнуться тим-лидеру группы разработки, какими качествами должны обладать мемберы группы, как должны взаимодействовать между собой программисты и как должны создаваться программные продукты. Эд является менеджером NuMega Technologies – софтверной фирмы, создавшей массу продуктов, одним из которых является SoftIce. Вопщем маст рид, двумя словами.

Я, когда читал эту книгу, решил выделять важные моменты и получилась такая мини-сборка из советов и идей(знал, что выйдет качественный пост ;=)). Они хоть и вырваны из контекста, но все равно понятны и очень полезны. Так что читайте советы и ищите контекст в книге:

  1. Самое большое препятствие — неэффективное управление группами разработчиков и проектами. Сейчас это самая распространенная проблема в индустрии программных средств. Она особенно актуальна для начинающих компаний — они сталкиваются с ней ежедневно.
  2. Замечательные люди создают замечательные программы. Они формулируют требования, отлаживают технологию и придерживаются графиков. Они тестируют, документируют и сопровождают продукт. Их идеи, профессионализм и энтузиазм определяют успех или провал разработки. Поскольку на судьбы проекта больше всего влияет «человеческий фактор», очень важно нанимать самых подходящих людей.
  3. Напротив, нужно иметь жесткое, закрепленное на уровне организации правило находить и удерживать наиболее квалифицированных специалистов. Это правило должно распространяться на три ключевых направления деятельности: поиск, собеседование и удерживание кандидатов.
  4. Во-первых, если человек в совершенстве овладел хотя бы одним предметом, он, вероятно, при необходимости освоит и другие.
    Во-вторых, в мощных командах важно взаимоуважение друг к другу ее членов, а оно зачастую основывается на знаниях и способностях. Каждый должен иметь квалификацию в одной или нескольких областях, в которые он может внести такой же или больший вклад, чем другие.
  5. Вам нужны специалисты, склонные к активным действиям, из тех, кто идет своим путем для достижения цели. Именно стремление к действию отличает истинно классных разработчиков.
  6. Хорошие работники обычно демонстрируют свою приверженность и ответственность за решаемые задачи и гордятся этим. Показателем такого положительного качества обычно являются «сильные» глаголы, например:
    • произвел; овладел; управлял; определил; написал; интегрировал; направил; создал.
    «Слабые» глаголы в целом означают меньшую приверженность делу и ответственность. Применение таких слов может указывать, что кандидат не в полной мере овладел предметом. Поищите такие слова:
    • принимал участие; ознакомился; следовал; помогал; способствовал;
    • комментировал.
  7. Менеджер проекта — это не просто управляющий, но один из тех, кто заинтересован в успехе продукта. Он должен быть в курсе конъюнктуры и тенденций рынка, а также четко представлять ценность функций программы. Без этих знаний он не сможет оперативно оценивать ход реализации ПО и обеспечить выполнение работы на должном уровне. Менеджер проекта работает в одной упряжке с менеджером продукта, формулирующим требования рынка и курирующим экономические аспекты создаваемого продукта. Оба вносят свой вклад во всех областях: в формирование политики лицензирования, ценообразование, продвижение и сбыт продукта.
  8. Лучший способ создать и воспитать корпоративную культуру — начать с приверженности определенным принципам и культивирования некоторых манер поведения, после чего группа какое-то время должна работать по новым правилам. Действия группы в соответствии с этими принципами и будут факторами, формирующими ее культуру.
  9. Создание качественного продукта основывается на четырех простых принципах:
    • тестирование продукта осуществляется параллельно с процессом его разработки;
    • качество продукта улучшается регулярно при завершении каждого планового этапа разработки;
    • тестирование необходимо максимально автоматизировать;
    • качество является частью культуры и технологии.
  10. Разработчики и тестировщики несут обоюдную ответственность за своевременное обеспечение качества. В такой системе реализация функции не завершается написанием кода. Функция считается законченной, если она проверена тестировщиками и соответствует заданным критериям. Разработчики и тестировщики должны осознавать, что для завершения работы над функцией они должны работать вместе.
  11. Через каждые 4-6 недель команда должна отводить 1-2 недели (в зависимости от сложности проекта) на тестирование, стабилизацию и интеграцию функций, завершенных к данному моменту. Такие периоды стабилизации и интеграции идут на пользу команде, функциональности и качеству.
  12. Тестирование эффективно, только если понятно, какую часть продукта, когда и как тестировать. Вроде вопросы простые, но если вы работаете в жестком графике и с ограниченными людскими ресурсами, то вам нельзя терять время, тестируя объект слишком глубоко или, наоборот, слишком поверхностно. Нужно сосредоточиться на проверке в следующих ключевых областях продукта:
    • процедуре установки;
    • функциональных возможностях;
    • интеграции функций;
    • производительности.
  13. Единственный способ создать великолепное первое впечатление — это разработать отличную процедуру установки. Иначе пользователь с первых минут будет недоволен вашей программой.
  14. Когда технологии, подходы и архитектура применяются впервые, мало кто из коллектива верит, что все заработает. Это и понятно: в отсутствие опыта решения подобных проблем шансы на успех могут казаться призрачными. Однако такого рода сомнения могут стать источником реальных проблем. От недостатка уверенности в успехе проекта страдает не только боевой дух группы, но и производительность ее труда. Поэтому задача — как можно раньше исключить всякие сомнения и создать уверенность, что проект может быть и будет успешным.
  15. Ознакомившись с положением в отрасли, мы обнаружили массу хороших продуктов, в целом составляющих весьма развитый набор ПО. Однако все существующие программы перегружали пользователя информацией, что, с нашей точки зрения, является недостатком, так как это очень затрудняет выполнение самой важной задачи продукта — поиск проблем с производительностью программ. Теперь мы знали, к чему стремиться: нужно сделать так, чтобы поиск проблем с производительностью с помощью нашей программы требовал не больше трех щелчков. Вся команда сообща работала над созданием интерфейса, чтобы решить эту просто сформулированную, но такую трудную задачу. Мы решили не усложнять интерфейс и разработали новый подход к навигации по сложной иерархии функций, в которой зачастую таятся проблемы с производительностью.
  16. Программа должна вызывать у пользователей не ощущение беспомощности, а стимулировать их к дальнейшей работе с ней. Если известен набор вероятных действий пользователя, то можно оптимизировать интерфейс под их потребности.
  17. Основные элементы пользовательского интерфейса должны быть «на местах» уже в начале работы над проектом. Их нельзя существенно изменять, если мы хотим уложиться в первоначальный план.
  18. Объем предстоящей работы, количество доступных ресурсов и время, отведенное на реализацию проекта, должны быть сбалансированы — вот старейшее и самое важное правило планирования.
  19. Одна из основных идей этой книги может быть сформулирована так: параллельная реализация всех аспектов проекта повышает эффективность цикла разработки. Для ее воплощения прекрасно подходит план проекта. При этом целью является реализация функций ПО путем интеграции различных задач по разработке, тестированию, обучению пользователей, инженерной психологии и работе над выпуском ПО.
  20. У параллельной разработки масса преимуществ. Во-первых, она концентрирует усилия всей команды, что позволяет как можно скорее завершить разработку набора функций. Это создает у участников команды ощущение срочной целенаправленной работы и (я на это надеюсь) успеха проекта уже на ранних стадиях его реализации. Кроме того, она позволяет сохранять синхронность работы команды в течение всего процесса разработки, так как все ее члены обсуждают и решают одни и те же проблемы. Во-вторых, поскольку вся команда сосредоточена на разработке одних и тех же функций, можно будет намного раньше понять, действительно ли завершена функция или пока написан только ее исходный текст, страдающий от недостатка качества, интеграции и мало пригодный к использованию. Задача в том, чтобы заставить команду как можно скорее создавать надежно работающие функции, чтобы не возвращаться к проблемам, давно считавшимся решенными.
  21. Базовые уровни определяют срок реализации группы связанных функций. Каждые 2-3 недели должен быть готов очередной базовый уровень. Помните: соответствующий фрагмент ПО должен устанавливаться с помощью программы установки, а его функциональность должна быть доступна для разработчиков. Реализация базовых уровней — важные краткосрочные цели, на достижении которых необходимо сосредоточить внимание и усилия команды. Вообще ничто не может быть важнее своевременного завершения очередного базового уровня.
  22. Вот самые распространенные внешние промежуточные этапы:
    • альфа-версия — выпуск, в котором реализован лишь ряд критических функций программы; альфа-версии не предназначены для широкого использования, однако могут быть полезны для демонстрации прогресса проекта или сбора внешних отзывов о работе критических функций;
    • бета-версия — выпуск, в котором реализованы если не все, то большинство функций; бета-версии передаются клиентам для испытаний и оценки;
    • кандидат на выпуск — в случае успешного окончания тестирования этот выпуск будет передан в производство для тиражирования; появление кандидата на выпуск — знак того, что проект почти закончен и выпуск ПО состоится;
    • передача в производство — к этому времени рабочий выпуск будет передан в производство для тиражирования (или опубликован в Web, в зависимости от назначения ПО).
  23. План проекта — это совокупность описаний отдельных его этапов, каждый из которых характеризуется определенным уровнем законченности некоторых функций программы, который должен быть достигнут к заданному сроку.
  24. Ежедневные сборки программы и базисные тесты — это пульс проекта. Оба мероприятия критичны для определения состояния проекта. Если в течение нескольких дней или недель вы не в состоянии скомпоновать программу, проект в беде. Возможность сборки ПО нужна для поддержания его внутренней согласованности, интеграции и визуализации изменений. Если нельзя выполнить сборку программы, оценить состояние проекта также невозможно.
  25. Бета-тестирование позволяет получить ценные сведения о готовности ПО, прежде чем оно попадает к заказчикам. Программы бета-тестирования являются решающим фактором успеха в начале развития компаний, когда объем ресурсов, выделенных под проекты, ограничен.
  26. Помните: цель программы бета-тестирования — испытание и усовершенствование продукта, поиск идей на будущее и помощь в продвижении продукта на рынке. Во время работы с бета-версией идет сбор отзывов о реализации функций, возможных улучшениях, практичности и качестве программы. Кое-что из этого еще можно изменить, но для добавления новых сложных функций этот период совершенно не годится.
  27. Поскольку работа над кандидатом на выпуск — критический период проекта, он требует открытого обмена точной информацией о состоянии проекта, отражающей как успехи, так и неудачи. В этот период необходимо оперативно принимать решения, чтобы устранять ключевые затруднения, исправлять ошибки, контролировать риск и выбирать между альтернативами.

…а музыка была: Ленинград – Терминатор

del.icio.us Tags:

Blogus tags :

Tags: