(предварительно – 4.12.2020)
Работая с иностранцами в одной команде над проектами в корпорации, я поражался их приверженности организационному порядку. Пока не будет некого плана с возможными перспективами, никаких телодвижений не будет.
С другой стороны, наиболее популярная работа со стороны западных читателей моих статей, оказалась статья: «Эйдос в системе концепта С2» (на ресурсах «… .edu»), на тему которая очень популярна в военно-промышленных кругах. Это все к тому, что любая организационная деятельность имеет некое системное ядро, а, следовательно, являются следствием онтологии (универсальной технологии).
Учитывая, что вышла свежая книга по методике Scrum (Рубин К.С. Основы Scrum – практическое руководство по гибкой разработке ПО, Пер. с англ. и ред. И.В. Берштейна. — Pearson Education, Inc.; CПб.: Диалектика, 2020. — 544 с.: ил. — Парал. тит. англ. — ISBN 978-5-8459-2052-2 (рус.), ISBN 978-0-13-704329-3 (англ.) ), есть смысл включить ее в условную «Big data» по онтологическим основаниям в организационной деятельности людей.
***
Автор вышеуказанной книги, опирается на первоисточник методики Scrum, о которой пишет так:
«Изобретатели методики Scrum, Джефф Сазерленд (Jeff Sutherland) и Кен Швабер (Ken Schwaber), опубликовали в 2011 году документ “The Scrum Guide” (Руководство по Scrum). Авторы описывают этот краткий документ объемом около 15 страниц как “обстоятельный свод правил Scrum и документацию собственно на Scrum”. Они приравнивают свой документ к правилам игры в шахматы, где “описывается, как перемещать фигуры, менять их позиции, что означает выигрыш и т.д.”.»
Надо сказать, что всегда существуют интерпретации первоначального замысла (иначе бы не было религии). Поскольку я увидел у Рубин К.С. некоторые искажения первоначального замысла, здесь будут приведены факты близкие к первоисточнику, который есть в русском переводе: «Исчерпывающее руководство по Скраму: Правила Игры».
Итак, для чего нужен Scrum.
«Скрам (сущ.) – фреймворк, предоставляющий спектр возможностей для продуктивной и творческой разработки продуктов с максимально возможной ценностью и решения нетривиальных задач в процессе работы.
<…>
Основными элементами фреймворка являются:
скрам‐команда;
роли, с ними связанные;
события;
артефакты;
правила.»
Я напомню, что субстанциональная сигнатура эйдоса, согласно Бартини-Кузнецова, представляет собой следующую схему: (А-1 – П1А-1 – П1А-2 – П2А-2 – П2А-3). Вышеуказанный фреймворк, если его представить его как последовательность:
команда → роли → события → артефакты → правила
очень напоминает эйдос, поскольку у него присутствует кумулятивность и эйдетическая структурность (пять статусов). Однако тут важна семантика – что понимать под членами команды (их физическую принадлежность или акторскую исполнимость, воплощённую в что-то?). А семантика держится на субстанциальных представлениях.
Согласно вышеприведенному представлению Scrum, роль активной субстанции играют члены команда как таковые, а роль пассивной субстанции – конкретную роль которую они должны исполнять процессуально. Вот собственно из этих двух компонентов и рождается сущность 2-го статуса [П1А-1] . Это дополняется тем, что такая сущность (роль) порождает организационные события. А события, в свою очередь, создают необходимое изделие (артефакт), для правильной эксплуатации которого организуются правила. Но все дело в том, что по логике эйдоса как схемы «одно» – «многое», артефакт и должен состоять из «одно», что не допустимо в таком раскладе формально, поскольку согласно сущности (роль) – она присутствует в артефакте, а такое невозможно поскольку согласно методологии Scrum, артефакт отделен от исполнителей (в частности, если это программа). Такое получается, поскольку культуры эйдосов пока еще нет на должном уровне.
Ранее, я уже представлял нечто подобное в статье – «Сингулярность как идеал эволюции»:
актор – роли – правила – сценарий – ландшафт (1)
И здесь, акторы, которые исполняют определенные роли, как и полагается в технологии «одно» – «многое» остаются в сценарии. Но если почитать внимательно работу Рубин К.С., то можно извлечь интересную мысль насчет того, что из себя представляет роль разработчика программ. А согласно Рубин К.С., неким «движком» метода служит двойственность: анализа (или инспекции) и адаптации. Собственно, мне, как имеющему опыт разработки программ, такая двойственность знакома. Речь идет об анализе исследуемого производства и синтезе ее воплощения.
Тут возникает очень полезная аналогия. В статьях я часто пишу о том, что все события мира можно представить, как некий глобальный метаболизм, сущность которого есть пассивно/активное ~ анаболизм/катаболизм ~ энтропийность/энергийность… Так вот к ряду таких сущностей, можно добавить и такую как: синтез/анализ, которая и отражает тот же самый метаболизм как анаболизм/катаболизм, но уже на более высоком уровне.
{Можно напомнить, на всякий случай, что катаболизм, как правило, проявляется в разделении «целого» на «части», а анаболизм наоборот в синтезе из «частей» «целого».}
В таких представлениях, мир постоянно перестраивается, реконструируется и никогда не «застывает». А вездесущность сингулярности, объясняется тем, что процесс метаболизма идет как бы «по кругу». Методология Scrum, которая родилась в применении, прежде всего, для программных продуктов, наиболее плодотворно вписывается в идеологию метаболизма.
***
Интересной особенностью методики Scrum, служат некие этические правила, которых основатели тоже указывают в качестве пяти ценностей (которые не являются эйдосом):
«Когда Скрам‐команда разделяет и воплощает в жизнь ценности Скрама – преданность, смелость, сфокусированность, открытость и уважение – основные принципы фреймворка – прозрачность, инспекция и адаптация – создают атмосферу всеобщего доверия. Участники Скрам‐команды познают эти ценности через события, роли и артефакты Скрама. Успешность использования, данного фреймворка напрямую зависит от того, насколько люди разделяют эти пять ценностей.
Каждый участник Скрам‐команды привержен ее целям. Люди должны иметь смелость принимать сложные решения. Каждый сфокусирован на целях Скрам‐команды и работе над их достижением в рамках Спринта. Заинтересованные лица и Скрам‐команда остаются открытыми относительно всей исполняемой работы и возникающих трудностей. Участники Скрам команды уважают профессионализм и самостоятельность друг друга.»
***
Не являются эйдосом и характеристики команды, хотя их пять. Число пять несет в себе, по-видимому некую статистическую содержательность в выразительности, которую можно рассматривать как неявное присутствие оптимальной статистической сущности ~ выразительность/содержательность.
«Команды Разработки имеют такие характеристики:
Самоорганизация. Команда самостоятельно решает, как превратить Бэклог Продукта в Инкремент Продукта – без каких‐либо внешних указаний (даже от Скрам‐мастера).
Кроссфункциональность – наличие в рамках команды всех необходимых навыков для командного создания Инкремента Продукта.
Разработчик – единственная роль в Команде Разработки, невзирая на тип выполняемых задач. Другие роли в Команде Разработки Скрам не признает, и данное правило не имеет исключений.
Отсутствие подкоманд в Команде Разработки – независимо от областей, над которыми необходимо работать (например, тестирование, дизайн или бизнес‐анализ). Правило без исключений.
Коллективная ответственность Команды Разработки за создание Инкремента Продукта наивысшего качества. При этом отдельные члены команды могут обладать различными специализированными навыками и экспертизой.»
***
Такую же статистическую сущность составляют и спринты, которых тоже пять:
«Спринт служит ядром Скрама. Спринт – это временной отрезок максимальной длительностью один месяц, в течение которого команда создает функционирующий и готовый к использованию и выпуску Инкремент продукта. Желательно сохранять неизменной продолжительность Спринта на протяжении всего процесса разработки. Новый Спринт начинается сразу после окончания предыдущего. Спринт состоит из Планирования Спринта, Ежедневного Скрама, разработки, Обзора Спринта и Ретроспективы Спринта.»
***
Подведя итог данной заметке, можно сказать следующее. Как и любая технология, которая является продолжением онтологии, методология Scrum обязана быть эйдетической, по схеме «одно» – «многое», т.е. строить артефакт («целое») из каких-то своих «единиц» («частей»). Авторы метода, хоть и не совсем явно, придерживались такой онтологии.
Что касается программных продуктов, то для переноса идей на программу нужны как «аналитики», так и «синтезаторы», хоть в одном лице, хоть в многих. При этом «аналитика» носят некий универсальный характер, который соответствует активной субстанции: любое изделие, что бы его понять надо (однообразно) «разобрать до винтика». А вот «синтезаторы» действуют исходя из неких конкретных условий и обстоятельств, что всегда выражается в уникальности. Но именно уникальность изделий позволяет существовать дисперсии и среднему значению, которое, обычно, служит идеалом системы (принцип Дарвина).
Дополнительно
Технологическое ядро и предметная периферия в развитии