Вдруг, кто не знал, - возрождение https://zlibrary-asia.se/

[UPDATE]: Тут еще одной превосходной ссылочкой поделились: http://libgen.is

[UPDATE-2]: И еще одной: https://annas-archive.org

[UPDATE-3]: И еще одной: https://www.letmeread.net/

#Literature

Бомбовый инструмент управления проектами на простых текстовых файлах. Попробовал - остался в восторге. И уже начал использовать его.
- https://github.com/taskjuggler/TaskJuggler

Не хватает только работы со среднеквадратичным отклонением оценки (но этим вообще мало какой инструмент может похвастаться). Если допилить, то будет вообще песня.

Позволяет организовать собственную структуру файлов проекта для упрощения навигации.

Импортер из Jira:
- https://github.com/melexis/jira-juggler

Импортер из Redmine:
- https://github.com/chris2fr/redmine_taskjuggler

OpenProject integration:
- https://www.project-open.com/en/integration-taskjuggler

Импортер из Trac:
- https://trac-hacks.org/browser/taskjugglerplugin?rev=16580

Импортер из org-mode:
- https://orgmode.org/worg/org-tutorials/org-taskjuggler.html

Дока:
- https://taskjuggler.org/download/TaskJuggler-Workshop.pdf
- https://taskjuggler.org/tj3/manual/index.html

Примеры:
- https://github.com/taskjuggler/TaskJuggler/tree/master/examples

Просто запускаете: $ tj3 examples/Scrum/scrum.tjp и открываете сгенерированную html-у.

Web-based UI:
https://www.project-open.com/en/integration-taskjuggler

#Management

Великолепный сборник материалов по оцениванию/планированию/прогнозированию от Troy Magennis:
- https://github.com/FocusedObjective/FocusedObjective.Resources
- https://www.focusedobjective.com/

Статейка в довесок "Monte Carlo Forecasting in Software Delivery":
- https://medium.com/expedia-group-tech/monte-carlo-forecasting-in-software-delivery-474bb49cb3f9

[UPDATE]: "Towards Risk-aware Scheduling of Enterprise Architecture Roadmaps" (Redmine integration of the risk-aware scheduling) https://www.researchgate.net/figure/Redmine-integration-of-the-risk-aware-scheduling_fig8_333435127

[UPDATE-2]: Тут советуют походить по его сайту через web.archive.

[UPDATE-3]: И ещё по его medium: https://medium.com/@troy.magennis

Довольно интересная статья "Open Source and Proprietary Project Management Tools for SMEs", из которой я узнал про LibrePlan - Open Source project management tool, поддерживающий Monte Carlo из коробки:
- https://www.libreplan.dev/
- https://github.com/LibrePlan/libreplan

Демо:
- https://demo.libreplan.dev/

Не призываю, но на безрыбье... Django + Transactional Outbox: https://medium.com/@antunesleo/ensuring-data-consistency-in-microservices-using-django-jaiminho-and-transaction-outbox-to-avoid-e9fbc21e2dcc

Исходный код: https://github.com/loadsmart/django-jaiminho

Параллельно подвернулась неплохая статейка "Event Sourcing vs. Change Data Capture" by Eric Murphy:
- https://debezium.io/blog/2020/02/10/event-sourcing-vs-cdc/

See also: https://github.com/juntossomosmais/django-outbox-pattern

#DistributedSystems

Мне нравится читать статьи людей, которые зарабатывают практикой, а не консалтингом, например, Владика Хононова. Они проделывают серьезный труд для того, чтоб отточить свои знания и возвести их до уровня серьезного профессионального орудия, используемого ими самими же на практике. Поэтому их статьи получаются лаконичными, содержательными и невероятно полезными. Они заняты практикой, поэтому времени на "литьё воды" у них просто не остается. Читая их статьи я обогощаю собственный горизонт знаний.

Раньше я читал статьи одного небезызвестного польского специалиста (воздержусь от конкретизации, скажу только, что это не Камиль) - они были содержательны. Но вот он полностью посвятил себя консалтингу и теперь строчит водянистые статьи как пулемет, которые я давно уже перестал читать ввиду невысокой их полезности. Но он все равно их строчит, ибо ему нужен индекс цитируемости и прочая мутотень, которая формирует его доход. Возникает диссонанс между "быть" и "казаться".

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

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

