Комментарии 34
если, конечно же, исключить проекты длиной в пару дней, в которые вовлечены пяток человек
Вот такие пассажи всё сильно портят — это явное преувеличение области применимости скрама. На практике, например, если надо написать отдельный микросервис, который пишется в среднем за неделю-две, то использование скрама явно избыточно и заметно замедляет разработку. А целый пяток человек, на практике, за пару дней в лучшем случае только-только успеют договориться что они будут делать, но никак не успеют за это время ещё и сделать что-то.
Ещё, на мой взгляд, канбан незаслуженно вынесен почти что за скобки, в область хаоса. Он прекрасно себя показывает в качестве более дешёвой и эффективной альтернативы скраму для тех самых небольших проектов и команд, вроде вышеупомянутых микросервисов. (Но, я понимаю, он слишком прост, и на обучении канбану много не заработаешь…)
К изложенному в статье я бы ещё добавил, что основное свойство конкретно скрама — это гарантированный ритм, с которым выполняются эти циклы A-B-Реагируй, который и обеспечивает относительно стабильное продвижение вперёд проекта в целом.
Вот такие пассажи всё сильно портят
Полностью согласен, но так в оригинале. Я тоже засомневался не добавить ли еще и сюда примечание переводчика, но решил что пункт недостаточно важный, чтоб совсем уж делать так, чтоб переводчика в статье было больше чем автора.
На практике, например, если надо написать отдельный микросервис
А вот тут вопрос конечно интересный.
С одной стороны он умышленно в своей статье подводит к мысли что «простых проектов в разработке ПО просто не бывает».
С другой «сделать за две недели без скрама» все еще можно очень по-разному.
Кто-то пишет-пишет 2 недели, потом рассказывает что у него все готово на 99% (причем последний процент потом растягивается еще на пару месяцев). И самое печальное таких — не скажу что большинство, но… немало.
А кто-то, по сути, делает тот же самый Agile, каждый день добиваясь небольшого, но полностью законченного и отлаженного инкремента, причем желательно чтобы в итоге что-то само по себе уже ценное получалось.
Что в этой статье ценно — она объясняет не только почему может работать скрам, но и почему подход #2 выше куда чаше приводит к реально работающему продукту, а вот подход #1 не смотря на его фейковую высокую экономическую эффективность (мы отлаживаемся/выпускаем только один раз, не тратимся каждый день) — куда чаще заводит проекты в полный провал.
Ещё, на мой взгляд, канбан незаслуженно вынесен почти что за скобки, в область хаоса.
И тут я полностью согласен. Я сам, если быть честным, куда больше делаю чистого Lean management/Kaizen чем Scrum.
У меня такое ощущение что долгое время Agile community умышленно дистанционировалась от Kanban и Kaizen. Ну наверное можно объяснить — говорящим головам продавать надо :-).
Статья 2017 года тогда еще Kanban для них был экзотикой. Как я тут давеча видел в комментариях на хабре — Канбан «оказывает плод скрещения Agile с чем-то-там». Ага, особенно если учесть что Канбан появился на десятилетия раньше — конечно же это так. Но сам уровень познаний большинства рассуждающих — характерен.
Но я, опять-таки, по опыту, пока побаиваюсь подступаться к этой теме. Kaizen вообще и Kanban в частности еще пока ждет человека который объяснил бы их «на пальцах». :-) Большая часть источников по ним — увы, просто зубодробительна.
Ну и надо отметить что за три года ситуация все-таки поменялась. И «Scrum with Kanban» появился у Scrum.org, и вообще в 2020 версии Scrum guide внезапно вспомнили Lean корни Agile и терминология Lean management стала снова активно использоваться.
К изложенному в статье я бы ещё добавил, что основное свойство конкретно скрама — это гарантированный ритм
Немножко позволю себе поправить.
Гарантированный ритм, и, как писал сам Швайбер — тамйбокс все-таки в первую очередь механизм принуждения команды. «Никогда человек не бывает таким изобретательным как с петлей на шее»©, однако. Но строго говоря ритмичность все-таки это побочка, особенно полезная в ситуации когда команда до конца не понимает эмпирицизма. Рваный ритм никак не противоречит скраму, пока между инспекциями проходит не больше чем установленный timebox. Т.е. sprint эквивалентно release — это ошибочная точка зрения. Sprint это не менее одного релиза. Но сколько их и в каком ритме — дело команды.
Если микросервис пишется людьми с опытом — он пишется быстро. Люди которые впервые пишут микросервис и пытаются его интегрировать — это уже сложная задача. Первый комментатор умышленно приуменьшает сложность, забывая про условия в которых будет выполняться задача.
Нет, дело в другом. Разработка в микросервисном стиле, по своей природе, подразумевает написание большого количества (от десятков до тысячи) достаточно однотипных сервисов. Более того, абсолютное большинство из них довольно простые (это следствие их количества и одна из основных причин вообще использовать микросервисы). Поэтому, хотя написание первых трёх сервисов может занять много времени, равно как и написание немногих больших и сложных сервисов, в общей картине разработки проекта эти затраты теряются. Поэтому однозначно имеет смысл оптимизировать методологию и процессы под бо́льшую часть работы — а это как раз те самые сервисы, которые пишутся в среднем недели за полторы одним разработчиком (опытным, но при таком количестве однотипной работы все разработчики быстро становятся достаточно опытными конкретно в этом).
Да, просто не совсем понятно было написано: «канбан простой и денег на нем не заработаешь». Насколько я понимаю: канбан будет работать где конвейер уже построен (понятный продукт, нужно только делать), а скрам будет работать там где конвейер только предстоит построить (непонятно что и как делать).
Не совсем так. Разные типы работ имеют бо́льшее влияние на выбор методологии, чем "понятный продукт". Например, при разработке обычного веб-проекта:
- Задачи девопс/админов: по своей природе часто внезапные и срочные, плюс ещё регулярно повторяющиеся. Это в скрам/спринты просто не засовывается без заметного вреда для проекта. А канбан подходит почти идеально.
- Разработка бэкенда, микросервисы: мы не совсем знаем, какой продукт мы пишем, и функционал продукта может довольно часто изменяться на ходу (по мере проверки гипотез бизнесом или просто потому что аджайл и бизнес может часто менять мнение и генерировать новые идеи), но… мы действительно имеем уже построенный конвейер написания/изменения микросервисов с циклом разработки "от нуля до выката на стейдж за полторы недели одним разработчиком" и понятные "как делать" задачи после декомпозиции в бэклоге на ближайшие недели. В таких условиях канбан просто позволяет двигаться быстрее, чем скрам, и меньше заморачиваться на процессы самой методологии. Но скрам тут тоже будет работать, в отличие от предыдущего пункта, просто хуже.
- Разработка фронта. Здесь я не готов описать первопричины происходящего (потому что сам больше по части бэка и немного девопс), но из опыта того, что я наблюдал на разных проектах — здесь скрам работает заметно лучше канбана (в смысле, при скраме бизнес чаще получает ожидаемый результат). У меня есть, возможно наивное, подозрение, что если бы на фронте кто-то делал декомпозицию так, как я на бэке, так же внедрил чистую архитектуру и автоматизированные тесты как я на бэке, т.е. "настроил конвейер" — там бы тоже канбан заработал лучше скрама. Но доказать это я пока не могу.
- Рисование дизайна. Вообще никогда даже не видел, чтобы это делалось "по методологии". Часто по дизайну даже декомпозиции задач толком не делается, и нередко их даже не трекают. Наверное в чисто дизайнерских студиях это не так, но при разработке обычных веб-проектов дисциплину и дизайн объединяет только то, что начинаются они на "ди". :)
Иными словами, да, для канбана нужен настроенный конвейер "берём таску из трекера, пишем чистый код, покрываем тестами, выкатываем на стейдж" — но это не имеет никакого отношения к тому, насколько хорошо бизнес понимает какой продукт мы пилим, равно как и к тому, пишем ли мы тупой CRUD или в процессе нужно проводить какие-то исследования и временами осваивать новые технологии (т.е. конвейер вполне справляется с задачами, у которых высокая степень неопределённости и/или сложности — просто их тоже нужно правильно декомпозировать и раз в пару дней анализировать по ним прогресс, т.е. выполнять Попробуй-Осознай-Реагируй или Осознай-Изучи-Реагируй в терминах статьи).
Хорошие примеры. Спасибо. Есть ощущение что вы правы, хоть пока доказать тоже не могу. :) За дизайнеров скажу: работают по скраму, если проекты более менее повторяющиеся и клиент больше ориентирован на запуск продукта, а не на цвет кнопок. И сюда приходит «конвейер».
Это косвенно подтверждается тем, что канбан был изначально внедрен в цехах по сборке автомобилей — то есть там где: вот тебе ключ, гайка — прикрути. То есть, там где процесс уже построен и речь идёт о механическом исполнении заданий.
Тогда как скрам в моем понимании — исследовательский подход. Я не знаю чем и что прикручивать, давай пообещаю что за неделю научусь прикручивать камешек палкой, а потом обсудим и попробуем что то ещё.
Основная проблема которая возникает — это стоимость. Нам продукт обходится не во столько, сколько минимально было необходимо чтобы сделать реальное проданное количество продукта, а во столько, сколько рабочие успели наваять.
Канбан же пришел с lean management и сменой парадигмы. Процесс становится pull — мы не делаем больше, чем надо дальше по цепочке, а у нас не вытягивают больше чем могут обработать. Это обеспечивает нам тот факт, что затраты не будут превышать минимально необходимых для того, чтобы сделать реально потребовавшуюся ценность.
Но «однотипность» микросервиса легко ломается как только даже при той же технологии внезапно становится надо решить принципиально новую бизнес задачу.
Я выше уже описал что нет, не ломается, конвейер отлично перемалывает и принципиально новые задачи. Но чтобы это сработало нужен поставленный процесс преобразования таких задач в обычные — декомпозиция исследовательских задач и частое (пара дней) получение обратной связи об их прогрессе с соответствующей коррекцией постановки этих задач при необходимости (чтобы в них не "тонуть", и чтобы не отклоняться сильно в сторону и не делать то, что не нужно бизнесу прямо сейчас).
При этом сама оригинальная задача вполне может быть довольно большой и сложной, и в целом работа над ней может занять от нескольких недель до пары месяцев. Но. В течении этого времени она будет делаться как последовательность небольших (2 часа … 3 дня) задач, создаваемых (и удаляемых тоже, кстати) в процессе непрерывной декомпозиции на основе анализа того, что уже стало понятно (та самая обратная связь каждые пару дней). И канбан отлично "переваривает" такие задачи.
P.S. А конечным итогом выполнения этой большой исследовательской задачи будет создание совершенно обычных задач по разработке совершенно обычных микросервисов, потому что уже стало ясно что и как в них надо делать.
И уж тем более в рамках Канбан и DevOps совершенно точно можно все, что в Скраме, и еще вагон и маленькую тележку. Полностью согласен.
Возможно. Я отвечал на
Но «однотипность» микросервиса легко ломается как только даже при той же технологии внезапно становится надо решить принципиально новую бизнес задачу.
в духе, что существует процесс, который позволяет в этой ситуации ничего не сломать, а выполнив предварительно группу других задач (не являющихся разработкой "незнакомого" микросервиса) вернуть возможность разрабатывать нужный микросервис как "типовой".
Возможно я просто не понял, что Вы имели в виду, и ответил на что-то другое.
Кстати говоря, возможно для большей ясности стоит ещё ответить на
это попадает под определение «простое».
Я искренне убеждён в том, что единственный способ делать "сложные" задачи — ни в коем случае не делать ничего "сложного"! Поэтому да, все задачи, которые в моих проектах добираются до колонки "To do" — простые. Потому что сложные задачи в "To do" никто никогда не добавляет — сначала их надо преобразовать в простые.
Так что да, это читинг, задачи которые я делаю по канбану действительно "попадают под определение простых" — так задумано. :)
Словоблудие какое-то. Статья про сложность, но даны два определения, которые к программированию отношения не имеют. Зачем-то притянуто за уши понятие «эмержентности», которое имеет строгое определение в теории хаоса, но при чем тут формошлепство? Затем предлагается целых два метода для преодоления сложности, раз речь про теорию сложных счистки ожидаем формулы, но нет, опять размахивание руками.
Скрам, очевидно, это итеративный процесс подходящий для исследования предметной области в процессе работы. К сложным системам он никакого отношения не имеет. Иначе бы те, кто имеет дело с реально сложными системами Скрам бы и применяли. Но что-то в биологии и социологии не видно Скрам мастеров.
Мне нечего ответить про ваш тезис про «словоблудие». Я, конечно, могу передать при случае ваше мнение и Вервейсу, и Швайберу, благо знаю обоих лично, но мне почему-то кажется, что они вряд ли придадут ему ожидаемое вами значение.
Мы можем попробовать более точно и внятно сформулировать претензии, но для этого надо начать со снижения накала эмоций и перехода к фактам.
И да, я полностью согласен что статья не имеет никакого отношения к программированию и уж тем более к «формошлепству» (да, позволю себе совет, если вы хотите чтобы вас вопринимали серьезно — надо немножко снизить градус презрения к коллегами и воздержаться от терминов имеющих презрительную коннотацию), она имеет отношение к разработке продукта. Возможно, для лучшего её понимания надо перейти с уровня кодера на уровень разработчика продуктов и понять разницу между «выполнением работы» и «созданием ценности для конечного потребителя».
И таки давайте к фактам
Для начала — в теории систем (по-русски «систем», не «хаоса»), эмержетность действительно имеет совершенно точное определение:
Эмержестность — появление у системы свойств, не присущих её элементам в отдельности; несводимость свойств системы к сумме свойств её компонентов.
Если вы покажете в каком именно месте статья или мои комментарии противоречат этому определению, или используют эмержестность в другом смысле — мы сможем предметно обсудить в чем дело — в фактической ошибке, в неудачном выборе слов или в вашем поспешном суждении о прочитаном.
Во-вторых я бы попросил вас потратить неможко времени и подумать о такой вещи как «логическая последовательность». Если бы где-то в статье утверждалось что Скрам является уникальной разработкой по преодолению сложности систем — я бы согласился с вашим утверждением, что странно что в биологии и социологии скрам не используют.
Однако и статья, и мои комментарии утверждают нечто прямо противоположное. Что Скрам не является новым изобретением, а является применением хорошо известного эмпирического подхода к разработке ПО. И привносит хорошо известные приемы, такие как планирование эксперимента, проведение эксперимента, анализ результатов эксперимена и коррекция текущей теории (ака понимания ситуации исследователем) в разработку ПО.
Было бы странным, как мне кажется, утверждать, что в социологии и биологии эмпирический подход совершенно не используется. Но еще более странно ожидать что люди которые уже используют эмпрический подход вдруг станут применять терминологию, разработанную для внедрения уже известного им подхода в совершенно другую отрасль.
Так что если вам удасться взять эмоции под контроль, успокоиться, внимательно перечитать статью и сформулировать корректные возражения — я с радостью продолжу диалог с вами. И конечно же вы с полном праве выражать свои эмоции, это особенно важно для поколения миллениалов, но не обессудьте, поддерживать или вести диалог на таком уровне я не стану.
Спасибо за понимание.
Давайте сначала с определение «сложности» разберёмся. Если следовать вашей логике, то «много молекул в комнате» это сложная система — предсказать температуру стен невозможно, потому что молекул слишком много. В то же время простые статистические модели температуру предсказывают. Один и тот же набор молекул оказался сложным и не сложным одновременно. В статье что-то такое есть, про то как Скрам снижает уровень сложности. Но в определениях ничего про относительность нет. Также ничего про относительность нет в методах преодоления сложности.
Вопросы также возникают к категоризации систем по сложности. Кто сказал, что описанные категории покрывают 100% систем, может быть только 1%? Кто сказал, что указанные категории не пересекаются? Ведь может быть так, что большая часть систем попадёт сразу во все категории. Если следовать определениям, то ничего сказать про это нельзя. И это понятно, чтобы о таких вещах говорить нужно формально вещи определять, дать мат. модель и в не рамках описывать категории, методы и прочее.
Ну и про эмержентность напоследок. Вы определил понятие как «Поведение, которое свойственно только системе как единому целому, но не свойственно ни одному её компоненту» Получается «велосипед» и «веник» это эмерджентные и, видимо, сложные системы. Веник состоит из прутиков, прутик не годиться для уборки пола, а их сумма вполне.
Так что если вам удасться взять эмоции под контроль, успокоиться, внимательно перечитать статью и сформулировать корректные возражения — я с радостью продолжу диалог с вами. И конечно же вы с полном праве выражать свои эмоции, это особенно важно для поколения миллениалов, но не обессудьте, поддерживать или вести диалог на таком уровне я не стану.
Я обсуждаю статью, а вы обсуждаете меня — мой возраст, неконтролируемые эмоции и так далее. Кажется ещё чуть-чуть и появятся намеки на невысокий уровень IQ. Вам бы стоило извинится и больше не переходить на личности.
Поправьте меня если я ошибаюсь, но в вашем комментарии собственны вы сами задали стиль «от себя». Определения сложной системы, эмержетности не выдуманы ни мной, ни автором статьи. Я далеко от наукобесия и слепой веры в «учОные написали», но как-то тот факт что лично вы считаете что Вервейс словоблудит — я как-то не считаю достаточно обоснованным выражением чего бы то ни было иного, кроме вашего личного мнения. Но отдам должное — тон этого вашего комментария уже намного лучше, за что я отдельно вам благодарен.
Теперь по теме
Давайте сначала с определение «сложности» разберёмся. Если следовать вашей логике, то «много молекул в комнате» это сложная система — предсказать температуру стен невозможно, потому что молекул слишком много
Давайте разберемся. Я использую определение сложной системы как «система, поведение которой не может быть описано через поведение отдельных её частей», например из Bar-Yan, «General features of complex systems». Логика по которой произошла экстраполяция «много» в «сложно» для меня к, сожалению, непрозрачна.
Если вернуться к определению которое я использую — то какими дополнительным свойствами обладает много молекул в комнате, которыми не обладает кластер из 100 молекул? Ну или хотя бы чем отличается поведение 1/100 части комнаты от поведения комнаты в целом. Короче, что делает систему сложной по тому определению, которое используется в статье?
Давайте я, в свою очередь, приведу вам пример механической системы и ситуации в которой система является сложной:
Есть самолет и его аэродинамика, в ситуации, когда методы компьютерного моделирования для нас еще недоступны.
Мы совершенно точно можем сесть и на логарифмической линейке посчитать обтекание каждой отдельной поверхности. Но обладаем ли мы вычислительной мощностью, достаточной чтобы предсказать каково будет обтекание (а значит поведение модели в воздухе), с учетом эффекта взаимодействия всех поверхностей, собранных в одно целое? Нет, не обладем и предсказать не сможем.
Поэтому так и строили еще 50 лет назад — через череду прототипов. И если вы читали мои примечания к статье, я как раз указал явное сходство между Agile и старыми добрыми методами НИОКР.
Но в определениях ничего про относительность нет.
Ммм… вы уверены? Способность описать/предсказать поведение абсолютна? Сложная система для трехлетнего ребенка и кандидата наук одна и та же? В конце концов если говорить и биологии — сложное в XIX веке так и осталось сложным в XXI?
Подсказка — среди работ по теории систем достаточно много можно найти по вопросу субъективной составляющей природы сложности. Вот прям с первой страницы поисковой выдачи гугля Efatmaneshnik & Ryan «A general framework for measuring system complexity».
Вопросы также возникают к категоризации систем по сложности. Кто сказал, что описанные категории покрывают 100% систем, может быть только 1%?
И теория систем, и скрам, и даже эмпрический метод касаются не вообще всех вопросов в мире, а ровно двух:
a) Наша способность понять (предсказать) поведение системы
б) Наша способность управлять (предсказуемо изменять) поведение системы.
Какие принципиальные практически-значимые моменты этих двух вопросах конкретных не покрыты в работе?
Кто сказал, что указанные категории не пересекаются? Ведь может быть так, что большая часть систем попадёт сразу во все категории.
А где в статье говорится что существует четко детерминированная граница? Такая интепретация возможна если упустить субъективную составляющую сложность, хотя статья прямо о ней говорит.
Ведь может быть так, что большая часть систем попадёт сразу во все категории.
Ммм… Можно для начала попросить пример ровно одной системы которая одновременно будет находится хотя бы в двух состояниях — простом и хаотическом? Это поможет мне понять что именно вы имеете в виду в этом утверждении.
Ну и про эмержентность напоследок. Вы определил понятие как «Поведение, которое свойственно только системе как единому целому, но не свойственно ни одному её компоненту» Получается «велосипед» и «веник» это эмерджентные и, видимо, сложные системы.
Ну во-первых, не я определил. И даже не Вервейс. Это наука такая, теория систем. :-)
Во-вторых, я не до конца улавливаю логическую цепочку. Какое именно поведение вейника или велосипеда мы не можем свести и объяснить поведением отдельных его частей?
Пример с непригодностью несобранного веника для подметания говорит скорее о том что веник — это просто система, ну как в Британике: system — a set of things working together as parts of a mechanism or an interconnecting network. Не способность отдельных веточек мести подтверждает что это система, но ничего не говорит о сложности.
система, поведение которой не может быть описано через поведение отдельных её частей
Но в определениях ничего про относительность нет.
Ммм… вы уверены?
Да, уверен, в определении выше нет ни слова о том, что система одновременно сложная и простая, в зависимости от знаний того, кто ее рассматривает. Видимо правильное определение сложной системы должно быть таким — « система, поведение которой не может быть описано конкретным индивидом через поведение отдельных её частей»
А у индивидов ещё может быть или не быть доступ к вычислительным ресурсам. Ммм… один может на суперкомпьютере посчитать, а другой нет. Так что в определение ещё нужно добавить наличие технических средств — « система, поведение которой не может быть описано конкретным индивидом, с использованием доступных ему технических средств, через поведение отдельных её частей» Все верно?
В нашей модели добавлена ещё одна ось, которой нет в исходной матрице Стейси — количество вовлеченных людей. Это отражает увеличение сложности любого процесса при увеличении количества вовлеченных людей.
А если добавить индивида, который знает как решить задачу, то сложность вырастет (количество людей увеличилось) или упадёт?
И ещё — в статье «система» это то, что мы разрабатываем или сам процесс разработки? Как-то странно видеть увеличение сложности разрабатываемого продукта при добавлении людей...
Логика по которой произошла экстраполяция «много» в «сложно» для меня к, сожалению, непрозрачна.
какими дополнительным свойствами обладает много молекул в комнате, которыми не обладает кластер из 100 молекул?
Есть самолет… мы… можем посчитать обтекание… Но… предсказать каково будет обтекание ..., с учетом эффекта взаимодействия всех поверхностей, собранных в одно целое? Нет, не обладем и предсказать не сможем.
Комната с молекулами обладает температурой, измеряемой градусником. Для 100 молекул в большой комнате градусник покажет температуру 0, у такой системы температуры (как я его определил) — нет. Добавьте молекул и увидим эмержентное свойство — температуру. Самолёт — строим макет самолета и обдуваем воздухом — профит. В некотором, весьма хорошем, приближении это даст ответ и никакой сложности тут нет. Попробуйте посчитать температуру через движения каждой молекулы — вот вам сложная система, совсем как самолёт. Возьмите статистику — и система простая, но предсказания приблизительные, ровно как и аэродинамика самолета, апроксимированная макетом. Сложность Шрёдингера получается, то есть, то нет.
Получается «велосипед» и «веник» это эмерджентные и, видимо, сложные системы.
Какое именно поведение вейника или велосипеда мы не можем свести и объяснить поведением отдельных его частей?
А что не так с самолётом тогда? Поведение самолета это сумма поведений его частей, просто посчитать мы не всегда можем. Велосипед и веник, ровно как и самолёт, состоят из частей. Каждая часть по отдельности свойствами велосипеда или веника не обладает. Картина симметрична самолету.
Можно для начала попросить пример ровно одной системы которая одновременно будет находится хотя бы в двух состояниях — простом и хаотическом?
Логистическое отображение x → rx(1 — x). Простое? Да. Имеет хаотическое поведение — да.
Если вы под хаотическим имели в виду «сложные» то примеров выше уже масса. А разъёмы согласны, что сложность явление относительное, то не удивительно найти системы одновременно простые и сложные.
Возникает вопрос — при существовании консенсуса вокруг теории систем, в котором не посчитали нужным все эти добавления делать — чьей отвественностью и что именно является:
— Всего мира отвественность изворачиваться чтобы отдельный юзер оказался удовлетворен?
— Отдельного юзера напрячься и понять о чем говорят другие?
Если вспомнить что вопрос идет еще и об аджильности — то как насчет одного из 12 принципов: «просто — в том чтобы не делать ненужной работы?». Какую ценность сообществу Agile в целом и большинству разработчиков принесет внесение всех этих правок?
Особенно если помнить, повторюсь, что:
а) Сложность рассматривается исключительно в контексте предсказания и управления системой
б) Предсказывать и объяснять может только человек разумный?
Вы хотите оспорить теорию систем и их видение сложности? Мне так кажется что место, время, аудитория и ситуация не совсем для того подходящее. Лично я просто не вижу потенциально конструктивного результата в спорах о гелиоцентризме, об атомарном устройстве вещества… или о вот природе сложности системы.
Комната с молекулами обладает температурой, измеряемой градусником. Для 100 молекул в большой комнате градусник покажет температуру 0, у такой системы температуры (как я его определил) — нет. Добавьте молекул и увидим эмержентное свойство — температуру.
Вы только что привели хороший пример субъективной природы сложности. Для человека, не знающего определения вакуума и не знакомого с началами термодинамики — появление температуры действительно будет непредсказуемым, а значит поведение системы — сложным.
А если добавить индивида, который знает как решить задачу, то сложность вырастет (количество людей увеличилось) или упадёт?
Вы приводили социологию, видимо в силу того что имеете какое-то представление о ней. Что там социология говорит о росте количества связей при увеличении группы и сложности коммуникации с ростом связи?
просто обдуваем
Вообще просто обдуваем — это не предсказываем. Вы в состоянии заплнировать результат обдува? Это, собственно, и есть — используем эмпирический опыт.
Так с чем именно вы спорите?
И какой именно эксперимент нам нужен для веника?
А что не так с самолётом тогда? Поведение самолета это сумма поведений его частей, просто посчитать мы не всегда можем.
Так проблема в управлении проектами и есть в том, что мы «просто не можем» и «просто обдуем», а в том что мы беремся предсказывать, обсуждать и управлять тем, что «просто не всегда можем».
Возникает вопрос — при существовании консенсуса вокруг теории систем, в котором не посчитали нужным все эти добавления делать — чьей отвественностью и что именно является:
Руководитель проекта Петя может предсказать динамику проекта, потому что он подобных сделал 100 штук. Руководитель Вася не может, он впервые сталкивается с таким проектом. Следуя данному нам свыше определению проект — сложный или простой?
Какую ценность сообществу Agile в целом и большинству разработчиков принесет внесение всех этих правок?
Никакую, просто если «сложность» относительная, то у вас часть логических выкладок в статье станут неверными.
Скорее всего мне нет смысла влезать в эту демагогию, но на случай если Вы не троллите а действительно пытаетесь что-то понять или донести ценную идею а мы её не понимаем — попробую ответить.
Сложность — всегда относительная. Тем не менее, практически все руководители регулярно сталкиваются со сложными лично для них проектами, и им полезно иметь инструмент (вроде обсуждаемых гибких методологий или любой другой), который помогает им справляться с такими проектами.
Какие конкретно выкладки в статье становятся неверными из-за относительной природы сложности конкретно для руководителя Васи, для которого текущий проект субъективно сложный?
Если сложность понятие относительное, то метод борьбы со сложностью это найти точку, откуда система перестает быть сложной. Если сложность абсолютная, то дополненная матрица Стейси неверна. Потому что при добавлении людей мы можем добавить экспертизу, которая сделает систему/проект простым. А матрица утверждает, что это невозможно.
на случай если Вы не троллите а действительно пытаетесь что-то понять или донести ценную идею
Отчасти я троллю. А ценная идея, которую я пытаюсь донести — вы идете не туда, и не на то тратите время. Либо у нас есть строгая математическая теория (этого нет), либо у нас есть эксперименты (тоже нет), либо это искусство и не нужно тешить себя мыслью, что какие-то эвристики сильно помогут.
К теории сложных систем и ее методам стоит относиться крайне осторожно. В этой «теории» нет ни формул, ни экспериментов, только философские труды. Ну и вот вики в какой-то степени со мной согласна
По Растригину[1], строгое определение сложной системы ещё не найдено, но к некоторым чертам сложной системы (как объекта управления) относятся:
Собственно о чем и статья. Особенно в части про Кеневин который и есть в том числе поиск способа, позволяющего снизить сложность системы.
Потому что при добавлении людей мы можем добавить экспертизу, которая сделает систему/проект простым.
Ну давайте так — тут надо осторожно подходить к этому вопросу. Мы говорим о какой-то сферической сложности в вакууме, или все-таки пользуемся терминологией из статьи.
В статье вопрос применимости и ценности экспертизы рассмотрен более чем достаточно. И нет, ни по Стейси, ни по Кеневину, когда мы находимся в уже в области сложных или хаотических систем, добавление экспертизы вряд ли поможет, потому что мы столкнулись с задачей, в рамках которой поиск эксперта сложнее чем эмпирическое решение. Иначе бы она не была сложной.
Но означает ли это что в рамках серии грамотно поставленных экспериментов МЫ тоже не можем стать этими экспертами в области этой задачи и таким образом снизить сложность? С точностью до наоборот, именно этот путь и рекомендуется.
Если же мы берем сферическую сложность в вакууме — то, весьма вероятно, имея бесконечный пул ресурсов и бесконечный бюджет на поиск конфигурации команды которая обеспечит нам упрощение — и тогда вы правы. Но какое это отношение имеет к реальным проектам?
А ценная идея, которую я пытаюсь донести — вы идете не туда, и не на то тратите время. Либо у нас есть строгая математическая теория (этого нет), либо у нас есть эксперименты (тоже нет)
Я прошу прощения, а какая «строгая математическая модель» стоит вообще за научным подходов в целом? Он весь такая же философия.
И эксперимента почему нету? Куда делся?
«система, поведение которой не может быть описано через поведение отдельных её частей», тут ничего про относительность нет
Вообще-то — есть. Описывает её всегда кто-то конкретный, в меру собственного понимания на данный момент времени — и именно он не справляется с этой задачей.
Так дайте «правильное» определение.
Извините, хотелось бы, но у меня его нет. Я давно пытаюсь найти определение сложности, такое, чтобы оно было одновременно и корректным/неоспоримым и при этом полезным в практическом смысле — пока без особых успехов. Упомянутые здесь в статье и комментариях хоть и приемлемы, но качеством неоспоримости явно не обладают — иначе что мы тут обсуждаем. Их полезность так же крайне относительна т.к. сильно зависит от того, кто будет применять это на практике — нельзя дать это прочитать кому угодно и получить на выходе руководителя, способного справляться с проектами любой сложности, к сожалению. Но кому-то из них прочитанное вполне может помочь, поэтому статья, на мой взгляд, полезная.
Потому что при добавлении людей мы можем добавить экспертизу, которая сделает систему/проект простым. А матрица утверждает, что это невозможно.
Так бывает, конечно. Но — очень редко. Поэтому полагаться на это, как на решение — нельзя. Матрица описывает как распознать и как действовать в типовых ситуациях, и польза от неё есть. А исключения, как принято, полезнее (с практической точки зрения) считать только подтверждающими правила. :)
Либо у нас есть строгая математическая теория (этого нет), либо у нас есть эксперименты (тоже нет), либо это искусство и не нужно тешить себя мыслью, что какие-то эвристики сильно помогут.
Мир не чёрно-белый, извините за банальность. Вы ставите вопрос некорректно, полагая что на него есть либо ответ "да", либо ответ "нет". Я в таких случаях люблю напоминать, что "в теории, теория и практика не должны различаться… но на практике они различаются". Можно, конечно, заявить, что проблема в несовершенстве теории… но люди вообще существа несовершенные, много ошибаются, и вообще — поэтому не стоит ожидать от них совершенных теорий (а когда такие всё-таки появляются — надо воспринимать это с благодарностью, но без особой надежды на скорое повторение чуда). Извините за отход от темы — ночь глубокая, соображаю уже не очень хорошо. Я веду к тому, что эксперименты у нас есть, хотя и близко не с такой научной точностью, как хотелось бы, и эвристики вполне помогают, хотя и не так сильно, как Вам бы хотелось. Но тот факт, что текущие подходы работают не так идеально, как хотелось бы нам всем — не повод ими вообще не пользоваться.
Либо у нас есть строгая математическая теория (этого нет), либо у нас есть эксперименты (тоже нет), либо это искусство и не нужно тешить себя мыслью, что какие-то эвристики сильно помогут.
К теории сложных систем и ее методам стоит относиться крайне осторожно. В этой «теории» нет ни формул, ни экспериментов, только философские труды.
Мне кажется, вы преувеличиваете значение формул и математики. Аксиоматический подход часто оказывается слишком жестким и негибким, он плохо подходит для описания процессов и ситуаций, которые часто меняются. Если вы сталкиваетесь с новым существенным фактом, который хотите учесть в своей модели, то вы можете натолкнуться на то, что его формулировка в старых жестких терминах противоречит системе аксиом. В результате всю модель придется выкидывать, а строго выведенные следствия доказывать заново в новых терминах.
Можно подойти к этому вопросу с другой стороны: по первой теореме Геделя о неполноте любая система аксиом будет либо противоречивой, либо будет содержать утверждения, которые невыводимы из этой системы вместе со своим отрицанием. Т.е. система оказывается одновременно слишком слабой (есть утверждения, о которых ничего нельзя сказать) и слишком сильной (мы не можем ее дополнить вновь открывшимися фактами). Если мы хотим постоянно менять «рамку» рассмотрения, то аксиоматическая система оказывается неудобным инструментов.
В т.ч. поэтому в гуманитарных науках при рассмотрении общества вы не найдете математически строгих терминов и аксиоматических систем. Они могут применяться, но лишь к отдельным ограниченным ситуациям, а не для описания фундаментальных взаимосвязей. Гуманитарное знание от отсутствия аксиом (а значит и жестких взаимосвязей, которые вы можете представить в виде математических формул) не перестает быть научным.
Если сложность понятие относительное, то метод борьбы со сложностью это найти точку, откуда система перестает быть сложной. Если сложность абсолютная, то дополненная матрица Стейси неверна. Потому что при добавлении людей мы можем добавить экспертизу, которая сделает систему/проект простым. А матрица утверждает, что это невозможно.
Если буквально трактовать эту матрицу как математическое множество, то возникают подобные логические затруднения. Вы сделали предположение, что на этой плоскости любая точка имеет численные координаты и что все две (три) введенные координаты действительно имеют числовую оценку. Но это совсем не так, эта матрица — визуализация общих соображений, а не математическая модель.
Частично про это есть в статье («Вторая причина заключается в том, что бездумное использование матрицы может создать впечатление что мы можем уменьшить сложность системы просто “усилием мысли”»). Т.е. ее автор явно предостерегал от трактовки этой матрицы как математического объекта, правда указал в качестве ложного вывода иной пример, нежели вы.
И если вы считаете что что-то в переведенной статье или моих комментариях некорректно и неприменимо к реальным проектам в контексте субъективности сложности в применении к проекту — я внимательно вас слушаю.
Логистическое отображение x → rx(1 — x). Простое? Да. Имеет хаотическое поведение — да. Если вы под хаотическим имели в виду «сложные» то примеров выше уже масса.
Распределение Фейгенбаума хороший пример, ровно как это хороший пример изъяна в ваших логических рассуждениях.
Что является простым и предсказуемым? Окончательная судьба популяции, её зависимость от rx проста, собственно и отражает.
Что является хаотическим? Размер следующего поколения.
Здесь нет системы которая одновременно находится в двух состояниях. Здесь есть хаотический выбор предмета разговора, вместо того, чтобы придерживаться чего-то одного. Непредсказуемость такого выбора действительно делает систему этого обсуждения — сложным. ;-)
И да, поскольку не все читатели знакомы с темой, бо к Agile сама по себе она относится слабо — почитать про это можно начиная отсюда:
ru.wikipedia.org/wiki/%D0%9B%D0%BE%D0%B3%D0%B8%D1%81%D1%82%D0%B8%D1%87%D0%B5%D1%81%D0%BA%D0%BE%D0%B5_%D0%BE%D1%82%D0%BE%D0%B1%D1%80%D0%B0%D0%B6%D0%B5%D0%BD%D0%B8%D0%B5
Так что в определение ещё нужно добавить наличие технических средств — « система, поведение которой не может быть описано конкретным индивидом, с использованием доступных ему технических средств, через поведение отдельных её частей» Все верно?
Вы неправильно используете термин «система». В объективной реальности нет никаких систем как таковых, это модельный объект. Системный подход предполагает модельное описание реальности, выбор модели субъективен в том смысле, что можно использовать для описания реальности одну модель, а можно и другую. ПМ Петя смотрит на реальность со своей стороны, он выбирает одну модель для описания части реальности, в ней система сложная. ПМ Вася смотрит на ту же часть реальности со своей стороны, он моделирует ее по-другому, в его модели система простая.
Математически строго определить субъект моделирования не получится, упретесь в ту же проблему, что и Платон с попыткой дать определение человеку.
Комментарии огонь еще лучше статьи.
Описание процесса разительно отличается от подавляющего большинства статей, описаний и обсуждений про скрам. 99% информации про скрам — это по сути карго-культ. Вот тебе правила — выполняй. Вот тебе принципы — следуй им. Следовать принципам хорошо, не следовать им — плохо. Возможно дело в коммерциализации скрама? Если навыки владения фреймворком продаются как товар, то создание карго-культа — это способ создать рынок для товара.
Кристиан Вервейс: О сложности или зачем вам Скрам?