Доходило до того, что при нахождении бага где-то на продакшне разработчики не могли его чинить, т.к. на это требуется задача, чтобы списывать туда время.
— расскажите, как вы скрещиваете поддержку и разработку? или что, надо поделить команду на 2 части: разработку и support?
Выводы 1, 2 очень спорные:
«она помогает правильно организовывать код, правильно называть классы и функции.»- да, ладно. Вы вкладываете в смысл организация кода явно не структуру файлов, каталогов и тд.
и про название классов и функций тоже мимо.
«Во-вторых, теория категорий позволяет писать универсальные алгоритмы» — универсальные для чего? Может он один универсальный алгоритм-то… Или если он не один, то почему они все универсальные…
Практического приложения не хватает очень…
Документ №1 (основное ТЗ): Сделать поле 1.
Документ №2 (Дополнение №1 к ТЗ): Сделать поле №2.
то:
1. удивительно, что оно на 40 страниц
2. это плохое ТЗ
Правильнее писать в ТЗ верхнеуровневый список функциональности, которая будет сделана, например:
шаг 1 Ввод клиентских данных
шаг 2 Сохранение клиентских данных.
«она помогает правильно организовывать код, правильно называть классы и функции.»- да, ладно. Вы вкладываете в смысл организация кода явно не структуру файлов, каталогов и тд.
и про название классов и функций тоже мимо.
«Во-вторых, теория категорий позволяет писать универсальные алгоритмы» — универсальные для чего? Может он один универсальный алгоритм-то… Или если он не один, то почему они все универсальные…
Практического приложения не хватает очень…
Привычка к BPMN: ищу хорошо заметное начало схемы слева вверху, не вижу, взгляд начал бегать.
то:
1. удивительно, что оно на 40 страниц
2. это плохое ТЗ
Правильнее писать в ТЗ верхнеуровневый список функциональности, которая будет сделана, например:
шаг 1 Ввод клиентских данных
шаг 2 Сохранение клиентских данных.