💬 "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://www.tgoop.com/+b4wEgaH81PI2MjZi

- Для участников процесса разработки (продакты, аналитики, архи, разработчики, тестировщики...):
https://www.tgoop.com/+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

Интересная статья о роли когнитивных искажений в процессе выявления требований:
"Why system requirements are a dangerous illusion"
June 5, 2013 by Paul Ralph

#Analysis

💬 "The first edition of Extreme Programming Explained had a more abstract estimation model, in which stories cost one, two, or three "points". Larger stories had to be broken down before they could be planned. Once you started implementing stories, you quickly discovered how many points you typically accomplished in a week. I prefer to work with real time estimates now, making all communication as clear, direct, and transparent as possible."

-- "Extreme Programming Explained", 2d edition, Kent Beck

Kent Beck - автор Extreme Programming, где и появилось понятие Story Point. Предполагаемый автор самого термина - Ron Jeffries, тоже высказался по этому поводу.

Есть ли польза от Story Points?

1. Существует мнение, что Story Point является абстракцией от скорости команды, хотя сам Ron Jeffries с этим не согласен. На самом деле, такая абстракция бесполезна, т.к. оценивание служит цели планирования, а значит, до назначения команды на Story мы лишены возможности осуществить планирование, ибо отсутствует ключевая переменная - скорость команды.

Но как только команда назначена (на Cross-Team Refinement, "It helps the Scrum Teams forecast which team will deliver which Product Backlog items"), тогда теряется смысл вводить паразитный уровень абстракции.

2. Если команды могут работать с разной скоростью, то, казалось бы, эффективность команды является атрибутом самой команды, и этот параметр можно было бы сделать конфигурируемым в системе управления проектом. И, по крайней мере одна такая система мне известна - это TaskJuggler. Но вот что они пишут в описании этого параметра:
💬 "A resource that isn't very good at some task might be pretty good at another. This can't be taken into account as the resource efficiency can only be set globally for all tasks."
-- https://taskjuggler.org/tj3/manual/efficiency.html

Эффективность команды может существенно варьироваться в зависимости от характера конкретной задачи. Таким образом, до тех пор, пока мы не назначим команду на Story, мы не можем судить об эффективности команды.

3. Самое главное - Story Point совмещает в себе и вероятностную оценку, и её среднеквадратичное отклонение. Именно поэтому в Story Points традиционно используются числа Фибоначчи - ибо нет смысла делать предел измерения точнее погрешности измерения, которая растет вместе с размером задачи.

Но оценка - это вероятностная распределенность, которая не выражается одним-единственным значением. Вероятностная оценка и среднеквадратичное отклонение складываются по-разному! Таким образом, не существует способа сложить Story Points, что делает их бесполезными для планирования даже если известно какая именно команда будет реализовывать Story. Мы можем их сложить лишь на краткосрочном горизонте одного-двух спринтов, где точностью сложения не существенна.

4. Существует мнение, что Story Point - это не о времени и не о трудоемкости, а о сложности. Кроме того, что сам Ron Jeffries опровергает это, Mike Cohn убедительно разъясняет почему это не так, в статье "Story Points Are Still About Effort".

Story Point - это все-таки о трудоемкости, и как показывает практика, это более сложный и менее точный способ оценивания для планирования, нежели, например, PERT. Нужно ли из времени выводить абстракцию, чтобы затем из неё снова получить время для планирования, при этом утратив точность?

Неужели он совсем бесполезен? На самом деле, польза от него есть, и она кроется в причинах его появления. Как говорил Ron Jeffries, они придумали Story Points потому, что было сложно объяснять, почему задача на 2 идеальных дня заняла 5 календарных дней. Иными словами, Story Point имел целью противодействовать когнитивным искажениям участников процесса разработки и снять напряжение между представителями бизнеса и техническими специалистами.

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

#Management #Scheduling #Estimation

💬 "Горожане хотят солнышка, а селяне - дождика. Всем не угодишь" -- не знаю, кто автор - говорят, что Марк Твен (хотя я отыскать не смог).

Казалось бы - все просто и понятно, как и "This morning your team can add more code, or add more customers. Which do you want?"

На первый взгляд кажется, что сторонами конфликта являются горожане и селяне. Можно ли примирить обе стороны? И так ли это на самом деле?

