Жемчужины разработки. Чему мы научились за 50 лет создания ПО

Краткое содержание Оглавление Отзывы о книге Предисловие Об авторе Благодарности От издательства Глава 1. Обучение на собственном опыте Моя точка зрения О книге Примечание о терминологии Ваши возможности Глава 2. Требования Введение Множество типов требований Подобласти разработки требований Роль бизнес-аналитика Требования — это фундамент Первые шаги: Требования Урок 1. Если вы неверно определили требования, то неважно, насколько хорошо вы выполните остальную часть работы Правильные требования — но когда? Правильные требования — но как? Урок 2. Основной результат разработки требований — общее вˆидение и понимание Урок 3. Интересы всех заинтересованных сторон нигде не пересекаются так явственно, как в требованиях Анализ заинтересованных сторон Кто звонит? Мы все на одной стороне Урок 4. В требованиях в первую очередь важны особенности использования, а затем — функциональность Зачем нужна лишняя функциональность? Ставим особенности использования на первое место Проблема пользовательских историй Правила использования Урок 5. Разработка требований — итеративный процесс Постепенное уточнение деталей Возникающие функциональные требования Возникающие нефункциональные требования Урок 6. Agile-требования не отличаются от других Роли и обязанности Терминология Детальность документации Выбор времени для выполнения действий Готовые формы Когда расставлять приоритеты Есть ли разница? Урок 7. Запись знаний обходится дешевле, чем повторное их обретение Боязнь рутины Преимущества письменного общения Разумный баланс Урок 8. Главное требование к разработке — налаженное и эффективное общение Разные аудитории, разные потребности Выбор методов представления Мы можем поговорить? Урок 9. Качественность требований определяется смотрящим Многообразие получателей требований Контрольный список для оценки качественности требований Урок 10. Требования должны быть достаточно хорошими, чтобы разработка могла продолжаться с приемлемым уровнем риска Уровень детализации Достаточно — это сколько? Урок 11. Люди собирают требования не просто так Сбор и выявление Когда выявлять требования Контекст выявления Методы выявления Собеседования Групповые семинары Наблюдение Анализ документов Опросы Вики Прототипы Закладка фундамента Урок 12. Выявление требований должно помочь разработчикам услышать голос клиента Способы взаимодействий Менеджер по продвижению продукта Другие пути передачи требований Преодоление разрыва Урок 13. Две распространенные практики выявления требований — телепатия и ясновидение. Но они не работают Угадай это требование! Старайтесь выражаться ясно Телепатия терпит неудачу Урок 14. Большая группа людей не способна организованно покинуть горящую комнату, не говоря уже о том, чтобы сформулировать какое-то требование Концентрируйте внимание! Координатор во спасение Фокус, фокус, фокус Не ограничивайтесь обсуждениями в группах Урок 15. Избегайте расстановки приоритетов по децибелам, когда принимаете решение о добавлении функций Методы определения приоритетов Критерии выбора приоритетов Бизнес-цели Группы пользователей Частота использования Соответствие нормативным требованиям Основополагающая функциональность Рискованная функциональность Анализ превыше громкости Урок 16. Без задокументированного и согласованного проекта нельзя узнать, увеличивается ли его объем Призрак разбухания проекта Как документировать объем Это входит в рамки проекта? Расплывчатые требования = расплывчатый объем проекта Следующие шаги: Требования Глава 3. Проектирование Введение Различные аспекты дизайна У вас хороший дизайн? Первые шаги: Проектирование Урок 17. Проектирование дизайна — итеративный процесс Сила прототипов Проверка концепции Макеты Урок 18. Чем выше уровень абстракции, тем проще выполнять итерации Отступая от деталей Быстрые визуальные итерации Итерации стали проще Урок 19. Разрабатывайте продукты так, чтобы их легко было использовать правильно и трудно — неправильно Не давайте пользователю возможности ошибиться Затрудните пользователю возможность ошибиться Упростите исправление допущенной ошибки Просто позвольте ошибкам случиться Урок 20. Невозможно оптимизировать все желаемые атрибуты качества Измерения качества Определение атрибутов качества Проектирование для качества Архитектура и атрибуты качества Урок 21. Проблемы легче предупредить, чем исправить Технический долг и рефакторинг Архитектурные недостатки Урок 22. Проблемы многих систем скрываются в интерфейсах Технические проблемы с интерфейсами Проверка входных данных Проблемы с пользовательским интерфейсом Сложности с интерфейсами Следующие шаги: Проектирование Глава 4. Управление проектами Введение Управление персоналом Управление требованиями Управление ожиданиями Управление задачами Управление обязательствами Управление рисками Управление коммуникациями Управление изменениями Управление ресурсами Управление зависимостями Управление контрактами Управление поставщиками Устранение препятствий Первые шаги: Управление проектами Урок 23. При планировании работ нужно учитывать разногласия Переключение задач и поток Эффективные часы Другие источники разногласия в проекте Последствия планирования Урок 24. Не давайте оценок наугад Поспешные прогнозы Страх неопределенности Урок 25. Айсберги всегда больше, чем кажутся Резерв времени Рискованные оценки Контракты на айсбергах Достоинства резервов времени Урок 26. Ваши переговорные позиции будут сильнее при наличии обосновывающих данных Откуда вы взяли эту цифру? Принципиальные переговоры Урок 27. Не записывая оценки и не сравнивая их с тем, что произошло на самом деле, вы всегда будете строить догадки, а не оценивать Несколько источников исторических данных Характеристики программного обеспечения Урок 28. Не меняйте оценку в зависимости от того, что хочет услышать получатель Цели и оценки Когда корректировать оценку Урок 29. Держитесь подальше от критического пути Определение критического пути Держитесь в стороне Урок 30. Задание либо полностью выполнено, либо не выполнено: частичное выполнение не засчитывается Что означает «Готово»? Не бывает частичной готовности Отслеживание по статусу требований Готовность ведет к ценности Урок 31. Команде проекта нужна гибкость в отношении хотя бы одного из пяти измерений: масштаба, плана, бюджета, персонала и качества Пять измерений проекта Соглашения о приоритетах Диаграмма гибкости Практическое применение анализа пяти измерений Урок 32. Если вы не контролируете риски своего проекта, то они будут контролировать вас Что такое управление рисками? Выявление рисков использования программного обеспечения Мозговой штурм Исследование списка рисков из публикаций Внутренняя хронология Действия по управлению рисками Всегда есть о чем беспокоиться Урок 33. Клиент не всегда прав Быть «неправым» Конфликт запросов Решения конфликтуют с потребностями Заместитель представителя Когда клиент действует в обход Поспешность У кого больше полномочий, тот и устанавливает требования Изменения не бесплатны Уважение точки зрения Урок 34. Мы слишком многое воображаем в области программного обеспечения Жизнь в стране фантазий Иррациональное преувеличение Игры, в которые играют люди Следующие шаги: Управление проектами Глава 5. Культура и командная работа Введение Сохраняя веру Культурная конгруэнтность Кристаллизация культуры Увеличение команды Первые шаги: Культура и командная работа Урок 35. Передача знаний не ведет к проигрышу Пожиратель знаний Исправление невежества Расширение масштабов передачи знаний Технические беседы Презентации и обучение Документация Готовые шаблоны и примеры Технические обзоры Дискуссионные группы Здоровая информационная культура Урок 36. Как бы сильно на вас ни давили, не берите на себя обязательства, которые не сможете выполнить Обещания, обещания В жизни случается всякое Урок 37. Не ждите, что без обучения и освоения передовых практик продуктивность повысится как по волшебству В чем проблема? Некоторые возможные решения Инструменты и обучение Индивидуальные особенности разработчиков Урок 38. Люди много говорят о своих правах, но права подразумевают ответственность Некоторые права и обязанности клиентов Некоторые права и обязанности разработчиков Некоторые права и обязанности руководителя или спонсора проекта Некоторые права и обязанности члена автономной команды Опасения перед кризисом Урок 39. Даже небольшие физические расстояния препятствуют общению и совместной работе Барьеры пространства и времени Виртуальные команды: максимальное разделение Дверь, дверь, королевство за дверь! Урок 40. Неформальные подходы, допустимые в небольших командах, работающих в одном месте, плохо масштабируются Процессы и инструменты Необходимость специализации Коммуникационные конфликты Урок 41. Не стоит недооценивать сложность изменения культуры организации по мере перехода к новым методам работы Ценности, модели поведения и практика Agile-разработка и изменение культуры Интернализация Урок 42. Никакие инженерные или управленческие приемы не дадут эффекта, если вы имеете дело с неразумными людьми Попробуйте поделиться знаниями Кто здесь вне очереди? В пользу гибкости Следующие шаги: Культура и командная работа Глава 6. Качество Введение Определения качества Планирование качества Несколько взглядов на качество Последовательное обеспечение качества Первые шаги: Качество Урок 43. Решая вопрос о качестве программного обеспечения, вы можете выбирать: платить сейчас или позже, но больше Кривая роста стоимости исправлений Сложнее найти Ранние действия по улучшению качества Предотвращайте дефекты, а не исправляйте их Выполняйте контроль качества раньше Отслеживайте дефекты, чтобы понять их Урок 44. Высокое качество естественным образом ведет к повышению продуктивности История двух проектов Подходы Результаты Анализ Бич переделок Стоимость качества Урок 45. У организаций никогда нет времени, чтобы правильно создать программное обеспечение, но они находят ресурсы, чтобы исправить его позже Почему не сразу? Синдром 100 миллионов долларов Достижение баланса Урок 46. Остерегайтесь малозаметных разрывов между плохим и хорошим Иллюстрация малозаметного разрыва между плохим и хорошим Малозаметные разрывы между плохим и хорошим в программном обеспечении Урок 47. Никогда не поддавайтесь уговорам руководителя или клиента сделать работу наспех Умение противостоять силе Спешка в программировании Нехватка знаний Негласная этика В обход процессов Урок 48. Стремитесь к тому, чтобы дефект нашли коллеги, а не покупатели Преимущества рецензирования Разновидности ревью программного обеспечения Положительная сторона: культурные последствия рецензирования Урок 49. Разработчики программного обеспечения любят инструменты, но дурак с инструментами — это вооруженный дурак Инструмент должен добавлять ценность Инструменты должны использоваться разумно Инструмент — это не процесс Урок 50. Сегодняшний проект, требующий немедленной реализации, завтра может превратиться в кошмар для службы сопровождения Технический долг и профилактическая поддержка Осознанный технический долг Качественное проектирование — сейчас или позже Следующие шаги: Качество Глава 7. Совершенствование процессов Введение Совершенствование процесса разработки: что и зачем Не бойтесь процессов Как возвести SPI в привычку Первые шаги: Совершенствование процесса разработки Урок 51. Остерегайтесь «менеджмента по Businessweek» Сначала проблема, потом решение Пример основной причины Диагноз ведет к излечению Урок 52. Не спрашивайте: «Что это даст мне?» Спрашивайте: «Что это даст нам?» Выгода для команды Личная выгода Вносите свой вклад в общее дело Урок 53. Боль — лучшая мотивация для изменения методов работы Боль причиняет неудобства! Невидимая боль Урок 54. Внедряя новые методы работы, оказывайте мягкое, но непрестанное давление Руководство Управление вышестоящими руководителями Урок 55. У вас нет времени, чтобы совершить все ошибки, сделанные до вас Кривая обучения Хорошие практики Урок 56. Здравый смысл и опыт иногда важнее определенного процесса Процессы и ритмы Не быть догматичным Урок 57. Адаптируйте готовые шаблоны документов Расширенный шаблон спецификации требований к программному обеспечению Урок 58. Если не тратить время на учебу и совершенствование, то не стоит ждать, что следующий проект будет реализован лучше предыдущего Оглядываясь назад Структура ретроспективы После ретроспективы Урок 59. Наиболее заметная повторяемость, которой удалось добиться в индустрии программного обеспечения, — повторение одних и тех же неэффективных действий снова и снова Достоинства обучения Достоинства мышления Следующие шаги: Совершенствование процесса разработки Глава 8. Что дальше? Урок 60. Невозможно изменить все сразу Приоритизация изменений Проверка реальности Планирование действий Ваши собственные уроки Приложение. Краткий перечень уроков Требования Проектирование Управление проектами Культура и командная работа Качество Совершенствование процессов Универсальный урок Список использованных источников Accelerate Your Pursuit of Software Excellence by Learning from Others' Hard-Won Experience Karl is one of the most thoughtful software people I know. He has reflected deeply on the software development irritants he has encountered over his career, and this book contains 60 of his most valuable responses. -- From the Foreword by Steve McConnell, Construx Software and author of Code Complete Wouldn't it be great to gain a lifetime's experience without having to pay for the inevitable errors of your own experience? Karl Wiegers is well versed in the best techniques of business analysis, software engineering, and project management. You'll gain concise but important insights into how to recover from setbacks as well as how to avoid them in the first place. --Meilir Page-Jones, Senior Business Analyst, Wayland Systems Inc. Experience is a powerful teacher, but it's also slow and painful. You can't afford to make every mistake yourself! Software Development Pearls helps you improve faster and bypass much of the pain by learning from others who already climbed the learning curves. Drawing on 25+ years helping software teams succeed, Karl Wiegers has crystallized 60 concise, practical lessons for all your projects, regardless of your role, industry, technology, or methodology. Wiegers's insights and specific recommendations cover six crucial elements of success: requirements, design, project management, culture and teamwork, quality, and process improvement. For each, Wiegers offers First Steps for reflecting on your own experiences before you start; detailed Lessons with core insights, real case studies, and actionable solutions; and Next Steps for planning adoption in your project, team, or organization. This is knowledge you weren't taught in college or boot camp. It can boost your performance as a developer, business analyst, quality professional, or manager. Clarify requirements to gain a shared vision and understanding of your real problem Create robust designs that implement the right functionality and quality attributes and can evolve Anticipate and avoid ubiquitous project management pitfalls Grow a culture in which behaviors actually align with what people claim to value Plan realistically for quality and build it in from the outset Use process improvement to achieve desired business results, not as an end in itself Choose your next steps to get full value from all these lessons Register your book for convenient access to downloads, updates, and/or corrections as they become available. See inside book for details.