Правила разработки ПО, издание 2006. Маккарти Мишель, Маккарти Джим В оригинале “Dynamics of Software Development (Pro-Best Practices)” by Michele McCarthy, Jim McCarthy

Нашёл в закромах давным-давно купленную книжку. Решил перечитать. Ну и дрянь же! Решил законспектировать, чтобы больше к ней не возвращаться.

Книга про то, чему научился автор, работая в MS над Visual C++. Где-то к середине авторы устали обосновывать собственные тезисы и просто набрасывают на вентилятор.

Если оставить только суть, правила выглядят так:

Организация

1. Добивайтесь общего видения.

Каждый в команде должен знать, что будет делать команда, как будет выглядеть продукт, какова базовая стратегия создания продукта, и когда команда должна выпустить продукт. Если общего видения нет, о качественном продукте не может быть и речи. Под угрозой даже сам факт выпуска продукта.

2. Привлекайте каждую голову в дело

Каждый член команды должен думать, какое поведение эффективнее всего в данном случае. Чем больше идей, тем лучше. При обсуждении проблемы, само осознание, что идей недостаточно, уже является огромным шагом вперёд. На каждом совещании каждый должен выдавать мо меньшей мере одну-две хороших идеи. Лучшие идеи должны находить применение.

3. Создайте технологический план выпуска версий

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

Одна из проблем в том, что у разработчиков слишком большие амбиции. Но если у людей есть вера в будущее, у них нет нужды реализовывать все задумки ИМЕННО В ЭТОЙ ВЕРСИИ.

4. Не устанавливайте бит ничтожества

Не выключать из общения человека, который неправильно понимает критическую обратную связь. Не выключать людей, которые назойливо пристают с идеями или запросами на обратную связь.

5. Используйте разведчиков

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

Определять минимальные конфигурации, требования к ресурсам, полготовка прототипов, выявление обоснованности предположений для следующей версии.

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

6. Соблюдайте пропорции

Ошибка руководителей: найм только разработчиков. Группа разработки: 6 разработчиков, 2-3 тестировщика, 1 руководитель проекта, 2 тех. писателя. Не обязательно числа именно такие: главное - равновесие

7. Используйте команду по особенностям

Отказаться от выстраивания иерархии подчинения и выстраивать команду, где каждый дополняет друг друга. Где спросив тестировщика: “В чём заключается твоя работа?” Он ответит: “Выпустить продукт”. Не тестировать, а именно выпустить. Все работают для достижения единой цели, а не решения своих задач.

Кейворды: наделение полномочиями, ответственность, идентификация с частью продукта, а не ролью в проекте, разрешение конфликтов внутри, без эскалации.

8. Используйте руководителей проекта

У руководителя проекта мало официальной власти (или вовсе нет). Ошибка: выпрашивать дополнительные полномочия.

Руководитель должен уметь уговаривать, содействовать, вдохновлять, требовать совершенства и эффективной работы. Должен знать все тонкости, необходимые для выпуска ПО в срок. Быть представителем команды перед руководством, клиентами, прессой и т.п.

Программное обеспечение выражает команду, его создавшую. Команда = ПО

9. Будьте властью, но не фигурой власти

Цель: сделать властью каждого члена команды, а не загребать власть на себя. Команда должна иметь власть как индивидуальную, так и коллективную.

Быть настоящей властью, а не фиктивной, спущенной по указке сверху. Сфокусировать внимание на выпуске продукта. Подключите все ресурсы, игнорируйте иерархические и функциональные границы, следите за выпуском продукта в срок. Отбросьте все формальности.

Конкуренция

10. Вы в одиночестве? Рынка без конкуренции не бывает

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

11. Идёте бок о бок с конкурентами? Избегайте перестрелки отличительными особенностями

В ситуациях с интенсивной конкуренцией часто компании приходят к “перестрелке” отличительными особенностями продуктов. Это дорогой и неэффективный способ конкурировать. К тому же, перегруженный функциями и отличительными особенностями продукт становится раздутым и ненадежным.

