Forem: Dídac Rios

Understanding the Domain and Building the Team: The Foundations of Change (II)

Dídac Rios — Sun, 19 Jan 2025 09:43:56 +0000

When starting a complex project like the one we are tackling, it's essential to gather as much context as possible while also approaching the domain knowledge from scratch and exploring it with the help of domain experts. This activity not only helps the technical team align with business goals but also creates a global map that lays the foundation for making better decisions throughout the product lifecycle.

To understand how the existing application worked, identify the various processes it executed, and determine how they were represented in the code, while establishing a common language with the previous team and current application users, we conducted initial sessions that were not very fruitful. At one point, we even considered whether we could move forward without these sessions and figure things out on our own, despite the potential for disruption.

EventStorming

From the beginning of the project, as the tech lead, given the complexity of the project and the need for the team to take real ownership of the product, I pushed to adopt a domain-driven approach to both the project and the team.

This approach allowed us to place the domain at the center of the narrative, aligning the entire team around a common language (ubiquitous language), which facilitated communication and enabled us to map the application's current state.

With this goal in mind, we formed the initial team and began preparing EventStorming sessions. This visual methodology helped us decompose the system’s key processes and identify relevant domain events and entities.

To facilitate the sessions, we used a Miro template that provided some guidance and a legend with key references to focus such sessions effectively. If you plan to conduct such a session, it’s helpful for participants to have a basic understanding of the concepts they’ll be working with, either through some pre-work or an explanation at the start of the session.

To maximize the effectiveness of these sessions, we developed a structured process divided into several phases:

Exploring Domain Events (Big picture)
- Identify the system's key events.
- Order them chronologically.
- Detect gaps and dependencies.
- Validate the sequence with domain experts.
Refinement and Analysis
- Add explanatory notes.
- Document doubts and questions.
- Delve deeper into each event.
- Highlight critical decision points.
Domain Modeling
- Identify aggregates and their boundaries.
- Define actors and their roles.
- Establish commands that trigger processes.
- Document policies and business rules.
- Identify internal and external triggers for each event.
Documentation and Validation
- Organize and clean the collected information.
- Establish clear relationships between elements.
- Validate the model with all stakeholders.
- Create reference documentation.

EventStorming not only helped us understand the domain but also served as the starting point for applying Domain-Driven Design (DDD) principles both strategic and tactical.

Strategic Domain-Driven Design

One of the most important aspects during the initial project phase was deciding how to structure the domain at a strategic level. The system's complexity, combined with the need to align technical and business goals, led us to adopt principles of Domain-Driven Design (DDD).

During this process, one of the most useful tools was Context Mapping. Although we were working with a monolith still awaiting refactoring, we took the time to identify various Bounded Contexts within the domain. Practically speaking, this meant that while we had described and defined multiple conceptual contexts, technically, we operated within a single Bounded Context with a shared kernel. This monolithic reality didn't prevent us from benefiting from this analysis.

Although we didn't delve deeply into Context Mapping, using these techniques at this stage was critical to ensuring the project had a clear path toward a domain-oriented architecture. This approach not only facilitated technical development but also fostered better collaboration between technical and business teams.

Defining Boundaries (Bounded Contexts)

Identifying the Bounded Contexts helped us better understand how different parts of the system related to each other and to external systems. This exercise not only helped us manage complexity more efficiently but also established a clear foundation for the project's evolutionary steps. As the system transitions to a more modular architecture, these initial decisions will guide us in breaking down the monolith into more manageable components aligned with the defined contexts.

It also helped us prioritize development efforts and identify parts of the system that could be simplified, decoupled, or eliminated. Technically, we focused on implementing Anti-Corruption Layers (ACL) to interact with external systems without compromising our system's integrity.

In our case, we initially identified five major contexts:

Order Assignment
Label Generation
Order Preparation
E-commerce Integration
Bulk Order Preparation

These decisions not only established the foundation for a sustainable architecture but also ensured that development processes were more focused and aligned with business needs.

Ubiquitous Language

Another key aspect was establishing a solid ubiquitous language. The advantages of defining this language far outweigh the extra translation effort or the risk of misinterpreting concepts. Domain Experts and developers must actively collaborate to create this common language, which goes beyond a simple glossary of terms. It's a living, dynamic resource that connects the technical team with domain experts.

Implementing this ubiquitous anguage improved communication, reduced misunderstandings, and ensured the code faithfully represented the domain. Software development isn't just a technical activity; it's based on communication and collaboration. Thanks to the ubiquitous language, all team members work in alignment, resulting in more efficient technical solutions that better meet business needs.

Tactical Domain-Driven Design

Once we established the strategic framework, we moved on to implementing tactical DDD principles in the system. This allowed us to structure the code to reflect the domain's reality and ensure long-term sustainability.

Entities and Value Objects

Entities and Value Objects are two fundamental concepts in Domain-Driven Design (DDD). Understanding their differences and roles within the domain is crucial.

Entities

Entities are domain elements with a unique identity that persists over time, even if their attributes change. This unique identity distinguishes them from other elements of the same type. Additionally, entities usually have a defined lifecycle within the system. Examples of entities we identified in the project include:

