Уроки из книги "Жемчужины разработки". Краткий перечень

Книга "Жемчужины разработки. Чему мы научились за 50 лет создания ПО".
ISBN: 978-5-4461-1986-8
Ссылка: https://www.piter.com/collection/all/product/zhemchuzhiny-razrabotki-chemu-my-nauchilis-za-50-let-sozdaniya-po

Требования

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. Остерегайтесь "менеджмента по Businessweek".
52. Не спрашивайте: "Что даст мне?" Спрашивайте "Что это даст нам?".
53. Боль - лучшая мотивация для изменения методов работы.
54. Внедряя новые методы работы, делайте это мягко, но непрерывно.
55. У вас нет времени, чтобы совершить все ошибки, сделанные до вас.
56. Здравый смысл и опыт иногда важнее определённого процесса.
57. Адаптируйте готовые шаблоны документов.
58. Если не тратить время на учёбу и совершенствование, то не стоит ждать, что следующий проект будет реализован лучше предыдущего.
59. Самая удручающая закономерность в индустрии программного обеспечения - повторение одних и тех же неэффективных действий снова и снова.

Универсальный урок

60. Невозможно изменить всё сразу.