Как говорил Gregor Hohpe:
"There's a definite Dunning-Kruger effect for authors.
The people who hold a ton of knowledge hesitate because they find their insights "obvious" or "nothing special".
Then you have people who write a lot but do little real work that they could base their writing on..."

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

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

Когда я говорю кому-то "используй PERT", то зачастую для человека это просто пустой звук, ибо из другого источника льётся "используй story points", из третьего - "noestimate" и т.п. Разобраться в этом может помочь эмпирическая проверяемость, но только как же её может проверить человек, который ни PERT, ни noestimate готовить не умеет? Это значит, что эмпирическая проверяемость должна быть обязанностью источника знаний, а не потребителя знаний. Иными словами, рынку нужны не информационные продукты (курсы, тренинги, статьи), а комплексные решения с измеряемой обратной связью. Это и есть та проблема, на решении которой я хотел бы сосредоточиться в обозримой перспективе, наряду с другой проблемой.

#Goal

Блог автора книги "Mastering Archimate":
- https://ea.rna.nl/
Есть что почитать.

#SoftwareArchitecture

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

Мой пост (как и другой) не об этом. В истории были и дворяне, которые посвятили свою жизнь интересам бедноты. Люди, поступающие "вопреки обстоятельствам", были, есть и будут всегда.

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

В этом отношении интересна книга Jeff Sutherland "A Scrum Book: The Spirit of the Game" о том, почему вместо роли Project Manager он ввел роль Product Owner.

Jeff - довольно проницательный руководитель и хороший диалектик (возможно, неосознанный), как и Владик Хононов.

Jeff ввел роль Product Owner вовсе не потому, что не было хороших Project Managers. А потому, что наложив на Project Managers ответственность за ROI он устранил зависимость от личностного фактора, ибо у Product Owner больше не было причин действовать в ущерб долгосрочным интересам проекта, т.к. те вошли в сферу его ответственности. Правда, сам Jeff признает, что таким образом он решил одну проблему, но породил другую проблему, ибо создал мотивацию Product Owner действовать в интересах бизнеса против технических интересов, подробнее здесь (начиная со слов "Интересно, что таким образом они пытались решить другую проблему...").

Да, есть хорошие Product Owners вопреки обстоятельствам, но тем не менее, мы регулярно слышим истории о том, что из-за какого-то Product Owner растет техдолг, кодовая база загнивает, стоимость разработки взлетает, а программисты разбегаются.

Можно сказать, что виной всему конкретная личность, и даже начать перебирать личности на позиции Product Owner до тех пор, пока не повезет с личностью. И это может даже сработать. Вот только таких личностей на все должности отрасли не напасешься.

А можно переделать процессы таким образом, чтоб устранить зависимость внутреннего качества программного обеспечения от личностного фактора, и тогда не придется "угадывать" с личностными качествами Product Owner. Именно так поступил Henrik Kniberg по той же ссылке. Изменяя систему мы изменяем системные проблемы.

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

Возвращаясь к своему посту - захламленность рынка знаний растет, и у этого есть своя причина в экономической плоскости. Означает ли это то, что на рынке больше никогда не появится нового Martin Fowler, Steve McConnell, Edsger Dijkstra, Donald Knuth и т.д.? Нет, не означает. Но означает ли это то, что все участники рынка экономически заинтересованы становиться такими самоотверженными светилами? Нет, тоже не означает. Означает ли это то, что проблема захламленности рынка растет? Да, означает. А значит, по законам диалектики должно появиться решение этой проблемы. Вопрос только в том, кто и какое решение предложит. Но оно обязательно возникнет, как в свое время возникла итеративная модель разработки или Bounded Context.

#Management #Goal

Превосходное пояснение природы сопротивления коллектива изменениям, от Gregor Hohpe "Reversing the disablement cycle:
Everyone does the right thing, yet nothing much gets done. How to break self-reinforcing bad habits":
- https://architectelevator.com/transformation/reversing-disablement-cycle/

P.S.: https://dckms.github.io/system-architecture/emacsway/soft-skills/change-making.html

#Psychology #Management

💬 "Vendors also create complexity in the product strategy. If marketing hasn’t coined a new buzzword or positioned a new-and-improved solution within 6 months, the sales pipeline is at risk."
-- Gregor Hohpe
https://architectelevator.com/architecture/it-complexity/

Gregor Hohpe разделяет точку зрения Niklaus Wirt.