Order: Represents a purchase order with a unique identity and an associated state.
Product: Catalog item with attributes like SKU code, price, and description.
Carrier: Company responsible for delivering orders with specific service options.
Shop: Identifies the e-commerce or platform where the order originated.
Customer: The person or entity placing the order and receiving the product.

Value Objects

Value Objects, on the other hand, are domain elements without their own identity. Their value defines them, and two Value Objects with the same attributes are considered equivalent. This makes them immutable and ideal for encapsulating key concepts that may appear across various parts of the domain. Examples of Value Objects in the project include:

ProductReference: Unique code identifying a product.
ProductEan13: EAN-13 barcode associated with a product.
OrderReference: Unique identifier for an order.
Price: With currency and precise value.
Weight: With standardized measurement units.
ShippingNumber: Identification number for tracking.

This approach helps create more understandable and modular code, as each system element has a clear and well-defined responsibility.

Example of a Value Object:

<?php
readonly class ProductEan13
{
    public string $value;

    public function __construct(
        string $value
    )
    {
        $pattern = '/^\d{13}$/';
        if (!preg_match($pattern, $value)) {
            throw new \Exception('Invalid product Ean13');
        }
        $this->value = $value;
    }
}

Services

In a complex application like ours, the concept of Services plays a central role in maintaining clean and modular code. Services are categorized into different layers and types based on their purpose and the patterns they implement. Let's explore how we organize and implement services effectively.

Domain Services

Domain Services encapsulate business logic that doesn't fit directly into any specific entity or value. These services operate strictly within domain rules and don't depend on infrastructure components.

<?php
class CheapestCarrierGetter
{
    public function get(
        DeliveryOptionCarrierCollection $deliveryOptionCarriers,
        Weight                          $orderWeight,
        Country                         $country,
        PostalCode                      $postalCode,
        bool                            $isCashOnDelivery = false,
    ): Carrier {
        // Lògica per obtenir el transportista més econòmic
    }
}

Application Services

Application Services encapsulate and coordinate logic that combines domain operations with external interactions to implement specific business or application scenarios. These services centralize and simplify the implementation of complex operations, ensuring a clear separation between the domain and infrastructure. The most well-known examples are use cases, but in our case, we will also have Command Handlers and Event Handlers.

Use Cases represent specific actions or processes that the application needs to perform to meet business requirements. They encapsulate the necessary logic to execute complex operations, including interactions with domain services and infrastructure, keeping the domain clean and focused. We could say that their responsibility should be only to orchestrate between these two layers, leaving the responsibility to the domain, as Vaughn Vernon says, "Keep Application Services thin, using them only to coordinate tasks on the model."

Command Handlers are the entry point for modifications to the domain. Upon receiving a Command, they validate the request, delegate the business logic to the corresponding aggregates, and finally, publish an event that reflects the change produced in the system.

On the other hand, Event Handlers act as listeners to changes in the system. They listen to events and execute specific actions in response, such as sending notifications, updating other aggregates, or integrating with external systems. This decoupled reaction allows for the construction of more flexible and scalable systems. I will expand on the details and concepts in future entries when we talk about the evolution of the application as an event-driven architecture (EDA) and queuing systems.

<?php
readonly class NotifyShopOnOrderShipped implements EventHandlerInterface
{
    public function __construct(
        private OrderRepositoryInterface    $orderRepository,
        private ExternalOrderUpdaterFactory $externalOrderUpdaterFactory,
        private LoggerInterface             $logger
    ) {}

    public function __invoke(OrderShippedDomainEvent $event): void
    {
        // Lògica per notificar la botiga quan una comanda ha estat enviada
        $order = $this->orderRepository->findById($event->getOrderId());
        if (!$order) {
            $this->logger->error("Comanda no trobada", ['orderId' => $event->getOrderId()]);
            return;
        }

        $updater = $this->externalOrderUpdaterFactory->create($order);
        $updater->updateStatus('shipped');

        $this->logger->info("Notificació d'enviament completada", ['orderId' => $order->getId()]);
    }
}

Infrastructure Services

Infrastructure Services implement operations that rely on external components such as databases, file systems, or third-party services. They often act as adapters to ensure that the domain remains agnostic to the specific implementation.

<?php
class MonologLogger implements LoggerInterface
{
    private $logger;

    public function __construct(Logger $logger)
    {
        $this->logger = $logger;
    }

    public function info(string $message, array $context = []): void
    {
        $this->logger->info($message, $context);
    }

    public function warning(string $message, array $context = []): void
    {
        $this->logger->warning($message, $context);
    }

    public function critical(string $message, array $context = []): void
    {
        $this->logger->critical($message, $context);
    }

    public function error(string $message, array $context = []): void
    {
        $this->logger->error($message, $context);
    }
}

Service Classification

As we've seen, services help us decouple and decompose our application's logic into more granular and independent units. Here's a classification of common services we've identified in our project, grouped by their primary function and associated with known design patterns. This classification provides a more structured view of our architecture and facilitates decision-making when designing new features.

