Шестьдесят жемчужин мудрости в разработке программного обеспечения 

Любой, кто не может честно сказать: «Я создаю программное обеспечение сегодня, так же как программное обеспечение может быть создано когда-либо», выиграет от изучения более эффективных способов работы. Опыт - это форма обучения, которая нам больше всего запомнилась. Кроме того, это самый медленный и болезненный способ обучения. Мы можем сократить кривые обучения, усвоив уроки, советы и рекомендации людей, которые уже приобрели, применили и подтвердили знания.

Я пошел на свой первый курс программирования в колледже в 1970 году. За последние полвека я провел много времени, занимаясь разработкой программного обеспечения: требования, дизайн, пользовательский опыт, кодирование, тестирование, управление проектами, написание документации, руководство по совершенствованию процессов, консультирование, обучение и написание восьми книг и множества статей. Плюс, конечно, я сам являюсь пользователем бесчисленного множества приложений. За это время я накопил множество уроков о программном бизнесе как на собственном опыте, так и на опыте многих клиентов-консультантов и студентов, с которыми я работал.

Здесь я предлагаю шестьдесят уроков из моей книги « Жемчужины разработки программного обеспечения: уроки пятидесятилетнего опыта разработки программного обеспечения». Эти уроки применимы ко всем вашим проектам, независимо от вашей роли, отрасли, технологии или методологии. Уроки делятся на шесть областей, которые являются ключевыми для успеха проекта: требования, дизайн, управление проектом, культура и командная работа, качество и улучшение процессов. Надеюсь, вы найдете их такими же полезными, как и я.

Требования

№1. Если вы не уловили требования правильно, не имеет значения, насколько хорошо вы выполните остальную часть проекта. Если он не будет основан на правильных требованиях, предъявленных правильными людьми, ваш продукт, скорее всего, не добьется успеха.

№2. Ключевыми результатами разработки требований являются общее видение и понимание. Документ или электронная таблица требований, база данных в инструменте управления требованиями, стопка учетных карточек, набор приемочных испытаний или стена, покрытая липкими наклейками, - это видимый результат разработки требований, но не реальный результат.

№3. Нигде больше, чем в требованиях, не пересекаются интересы всех участников проекта. Выявление и соблюдение всех требований и ограничений, установленных ключевыми заинтересованными сторонами, является ключом к успеху.

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

№5. Разработка требований требует повторения. Создание прототипов, моделирование, постепенное уточнение деталей требований и постепенная разработка помогают преобразовать исходные концепции требований в более глубокое понимание, которое служит основой для проектирования и строительства.

№6. Требования Agile не отличаются от других требований. Разработчикам нужна одна и та же информация для правильной реализации нужных функций независимо от того, какой жизненный цикл разработки или процесс управления использует проект.

№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. Следите за «Management by Businessweek». Прежде чем остановиться на каком-либо новом подходе к разработке, который обещает большие улучшения, спросите себя: «Что мешает нам уже достичь этих лучших результатов?»

№52. Не спрашивайте: «Что это для меня?» Спросите: «Что это для нас?» Иногда новый подход окупается не для каждого, но помогает команде в целом.

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

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

№55. У вас нет времени на каждую ошибку, которую каждый практикующий до вас уже сделал. Учитесь у тех, кто делал это раньше, чтобы сгладить кривые обучения и уменьшить количество ложных шагов.

№56. Хорошее суждение и опыт иногда важнее определенного процесса. Процесс не заменяет размышления, но необходимо понять цель шага, который вы ставите под сомнение, прежде чем вы решите его пропустить.

№57. Придерживайтесь философии уменьшения размеров с помощью шаблонов документов. Соответствующим образом адаптированные шаблоны обеспечивают единообразные способы организации информации и выявления недостающей информации.

№58. Если вы не потратите время на обучение и совершенствование, не ожидайте, что следующий проект будет лучше предыдущего. Ретроспективы предлагают мощные возможности обучения, которые напрямую влияют на усилия по улучшению процессов.

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

Что делать дальше

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