💬 "System Integrators...

Generally, more complexity means more work and thus more revenue. This isn’t necessarily intentional or devious - self-preservation is at the very base of Maslow’s Hierarchy of Needs.

Consultants

While the SIs are the enterprise’s helping hands, consultants are the hired brains. They solve complex problems and devise IT strategies. But they also want to remain employed, so they might solve a problem almost completely, leaving just enough for more work to be done. Self-preservation equally takes hold here. In consultant vernacular this is called scoping or expectation management."
-- Gregor Hohpe
https://architectelevator.com/architecture/it-complexity/

Gregor Hohpe о той же проблеме неоправданного переусложнения.

💬 "If you let externals or vendors define the strategy, you’ll be surprised how well their products fit “your” strategy… Your own strategy has to be the benchmark against which you measure products and services that you buy. Without that baseline, your IT management will resemble kids running down the supermarket aisle, tossing whatever they like into the cart. Come to think of it, I have seen more than one IT that does resemble such a shopping cart…"
-- Gregor Hohpe, "Don’t Outsource Thinking"
https://architectelevator.com/strategy/dont-outsource-thinking/

💬 "Don’t outsource thinking. Keep control of your IT in house and match vendor offerings against your plan, not the other way around."
-- Gregor Hohpe, "Here’s why enterprise IT is so complex"
https://architectelevator.com/architecture/it-complexity/

Gregor Hohpe о ключевой проблеме outsoursing.

Статья уже трехлетней давности, но приводятся методика и средства тестирования - при необходимости можно актуализировать своими силами: "Benchmarking Apache Kafka, Apache Pulsar, and RabbitMQ: Which is the Fastest?"
- https://www.confluent.io/blog/kafka-fastest-messaging-system/

[UPDATE]: Отчеты посвежее, средства тестирования те же:

- "A Comparison of Messaging Platforms: Apache Pulsar vs. RabbitMQ vs. NATS JetStream" https://streamnative.io/blog/comparison-of-messaging-platforms-apache-pulsar-vs-rabbitmq-vs-nats-jetstream

"Apache Pulsar vs. Apache Kafka 2022 Benchmark"
- https://streamnative.io/blog/apache-pulsar-vs-apache-kafka-2022-benchmark

#DistributedSystems

💬 "One of the challenges with outsourcing is that the learning often happens outside your org. How then will you transform? Make sure your outsource partner makes you smarter, not just themselves."
-- Gregor Hohpe

💬 "Indeed, GM is well known for its excellent software. A story: some years ago, I met up with the GM CIO (now long gone) who was proudly asserting that to cut costs GM was outsourcing ALL software development. I advised him, in very polite terms, just how stupid was that idea."
-- Grady Booch

💬 "Almost every outsourcing or service provider contract drives toward 100% utilization of the resources."
-- Michael Nygard, в ответ на "Striving to ensure that no resource be idle is the biggest generator of waste." —Eli Goldratt

💬 "In my experience, IT outsourcing can work well in two situations:
1. Where the outsourced capability is provided as a service with defined APIs and SLOs - ongoing.
2. Where the outsourced capability is provided as a
@ TeamTopologies
Enabling team - temporary."
-- Matthew Skelton

💬 "Every org I talked to that relies heavily on outsourcing mentioned similar problems of lack of alignment of purpose, lack of trust, time to onboard, and (consultant/contractor) turnaround time as blockers to fast flow, ownership, performance, etc."
-- Manuel Pais

Бесподобная статья о legacy от Mathias Verraes "Software design is just theory".

Знакомы фразы?
- “Software design is just theory.”
- “Design patterns are too academic.”
- “Writing code is the only way to become a better programmer.”
- “Just ship it.”
- “That’s over-designed.”

Меткое выражение проблемы (даже Matthew Skelton оценил):
💬 "We have created outsourcing farms, that produce legacy at the speed of typing. It’s legacy as a service (LaaS) [Quote by Pieter Hintjens]"

💬 "Software design has a slow feedback cycle. It takes a long time before your design starts biting you in the butt."

Теория - это обобщенная практика:
💬 "Their ideas are not “just theory”. It’s years of accumulated practice and insights. They work — often in many different contexts. We’re lucky: we can build on top of their ideas."

💬 "Learning is the bottleneck [Ashley Johnson]"

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

#SoftwareDesign #Legacy

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