Service Type	Description	Pattern	Example
Transformers	Convert data between different formats or representations.	Adapter	Convert external API responses into domain models.
Builders	Construct complex objects step by step.	Builder	Create an `Order` object.
Factories	Create domain objects ensuring they comply with rules and restrictions.	Factory	Create instances of `Product`.
Presenters	Format data for the user interface or API responses.	Decorator	Enrich data to display to the user.
Notifiers	Send notifications (email, SMS, etc.).	Observer	Notify the user of important changes.
Validators	Ensure that objects comply with business rules.	Strategy	Validate user requests or forms.
Clients	Interact with external applications or services.	Proxy	Consume external APIs to obtain information.

All these domain concepts are just a small sample of everything we managed to model. Obviously, we didn't do it all at once and we didn't get everything right the first time: there are many parts that still needed to be restructured, concepts that we didn't fully clarify and repositories that we knew didn't make sense, but that we had to maintain for functionalities, but that we had to end up eliminating.

But with this initial work done, it allowed the entire team to participate in this process and have a commitment to everything we were building.

To delve deeper into these DDD concepts and how to apply them, I recommend reading the following books:

"Domain-Driven Design: Tackling Complexity in the Heart of Software" by Eric Evans: The foundational work on DDD that introduces and explains in depth the concepts of entities and value objects.
"Implementing Domain-Driven Design" by Vaughn Vernon: A practical book that offers concrete examples of how to implement DDD in real-world projects.
"Domain-Driven Design in PHP" by Carlos Buenosvinos, Christian Soronellas & Keyvan Akbary

Building the Team

The process of adopting DDD went hand-in-hand with the team's formation and evolution. This is where I want to talk about Tuckman's stages model (1965): Forming, Storming, Norming, Performing, as I believe the team's evolution followed this sequence and it helped us, on the one hand, to align our technical practices and on the other to develop a culture of collaboration and trust within the team. As Tuckman (1965) describes, understanding and embracing these stages is key to building high-performing teams. The original reference can be found in his work: Tuckman, B. W. (1965). Developmental sequence in small groups. Psychological Bulletin, 63(6), 384–399.

According to this model, teams go through four distinct phases to reach maximum performance. During the initial phase (Forming), team members introduce themselves and define general objectives. In the Storming phase, conflicts emerge as roles begin to be established. Over time, in the Norming phase, teams achieve a cohesive work dynamic, culminating in Performing, where they work efficiently towards common goals.

Forming

The team was initially formed with two developers who began reviewing the project and documenting its operation, while other members closed their respective projects to join. For my part, I joined as a tech lead and began reviewing the new documentation that had been generated and establishing the technical and organizational foundations of the project and the team in terms of processes, standards, and tools.

Storming

We couldn't say there were major disagreements within the team, but we did see the need to "regulate" certain aspects in order to be more aligned. This need became more apparent when we added two more people to the team and the roadmap began to take shape. This led us to consider how we wanted to work, communicate, and above all, how to make all these decisions and knowledge visible in a project that was constantly evolving.

So we quickly moved on to the Norming phase to establish the foundations of how we wanted to work and how we wanted to organize ourselves.

Norming

During this period, we agreed on several aspects to facilitate teamwork:

Team Agreements: Rules for teamwork and communication such as defining ceremonies, meeting schedules, communication channels, etc.
Coding Standards: Guidelines for writing clean and maintainable code following the foundations of DDD, Hexagonal Architecture, and SOLID principles.
Development Process: Definition of the tools, processes, and practices to follow to maintain an efficient workflow, with the aim of improving code quality and team productivity, fostering a culture of collaboration and learning.
WIP (Work In Progress) Limits: To ensure a sustainable workflow. It has a separate chapter to reinforce its importance, as part of the Lean methodology that we approached.
Deployments: Rules for controlled and reliable deployments, including time limits and rollback procedures.
Technical Debt: Definition and management of accumulated technical debt as well as providing a framework to identify and prioritize it if necessary.
ADRs: Registration and justification of architectural decisions to ensure consistency and traceability of decisions made.

Performing

With all the work done in the previous stages, we had created a framework that allowed us to focus on product development efficiently and without worry, beyond the need to prioritize those initiatives that provided the most value in the context of each moment. This allowed the team to focus on implementing business functionalities while improving code quality, training, and keeping documentation alive.

Documentation

All this effort would be meaningless if it were not made visible in some way. We documented it so that it was accessible at any time and easy to update. We used GitLab to manage the project code, so we activated the GitLab Pages functionality and after a little research we used Jekyll with the Just the Docs theme.

To organize the information, we based ourselves on the Diátaxis model:

Tutorials: Guides for application functionalities, mainly aimed at the end user (example: Transporter Configuration).
Guides: Practical instructions and solutions to specific problems, for both end users and developers (example: How to install the application).
Explanations: In-depth knowledge of team processes and standards (example: Team agreements and coding standards).
References: Detailed information for developers (example: ADRs, application architecture).

A next step we didn't fully implement was automating technical documentation using Event Catalog and AsyncAPI. This would have allowed us to generate documentation directly from our codebase, ensuring that it was always up-to-date.

