Порог готовности

Шаги между началом работы и результатом не имеют для нас значения, а потому они хаотичны. Мы держим в голове образ конечного продукта, и стремимся к нему, на каждом этапе корректируя направление. Но промежуточные состояния — это просто… баги, фичи, строчки кода; мы не пытаемся осознанно применить какие-то критерии готовности к ним.

Предположим главный порог готовности продукта это фичи.
https://ru.wikipedia.org/wiki/Фича

Фича (англ. feature — особенность, необычное свойство, «фишка») — сленговое обозначение каких-либо необычных признаков какого-либо явления. «Фичей» могут выступать необычные программные возможности, особые функции, что-либо, что привлекает особое внимание.

Фичекат (от англ. Feature Cut) — обрезка фич. Удаление фич, которые являются излишествами, к примеру, переусложняя игровой процесс, или, в случае с ПО, не представляя необходимости (редкоиспользуемые функции).

Киллер-фича (от англ. Killer-feature — убийственная особенность) — определенная особенность или черта программного продукта, которая выделяет его на фоне конкурентов.

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

• A – главный номер версии (major version number).
• B – вспомогательный номер версии (minor version number).
• C – номер сборки, номер логической итерации по работе над функционалом версии A.B (build number).
• D – Номер ревизии, сквозной номер назначаемый автоматически программным обеспечением хранения версий (revision number).
• [r] – условное обозначение релиза.

• Pre-alpha (pa • Alpha(a) • Beta (b) • Release Candidate (rc) • Release to manufacturing • General availability (ga) • End of life (eol)

Помимо этого в трекерах задач используется разделение их на виды.

планирование, модель, требование, проектирование, конструирование, испытание, ошибка, документирование, развёртывание, сопровождение

Последнее даёт распределение задач различным специалистам, для, примера, менеджерам, бизнес аналитикам, системным аналитикам, архитекторам по, разработчикам кода, тестировщикам и так далее. Любая фича является данными, в свою очередь это значит она может подчиняться действиям языка управления данными.
https://ru.wikipedia.org/wiki/Data_Manipulation_Language

Функции языков DML определяются первым словом в предложении (часто называемом запросом), которое почти всегда является глаголом. В случае с SQL эти глаголы — «select» («выбрать»), «insert» («вставить»), «update» («обновить»), и «delete» («удалить»). Это превращает природу языка в ряд обязательных утверждений (команд) к базе данных.

В итоге запрос select должен выполняться для любой фичи, а каждая сборка имеет список работы над фичами:

product_0.8.13-f26ea91.rc – релиз product версии 0.8, сборка 13, ревизия f26ea91, релиз-кандидат
-insert фича_123
-insert фича_124
-update фича_080
-update фича_101
-delete фича_057

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

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

Будем считать продуктом не только завершенную программу, но и:

алгоритм
класс
фичу
метод или функцию
пофиксенную багу
юнит-тест
джавадок
билд-скрипт
и т.д.

И какова тогда целесообразность создания задач на трекере по каждой фиче, например, для метода:

-insert фича_123
--конструирование
--испытание
--документирование

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

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

Здравствуйте, velkin, Вы писали:
V>Конечно, можно воспользоваться старым добрым хаосом и без проблем написать небольшой проект, но интересно поразмыслить над современными технологиями разработки программ.

Этих современных технологий была тьма тьмущая и весь менджмент почему-то хочет решить проблемы людей, какими-то техническими средствами и правилами. Каким бы не был процесс, если у вас нет команды, нет сработанности и нет профессионалов, то никакие СОВРЕМЕННЫЕ технологии вам не помогут.
90% времени на легаси получатея в результате того, что проект развивается хаотично. Каждый решает только свою задачу, без оглядки на перспективу и без понимания того, укладывается ли его задача в общую концепцию.
А все новые современные технологии маркетинговое надувание щек. Видел хороший код еще в 2004 году без всяких скрамов аджайлов и т.д.