Как отразится на горожан засуха? Разве не пострадают они больше селян от недостатка продовольствия? Между горожанами и селянами существует связь, которая не была рассмотрена. И связь эта - жизнеобеспечивающая. Тут начинает проясняться, что конфликт этот вовсе не между горожанами и селянами, а между краткосрочнами и долгосрочными интересами горожан. Это и есть основная проблема в разработке.

💬 "Это достаточно сложно — разработать процесс, в рамках которого краткосрочные личные интересы служат долгосрочным интересам всей команды. Вы можете сколько угодно рассуждать на тему, насколько та или иная методика способствует достижению долгосрочной всеобщей цели, однако как только вы оказываетесь под давлением, вы обнаруживаете, что если методика не способствует решению конкретной проблемы, стоящей перед вами в настоящий момент, вы отбрасываете ее в сторону. Если дисциплина ХР не будет удовлетворять краткосрочным личным интересам людей, она обречена на провал.

It's been tricky, designing a process where following short-term self-interest also serves long-term team interest. You can expound all you want on how some practice or other is in everybody's best interest long-term, but when the pressure mounts, if the practice doesn't solve an immediate problem it will be discarded. If XP can't work with people's short-term interest, it is doomed to the outer methodological darkness."
—"Extreme Programming Explained" 1st edition by Kent Beck, "Chapter 8. Basic Principles", перевод ООО Издательство "Питер"

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

Short-term individual goals often conflict with long-term social goals. Societies have learned to deal with this problem by developing shared sets of values, backed up by myths, rituals, punishments, and rewards. Without these values, humans tend to revert to their own short-term best interest."
—"Extreme Programming Explained" 1st edition by Kent Beck, "Chapter 7. Four Values", перевод ООО Издательство "Питер"

Задача хорошего лидера - проливать свет на последствия того или иного решения, предвидеть и предотвращать.

#Management

💬 "Impact – воздействие, которое мы собираемся сделать. Это самая сложная часть, которая мало кому дается. Я сравниваю ее с созданием гипотезы в научном методе или рождением идеи в ТРИЗ, т.е. техника понятна, но откуда берется идея, как она рождается в голове, как научить человека эти идеи создавать, решительно неясно."
-- https://habr.com/ru/articles/652577/

Это та самая причина, которая вызывает у меня неподдельный интерес к диалектической философии и теории игр. Особенно к диалектической философии. О её практичности и полезности говорит хотя бы тот факт, что она успешно существует и здравствует еще со времен Гераклита, и широко распространена на востоке (значок Инь-Янь известен, наверное, каждому). И не случайно слова "развитие", "развить" имеют значение "расплести": развить веревку, развить венок, развить косу.

Итак, чтобы развить продукт, нужно сперва развить (расплести) его противоречия. Наглядно это можно увидеть на примере того, как Владик Хононов в своей книге удивительным образом выводит противоречие, которое привело к появлению решения в виде Bounded Context.

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

С другой стороны, оплата за битье горшков само по себе является синтезом, а значит, в его основе должно лежать противоречие. Какое же?

Противоречие это заключается в том, что стремясь получить больше денег, гончар производит больше горшков. И чем больше горшков он производит, тем больше он привлекает к ним хулиганов, и тем больше величина ущерба (меньше денег). Все в точности как с проблемой о полноте и сложности модели в DDD.

И влияет это противоречие на доходность гончара.

Решением в DDD стала граничность модели (с целью снижения сложности) в контексте решаемой проблемы - Bounded Context. Решением в притче о гончаре стала граничность доходности за причинение ущерба. Гончару потребовалось сформировать обратно-коррелирующее противоречие, т.е. чем больше горшков разбито, тем меньше доходность у соперничающей стороны. Для этого была навязана другая модель мотивации, которую соперничающая сторона могла контролировать исключительно посредством функции, единственный входной аргумент которой - это количество разбитых горшков.

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

Диалектика - это искусство, которое равно применимо и в военном деле, и в дипломатии, и в полемике, и в экономике, и в политике, и в архитектуре. Она абстрактна. Потому Морихей Уесиба и сказал, что

💬 "В Искусстве Мира нет состязаний. Истинный Воин
непобедим, поскольку он ни с кем не сражается. Когда мы говорим "нанести поражение", то имеем в виду поражение нашего собственного противоречивого ума"
-- 111 жемчужин, Морихей Уесиба

