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

Отзывы о книге
Предисловие
Благодарности
Об авторе
От издательства
Глава 1. Обучение на собственном опыте
Моя точка зрения
О книге
Примечание о терминологии
Ваши возможности
Глава 2. Требования
Введение
Множество типов требований
Подобласти разработки требований
Роль бизнес-аналитика
Требования — это фундамент
Урок 1
Если требования не будут удовлетворены, то неважно, насколько хорошо вы выполните остальную часть проекта
Правильные требования — но когда?
Правильные требования — но как?
Урок 2.
Основной результат разработки требований — общее вˆидение и понимание
Урок 3
Интересы всех заинтересованных сторон нигде не пересекаются так явственно, как в требованиях
Анализ заинтересованных сторон
Кто звонит?
Мы все на одной стороне
Урок 4
В требованиях в первую очередь важны особенности использования, а затем — функциональность
Зачем нужна лишняя функциональность?
Ставим особенности использования на первое место
Проблема пользовательских историй
Правила использования
Урок 5
Разработка требований — итеративный процесс
Постепенное уточнение деталей
Возникающие функциональные требования
Возникающие нефункциональные требования
Урок 6
Agile-требования не отличаются от других
Роли и обязанности
Терминология
Детальность документации
Выбор времени для выполнения действий
Готовые формы
Когда расставлять приоритеты
Есть ли разница?
Урок 7
Запись знаний обходится дешевле, чем повторное их обретение
Страх письма
Преимущества письменного общения
Разумный баланс
Урок 8
Главное требование к разработке — налаженное и эффективное общение
Разные аудитории, разные потребности
Выбор методов представления
Мы можем поговорить?
Урок 9
Качественность требований определяется смотрящим
Многообразие получателей требований
Контрольный список для оценки качественности требований
Урок 10
Требования должны быть достаточно хорошими, чтобы разработка могла продолжаться с приемлемым уровнем риска
Уровень детализации
Достаточно — это сколько?
Урок 11
Люди собирают требования не просто так
Сбор и выявление
Когда выявлять требования
Контекст выявления
Методы выявления
Закладка фундамента
Урок 12
Выявление требований должно помочь разработчикам услышать голос клиента
Способы взаимодействий
Менеджер по продвижению продукта
Другие пути передачи требований
Преодоление разрыва
Урок 13
Две распространенные практики выявления требований — телепатия и ясновидение. Но они не работают
Угадай это требование!
Старайтесь выражаться ясно
Телепатия терпит неудачу
Урок 14
Большая группа людей не способна организованно покинуть горящую комнату, не говоря уже о том, чтобы сформулировать какое-то требование
Концентрируйте внимание!
Координатор во спасение
Фокус, фокус, фокус
Не ограничивайтесь обсуждениями в группах
Урок 15
Избегайте расстановки приоритетов по децибелам, когда принимаете решение о добавлении функций
Методы определения приоритетов
Критерии выбора приоритетов
Анализ превыше громкости
Урок 16
Без задокументированного и согласованного проекта нельзя узнать, увеличивается ли его объем
Призрак разбухания проекта
Как документировать объем
Это входит в рамки проекта?
Расплывчатые требования = расплывчатый объем проекта
Глава 1. Проектирование
Введение
Различные аспекты дизайна
У вас хороший дизайн?
Урок 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
Невозможно изменить все сразу
Приоритизация изменений
Проверка реальности
Планирование действий
Ваши собственные уроки
Приложение. Краткий перечень уроков
Список использованных источников