From Legacy Software to Strategic Opportunity: The Starting Point (I)

Dídac Rios — Mon, 13 Jan 2025 16:02:21 +0000

When we talk about legacy software, we often think of outdated or poorly designed applications. However, the reality is that "legacy" can refer to any application that, while functioning correctly, presents significant challenges for evolution and maintenance. This is the story of how we approached the internalization of a logistics order management system (OMS), with the added challenge of integration with a new e-commerce platform.

The Initial Context

In 2018, the application was developed with the aim of optimizing the order preparation process for a growing e-commerce business and ensuring efficient integration with various logistics operators. Built with PHP (Symfony), MySQL, Socket.io, and jQuery, the application handled everything from packaging to shipping, including shipment tracking, carrier connections, label generation, and performance metrics for order preparation.

For years, this tool fulfilled its purpose. However, over time and with business evolution, significant limitations began to surface.

Accumulated Technical Debt

The technical debt situation was particularly concerning, as it affected multiple layers of the project. On the technological infrastructure level, the application ran on outdated versions of both the framework and the base language:

The Symfony version (4.0) was not LTS (Long-Term Support) and had stopped receiving security updates as of January 2019.
PHP 7.1 had also reached its end-of-support cycle, leaving the system without critical security updates.

Beyond outdated versions, the project showed significant deficiencies in fundamental aspects of software development:

Non-existent or inadequate testing: The lack of automated tests (unit, integration, and end-to-end) not only made early error detection difficult but also turned any modification into a potential risk for system stability.
Lack of code standards: The codebase did not follow documented patterns or standards, and those applied were not aligned with industry best practices. This complicated both maintenance and the on-boarding of new developers to the project.
Insufficient documentation: Existing documentation was scarce and often incomplete. This impacted not only technical development but also the understanding of business processes implemented in the code.
Poor version control: The Git history was poorly descriptive, with non-granular commits and messages that followed no conventions or provided context about the changes made. This made it hard to understand the code's evolution and the decisions made over time.

This accumulation of technical debt not only posed a risk to the system's stability and security but also:

Slowed the development pace for new features.
Increased the risk of introducing errors.
Hindered the on-boarding of new team members.
Increased maintenance costs.
Complicated problem diagnosis and resolution.

Structural Limitations

The initial architecture presented coupling issues that severely affected its flexibility and scalability:

Total dependency on the main e-commerce platform: The application could not operate autonomously, as all logistics operations depended directly on the data and processes of the e-commerce platform. This meant that any change to the main platform could break the system's functionality.
Shared database causing performance issues: Both the logistics application and the e-commerce platform used the same database, leading to performance problems, especially during peak loads for either application. Additionally, this setup complicated permission management, as any database access could compromise critical data from other systems.
Inability to operate independently: The application was designed to work exclusively with the e-commerce platform. This not only limited its portability but also complicated testing in isolated environments or migration to other platforms. Its dependencies were not properly encapsulated, making any attempt to isolate it require massive and costly system-wide changes, with main classes failing to adhere to the Single Responsibility Principle.
Difficulty implementing new features: The lack of adherence to principles like Open/Closed (OCP) and Liskov Substitution (LSP) made system evolution extremely challenging. New features required modifying existing code, increasing the risk of introducing regressions. Moreover, direct module dependencies made it nearly impossible to follow the Dependency Inversion Principle (DIP).

These structural limitations not only reduced the system's maintainability and scalability but also increased the risks associated with any modification or evolution, placing the application in a technically fragile and strategically vulnerable state.

Development Management and Strategic Alignment

One of the most significant challenges was not only technical but also strategic. External development, while functionally correct, presented important limitations in the organizational domain:

Disconnection from overall strategy: Development was carried out in isolation, without a complete view of the company internal goals and processes. As a result, functionalities that were technically correct did not always align with the business actual needs.
Lack of strategic prioritization: New features were implemented without a clear vision, valuation and prioritization process. There was no questioning of whether a feature was truly necessary, the best way to implement it, or whether there were more efficient alternatives.
Reactive vs. proactive development: Development followed a largely reactive pattern, addressing immediate needs without considering the long-term impact or potential synergies with other company processes.
Absence of validation processes: The lack of a structured review and validation process resulted in functionalities that, while operational, were not always the best solution for end users or the company's overall objectives.

This situation was unsustainable in the long term, as it:

Produced a product increasingly misaligned with real needs.
Complicated integration with other systems and company processes.
Hindered strategic decision-making about the product.
Limited the team's capacity for innovation and continuous improvement.

The Basal Cost Impact

An often-overlooked but particularly relevant aspect of this project was the basal cost, a key concept in software development that refers to the minimum cost required to keep a system operational, even without adding new features or improvements.

In our case, the basal cost included all expenses related to maintaining outdated versions of the framework and language, addressing urgent issues stemming from accumulated technical debt, managing dependencies with other systems, adapting to a tightly coupled architecture, and lacking domain knowledge. These factors consumed a significant portion of available resources, directly impacting the team's ability to invest in innovation and continuous improvement.