О чем он говорит? Он говорит о том, что если воин владеет диалектикой, то не нуждается в проявлении физической агрессии для того, чтобы победить, ибо изменить расстановку сил он может и словом, компенсируя противоречия, как в случае с гончаром.

💬 "Всякая истина, выраженная словами, есть сила, действие которой беспредельно."
-- Л.Н.Толстой

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

Какое это все имеет отношение к архитектуре? Ключевой деятельностью в архитектуре является разрешение противоречий требований (и целей). Задача архитектора - разрешить эти противоречия до того, как они проявят себя в реализации, теряя ценность продукта в глазах пользователей. Тогда не понадобится проявление героизма для спасения продукта от самого себя. Знать, чтобы предвидеть.

Потихоньку возвращаюсь к Golang DDD Reference Application Grade. Это не только демонстрационный, но еще и вполне реальный проект, который, используя принципы теории игр, позволяет существенно повысить объективность и качество т.н. карма-движков, и повысить качество информационного пространства экспертных сообществ. А так же будет выступать альтернативой бесполезным формально-бюрократическим grade-системам ИТ-компаний на основе матриц компетентностей, которые не способствуют развитию специалистов, а, наоборот, препятствуют, оттягивая ресурсы времени на нерелевантные аспекты в ущерб релевантным. А самое главное - экспертное сообщество будет само себя квалифицировать и развивать, без всяких тестов, эталонов, экзаменаторов и пр. ограничителей развития, установивших монополию на компетентность.

С технической стороны проект принципиально не использует ORM (чтоб продемонстрировать, как можно без него обходиться); принципиально соблюдает ключевые принципы OOP, особенно инкапсуляцию, поскольку иначе технически невозможно гарантировать инварианты агрегатов; использует CQRS/EventSourcing, причем, будет реализовывать Causal Consistency посредством Causal Dependencies.

Задача амбициозная. Взялся за нее потому, что не смог отыскать существующего прецедента. Реализация сопровождается интенсивной исследовательской работой, и каждая строка кода подкреплена теоретическими изысканиями в десятках архитектурных книг. Будет документация, ADR, архитектурная документация и трассировка требований - в общем, будет демонстрация всех SDLC-этапов разработки.

Если у кого-то есть желание принять участие в разработке - обращайтесь в приват ( @emacsway ). Сейчас уже вырисовываются задачи и для джунов/мидлов тоже.

#Goal #Grade

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

# \d permission
Table "trac.permission"
Column | Type | Collation | Nullable | Default
----------+------+-----------+----------+---------
username | text | | not null |
action | text | | not null |
Indexes:
"permission_pk" PRIMARY KEY, btree (username, action)


Trac не перестает удивлять. Если бы не документация, то вряд ли догадался бы. Простота, с которой авторы Trac решают сложные задачи, шедевральна. Нечасто можно встретить, когда так мало кода делает так много. Гораздо чаще приходится наблюдать гораздо большее количество таблиц, которые не реализуют вообще никакого наследования, не говоря уже о множественном наследовании.

💬 "Simplicity is a great virtue but it requires hard work to achieve it and education to appreciate it. And to make matters worse: complexity sells better."
—Edsger W. Dijkstra, 1984 On the nature of Computing Science (EWD896)

#Management #SoftwareDesign

Если у кого-то есть желание сделать имя на действительно важной и востребованной вещи, для которой не требуется глубоких теоретических познаний (в отличии от Grade) и достаточно уровня middle по Python, то я могу подкинуть идею:

1. Портировать plugin TracHoursPlugin на Trac 1.6. Руководство по миграции:
- https://trac.edgewall.org/wiki/TracDev/PortingFromGenshiToJinja

По большей части нужно портировать только шаблоны с Genshi на Jinja2:
- https://trac.edgewall.org/wiki/TracDev/PortingFromGenshiToJinja/Example

2. Усовершенствовать этот plugin, чтобы он позволял выражать оценку в виде вероятностной распределенности в соответствии с PERT, т.е. исходя из введенных пессимистической, номинальной и оптимистической оценок вычислял вероятностную оценку и среднеквадратичное отклонение. Это несложно.

3. Доработать plugin SumFieldsPlugin, чтобы он мог складывать среднеквадратичные отклонения как корень квадратный суммы квадратов.

4. То же самое сделать с plugin ValuePropagationPlugin.

