Метод разработки ничего не скажет об организации
Не ждите от описаний метода разработки каких-то деталей. Скорее, детали вы найдёте в литературе по отдельным практикам.
Орг-проектировщики обычно кладут в основу концепции организации метод разработки, по которому будет работать организация. Часто это даже не полный метод разработки, а только те практики, которыми будет заниматься организация. Скажем, только практики изготовления системы, но не её проектирования. Или наоборот --- только проектирования, но не изготовления. В отличие от инженеров целевой системы, которых тренируют думать о полных методах разработки (всё время создания и развития по ходу всех проектов! Учитывать и то, что уже происходило с системой и её описаниями, и то, что только будет происходить в будущем, включая попытки предсказать это будущее!), у орг-проектировщиков, а также у менеджеров в их разговорах с инженерами во внимание обычно попадает только та часть практик метода разработки, которыми занимается вверенное им оргзвено, оно для них «наша система».
Не ждите от описаний метода разработки какой-то оргструктуры (органиграммы: кто кому подчиняется, решения орг-проектировщика) или структуры управления (централизованной, децентрализованной, матричной, функциональной и т.д., решения орг-архитектора). То есть в методе разработки не будут указаны отделы, команды. Не будут указаны сроки. Но будут указаны практики (прежде всего дисциплины, но и упомянута технология).
Метод разработки --- это поведение создателей, поэтому он представляется развёртками во времени: пару десятков лет назад это была диаграмма работ-стадий в физическом времени, современный вариант --- это функциональная диаграмма связи практик в логическом времени, а самый современный вариант представляет собой исполняемые варианты в каких-то табличных моделерах, часто связанных с issue tracker, что позволяет связать в жизни управление процессом/методом/практиками разработки (управление жизненным циклом) с управлением работами.
При обсуждении метода разработки вопрос «кто это выполняет» обычно остаётся за рамками обсуждения, а назначение ресурсов поднимается только при обсуждении управления работами/операционного управления. Например, обсуждаем выбор практики создания концепции системы (практики, которые будут изменять состояния альфы концепции системы), а потом назначаем работы по выбранной практике на оргзвено, имеющее оргвозможность/capability выбранную практику выполнять (то есть имеет людей с нужным мастерством, моделеры с нужными шаблонами, или на которых можно эти шаблоны получить, а также полномочия по трате времени и других ресурсов на выполнение этой практики, да ещё и это время, и все другие ресурсы наличествуют). Это два разных вопроса: 1. Как будем работать и 2. Кто будет работать. Сама работа получается только после ответа на оба вопроса!
Физическое время тоже нельзя найти в описаниях метода разработки, там «работы по практикам выполняются, когда возникнут для этого обстоятельства». Физическое время надо смотреть в моделях управления работами (планы-графики в системах проектного управления, штампы времени в выдачах трекеров) соответствующих проектов, а на диаграммах жизненного цикла или описаниях практик их не увидишь.
А если посмотреть на постепенный переход на методы разработки продуктных линий (product lines, иногда product families, когда из стандартных модулей собираются разные конфигурации системы для разных потребностей, и это происходит на нескольких уровнях платформ этих продуктных линий), жизненные циклы разных таких платформ как частей системы или систем в окружении могут быть переплетены причудливым образом. Нужно всегда помнить, что системы выделяются из окружающего мира субъективно (хотя это и хорошо организованная субъективность! Все договариваются, системное мышление для этого!), в зависимости от деятельностного/ролевого/трудового/практического предмета интереса и предпочтений в важных для ролей характеристиках этих систем, и тем самым выделение метода разработки как объекта из окружающего мира тоже субъективно. Разные люди с разным опытом и предложат разные методы разработки для одной и той же системы, и опишут по-разному практики уже полным ходом идущей разработки, признают в ней разные методы разработки/модели жизненного цикла.
Ещё нужно помнить, что метод разработки может существенно дрейфовать по ходу проекта. Там постоянно будет идти совершенствование, будут заменяться технологии, но в любой момент может быть затеян переход на новые практики работы --- организация, занимающаяся созданием и развитием системы будет непрерывно развиваться. Развитие организации --- это и есть изменение метода разработки прежде всего.
Нужно всегда помнить, что должна быть оргвозможность управления методом разработки: кто-то::роль с его инструментами моделирования методов и мастерством это делать должен проектировать метод разработки и превращать его в оргвозможность (чаще всего это ответственность CTO или CIO), договариваться со всеми причастными. У ответственного за метод разработки должны быть полномочия убирать из проекта (а то и увольнять из компании) сотрудников, которые не хотят или даже просто не умеют работать по практикам выбранного метода разработки. Если какой-то инженер будет считать, что он работает по «водопаду» в команде, которая придерживается какого-то варианта гибких методов разработки, то или он смиряется и тоже работает по предложенным практикам гибкой разработки, или просто увольняется (уговаривать может быть дольше и дороже: он успеет своей вроде как работой нанести много вреда, будет ведь много конфигурационных коллизий, которые потребуют тратить на его упрямство и неумение время многих других инженеров. Проще уволить, и это правильно: пусть вовремя повышает квалификацию).
Обязательно узнайте метод разработки не только целевой системы, вашей системы где-то в цепочке создания, но и их надсистем, и систем создателей (то есть методы разработки, которые применяют внешние проектные роли в проектах создания всех этих систем). И у систем в окружении целевой, и у создателей (станков, организаций), как и любых других систем, тоже есть свои методы создания и развития, а также для работ по их созданию и развитию тоже используют методы управления работами: альфы и описаний, и воплощений этих систем тоже проходят через цепочку разных состояний от «системы ещё нет» через «система разрабатывается» и «система эксплуатируется» к состояниям развития «система в очередной раз модернизируется и продолжает эксплуатироваться».
Вот это одновременное удержание внимания на целевой системе в её окружении в первую очередь, но и работах по практикам выбранного метода создания и развития (поведении системы создания) во вторую очередь и отличает системного мыслителя. Системное мышление ---это всегда первый мыслительный ход от целевого объекта рассмотрения наружу, к окружению, а не внутрь к частям. Затем внутрь к частям --- и после этого обязательно к практикам создателей этих частей целевой системы, а затем и к исполнителям этих практик (оргролям и играющим их оргзвеньям).
Системы всегда находятся в окружении, а ихсоздание и разработку ведёт какой-то создатель, ведь системы очень редко создают сами себя. Поэтому во внимании всегда должна быть не только целевая система или система создания, но целевая система, системы в её окружении и системы в длинных цепочкахсоздания. Собранность при удержании этого внимания, в том числе собранность, обеспечиваемая документированием моделей всех этих упомянутых систем, включая моделирование методов разработки и включённых в них практик. Не надейтесь на системное мышление «в уме», надейтесь на мышление моделированием и мышление письмом!