Внедрите несколько особенностей, изменяющих парадигму продукта. Чтобы чувствовать себя безопасно потребуется как минимум три таких особенности. После вашего прорыва конкуренту придётся вернуться на стадию проектирования, даже если он обгонял вас по функциям.

Прекращайте перестрелку функциями и переходите к изменению парадигмы.

12. Вы позади конкурентов? Выпускайте продукт чаще и с новым содержанием

Сократите усилия на пиар. Не делайте предварительных объявлений. Если в продукте было много ошибок, вы должны исправить их и выпустить исправленную версию. Постарайтесь сделать это не за счёт клиентов. Лучший подход к лидирующей позиции: непреклонность.

13. Вы впереди конкурентов? Не оглядывайтесь назад

Вам надо конкурировать с самим собой. Установите такую скорость перемен, чтобы никто не смог сравниться с вами. Продолжайте рисковать, пресекая всякие попытки возврата назад. Самоуспокоенность убивает.

14. Глотните кислорода

Это эмпирическое правило касается эстетики. Научить клиента решать его задачи лучше, используя новые возможности продукта. Для этого продукт должен постоянно улучшаться.

Клиент

15. Приведите клиента в восторг

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

Понимание рынка - основа для создания качественного ПО. Покажите на протяжение двух-трёх версий понимание рынка и это обеспечит огромную верность клиентов и даст знак качества вашему продукту.

Как определить, что приводит клиента в раздражение? Спрашиваайте у них! Пишит письма, звоните, встречайтесь на выставках, организуйте фокус-группы.

16. Найдите точку наилучшего восприятия рынка

Точка пересечения ценностей. Она всё время движется, но если продукт непрерывно бьёт в неё, то он завоюет рынок как бы сам по себе.

Microsoft выпустил VC++. Аналитики, пресса и клиенты, все, как один говорили, что для того, чтобы перейти на VC++ им не хватает специальных возможностей языка и просили включить их в продукт. Но и внедрение было крайне дорогим и трудоёмким, поэтому в MS провели исследования и выяснилось, что менее 15% пользователей перешли с C на C++. Людей пугала сложность C++.

17. Бизнес ПО - отношения, а не продажа

Поняв, что пользователи не могут перейти на С++ из-за его сложности, в Visual C++ добавили мастер (wizard). Пользователь выбирал типичный шаблон использования языка, а мастер создавал готовый код, не требуя программирования. Мастер позволил увеличить долю на рынке на десятки пунктов.

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

18. Уменьшайте время цикла разработки

Отношения с рынком лучше поддерживать путём частых и честных сообщений. Лучшие сообщения - это выпуск новых версий продукта.

Выпуск ПО в срок и частый выпуск версий приносит лучший результат, чем великие революционные достижения, выдаваемые редко.

Большое число маленьких усилий почти всегда более эффективно, чем одно большое усилие.

Проект

9. Боритесь за качество

Как? А х.з. Попробуйте вспомнить Леонардо.

20. Сформулируйте тему

Тема ПО - это идея, которая создаёт основу для проектирования. Вс остальные особенности нужно выбросить, принести в жертву. Публичные сообщения о продукте тоже нужно прогнуть под тему. Если они в тему не укладывается - выбросите эти сообщения.

21. Минимизируйте зависимости

Наличие зависимостей - очень серьёзная проблема. Подвергайте целесообразность каждой зависимости самому глубокому анализу.

22. Умиротворяйте богов

Сходу выбросите (отложите на следующую версию) какую-либо фичу. Какую? В описании которой больше всего неопределённости или сомнений в целесообразности реализации.

23. Тщательно выбирайте платформу

Зачем? Почему? Как?… А выберете неправильную - загубите проект.

24. Устанавливайте сроки на стадии проектирования

