Александр, большое Вам спасибо! Семинар - как раз то, что мне было нужно, как раз в тему задач, которые я сейчас решаю на работе.
Отчёт о семинаре Владимира Павлова.1) Семинар начался издалека - с того, что среди Top 500 предприятий средний годовой оборот на отдного сотрудника ~$1 млн., средняя чистая прибыль на сотрудника - ~200 тыс. (эх... к вопросу о Карле Марксе, эксплуатации и эксплуатируемых), что самые прибыльные - правильно, oil & gas, чуть менее - software, ещё менее - retail, и что для того, чтобы просто не терять позиций, нужно расти на 30% в год, а делать это можно только за счёт повышения эффективности
2) Дальше Владимир рассказал об идее обратной семантической трассировки. Вкратце - допустим, Вам нужно перевести маркетинговые материалы с русского на японский. Как Вы можете проверить правильность перевода, если не умеете читать иероглифы? Правильно, сначала дав одному переводчику перевести с русского на японский, потом другому - обратно, с японского на русский, и сравнить смысл (
семантику) полученного текста с исходным. А разработка ПО, да и любая работа - по сути цепочка переводов: из требований в архитектуру, их архитектуры - в код и т.д.
3) Затем мы некоторое время привыкали понимать друг друга без слов - игрой в пантомиму.
4) После этого Владимир разделил нас на две команды, запретил говорить, выдал задания и... мы принялись разрабатывать архитектуру систем, общаясь исключительно рисунками на UML, ну и ещё иногда мыча друг на друга. А потом обменялись архитектурами и постарались понять, какая у другой команды была задача, какое решение она предлагает и что в этом решении неправильно.
Что выяснилось: 2 команды из 4 человек с разными бэкграундами, впервые видящих друг друга, способны за 3 часа молча разработать на UML вполне сносную и целостную архитектуру для решения весьма сложных задач. Молча самоорганизоваться, описывая роли друг друга на UML. Написать use case view, analysis view, static view, dynamic view, component view, deployment view. Эта архитектура оказалась вполне отчуждаемой, её можно было понять и прорецензировать без присутствия автора. Она была достаточно прагматичной, чтобы её можно было реализовать, по крайней мере, после детализации. Всё понятно, как делать, нужен капитал
.
5) Весь следующий день мы на теории на практике учились управлять рисками, выявлять те области, в которых применение обратной семантической трассировки позволяет их снижать. Поговорили о валидации артефактов, о SCRUMе.
Семинар не из лёгких. Вечером чувствуешь себя выжатым, как после мозгового штурма длиной в день, чем, в принципе, и является. Он может обмануть ожидания тех, кто хочет отсидеться, отдохнуть от работы, повалять дурака. Не дадут!
Семинар НЕ имеет дела с глубинами архитектуры, применением паттернов.
Семинар НЕ имеет дела с академически правильным применением UML: на практике это делать некогда. UML в нём представляется как живой язык, не такой красивый, но куда более быстрый и понятный, нежели литературный.
Участники были разными. Особенно запомнился скептик, высокопоставленный архитектор, утверждавший, что архитектура имеет слабое отношение к реализации (а зачем она тогда нужна?), и что UML для описания архитектуры больших систем не подходит (а на чём тогда описывать? ERD + DFD + block лучше? или лучше кондуит в 1000 страниц без единой картинки? или решение должно быть документировано на языке C++?). Ну и ещё был разработчик, очень хотевший проявить себя, постоянно споривший на пустом месте. Но Владимир мастерски модерировал теоретическую часть, а практические задания все выполняли на удивление дружно и слажено.