Эти решения могут не только облегчить участь участников рынка, но послужить коммерческой пищей.

Сделал две группы для обсуждения проблем заказной разработки:

- Для участников рынка (заказчики, инвесторы, представители подрядчика):
https://news.1rj.ru/str/+b4wEgaH81PI2MjZi

- Для участников процесса разработки (продакты, аналитики, архи, разработчики, тестировщики...):
https://news.1rj.ru/str/+1JcBJVE6s3M5N2Qy

Об инструментах управления процессами гибридной SDLC-модели разработки небольших проектов.

Почему меня интересует гибридная модель? По двум причинам:

1. Небольшие проекты имеют, как правило, низкий уровень неопределенности, а значит баланс Prediction/Adaptation у них смещен в сторону Prediction. Они могут разрабатываться вообще по спиральной или даже каскадной SDLC-модели.

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

Я исследовал исключительно Open Source решения.

Абсолютным моим фаворитом стал TaskJuggler (упоминался здесь) - инструмент, который позволяет управлять процессами на текстовых файлах (подобно ADR).

К Taiga у меня интерес угас, т.к. он до сих пор еще использует AngularJS первой версии.

Внимательно изучил три решения: Trac, Redmine и OpenProject.

Все три системы хорошо настраиваются для гибридной разработки - Program Backlog можно организовать либо посредством иерархии проектов, либо через components/subcomponents/category. Все три системы поддерживают Gantt-diagram.

Trac - это недооцененное произведение искусства. Но есть нюанс - подавляющее большинство плагинов написано под версию 1.2. Начиная с версии 1.3.1 шаблонизатор Genshi заменен на Jinja2. Python3 поддерживается только начиная с версии 1.6, которая пока еще в разработке.

Если отфильтровать плагины, совместимые с версией 1.6, то можно увидеть, что для полноценной системы хватает не всего, т.е. развивается Trac в вялотекущем режиме. Это порождает дилемму - использовать Trac 1.2 с полноценным набором плагинов и самостоятельно мигрировать его когда-нибудь потом на Python3, или использовать Trac 1.6 и самостоятельно мигрировать недостающие плагины сейчас? Первый вариант выгодней в краткосрочной перспективе.

Чтобы получить полноценное решение на Trac, нужно попотеть, собрав винегрет из плагинов, но зато открываются широкие возможности кастомизации - можно допилить и PERT, и Monte Carlo, и многое другое. Внутренняя архитектура Trac вызывает симпатию, хотя и не без нареканий в адрес чистоты расслоения.

Пока не обнаружил (два, три) в Trac возможность назначать ticket на команду (см. set_owner).

Сопоставление Agile-терминов и терминов Trac идентично как в Gitlab.

Redmine, в отличии от Trac, предоставляет основной функционал из коробки. Хотя он тоже имеет хранилище плагинов для расширения, но в них нет особой нужды. Есть неплохой плагин для Scrum, хотя Redmine и без него можно использовать в Agile.

OpenProject - это форк Redmine с Angular-based frontend, из коробки адаптированный под Agile несколько более Redmine.

Создание плагинов

Поскольку ни одно из этих решений не предоставляет возможности работать с оценкой, как с вероятностной распределенностью, то возникает потребность в допиливании.

Trac
- Developer guide
- Writing plugins
- Extension Points
- Project management ideas
- By apache (REST)

Redmine
- Developer guide
- Writing plugins
- Hook list
- Sample

OpenProject
- Developer guide
- Writing Plugins
- Application architecture
- Sample (там же список hooks & events)

Другие решения

LibrePlan - Open Source project management tool, поддерживающий Monte Carlo из коробки (упоминался здесь). Интересное решение для коллективного планирования. Не обнаружил поддержки иерархии ресурсов (Team/Member).

Но иногда коллективность не востребована, например, на этапе предварительного согласования плана разработки. Потенциальный исполнитель и заказчик/инвестор пока еще не объединены ни контрактом, ни совместно-используемыми инструментами, и их могут заинтересовать:
- ProjectLibre
- GanttProject (имеет политизированный GUI, но предоставляет средства синхронизации)
- Twproject Gantt editor

Django-based

Ещё привлекли внимание django-projector (давно заброшен, но несложно реанимировать), NearBeach и matorral.

Reference Application

From the book "Implementing Domain-Driven Design" by Vaughn Vernon for Java and for .Net.

#Management #Scheduling #Estimation