Лучше указать сроки выпуска продукта и обосраться, чем не указать и обосраться… Ну, я бы поспорил.

Разработка

25. Не слушайте диктатов

Около трети усилий разработчиков страдают (по их собственным словам) от навязанных фичей, ресурсов и дедлайнов.

Человек, которому предстоит выполнить работу, обычно не в состоянии спрогнозировать, сколько времени она займёт. Единственное спасение - в составлении графика разработки снизу вверх.

26. Теперь приступайте к игре

Не разрабатывайте ПО. Играйте в разработку ПО. Как это должно помочь, интересно?

Середина игры

27. Действуйте как врач

Не говорите конкретно. Всё ставьте под сомнение.

28. Помните треугольник: фичи, ресурсы, время

Возможны только четыре варианта: добавить время, вырезать часть фичей, увеличить ресурсы, применить все три в какой-то комбинации.

Добавление людей в команду приводит к задержкам выпуска (Брукс, Мифический человеко-месяц). Но иногда добавить людей - спасение. Как отличить ситуацию когда для спасения нужно добавить людей от ситуации, когда добавление людей убьёт проект окончательно? Ээээ…

29. Не делайте вид, будто вам всё известно

Не бойтесь сказать, что вы чего-то не знаете. При малейшем сомнении записывайте факт в “неизвестное”. Это намного здоровее для продукта, чем притворяться, что вы в курсе всего.

30. Не уходите в темноту

На пороге майлстоуна вы спрашиваете ведущего разработчика: “Как дела?” Знаешь, - отвечает он, - у меня дела шли прекрасно последний месяц, но сегодня всё плохо. Мы отстаём от графика на полгода.

Не отрывайтесь от команды/продукта дольше, чем нам половину спринта. Дайте возможность исправить отставание.

Неделя - это очень много, если неизвестно, что происходит.

Да, вам будет прилетать за “микроуправление”, но главное самому себе отдавать отчёт в пределах влияния, и не скатываться в микроменеджмент по своей собственной оценке, чем оставить всё на самотёк.

31. Опасайтесь человека в комнате

Поручив супер-элитному разработчику какую-то часть проекта, и оставив его без контроля, вы рискуете получить сорванные сроки, выгоревшего разработчика, и проблемы с пониманием текущего состояния дел. Не оставляйте разработчика наедине с проблемой.

32. Регулярно проводите сборку продукта

Тут даже и обсуждать нечего. Проводите! Регулярно! А в 21 веке так вообще модно CI/CD.

33. Достигните состояния ясности и оставайтесь в нём

Дурацкая формулировка, но по сути, это “имей в каждый момент времени продукт, готовый к поставке”. В 20 веке это звучало, как открытие, а сейчас этим уже никого не удивить.

Научитесь отмечать прогресс

34. Используйте бездефектные контрольные точки

Периодически устраивайте приёмочное тестирование как перед выпуском продукта, даже если вы в середине разработки.

35. Никто не достигнет контрольной точки раньше остальных

Если часть команды уже заверила работу, а другая задерживается - не расслабляйтесь. Бросайте высвобожденные ресурсы в помощь!

36. Каждая контрольная точка заслуживает обсуждения без поиска виновных

Наказывать за факап дедлайна не стоит. Умные люди сами поймут (???) что обосрались и больше так не будут. Лол!

37. Придерживайтесь буквы и духа контрольной точки

Конкретики не будет, просто придерживайтесь, ок? Ну, пожалуйста!

38. Держите рукоятку в положении “Норма”

Какую рукоятку? Что такое “норма”? Просто держите и не допускайте факапов, ладно?

39. Горсть контрольных точек - это немного

Каждый майлстоун (контрольная точка) - от месяца до трёх. Если в проекте больше семи майлстоунов - это проблемный проект. Оптимальное значение для проекта - три или четыре, плюс один при выпуске продукта.

40. Каждая контрольная точка имеет историю