While the basal cost was not the sole reason behind the decision to internalize development, it played a crucial role in the initial diagnosis of the project. Ignoring basal costs when evaluating the sustainability of a system can lead to overlooked risks, but in this case, it was clear evidence that the current strategy was unsustainable in the long term. As we will explore in subsequent articles, any attempt to maintain the existing structure would have led to exponential increases in the basal cost over time.

For a more detailed explanation of the basal cost concept and its implications, I recommend consulting Eduardo Ferro's original article.

The Turning Point: A New Challenge and Strategic Decision

In any refactoring project, multiple strategies can be adopted, and it is common to face the dichotomy of: the strangler fig strategy or starting anew with a "big bang rewrite."

Initially, the technical decision was to work within the same legacy project, applying the Strangler Fig strategy, an approach that involves developing a new module or system that progressively replaces parts of the old system. This strategy allowed us to make parallel changes, reducing risks and maintaining current functionality while building a more solid foundation for future features.

However, from a business perspective, this option was considered too risky for the current system, which was already operational and meeting its functions. The decision was made to avoid modifying the existing project and instead focus on developing an independent application that met the new requirements.

This change of direction led us to fork the existing codebase, a decision that, while technically feasible, came with certain challenges:

Codebase duplication: Two separate codebases now needed to be maintained.
Separate databases: Data structures had to be duplicated and adapted for each system.
Replicated infrastructure: Independent servers had to be deployed, ensuring adequate observability for each system.
Increased cognitive load for the team: All these duplication required additional effort to maintain consistency between the two systems, increasing the team's complexity and error risk.

This approach allowed us to move towards an independent solution, ensuring the existing system's stability while developing a project aligned with the new strategic objectives. However, it was crucial to analyze the pros and cons in detail to tackle this challenge with confidence and planning. Additionally, a business-level commitment was made to avoid expanding functionalities and maintain strict control over the project backlog until the migration to the new e-commerce system was complete.

Pros	Cons
Working in a non-productive environment, reducing production risks	Temporarily maintaining multiple projects
Freedom to implement new technologies and patterns from scratch	Temporary duplication of maintenance efforts
No concern for technical limitations or dependencies of the old system	Duplicating functionalities may slow development due to synchronization needs
Ability to focus exclusively on necessary functionalities	Risk to deadlines from managing two codebases
Opportunity to implement best practices from the beginning	Complexity in project management
Greater ease of incorporating testing from the start	Need to maintain compatibility with historical data
Flexibility to adapt to new business requirements	Higher initial cost in time and resources
Better alignment with the company's overall strategy	Possible temporary loss of non-essential functionalities

Conclusions and Next Steps

The decision to internalize and rewrite legacy software is never easy, especially when the software fulfills its function. The saying "if it ain't broke, don't fix it" will always be present. However, sometimes it is necessary to take one step back in order to take two steps forward.

The next steps in this process involve a gradual migration strategy that focuses on the following:

Prioritize features based on their business impact and technical cost.
Adopt automated testing and CI/CD practices to ensure the stability of new developments.
Improve team training and communication to ensure alignment between business and development.

The ultimate goal is to deliver a product that not only meets the company's operational needs but also ensures its future growth. As with any process of change, this will not happen overnight, but the team is committed to moving forward one step at a time.

Plantilla d'iniciatives pel desenvolupament de software

Dídac Rios — Mon, 30 Dec 2024 17:58:43 +0000

En els meus últims projectes amb responsabilitats compartides de Product Owner i Team Lead en la que tenia més control sobre el backlog del producte, vaig veure la necessitat de crear una plantilla per treballar les nostres iniciatives. Aquest sistema no només ens ajuda a prioritzar el treball enfront d'altres tasques, sinó que també garanteix que tots els implicats comparteixin un mateix context abans de començar. Aquesta metodologia reforça la transparència i l’alineament dins de l’equip i facilita l’avaluació de les decisions durant el desenvolupament.

Què és una iniciativa?

Podem debatre molt sobre organització i jerarquia de les tasques en un backlog, cada equip i empresa son completament diferents. Des del meu punt de vista, una iniciativa és una agrupació de desenvolupaments necessaris per solucionar un problema o implementar una funcionalitat o requeriment. Cada iniciativa pot dividir-se en:

Èpiques: Conceptes generals que funcionen com a etiquetes.
Històries d’usuari: Unitats més concretes de treball.
Tasques: Accions específíques derivades de les històries.

Com es treballa una iniciativa?

Idealment, l'equip es centra en una única iniciativa a treballar, la que té la prioritat més alta i està lo suficientment refinada per poder començar el seu desenvolupament. I que vol dir suficientment refinada us preguntareu? Aquí és on entra la plantilla, la plantilla ens donarà uns mínims, però al igual que una història d'usuari, no ens donarà la solució, sinó que serà el tret de sortida per trobar la millor solució.

Com és la plantilla?

La plantilla conté diferents apartats que permeten capturar tota la informació necessària. Vegem els més importants:

💡 Títol de la iniciativa

Un títol breu i descriptiu que resumeixi el propòsit de la iniciativa.

