ruGuardian

Ответ на подобный вопрос зависит от ответственности ПО. Вообще сценарии составляются на основе требований. Не абстрактных лозунгов, которые обычно пишутся в ТЗ, а требований с однозначными техническими характеристиками. Если проект ответственный, требующий сертификации (ПО для транспорта, например), это вопрос регулируется соответствующими стандартами, по которым производится сертификация. В частности для гражданской авиации, есть документ DO-178 (российский перевод - КТ-178 и менее требовательный аналог ГОСТ-51904), определяющий например, что на основе требований к системе, разрабатываются требования верхнего уровня к ПО (параллельно - к железу), на основе которых создаётся дизайн и требования нижнего уровня, на основе которых уже код, а тестировщики пишут тесты верхнего уровня по требованиям верхнего уровня (проверка функционала всего приложения) и тесты нижнего уровня по требованиям нижнего уровня (юнит тесты). Получается реализация и независимая верификация по общим исходным данным для программиста и тестировщика. Причём здесь не нужно полагаться на опыт и изощрённость тестировщика, он просто достигает цели по явным критериям, это прозрачно и управляемо. Но это очень дорого и долго.
В вашем случае, конечно, процессы разработки будут гораздо проще, но здесь вы должны понимать, что усиление процесса верификации неизбежно потребует затрат. Чудес не бывает, как и тестировщиков которые без документации покрывают как боги. Здесь явно требуется бОльшая формализация, а значит хотя бы ещё один уровень детализации после ТЗ. Насколько детализировать - зависит от того, сколько вы готовы на это потратить. Процент выгребания багов будет соответствующий.

В теории теория и практика совпадают. А на практике...
Можно очень долго пытаться строить из себя тайм менеджера крупного звена, играться с формулами, учитывать коэффициэнты форс-мажоров и никогда не стать вангой. Но сама жизнь подсказывает вам решение. Я с удовольствием использую этот метод и не подводило никогда. Следует набросать план и умножить срок на Пи. И признаться себе в том, что несмотря на твою гениальность и работоспособность - так оно и будет. Это психология нас подводит. Даже самый детальный план с десятками подзадач не включает такие пункты как: обед, сон, я заболел, я напился, кошка окотилась, теща приехала и т.д.. Оценивая задачу вы исходите из 100% занятости и максимальной фокусировке. Умножайте время на Пи это гарантированный прогноз (к финансовым тратам это относится аналогично).

Пишу на С++ более 10 лет и не уверен, что знаю этот язык. :)
В свое время учился по Б.Эккелю - Философия С++, там много задач, после решения которых можно делать осторожные заявления, что знакомы с этим языком.

Git не отслеживает изменения бинарных файлов, а docx, как и odt - это zip архив.
У меня сейчас схожая проблема и я сегодня накопал про формат flat xml. Это документ в том же формате, что и odt, но одним файлом и несжатый. Либреоффис ест с удовольствием. Его гит будет отслеживать, но, естественно, в сыром формате - смотреть диффы будет не очень удобно. И мелкомягкие такое не поддерживают.

Харрис и Харрис «Цифровая схемотехника и архитектура компьютера»
Там про всё и то, что вам нужно - тоже. Правда архитектура mips, но в вашем случае это скорее даже плюс.