Agile Production in a Nutshell

Chapter two of the book is a small preview of the whole book, where the authors talk a bit about:

  • engaging the stakeholders
  • defining the problem
  • what the system is
  • what the system does
  • the code

Stakeholders

The stakeholders are all the people and systems that care that this system even exists, what it does, or how it does it (pg. 28).  This means anyone from developers to end-users, including business people, customers, designers, salesman, marketing, etc.

Nevertheless, not all stakeholders are relevant all the time in every context. To better know what the relevant stakeholders are in each context, and therefore in each meeting, we separate the system in two contexts and the relevant stakeholders:

  • What the system IS:
    The platform, the architecture, the product. In this context, the most relevant stakeholders are domain experts, system architects, and business people.
  • What the system DOES:
    The functionality provided to the end-user. In this context, the main stakeholders are the end-users, the UI designers and the UX designers.

From all these stakeholders, however, the most important one is the end-user. The end-user mental model of the system is what is needed and therefore is what we should strive to reflect in the application.

Defining the problem

Before anything else, we need to define what it is that we need to create. Only after that, we can come up with a plan.

So the idea is that we get all the stakeholders together and convey a short description of the problem definition that everyone can agree upon. Defining the current state and the desired state is a great way to do this.

For some reasons, along the way, we might end up deviating from the plan, or the problem might change. Therefore we must revisit the problem definition often, to make sure that we are still on the right track and still solving a current problem.

What the system IS

The design of a system form is what a system is. The form is the most important factor for long-term system health. It must provide a firm foundation for the end-user functionality and also for the changes that will be needed in the future but can not be anticipated.

It’s interesting to note that the authors distinguish “form” from “structure” in a different way that I would. For the authors, “form” can be compared to a skeleton while the structure would be the meat that provides for the functionality. So they define “structure” as the actual code of an application.

Architecture focuses mostly in creating the form of a system:

  • Capture the stakeholders’ perspectives that affect design;
  • Embrace and prepare for change, to reduce the cost of solving problems;
  • Create a shared vision across the team and stakeholders;
  • Create mechanisms to smooth and fasten the decision-making process.

The architecture deliverables are:

  • Class interfaces as source code contracts;
  • Boilerplate code;
  • Ubiquitous language;
  • Minimal necessary documentation;
  • Rule set of procedures, like coding standards.

With the architecture in place, we have a solid ground where to stand and respond to change.

Good form up front reduces cost in the long term.

Pg. 32

What the system does

The system should do what the end-user needs it to do. We need to capture the end-user mental model of the system, what he needs the system to do, how he envisions the system, how he dreams the system.

The way to capture this mental model is through the specification of use cases. Use cases define the various actions the end-user can do with the system, and are a valuable tool to elicit, explore, refine and capture the end-user vision of the system, but also to organise requirements, dependencies and priorities.

In this context, the deliverables can be:

  • Screen designs;
  • Domain specifications;
  • Use case definitions.

Designing and coding

This is when we do the development of the product. At this point we:

  • Extract actors and algorithms from the given use cases;
  • Write system tests;
  • Adjust the initial class interfaces;
  • Translate the use cases into code;
  • Run the tests against the written code.
This post is part of a set of posts with my personal notes about all the chapters in the book “Lean Architecture for Agile software development” by James Coplien and Gertrud Bjornvig. I will do this as I read through the book, and take notes on the concepts I personally find more relevant.
Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s