Taula resum

Inclou informació clau com:

Summary
🧑‍🏫 Product	Name of the product owner/ project manager in charge of the initiative
👩‍💼 Stakeholders	Name of the stakeholders involved
👥 Teams Involved	Name of the teams

Criteris de priorització

Aquí es pot afegir el criteri de priorització que cada equip consideri, en el nostre cas hem passat per varis criteris, des del RICE a una versió simplificada de la matriu Value/Urgency per quantificar el màxim possible el cost del endarreriment. Us deixo un article del Marc Rodríguez (former Digital Project Manager @ Freshly Cosmetics) on explica com treballavem a nivell de productes per priotitzar objectius.

Priorization criteria
🎯 RICE Score	Points
💎 Value	Meh / Bonus / Killer
⏰ Urgency	ASAP / Soon / Whenever

📚 Context

L'equip o persona de producte s'ha d'encarregar de donar el màxim de context possible de la iniciativa, deixant clar l'oportunitat que implica aquesta iniciativa, quin impacte ens aporta i el criteri pel qual sabrem que aquesta iniciativa l'hem complementat.

🧐 Problemes a resoldre

A omplir per l'equip o persona de producte que ha proposat la iniciativa. Una taula que connecta la iniciativa amb els objectius globals de l'empresa:

📐 Framing

Aquesta taula s'ha d'omplir per part de l'equip o persona de producte amb l'ajuda d'un referent tècnic de l'equip, aquí es tracta també d'identificar a quins punts claus dels objectius globals de l'empresa impacta. Pot ser una ⭐ North Star o pot ser un OKR, etc, el que s'intenta aquí es identificar si anem alineats o no.


⭐ North Star	filled by PM/PO
🚀 Direct Impact	filled by PM/PO
🌱 Indirect Impact	filled by PM/PO
💻 Development effort	Low, Middle, High (filled by team lead or team)
📈 KPIs	filled by PM/PO

Fins aquest punt de la plantilla, tot el que s'ha demanat no requereix cap tipus de desenvolupament, però es molt rellevant per entendre el que es vol fer i dona la informació suficient per poder-la prioritzar o descartar-la. Si la passem a prioritzar i volem començar-ne el desenvolupament, el que farem, ja per part de l'equip de desenvolupament, es omplir un últim apartat que anirà seguit d'una kick-off per presentar el document i anar tots alineats.

🔭 Descoberta

En aquest apartat s'hauran d'omplir els següents punts:

🛠️ Solució

En aquest punt es tracta d'exposar una proposta de solució, tot i que és a nivell teòric també pot anar acompanyat d'una prova de concepte (POC)

🐉 Riscs

Llistats d'impdiments i riscs que poden afectar el desenvolupament o al producte pel fet d'optar per aquesta solució

🔖 Enllaços i altres documents

Llistat d'altra informació rellevant o enllaços d'interes que poden ser útils. (Diagrames, issue tracker, project managment tool ...)

A continuació us deixò la plantilla complerta en format Markdown

# 💡 Initiative Title

| **Summary** |  |
| ----------- | --- |
| **🧑‍🏫 Product** |  Name of the product owner/ project manager in charge of the initiative |
| **👩‍💼 Stakeholders** | Name of the stake holders involved  |
| **👥 Teams Involved** | Name of the teams |

| **Priorization criteria** |     |
| ----------------- | --- |
| **🎯 RICE Score** | Points |
| **💎 Value** | Meh \| Bonus \| Killer |
| **⏰ Urgency** | ASAP \| Soon \| Whenever |

## 📚 Context

The context should be filled by the PM, PO or the person who is proposing the initiative. It should contain the following information:

- **Opportunity**: What is the opportunity that we are trying to take advantage of?
- **Impact**: What is the impact that we are trying to achieve?
- **Success Criteria**: What are the criteria that we will use to measure the success of the initiative?

## 🧐 Problems to solve

The problems to solve should be filled by the PM, PO or the person who is proposing the initiative.

### 📐 Framing

|  | |
| ----------- | --- |
| **⭐ North Star** | filled by PM/PO  |
| **🚀 Direct Impact** | filled by PM/PO  |
| **🌱 Indirect Impact** | filled by PM/PO  |
| **💻 Development effort** | Low, Middle, High (filled by team lead or team) |
| **📈 KPIs** | filled by PM/PO  |

## 🔭 Discovery

### 🛠️ Solution

To be filled by the whole team or the team lead during the Kickoff

### 🐉 Risks

To be filled by the whole team or team lead during the Kickoff

### 🔖 Important links and documents