5. И то же самое - с plugin RoadmapHoursPlugin. Там уже пытались сделать костыль для обработки погрешности - нужно сделать нормально.

6. Разобраться с Gantt-плагинами, выбрать наиболее перспективный, портировать его на Trac 1.6, и научить его работать с вероятностной распределенностью.

7. Если этого показалось мало, тогда можно заглянуть сюда и сюда. На рынке мало толковых инструментов для организации грамотного планирования и процессов разработки, особенно среди Open Source. А это - хороший шанс донести свое имя грамотным управленцам вместе с инструментом, который им нужен.

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

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

В крайнем случае придётся сделать самому.

Я вижу возможным создать быстровозводимую коробочную среду управления процессами для гибридной SDLC-модели разработки с открытым исходным кодом, заточенную для небольших проектов маленьких аутсорсеров. Чтобы разворачивалось одним кликом, как когда-то Apache Bloodhound (подробнее).

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

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

Почему Trac? В силу определенной проблемости использования Jira (и её расширений) в РФ, и в результате моего исследования рынка существующих решений, я пришел к выводу, что Trac несправедливо недооценен, и архитектурно он является наиболее гибкой системой с безграничными интеграционными возможностями для автоматизации процессов и с богатым консольным интерфейсом. Остальные инструменты я со счетов тоже не сбрасываю, но, в качестве фундамента для допиливания, Trac мне видится наиболее привлекательным.

Может показаться, что Trac морально устарел перед, например, OpenProject. Но его особенность в том, что там стареть нечему. Для написания плагинов достаточно знать SQL, в то время как для написания плагинов под OpenProject нужно знать Ruby On Rails и Angular, что существенно сокращает круг контрибьюторов. Новомодный frontend на Vue под Trac тоже есть.

Но главная особенность Trac - его легче оформить в DDD-стиле с нормальными Domain Events, чем обеспечится еще более стройная расширяемость. На его базе можно создать современный и архитектурно красивый продукт. Не просто же так Vaughn Vernon выбрал именно эту предметную область для своей "Красной Книги".

Кому интересно - пишите мне в личку: @emacsway

[UPDATE]: Вводный материал по оцениванию можно посмотреть здесь.

#Management #Scheduling #Estimation #Goal

Вводный материал по оцениванию и планированию можно посмотреть здесь:
- https://www.tgoop.com/emacsway_log/916

Скачать литературу можно здесь:
- https://www.tgoop.com/emacsway_log/1078

#Scheduling #Estimation

Сделал в Trac обратное портирование поддержки Genshi шаблонов и ITemplateStreamFilter, которые широко использовались плагинами его предыдущих версий:
- https://github.com/emacsway/trac

Заманкипатчить, к сожалению, не получилось, поэтому получился форк вместо плагина. Хотя, так будет даже легче сопровождать.

Теперь для Trac 1.6 стало доступно большое количество плагинов от его версий 1.0 - 1.4 с минимальными переделками (как правило, достаточно запустить команду 2to3), что позволяет выиграть время для полноценного портирования плагинов и уже сейчас начать их использовать.

По крайней мере уже один из плагинов (для оценивания и учета времени) заработал нормально. Здесь его актуализированная версия.

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

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

В перспективе - создать полноценный инструмент для управления процессами гибридной SDLC-модели разработки, включая Program Backlog, Product Backlog, оценивание посредством вероятностной распределенности, управление требованиями и описание архитектуры. Все это - исключительно с открытым исходным кодом. В отдаленной перспективе - переписать все в DDD-style с нормальными Domain Events, чем обеспечится еще более стройная расширяемость.

Хотя в Trac существует плагин для мультипроектности, но мне больше импонирует вариант развертывания по отдельному проекту на окружение. Это дает команде полный контроль над настройками, плагинами, конфигурацией workflow, интеграцией. Не нужно дергать службу эксплуатации по каждому чиху. Из всех щелей не лезут нерелевантные данные других проектов. При этом различные проекты прекрасно между собой интегрируются, образуя распределенную сеть независимых проектов.

#Management #Scheduling #Estimation #Goal

🔷 "Что такое сопротивление изменениям и как с ним работать?"

Автор проделал немалую работу по систематизации знаний на тему сопротивления коллектива изменениям. Этой теме посвящен весь сайт.

#Psychology #Management