“История” - это пара предложений, описывающих простым языком, что даст эта контрольная точка. Люди готовы бороться и достигать только того, что им понятно. За непонятную цель никто биться не будет.

41. Ищите естественные контрольные точки

В идеале иметь майлстоуны, для которых даже выдумывать ничего не надо: прохождение внутреннего тестирования, тестовая эксплуатация на фокус-группе и т.п.

42. Если что-то не получается, не падайте духом

Шесть (!) листов воды. Благо тема плодотворная. Ну вы же не падаете, да!?

43. Не меняйте дату на такую же плохую дату

Как только вы поняли, что проект опаздывает, любая новая конкретная дата - ложь. Лучше всего вообще ничего не менять, пока не станет очевидно понятно, что же пошло не так, и из-за чего пришлось двигать сроки.

44. После опоздания достигайте следующую контрольную точку вовремя, ни смотря, ни на что

После факапа важно восстановить веру в себя. Изо всех сил постарайтесь достичь следующего майлстоуна в запланированный срок, который не учитывал факапа промежуточных сроков.

45. Сделайте опоздание положительным переживанием

Извлеките опыт из факапа. Разберите его предпосылки и стратегию развития. Научитесь распознавать его на раннем этапе.

Пересмотрите фичи продукта. Может быть, часть вы и так собирались отложить?…

46. Наблюдайте за всем

Вообще не понял посыла этого пункта… “Наблюдайте. Не делайте плохо, делайте хорошо”.

47. Изменяйтесь вместе с миром

Каждый день мир будет меняться, требование к нему будут меняться, продукт будет меняться, требования к продукту будут меняться…

Типа, следите, что вообще происходит. Может быть ваш проект стал никому не нужен. Или наоборот: его ценность выросла в тысячу раз и любая ошибка теперь стоит миллион.

Режим выпуска

48. Оскверните хотя бы одну “священную корову”

Нарушьте формальное правило с целью демонстрации того, что вы за команду, за людей. (Интересно, авторы вообще это пробовали? Больше одного раза это не работает! Эпатаж очень быстро приедается)

49. Бета-тестирование - не время для внесения изменений

Фича-фриз - это альфа. В бете только и исключительно исправление ошибок, никаких рефакторингов и широких изменений. Только точечные!

50. Бета-версии - для разработки посланий

Можно эксплуатировать первое впечатление от бета-версии. То впечатление, которое тестировщик получит при первом опыте, то он и будет распространять клиентам. И пусть версия в целом забагована, но первым впечатлением всё равно будут делиться.

51. Сортируйте дефекты безжалостно

Если проблема не мешает зарабатывать деньги прямо сейчас - подвинем её вперёд. Если проблема редкая и не связана с получением прибыли: пожалуй, не будем её исправлять никогда.

52. Не взбалтывайте шампанское

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

Запуск

53. Придумайте подходящую историю

Придумайте легенду продукту. Всегда позиционируйте продукт так, как сформулировали идею. Даже при поездке в деревню в баню. Никогда не противоречьте легенде.

54. Создайте образ победителя

Станьте победителем Продавайте продукт для победителей

Если вы ещё не победитель: ну… станьте победителем.

Новые эмпирические правила (добавлены в 2006)

55. Будьте идеальным боссом

Идеальный босс рассматривает людей, работающих на него, как своих самых важных поставщиков. Предоставление ему услуг - это их главная обязанность.

Отказывается выступать в роли родителя или судьи в конфликтах между подчиненными. Запрещает людям жаловаться на других заочно.

56. Босс - самый важный клиент

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

57. Плати налог на лишний жир

Существуют затраты, которые вы навлекаете на себя каждый раз, когда имеете дело с мужчинами. Мужчины действуют эффективнее, когда между ними есть чёткая иерархия. Затраты на достижение и поддержание этой иерархии - это “налог на лишний жир”. Это сложная система неизбежных затрат, которые только увеличиваются, если их игнорируют.