- [project managment](#)
- [drive folder](#)

Enllaços relacionats

La metodología de desarrollo de Producto que utiliza Freshly Cosmetics para crecer a toda velocidad

Lean Software Development: Muda (I)

Dídac Rios — Wed, 25 Oct 2023 21:29:47 +0000

Aquest estiu he revisat el llibre Lean Software Development: An Agile Toolkit de Mary & Tom Poppendieck i aprofitaré per fer una serie d'articles resum dels punts que crec més interessants del llibre.

En aquesta primera entrega parlarem del malbaratament (desperdici, waste, muda).

El malbaratament (waste, muda) és tot allò que al client no li aporta un valor directe. Les pràctiques àgils en el desenvolupament de software busquen eliminar aquest malbaratament, i el primer pas per fer-ho és saber-lo identificar.

Una de les pràctiques lean ens diu que per a identificar el malbaratament cal classificar-lo, així que influenciats pels 7 malbarataments del lean manufacturing es proposa classificar el malbaratament en el desenvolupament de programari en 8 categories.

Feina feta parcialment (Partially Done Work)

Fa referencia a desenvolupaments que es queden a mitges i no s'arriben a desplegar en un entorn de producció, aquest tipus de desenvolupaments tendeixen a quedar-se obsolets en poc temps, interferint en el desenvolupament d'altres tasques que s'han de realitzar. El principal problema es que el que s'ha fet no s'arriba desplegar, per tant no hi ha working software, el que ens impossibilita obtenir feedback i saber si realment funciona, si causa algun efecte no previst en el sistema o si realment estem solucionant el problema que voliem solventar.

S'ha de tenir en compte que en aquests desenvolupaments s'ha fet també una inversió en recursos (planificació, priorització, definició, disseny, codificació…), que encara no ha generat resultats, això implica que es "cancela una gran inversió", convertint-se en un risc si ho extrapolem a nivell financer.

Així doncs, el fet de reduir la feina feta parcialment redueix riscos i es converteix al mateix temps en una estrategia per a la reducció del malbaratament.

Processos extra (Extra Processes)

T'has preguntat mai si la burocràcia i la paperassa són necessaris? La burocràcia consumeix recursos, és lenta, es perd, queda obsoleta, i molts cops ningú li fa cas.

En el desenvolupament de programari, també hi ha burocràcia. Molts processos de desenvolupament requereixen d'omplir formularis de sol·licitud, requeriments, tests, actualitzar seguiments, reportar hores, documentar, etc.

Planteja’t si realment, al client, tots aquest processos importen i l'ajuden a tenir un producte més valuós, i en el cas de que ho sigui, recorda aplicar aquestes 3 regles: Que sigui la minima possible (Keep it short). que sigui a alt nivell, clara i consisa. (Keep it high level) i que estigui fora del procés de desenvolupament. (Do it off line).

En la majoria de desenvolupaments, hi ha requeriments escrits. En aquests casos, el fet que aquests requeriments siguin fàcilment accessibles i evaluats per a la seva comprovació es pot considerar una activitat que aporta valor. Estem parlant de taules i/o plantilles que fan que tant els clients com els desenvolupadors puguin ràpidament entendre i validar. L'utilització de pràctiques com BDD (Behaviour Driven Design), ATDD (Acceptance Test-Driven Development), Specification by Example, reduirien el malbaratament en tant que es consideren pràctiques que aporten valor.

Una altra forma d'identificar si la burocràcia aporta valor o no és el fet d'identificar si hi ha algú que l'estigui esperant. Hi ha algú que escriu escenaris per a que es puguin interpretar i programar? Doncs probablement aquesta burocràcia aporta valor. Tot i això s'ha de treballar en millorar l'eficiencia en aquest sentit i buscar la millor manera de transmetre la informació, per exemple, no escriure requeriments i utilitzar pràctiques com les citades anteriorment o bé que els detalls d’implementació no fer-los massa aviat i limitar-se a aprofundir-hi en la iteració en la que s'haurien d'implementar.

Funcionalitats extra (Extra Features)

Pot semblar molt bona idea afegir funcionalitats extra, per si de cas es necessiten. Als programadors ens encanta afegir complexitat tècnica i funcionalitats extra. Això que ens pot semblar inofensiu, és un dels més grans malbarataments. Cada línia de codi s'ha de compilar, integrar, testejar, desplegar i després, s'ha de mantenir. Cada línia de codi incrementa la complexitat i es un punt de fallida (failure point). Fins i tot hi ha la possibilitat que aquella part de codi quedi obsoleta abans de que s'utilitzi, ja que en realitat mai s'ha arribat a demanar. Quan el codi no es necessita ara, és malbaratament. Que no et tempti la serp.

Canvi de tasques (Task Switching)

Gent treballant en multiples projectes és despedici de per se. Cada cop que un programador canvia de tasca, hi ha un lapse de temps significatiu en el que es despren de les referencies de l'antiga tasca i comença a entrar en la dinàmica de la nova (DeMarco & Lister, 2003). Si algú forma part de varis equips i projectes, les interrupcions i canvis de tasques es fan exponencials, tot això és malbaratament.

Així doncs la millor forma de completar 2 projectes que utilitzen els mateixos recursos, és fer-los un després de l'altre. Goldratt (1997) planteja que quan tens 2 projectes d'aproximadament 2 setmanes de duració cadascún, esperes tenir-los enllestits en 4 setmanes. Si els realitzes al mateix temps, al afegir els canvis de context el resultat final és que el tens més aviat en 5 setmanes enlloc de les 4.

El fet d'afegir un excés de feina en el desenvolupament crea malbaratament, fent que les coses vagin més lentes. Tot va més fluid per una canonada que no està plena (Poppendieck & Poppendieck, 2003).

Esperant (Waiting)

Un dels màxims malbarataments en el desenvolupament de programari es esperar a que les coses passin. Endarrerir l'inici d'un projecte, la conformació de l'equip, la confecció de requeriments, les revisions de codi, les proves, desplegar funcionalitats, tot això és malbaratament.

Els endarreriments son comuns i poden arribar a forma part de la normalitat i no veure'ls com a malbaratament. Quin és el problema d'esperar? Les esperes fan que el client no rebi valor aviat. Quan el client vol implementar una necessitat o solucionar un problema la velocitat en la que obtindrà la solució anirà estrictament lligada a la velocitat en la que va el nostre proces de desenvolupament.

En certs entorns, potser aquest no és un dels principals problemes. Però si que ho és si desenvolupes programari per a un domini en constant canvi, en el que s’han de prendre moltes decisions, i aquestes no són àgils. Un dels principis fonamentals de lean és pospondre les decisions fins a l'ultim moment responsable (the Last Responsible Moment), de tal manera que puguis decidir més endavant, quan tingui més context. Aquesta és una de les millors formes de manejar la incertesa. Posposar una decisió també és una decisió.

Es podria pensar que això i procrastinar ve a ser el mateix, però en realitat es una estrategia per evitar riscos. Una mala decisió feta molt al inici d'un projecte el pot comprometre per complet, ja sigui fent que el desenvolupament vagi molt més lent o lligar-se a infrastructures innecesaries, així que les decisions que s'han d'anar prenent han de ser decisions que no et collin massa, i siguin el maxim d'adaptables posibles.

Moviment (Motion)

Quan un programador té dubtes, que és el que ha de fer fins aconseguir una resposta? Hi ha gent disponible per solucionar problemes tècnics? I els funcionals? El client o el seu representant (PO, PM) està disponible per contestar-li? Pot el programador interpretar correctament la feina a fer de forma senzilla sense haver d'anar a trobar algun company?

El text original es refereix més aviat a desplaçaments físics com a malbaratament, ara amb el teletreball i la feina asíncrona això podriem pensar que queda obsolet, però si fem l'adaptació al teletreball, podem canviar el temps del desplaçament físic per la dificultat d'obtenir una resposta adient.

El desenvolupament de programari requereix d'una gran concentració, cada cop que se'ls hi plantegi alguna de les situacions anteriors perdran el focus. Tenir l'equip disponible i treballant conjuntament farà que aquestes situacions acabin esdevenint en grans problemes, evitant així el malbaratament.

La gent no es la única que es mou, els requeriments, la documentació, el codi, també està en constant moviment durant el cicle de desenvolupament. Traslladar tota aquesta informació és també un malbaratament, tots aquests artefactes no poden contenir la totalitat de la informació, sempre hi ha informació que es retindrà en els seus creadors com a individual o grup. Es per això que també, traslladar aquests recursos entre diferents grups també és malbaratament.

Defectes (Defects)

El principal malbaratament causat pels defectes és l'impacte del defecte sobre el producte i el temps en que passa desapercebut. Un greu defecte que es localitza al cap de 3 minuts no és un gran malbaratament. Però un petit problema que fa setmanes que ningú se n'ha adonat, és un malbaratament molt més gran.

Així doncs, per tal de reduir l'impacte dels defectes el millor és identificar-los el més aviat possible i per fer-ho cal testar, integrar, i desplegar el més aviat possible.

Activitats de la gestió (Management Activities)

Les activitats de gestió no afegixen valor directament a un producte, però tenen un gran impacte en el malbaratament en una organització. Considera per exemple el sistema de gestió de tàsques i projectes. En aquest cas minimitzar el malbaratament implica mantenir al minim la feina feta a mitges, i això prové normalment de com es gestionen els projectes i les seves tasques. Si aquest sistema no va fluït probalement esdevingui en un gran generador de malbaratament i malbaratament de recursos.

Els sistemes de control i seguiment tampoc aporten valor, i si existeixen acostumen a indicar que hi ha massa feina a fer. En lean manufacturing quan es parla d'un sistema just-in-time, es parla d'un sistema en que la feina es realitza de forma eficient i flueix de tal forma que no es necessàri el seu control amb sistemes complicats d'analisis i seguiment.

Sistemes d'autorització per a la revisió i aprovació de canvis de requisits acostumen a aportar endarreriments enlloc de valor. Aquests sistemes també esdevenent simptoma d'un malbaratament més gran lligat a una definició previa i prematura de llargs requeriments.

Aprendre a identificar el malbaratament és un procés constant de canviar la manera que tenim de pensar sobre el que realment és i no és necessàri.

Bibliografia

DeMarco, T., & Lister, T. (2013). Peopleware: productive projects and teams. Addison-Wesley.
Goldratt, E. M. (1997). Critical chain: A business novel. Routledge.
Poppendieck, M., & Poppendieck, T. (2003). Lean software development: an agile toolkit. Addison-Wesley.