Measuring Software Architecture

I found interesting approach on the subject being developed by Structure 101 team. They introduced Excessive Structural Complexity, XS in short.

They pointed that an architecture may be seen in two dimensions: Tangle which is structural complexity on design level and Fat which is "too much code in one place". More precisely:

Tangle

it's set of items being in a cyclic dependency; tangle is counted on packages level; for each set of tangled items a Minimum Feedback Set (MFS) is calculated which is a minimum set of dependencies that would need to be removed in order make the graph clean

Fat

for methods it's Cyclomatic Complexity, but for clases and packages it's a number of dependencies between them

XS is an excessive ie. unnecessary complexity, so some thresholds must be given. Indeed, you are able to define thresholds for Tangle, and also for Fat on each method, class, leaf package, package (design) levels. You may also trust the defaults. Those come from Structure 101 team experience.

After normalization, XS gives one single number expressing an excessive complexity of a piece of code. Depends on code level, a XS might be Fat mean, Tangle mean or sum of these two.

It is very interesting because it gives fancy measure for each architectural level. It works well on: methods, classes, packages, layers and more abstract components levels.

Intersecting XS and number of commits to a repo, we might more accurately say what is worth to be refactored and what is not. (Idea of this intersection comes from Michael Feathers, but, as far I remember he use the Cyclomatic Complexity instead of XS)

For more information read the whitepaper or try out the tool.

Frame-of-our-work

Working with a software and repeatable tasks, teams walk form a hard-coded solution to a generic framework and back with confusion. Let's search for the third way.

Table below presents some attributes of those two types of approaches:

	adding a new code	maintaining a design	redesigning	as time goes by...
comment	How much time is needed to add new functionality which respects a framework architectural boundaries?	Any piece of code must be maintained from now to the end	Sometimes new functionality is out of a framework architectural boundaries. So that one need to be redesigned and refactored	What will be happening with the code in the future?
hard-coded solution	offhand	n/a there's no a design	n/a there's no a design	maintaining becomes really hard
generic framework	easy if one knows how a framework works	needs some effort	might be hard and expensive	two scenarios might happen: a framework becomes more and more generic till someone decides to kill the project or a framework becomes more and more coupled with business-specific code and then it goes toward a hard-coded solution

Frame-of-our-work

If both of extremes are wrong what is the third possible way? This is: don't build THE FRAMEWORK. Build THE FRAME-OF-OUR-WORK instead. Please, pronounce these two words: framework and frame-of-our-work. I am serious. So now:

• What a responsibility do you you put on framework and frame-of-our-work?
• What is possible to do with framework and frame-of-our-work?
• What is impossible to do with framework and frame-of-our-work?
• What would you give up changing a focus from framework to the frame-of-our-work or opposite?

You know, naming is important. When you label a project you give a team the direction of work and it determines what kind of work will be done or undone. Focusing a team on building a framework you are at lots of cognitive biases. A framework word is so imprecise that you may do more work than you intended to. Besides we do really like to build frameworks - check Source Forge or Google Code :).

Frame-of-our-work focus you on what are we really doing now? You need to inspect tasks a team do, before you start building a frame-of-our-work. This is nothing but Single Responsibility Principle.

I put a characteristic a frame-of-our-work into the table:

	adding a new code	maintaining a design	redesigning	as time goes by...
comment	How much time is needed to add new functionality which respects a framework architectural boundaries?	Any piece of code must be maintained from now to the end	Sometimes new functionality is out of a framework architectural boundaries. So that one need to be redesigned and refactored	What will be happening with the code in the future?
hard-coded solution	offhand	n/a there's no a design	n/a there's no a design	maintaining becomes really hard
frame-of-our-work	fast	easy	needs some work but it's acceptable	it's sensitive on rapid changes of business processes because it's highly coupled with them
generic framework	easy if one knows how a framework works	needs some effort	might be hard and expensive	two scenarios might happen: a framework becomes more and more generic till someone decides to kill the project or a framework becomes more and more coupled with business-specific code and then it goes toward a hard-coded solution

Although a frame-of-our-work is not so sexy as a framework does, my observation is the cost of redesigning a frame-of-our-work is mostly lower than the cost of maintaining a generic design of a framework.

A simple example

You build desktop application and you search for a good way to implement the GUI logic. It's not trivial in Java:) Focusing on framework you might decide to implement a generic Presentation Model with fancy widgets binding. This is very flexible solution, but...what kind of flexibility do you really need in your project?

On the other side, building a frame-of-our-work you might decide to prepare very simple Presentation Model where you have one stupid POJO per one user screen.

Both are well known approaches, but the difference is how much work will be done.

At last...

What if you really discovered a generic domain and a generic framework would be very useful? What then? Fork the project, find a sponsor in your organization and build the framework. But never ever build a generic frameworks as a part of your regular workflow.

The Developer and a developer

As an employer I have a privilege to decide who I work with. I hire people and also have fired some of them. I've noticed there is kind of employee who does right anything one has touched. And opposite: some people screw up even simple stupid tasks.

I cannot say what exactly is the difference, mostly I feel one is the right one. But I have some observations:

The Developer	a developer
is focused on the task	is focused on options of the solution or on 'the best solution'
is patient	wants to have things NOW
when failed feels a frustration or a sadness	when failed feels a guiltiness
assumes oneself of being a cause of one's mistakes	assumes others of being a causes of one's mistakes
argue with people	blame people
has own daily routine	does things impulsively
wants to know what was done right or wrong	afraids to know what was done right or wrong, so avoids it
takes things happened as a result of work and constant feedback	takes things personally
takes the responsibility for a relationship between involved stakeholders	takes the responsibility for tasks one was told to accomplish

Taking a responsibility

I always hear from team leaders: I want a developer to take a responsibility for assigned things. I was unable to understand what was 'a responsibility'. Now I think I should ask them: What are those 'things' you want a developer to take responsibility for?

Personally I am sure team leaders didn't mean responsibility for a task. A task is nothing. Having a task completed is not always directly related to increasing a business value. It may be, but this is not the rule.

Having said responsibility team leaders had in minds responsibility for a relationship. That's right. The core of being responsible for something is responsibility for a relationship between all involved stakeholders. Doing tasks is part of it. But meeting stakeholder needs and increasing business value always comes with taking care of relationship.

About payment

I won't write anything new. But spending our own money I convinced myself that cheap is expensive if about employee's salary. We used to hire employees only by reason of their financial expectations. Mostly they were unskilled. We invested our time teaching them. When they picked up some knowledge they left the organization. So we decided to hire the best people we can afford according to our business goals.

What Exactly Are Patterns?

I found very interesting paper: Developing GUI Applications: Architectural patterns Revisited by Alexandros Karagkasidis

Implementing presentation layer is a really tricky. It is at least so complex as implementing a domain layer and not at all less important. There are lots of approaches to the subject, from the most comprehensive MVC, MVP, PAC and HMVC to the most detailed being described by Martin Fowler or vendor-specific approaches i.e. MVVM (which might be described in a Flowler's language as well).

According to Alexandros all these share same problem: work well for simple cases. My own understanding is the core is how a GUI functionality should be exactly mapped to structural elements of a pattern.

Let's take MVC pattern. One may use this pattern on widget, container or window/frame level. Decision is left to a developer. Besides, from my experience an approach is highly coupled with a functionality flow and refactoring is really hard. Let's say you decided to implement MVC on container level and then a CR requires some small interaction between a frame caption, button, and tab color. You may hardcode it or extract a smaller MVC triad. With this, a refactoring is quite time-consuming.

My point is: non-GoF patterns define a general idea but it is not enough to implement them in a complex case. My observation is teams sometimes needs lots of iterations to find their own way to implement an architectural pattern. It may takes months or even years.

Mentioned article doesn't contain any solution, but it is worth to be read to give you an insight into a complexity of GUI development.

Conversation Patterns: Upward Generalization Pattern

This article is part of my work on Conversation Patterns for Software Professionals

---

Finally I've done Upward Generalization Pattern. I am really glad because the one and also Downward Specification Pattern are the 80 from the Pareto Principle.

Mastering both of them is essential for a developer to looking for the business needs and then system features effectively.

Sold out!

I had the agreement with my wife: we will buy new bookcase, when we will change the flat. Because changing a flat takes some time, so that the old one is still with us. But I found it overpacked.

I was standing looking on that 300+ books I had being collected for seventeen years and realized that a few of them really influenced my life. I realized I have read lots of books (there were times I was reading ten hours a day) and I know a lot of things, but it's a few things I have truly mastered.

For example, it has taken almost three years since I read Getting Things Done to implement it in my daily routine. It has taken thirteen months to implement some personal finances habits. Learning takes time, it takes plenty of time. God, I wish I could fully express what the difference between knowledge and skills means to me!

I packed all that books into bags and went to sell them. They picked out bestsellers and gave me 500PLN, its about 120EUR. 500PLN for seventeen years of collecting the books.

I feel strange now. I am terrified from one side and freed from the other one. Having books sold I only wish I met more friends instead of reading all that stuff.

What next?

---

Update: and I think I felt a shadow of the News is bad for you

There Is No The One Way in Software Architecture

At last they publish the presentation I did at Confitura Conference. It's in Polish, sorry.

This presentation contains my thoughts on software architecture. I'm talking about:

• importance of a technical context
• importance of a business context
• core domains which may belongs to the both technical and business areas
  
• few points being my own-made steps to verify vision of new architecture

I wish they published my 33rd Degree presentation, where I was talking about looking the Holly Grail and all that *Driven madness.

Conversation Patterns: What is "a need"?

This article is part of my work on Conversation Patterns for Software Professionals

---

We work with stakeholders needs hidden by wanted features, we try to fulfill our needs hidden by wanted refactorings :) I've already posted two entries in the subject. These are: A User Story Template Revisited and Don't Confuse a Need with a Feature.

But what is actually "a need"? I clarified this term in the Need Structure article on the Conversation Patterns for Software Professionals.

Conversation Patterns: Questions for Setting Priorities

This article is part of my work on Conversation Patterns for Software Professionals

---

Before we we'll talk about questions for setting priorities, we need to take a look at this issue from a stakeholder point of view. So, you are Stakeholder and I am Developer. Context is you want me to to deliver hot dogs to your team :) Here is our conversation:

You: Listen, we are waiting for hotdogs for four hours and we are starving. So, hurry up, pleeeease... Me: Ok, ok! We are doing our best. When do you want them delivered? You: When!? Four hours ago! Me: I have a solution for you. Let's talk about your priorities. What is the most important for you: bun, sausage, or ketchup? You: What? They are all equally important! Me: It's impossible. Choosing priorities allows you to have your wants at least partially done. It is for your own good to prioritize your requirements. Besides, there is no two things in the world being equally important. So, again: bun, sausage, or ketchup? You: But they ARE ALL important for us !^%@!#&!

Maybe the dialogue above sounds funny and you discovered a solution during a first reading. But it presents the structure of a typical conversation between a stakeholder and a developer.

The main issue is two points view. For most stakeholders their requirements are atomic. No matter how large they are: one LOC change or four-week long teamwork. For a stakeholder requirement is mostly atomic by design.

What Is The Need?

To set priorities the stakeholder need must be recognized first and this may be one of: an expected benefit or a problem to be solved.

To be clear, a human being is a really complicated object and the only things we have are models of its behaviour. All models are simplifications, but the may by useful or not. My model assumes that every requirement (functional, architectural or so on) of a stakeholder is driven by a need (an expected benefit or a problem to be solved or both). This model is extremely useful, so that I recommend it.

Questions for Discovering the Need (in the Priorities Context)

A stakeholder is mostly focused on the thing he wants, so it is good for your conversation to help him/her to name the need.

We'll use the Drilling Question Pattern. We'll ask a question with a presupposition there is a need back to the requirement. Because there are two types of a need (an expected benefit or a problem to be solved) you may ask two questions. One for presupposing an expected benefit and next one for presupposing a problem to be solved.

A structures for these questions are:

• If you would to start [a benefit presupposed] now, what it would be?
• If [a problem presupposed], which one you would give up first?

As you can see, assuming a benefit we asking for "achieving", but assuming a problem we asking for "avoiding". Some explanation of it you may find in article Don't Confuse a Need with a Feature.

You probably wondering: "Ok, but what kind of an expected benefit or a problem to be solved I should presuppose in my case"? Obviously it depends :) I'll give you a tip how to start.

There are two typical needs when you're asking for setting priorities in the business context:

• One wants to use a system feature - that is an expected benefit
• One is under pressure of time or money - that is a problem to be solved

So, now our questions for setting priorities might be:

• I you would to start using a feature now, what would you choose in the first place?
• Assuming you're lacking of money or time, which one of these features you would give up first?

I have mixed tenses intentionally, because benefits refers to the "future", but a pressure is being felt "now". So, if you are a native speaker, let me know how it sounds for you.

Let's Back to The Hot Dogs

You: Listen, we are waiting for hot dogs for four hours and we are starving. So, hurry up, pleeeease... Me: We are doing our best. I want to ask you something. If it takes next two hours to deliver all hot dogs, would you mind to give up bun, sausage or ketchup? You: !^%@!#&! We are taking buns, but NOW!

:) The dialogue above might happen, but it's trivial, huh? Let's take a look on the more realistic one:

1| You: Listen, we are waiting for hot dogs for four hours and we are starving. So, hurry up, pleeeease... 2| Me: We are doing our best. I want to ask you something. If it takes next two hours to deliver all hot dogs, would you mind to give up bun, sausage or ketchup? 3| You: Are you crazy! We want hot dogs! 4| Me: I see you are starving and I know we're late. I need more details to deliver hot dogs faster. May I ask you something? 5| You: Hit me. 6| Me: What it will happen when we don't deliver hot dogs on time? 7| You: I am afraid my boss will kill me. 8| Me: Listen, I'll give you two hot dogs off-hand for you boss. Would you mind to convince your team to wait? We will try to deliver hot dogs in two or three hours. 9| You: Hmmm...sounds interesting...

Again I tried to find a need (I assumed it is a problem to be solved = a hunger). This was line [2]. But my presupposition didn't meet your real need. So, I tried one more time in the line [6]. Your boss was your problem, not a hunger :). Starting from the 'boss problem' we build an acceptable solution.

That's all for now. Watch the blog for more Conversation Patterns.

Photo Credits: Bun, sausage, ketchup :)

Conversation Patterns: Don't Confuse a Need with a Feature

This article is part of my work on Conversation Patterns for Software Professionals

---

I have used an Inverted User Story presented in User Story Template Revisited during some workshops with teams and I want to add a tip.

How to recognize you discovered the right benefit or problem to be solved. Well, you can't. You should stay aware of a conversation flow and test a timeliness of stakeholder needs. So the core need driving a user story doesn't escape your notice. Try to implement the Heart beat design pattern in your mind :)

But you should distinguish between "need" and "feature". A Stakeholder often confuse these two. For example:

As a Logged user I want to generate salary report so that I will know who is a VIP

Without a wider context it's difficult to validate the story. But, "I will know who is a VIP" is probably a feature, not a need. It's because it points a system feature, but not a stakeholder benefit or problem to be solved.

I want to score under this is my supposition and I would fire up my Heart beat pattern asking a stakeholder about a need details.

In general you may use following heuristics to recognise stakeholder need:

• Benefits you discover, mostly fits to the template: I want to achieve...[benefit]
• Problems to be solved you discover, mostly fits to the templates: I want to avoid....[problem to be solved]

The 'e' Letter Problem

I was inspired by Crista Lopes and her presentation to write this post. However, I found an analogy between her thoughts and my job, I recommend watching this presentation.

So, would you try to write a book or at least blog post without using words with the 'e' letter in the middle of a word? (In Polish it would be probably the 'a' letter). What implications it would cause? Would it be a challenge to express yourself giving the 'e' letter a miss?

Well, I think some of expectations about software development methodologies or techniques are similar to the 'e' letter restriction I mentioned:

• How to estimate this requirement? But I only have three-words explanation and that's all?
• How to start writing a code? But requirements will be precised soon ('soon' becomes 'now' when we will decide it is 'now')
• How to refactor 10-years old code during a weekend?
• How to deliver a software in 50% of time estimated with 50% of developers needed?
• How to start *DD with a team not experienced enough?
• How to accomplish more projects than our current capacity?
• How to motivate people with a pay cutting at the same time?
• How to boost our effectiveness without changing anything?
• etc.

There is no magic in the world. All methodologies and techniques have its own preconditions. These must be guaranteed before start. But we do repeat the same mistake over and over again. We want to write a book without the 'e' letter.

Software delivery organisational anti-patterns

It's good to have some electrical engineering background before reading this post ;P

I am confused every time I am asked what is the best way to manage requirements or which one is better: use cases or user stories, or how to ensure software quality by testing or how to evolve architecture properly, or does the *DD works, which design patterns are most wanted, what is better: agile or RUP. These are tricky questions, especially asked a consultant as I am.

Let's me try to explain what is a tricky part in these questions.

From IT point of view, the only goal of IT-Business collaboration is software delivery and nothing more. I like this term "software delivery" because it simply explains what we are responsible for. To achieve this goal we developed many tools which makes our work more effective. These tools address some difficulties we faced with when we collaborate with business people.


It is very important to notice these tools (show on the figure above) are not either-or dilemmas. You take whatever works and fits to a project context. Please read carefully at least:

• Writing Effective Use Cases by Alistair Cockburn
• Introducing BDD by Dan North
• Decisions, decisions by Dan North
• Specification By Example by Gojko Adzic
• Domain Driven Design by Eric Evans
• The Object Primer or agilemodeling.com by Scott Ambler

and you will see the tools are not competitors. Use stories are not compete with use cases, TDD is not competes with test-last approach, Scrum is not competes with free-style processes, DDD is not competes with simple anemic model, testing is not competes with test-free approach (really).

There is no "better", there is no "the best". Every single tools covers some aspect of IT-Business collaboration on software delivery. And everyone causes some benefits and consequences. But, you are responsible to choose a tool according to the project context. So yes, you should familiarize yourself with all of them.

The Source of All Evil

Problems start when one want to build a business around software delivery.

To scale the business one have to scale software delivery process to be more efficient.
So, one takes some of the tools and tries to compose The Process, for example: Analysis -> Architecting -> Implementing -> Testing -> Maintaining. So, tools becomes The Process steps and one builds teams around this steps.

You may say: ok it's old-school waterfall process. But, even organisations declaring agile approach have at least Analysis and Testing Departments. The rule is: the larger organisation is the more presented solution is applied. Where is a trick?

Software delivery is atomic. The only responsibility is to deliver software that is satisfying business needs and that's all. But scaling a software delivery we split this atomic thing into steps in a sequence.

We assume we may also split the Responsibility into small responsibilities of every single step. Moreover, we assume that Responsibility of whole software delivery is the superposition of the small responsibilities. In general it is not true.

You know, organisations where software is developed by programmers and tested by testers I may observe a lot of problems with a code quality and tension between Software Development Software Quality Departaments. Why? Because software developers are focused on their own responsibility and testers are focused on their own one.

Software Developers assume that testers will find all bugs and they are less motivated to test their own code. As a result tester have more and more work with bugs. And this a vicious circle.

One more example. Organisations where analysis is done by analysts (God, I'm trembling ever time I hear "Project Management Center") and development is done by developers, mostly have problems with requirements quality. It is happen that people don't know how to implement a requirement.

I think that problems listed above were caused by splitting what is unsplittable by the definition. Software delivery is unsplittable, it is atomic. We may use all tools to deliver better, faster or simpler. But we cannot split that tools into steps in a sequence. It doesn't work in that way. Once again: problems were not caused by the people or lack of competences. Problems were caused by the organisational anti-pattern.

Decoupled teams

Better idea is using tools around software delivery without splitting them.

Do you see the difference? Regardless of tools used the responsibility stays constant.
Ok, that was a metaphor but what about real world solution.

Solution is many stable Development Teams. A Team is responsible for delivering a complete working product. Moreover, there is no any dependencies between teams. A team is atomic.

Yes, I know there is more question than answers. How large a product should be? How to cooperate with other teams? How to build and develop a team? And so on, and so on.

The truth is we are in alpha-phase if about scaling agile teams on large projects and organisations. Some inspiration you may find in Disciplined Agile Delivery by Scott Ambler. Absolutely great case study is Scaling Agile @ Spotify. I believe the answer is out there and it will come soon.

Maturity is the Key

Do you know why: architecture, leadership, agility, effectiveness are so widely discussed? Because nobody know what they exactly are:) Or precisely: these are as complex as these mean different for different people and every point of view gives us some useful knowledge.

We coach development teams and looking in the past I may observe some interesting fenomenas. Let' see (important: I'm writing about Poland):

8 years ago

Nowadays

Some heard about XP A leader aka PM was non-technical quy Some heard about GoF Patterns There was no terms "clean code", "implementation patterns" well known Some have read "Code Complete" When we talked about programmer soft skills we were understood as weirdoes

Teams declare using Scrum or "our own adaptive agile framework" Most leaders do have a technical background "patterns" is one of most discussed word in many meanings Software Craftsmanship movement encourage to searching for better ways to do what we do and to improveme the craft Honestly, there is so many books about "patterns", "agile", "software craftsmanship", "good enough", "code readability" I cannot handle it Soft skills are widely discussed, but narrowly applied :)

So, we see the craft is changing. Software developers are changing. Nowadays, trainees or couchees are more experienced and educated then eight years ago. Some problems from the past are not problems anymore. But, we are faced with some new challenges.

What I want to say? According to Manfred Spitzer learing takes time (esspecially if we talk about social and soft skills). It is trivial, but not understood enough. We want to get skills and knowledge RIGHT NOW!. But it is impossible. Learning starts with acting based on simple procedures and lead up to contextual knowledge and contextual skills.

The crux is learning takes more time than average project length. Sometimes one expects to learn, let' say, "patterns" in four-days training. One also wants to apply its correctly in the project which is coming soon. But during a four-days training one will get a seed and an individual is responsible for its growth.

So, conclusions:

• Software Craftsmanship is a lifelong challenge
• See your learning goals from the five, ten or more years perspective...
• ...but be aware that every single line of code is a small step leading you to some learning goal? Do you like this goal?
• It is impossible to apply "patterns" or whatever always correctly
• Yes, you will smell the code from time to time.
• Make the failure faster :)

Conversation Patterns for Software Professionals

This article is part of my work on Conversation Patterns for Software Professionals

---

Real understanding of our stakeholders needs comes with a conversation. So we want to develop and share the best ways to do it.

Some readers of my book (in polish) and clients as well found its content very usefull. They encourage me to translate it into English. I have thought about it for a year, but couldn't decided.

So, I sent a proposal to couple international publishers and I am waiting for feedbacks. Regardless of their decisions I'm to gonna translate the book as Conversation Patterns for Software Professionals in the form of website conversation-patterns.com (guess what my inspiration was? :))

Having the book written I noticed that conversating with domain experts, users or clients is still difficult for a software professional. It is not a piece of cake to have a good conversations. So, the conversation-patterns.com and some of posts from this blog are intended to challenge it. I've already written two entries on the subject:

• A User Story Template Revisited - its abot how small change in a user story structure you use might cause quality difference
• A Buffer of Useless Answers - it about of application the Drilling Question Pattern. It will help you to obtain quality answers from your stakeholder.

I have also a vision of a community around Conversation Patterns. There is a lot technical stuff we know. But a real understanding of what have to be done comes with a conversations. So, my dream is finding ways to do it effectively.

That is early stuff so any feedback is welcomed.

A Thought on Design Patterns

We were told a design pattern is a solution of a problem in a given context.

The metaphor above focuses our thinking on a space of a given problem. But if we extended a view a little more, we would see there is one more thing: tools.

So, a design pattern is a solution of a problem in a given context with given tools usage. And tools are obviously programming languages we use. Observing programming languages evolution (as I remember a great piece of it was given here), we may arrive at the conclustion that design patterns try to solve lacks of programming languages.

From this point of view moving to a next programming language may cause a problem disappears.

So don't try to introduce patterns to solve the problem you faced with. Find a technology where the problem is gone. This is a way I understand the Polyglot Programming movement. I think it is the right direction.

Please, define your organisational values

Dear HR Director,

I decided to write this letter, because for over five years I have worked with software engineers on their effectiveness and seen how organisational values influence software developers work.

Probably you have defined a mission statement and values in your organisation. But did you ever noticed their correlation to a quality of the source code or development processes?

Developers too often take organisational values with a grain of salt. They tell me these are just only "posters" on the walls or on their screen savers. But for me - an outer observer - it definitely is obvious that a mission statement and organisational values do their job. And do it well.

So, what I have seen? Organisations where values statements looks like:

• We put our customers first
• Our success is customers satisfaction
• A customer can't wait
• We are professionals
• We do everything for our customers

and that is all, that organisations mostly (I said: m o s t l y) have a lot of multitasking and technical debt inside. That two lead to the even more multitasking and more smelling code as a consequences.

To be precise: all values above are good. I would be proud to identify myself with one of them. But, the problem is the values are not defined clearly enough. Engineers, managers and non-technical stuff simply do not know what to do. They try to satisfy organisational values so much, so they do just only one thing possible to be done: they guess what to do.

Of course, every individual guesses on its own account. In addition clients and deadlines bring the pressure to the teams. And here a multitasking and lack of decision making start working on software quality.

So please, define your organisational values. Define at least:

• What kind of behaviours are acceptable
• What kind of behaviours are not acceptable

I emphasised "behaviour" word on purpose. You have to be precise. People do not understand "be professional" but they clearly understand "do a code review". And last but not least - do what you said.


Yours sincerely,
Michal

Conversation Patterns: A User Story Template Revisited

This article is part of my work on Conversation Patterns for Software Professionals

---

This is well known user story template:

As a [role]
I want [feature]
so that [benefit]

But I noticed that because of this template teams focus mostly on features. What is wrong with that? However, discovering the right features is the goal of user stories, but at the same time a benefit part is neglected.

Consider following (anti)stories:

• As a User I want to login, so that I use a system
• As a User I want to print report, so that I can do my job
• As a User I want to click RMB, so that I choose wanted option from the context menu

These are examples of stories where a benefit part was not clarified enough. Again, what is a big deal?

In general a benefit is a need and another type of a need is a problem to be solved. So, a role wants a feature because one requires a benefit or problem solution. This is natural feature - business need relation.

A feature is a way to satisfy business need by the software functionality. Having need clearly defined a team and PO are able to discover set of features satisfying business need and choose the best one.

But using a given user story template we start a conversation from a feature without talking about a business need first.

Then we want to fill a template so it is possible to put some general benefit instead of, you know, the "real" one.

My solution is: use a slightly different user story template:


In order to [benefit/problem to be solved]
I want [feature]
Being a [role]


---

UPDATED@10/03/2014
Upon further study I decided to redesign the given template as follows:

In order to avoid [problem to be solved]/In order to achieve [expected benefit]
As a [role]
I want [feature]

So now we have two US templates for each of stakeholder's need favour.

---

This template helps to focus on business need first. When the one is clearly defined you may start discovering possible features to satisfy the need.

Conversation Patterns: A Buffer of Useless Answers

This article is part of my work on Conversation Patterns for Software Professionals

---

So you're talking with a stakeholder about new backlog items. Which of the following questions you are going to ask:

1. Do you want to add new items to the backlog?
2. What of new items you want to add to the backlog?
3. What of new features you're going to use next week?

You must always consider stakeholder answers as a result of your questions. So the better question you ask the better answer is given to you.

Choosing the first question: Do you want to add new items to the backlog? you indirectly define possible answers. These are: yes or no. Answering that question is not an effort, so your stakeholder will do it automaticly, without thinking a lot. One will take an answer form a buffer :)

I imagine every human being has a special area in its mind where all answers comes from. Stakeholder is trying to optimize energy when one is querying for the answer, so an 'answer area' is divided into two subareas: surface area and deep area.

The surface area I called a buffer of useless answers. When you ask the question a stakeholder tries to find an answer in this buffer first (to optimize its energy, of course).

The problem is what a buffer contains. Well, rubbishes in most cases: parts of memories, parts of conversations, random informations. A buffer of useless answers is like an uninitialized variable in C - it may contain anything :).

So, to get quality answers you have to drill deeper under the buffer of useless answers. How to do it? Well, ask a question with a suggestion where or how to seek an answer.

Consider the second question example: What of new items you want to add to the backlog? There is an assumption in the question: I know you want to add some items. A stakeholder is not instructed to take an answer from the predefined set of answers. Finally, one will make an effort querying a deep answer area, not a buffer of useless answers.

You may decide to drill even deeper. The third question example is: What of new features you're going to use next week?. Oh, yeah! A stakeholder's brain is red hot now. One was instructed to imagine oneself of act of using a software in the future. One tries to place priority features among the existing ones. Then one verify a usability of whole new mental model and then is ready to answer the asked question.

What questions you might to drill deeper?

"You may say I'm an extremer (...)"

I found this one years ago #nostalgic...


Imagine there’s no requirements.
It’s easy if you try
Just a bunch of coders,
reachin’ for the sky
Imagine all the people,
coding for today

Imagine there’s no schedules.
It isn’t hard to do
No silly project deadlines,
no one supervising you
Imagine all the people,
coding hand in hand

You may say I’m an extremer
but I’m not the only one
I hope someday you’ll join us
and make coding lots more fun.

Imagine oral documentation.
I wonder if you can
No need for UML diagrams.
Just words passed, man to man
Imagine just refactoring,
playing in the sand

You may say I’m an extremer
but I’m not the only one
I hope someday you’ll join us
and make coding lots more fun


Public activities calendar

I publish my public activities calendar because I want o meet you, share our ideas and talk about our professional experiences.

You will find the calendar on this blog on the left or you may subscribe it via xml, ical or html.

So let's stay in touch, I hope to see you soon :)

The most valuable lesson learned from GTD

Whole GTD framework is worth to familiarize yourself with. But the one thing was a rocket jump for me - tasks chunking.

David Allen advice is tasks should be actionable. It means they should be ready to do now. You may examine your tasks by asking: Is it a physical action? where physical means you may express it in the language of your senses and you body. For example 'Process input data' is not physical action. Why? Try to show a process activity by your hands:). Impossible.

In opposite to tasks above: 'Talk to Peter about object model for input data', 'Draw down sketch of classes', 'Write down steps of the data processing algorithm', 'Write initial unit tests for data processing service',... are more 'physical'. So if you are aware of the context these tasks are ready to do as they are now. And this is what we call task chunking.

When I start working on a project I write down some general epics, stories, goals. But I never start working on them unless I write down at least one actionable task. In fact one actionable task is the minimum you need. Ok, I do mistakes and sometimes I take a task which is too general to accomplish it and then I always fail. The only rescue is tasks chunking.

I have also my own actionability cirterion I call it Copy-Paste Test:
'copy' a task and 'paste' it into different context; the less sense it make the more actionable it is. The reason is that specific and actionable task are strongly coupled with its context. So 'copying' them into different context make them incomprehensibled.

Consider: 'Implement the finding service' fits to every context so it is unactinable, but 'Implement service for finding Employee entity by department and salary' is stronger coupled with its context and it is more actionable.

About tools

Personally I use a kanban board on my fridge, at work we currently use LeanKit.com/. These two help me to keep clarity and limit work in progress. For tasks chunking I use todoist.com.

Quora.com - my new public service

I made a resolution to contribute to the Community more than I used to. I chose the quora.com to be my first step. Reading my blog or tweets you probably have some ideas what I am involved in. So, do not hesitate to ask detailed questions, if I know the answer I will let you know. You may follow your questions and my quora.com activity as well.

Conversation Patterns: Polowania na czarownice i czarowników

This article is part of my work on Conversation Patterns for Software Professionals

---

(...) uzmysławiamy sobie tę prostą prawdę, że za wszystkimi komunikatami, którym dotychczas pozwalaliśmy brzmieć groźnie, stoją jedynie ludzie o niezaspokojonych potrzebach, którzy proszą nas, abyśmy coś zrobili dla poprawy ich samopoczucia, Marshall B. Rosenberg

A gdy już coś pierdyknie, to zaczyna się poszukiwanie przyczyny niepowodzenia. Skądinąd ta racjonalna idea opiera się na uproszczonym założeniu, że gdzieś istnieje single point of failure, lub double. No, skończona ilość pojedynczych przyczyn.

Jednak dyscyplina system thinking wskazuje, że niepowodzenie jest wypadkową złożonych interakcji w "systemie". Ciekawe studium przypadku w tym kierunku możesz znaleźć w Efekcie Lucyfera by Philip Zimbardo.

A więc szukamy winnych...

...ponieważ, czujemy potrzebę rozładowania emocji, z którymi sobie nie radzimy. Kolejne szczegółowe objaśnienie znajdziesz w Porozumieniu bez przemocy, skąd pochodzi początkowy cytat.

...ponieważ, to najłatwiejszy sposób do uzyskania poczucia, że problem został zrozumiany, i że w przyszłości będzie można go uniknąć. Oczywiście owo "poczucie", nie oznacza, że sprawa rzeczywiście została rozwiązana. Oznacza to wyłącznie tyle, że skoro polała się krew, to wszyscy zestresowani zainteresowani odetchnęli z ulgą, że oberwał ktoś trzeci i że sprawę załatwiono.

...ponieważ nie umiemy sobie radzić z "otwartymi" sprawami. Trudno zająć się czymś innym, gdy nurtuje Cię pytanie, na które nie znasz odpowiedzi, test, który nie przechodzi, czy //XXX, którego nie możesz namierzyć. Ta zasada jest podstawą każdej hmmm... metodologii efektywności m.in. 7 Habits of Highly Effective People, Getting Things Done, Personal Kanban, Awake the Giant Within, które dają przepisy na przekształcanie "otwartych" spraw w motywujące mierzalne cele.

Psikus z otwartymi sprawami polega na tym, że gdy czegoś nie rozumiemy i w dodatku mamy do tego mocno emocjonalny stosunek, to rozpaczliwie szukamy zamknięcia otwartej sprawy, choćby owo zamknięcie było najgłupszym z możliwych. W ten sposób zadowalamy się prostymi odpowiedziami na trudne pytania i preferujemy tanie suplementy intelektualnej diety.

Co z tym fantem?
Poniżej podaję kilka pomysłów, jak przeciwdziałać poszukiwaniu winnych. Nie są to rozwiązania instant, ale kilka z pewnością się przyda.

• Omawiaj wtopy po weekendzie; będzie nieco czasu na ochłonięcie
• Omawiaj wyłącznie fakty (ad rem). Fakty dotyczą tego, co do mózgu dostarcza nam jeden z pięciu podstawowych zmysłów, czyli to co można zobaczyć, usłyszeć, powąchać itd; szósty zmysł a więc wszelkiego rodzaju mind reading zostawiamy w spokoju
• Jak ognia unikaj zdań zawierających: jesteś (ad personem), zawsze, nigdy, ciągle, wciąż, żaden (kwantyfikatory)
• Jak piekielnego ognia unikaj ocen - ten punkt jest dla wielu z nas nie do przejścia. Zdanie Zobaczyłem, że to spieprzyliście nie jest stwierdzeniem faktu lecz oceną, bo czynności spieprzenia nie można zobaczyć, ale można zobaczyć, że: w połowie iteracji na tablicy wisiało dużo zadań z błędami, burn-up chart ma 20 schodków, ktoś zatwierdził kod z błędami itd.
• Omawiaj fakty tylko z pierwszej ręki. Zabawa w głuchy telefon jest śmieszna w przedszkolu i to tylko wtedy, gdy traktuje się ją jako zabawę; tymczasem dorośli traktują głuchy telefon śmiertelnie poważnie
• Najpierw zbierz wszystkie punkty widzenia, a dopiero potem je omawiaj. Z szacunku dla tajemnicy ludzkiego umysłu bezpiecznie jest założyć, że nawet gdy ktoś coś komuś zrobił, to każda ze stron ma świadomość tylko wycinka całej sytuacji. Najpierw zbierz wszystkie puzzle, a dopiero potem staraj się zobaczyć obrazek
• Rozwiąż problem lokalnie, a potem standaryzuj
• Trenuj Technikę pozytywnej intencji

Dużo piszę o faktach. Mówimy o faktach, ale wszystko to w obrębie empatycznego porozumienia, po które odsyłam do książki Marshalla Rosenberga.

Niezadowolenie ma sens

Product Owner, który "odpuszcza" w trakcie demo, działa przeciw zespołowi. O co chodzi?

Iteracja była trudna. Wyskoczyło sporo bugów, związanych z niezaplanowaną refaktoryzacją dawno zapomnianego kawałka systemu. Zespół pracował na najwyższych obrotach, a schodki na burn-up chart zdawały się nie mieć końca. W ostatnim tygodniu wszyscy z utęsknieniem czekali na piątek, a gdy już nadszedł, od samego rana czuć było podekscytowanie zbliżającym się demo.

Wysprzątany pokój, rozstawiony rzutnik, zespół w świątecznym nastroju. Brakuje tylko czerwonych goździków dla zasłużonych. Wszyscy z uwagą śledzą rozmowę PO z jednym z programistów, prezentującym implementacje poszczególnych historyjek. Scenariusz po scenariuszu idą jak z płatka i nagle..&^@%!@

W tym momencie w zgodzie z niektórymi teoriami Wszechświat się rozgałęzia i mogą wydarzyć się co najmniej dwa scenariusze.

Scenariusz A

Następuje chwila niezręcznej ciszy, podczas której PO patrzy na napięte twarze zespołu, na których między wielkimi, jak u Puszka Okruszka oczami, powiększa się nabiegły łzami znak zapytania.

Ktoś powiedział, że największe boje w historii ludzkości wydarzają się w zakamarkach ludzkiej duszy. Nie inaczej jest teraz. Po długiej jak wieczność chwili, na twarzy PO pojawia się miękki uśmiech.
- Ok - rzuca ciepło - powiedzmy, że jest zrobione. Dokończycie w międzyczasie ("międzyczas" - niepotwierdzony żadną poważną teorią bufor czasowy, w którym da się wykonać więcej pracy, niż w całym projekcie łącznie).

Wszyscy oddychają z ulgą. Znów jest miło. Po zakończonym demo ludzie w pośpiechu wymykają się z biura. Już weekend. Można odsapnąć i zająć się czymś innym niż to natrętne, kołaczące na skraju świadomości odczucie wewnętrznego "fuj".

Niestety historia lubi się powtarzać, więc i ta się powtórzyła. Po trzeciej podobnej repecie, idąc na demo ludzie zaczynają włączać autopilota itd., itd., itd.

---

Scenariusz A'

Nastąpiła pełna napięcia cisza. Cisza. Przeciągająca się cisza. PO wziął głęboki oddech i:
- Przykro mi, ale to jest DONE. Nie zgodnie z tym, co ustaliliśmy jako DONE.
- Ale przecież jest to tylko kwestia kosmetyki. Parę godzin i będzie gotowe. A ta druga historyjka jest gotowa, tylko jeszcze nie wdrożona. Projekt nam się za długo buduje.
PO popatrzył na rozmówcę wzrokiem Johna Wayne'a i powiedział:
- Gdybyś miał za tę pracę zapłacić z własnych pieniędzy, to zapłaciłbyś?

Niemal w tej samej chwili, Piotrek wybiegł z sali trzasnąwszy drzwiami, a w reszcie grupy, wybuchła gorąca dyskusja, od czasu do czasu ocierająca się o kłótnie.
- Nie - powtórzył twardo PO - Nie jest DONE. Nie odbieram.
Na tym dyskusja się zakończyła.

Gdy pył opadł, zespół zasiadł do retrospekcji. Mieli nad czym dyskutować, więc ledwo zmieścili się w założonym czasie. Ustalono, że: Paweł z Marcinem rozpoznają temat serwera CI i one-click building, koncept zadania zawsze będzie analizowany zespołowo, blokery będą omawiane na forum i w razie potrzeby zespół decyduje się na swarming, historyjki z najbliższego sprintu zostaną ponownie przeszacowane, refaktoring będzie robiony zawsze parami.

Ludzie wychodzili z biura w znakomitym nastroju. PO ich cholernie wkurzył, ale znaleźli rozwiązanie. Zawsze znajdują. Wprowadzili do swojej pracy niezbędne modyfikacje. To się już nie powtórzy. Nie ma prawa się powtórzyć. Po weekendzie zaczyna się nowy sprint. Każdy z programistów już widzi najbliższe demo i PO śpiewającego peany na ich cześć.

---

Wniosek

Czasem, nie chcąc sprawiać komuś przykrości, robimy mu krzywdę.

Dekomponowanie zadań

Umiejętność dekomponowania zadań uważam za kluczową, jeśli chodzi o zarządzanie czasem. W różnych momentach prowadzenia szkolenia z tego tematu, starałem się formułować mniej lub bardziej zjadliwe procedury do przeprowadzania owej dekompozycji. W końcu mnie oświeciło i wpadłem na tę, jak sądzę, najprostszą, elegancką i skuteczną:)

Definiuj zadania maksymalnie czterogodzinne

Wiem, że brzmi to jak magiczna formułka na wszystkie problemy. Aczkolwiek to proste zdanie to tylko wierzchołek czegoś większego. Zauważyłem, że gdy wyodrębniając zadanie skupiamy się na tym, aby zajęło cztery godziny, przebiegamy w myślach przez kilka procedur i kryteriów dekomponowania, które tak usilnie starałem się wcześniej sformułować.

Trik polega na tym, że fiksując się na owych czterech godzinach, musisz wykonać eksperyment myślowy i dość szczegółowo wyobrazić sobie to, co ma być efektem zadania i jak to wykonasz. Czyli właśnie to, czego nie robią osoby mające kłopot z dekomponowaniem, a w konsekwencji i z dotrzymywaniem szacowań.

Cztery godziny to dość krótka perspektywa czasowa, którą w dodatku, jako homo sapiens, potrafisz dość dobrze percypować (@see Nie myj zębów, rób retrospekcje). Żeby więc to czterogodzinne zadanie wykonać, musisz być pewny, że da się je wykonać i formułujesz je bardzo konkretnie (przechodzi Test Copy-Paste). I to jest druga zaniedbywana sprawa.

Cztery godziny to, rzecz jasna, wartość umowna. Chodzi o to, aby perspektywa czasowa, była na tyle bliska, aby ze spokojem się na niej skupić i realnie o niej myśleć. Poeksperymentuj z godziną, dwoma, trzema - sprawdź, co będzie. Czy z większymi liczbami też? Moim zdaniem - nie.

Sądzę, że raczej nie jesteśmy w stanie wiarygodnie oszacować na np. 8 godzin. Wiarygodnie tzn. ze powtarzalną trafnością.No, może z wyłączeniem zadań typu: przybij tysiąc stempli na kopercie, napisz walidację not null dla pięćdziesięciu textfieldów na stronie, gdzie obowiązuje proste mnożenie.

Zachęcam gorąco do eksperymentowania i postępowania wg własnego uznania:)

---

UPDATE 30/08/13
Komentarz do posta uświadomił mi, że powinienem jeszcze kilka słów dodać:)

Moja teza nie brzmi "szacuj na max, 4h bo powyżej tego źle oszacujesz", lecz "jeśli wyodrębniasz zadanie z wystarczająco krótką perspektywą czasową, to zrobisz to konkretnie, gdyż wymusi to przemyślenie przedsięwzięcia i być może utrzymasz szacowanie - lecz nie z powodu szacowania, a konkretności właśnie"

Tak jak napisałem, 4h przyjąłem arbitralnie. Co do trafienia w większe oszacowanie, to różnie bywa (por. "Szacowanie oprogramowania", Steve McConnell). Jednakże zwróciłem uwagę, że gdy szacujemy, to zazwyczaj szacowania wyglądają np. tak: 8, 8, 24, 16, 8, 12, 24.

Gdy położyłem przed sobą wiele takich szacowań, to zaważyłem, że niemal wszystkie to wielokrotności jakiejś bazowej liczby: często 8 bądź 6.

Wnioski były dla mnie takie:

• szacując operujemy jakimiś tam idealnymi interwałami (osobodniami, efektywnymi dniami), za pomocą których próbujemy odwzorować czasochłonność zadania
• raczej nie szacujemy czasu, lecz rozmiar zadania - jak duże ono jest

Gdyby chcieć podawać rzeczywiste oszacowania, trzeba by zaprzęgnąć jakaś metodę analityczną np. PERT.

Wg mnie sensowna metoda szacowania polega na retrospektywnej analizie zadań. Najpierw musisz popracować, zobaczyć z czym masz do czynienia, szacować na wyczucie. A potem zaprzęgasz statystykę, analizujesz dane, wyodrębniasz klasy zadań i estymujesz przyszłość z założonym prawdopodobieństwem.

Wtedy dopiero wychodzi, jak bardzo szacowanie wrażliwe jest na zmiany kontekstu, środowiska. Innymi słowy, gdy nie mogę sobie zbudować jakiegoś punktu odniesienia i wszystko absolutnie wszystko się zmienia, to szacowanie jest tylko złudzeniem. Lubimy wierzyć w to złudzenie, bo to łatwiejsze, niż przyznanie, że jednak przyszłość nie będzie wyglądać tak, jakbyśmy chcieli.

Niejednorodny zespół

Scrum recognizes no titles for Development Team members other than Developer, regardless of the work being performed by the person; there are no exceptions to this rule - napisali niegdyś mądrzy ludzie i zespół w tej postaci jest super. Jednakże robiąc przegląd inwentarza, możesz dojść do wniosku, że stan rzeczy rzeczy w Twoim zespole oraz zasoby, którymi dysponujesz, odbiegają od tego docelowego obrazka. Co wtedy?

Co jest?

Może się dla przykładu okazać, że "dostałeś" pięciu programistów, trzech testerów, analityka oraz Scrum Mastera z nadania, który ostatnimi czasy poświęcał się wyłącznie zarządzaniu.

W takiej konstelacji możesz się spodziewać następujących objawów:

• Polaryzacja między testerami a programistami; nie piszę "wrogość", lecz właśnie polaryzacja my-wy: wy zrobiliście błąd, wy skopaliście testy, my coś zaimplementowaliśmy, itp.
• Programiści mają chroniczny opór przed testowaniem
• Testerzy biorą znikomy udział w planowaniu
• Analityk nie za bardzo może znaleźć swoje miejsce w zespole
• Pojawia się zastanawiająco dużo spadów z poprzednich sprintów

Może się okazać, że po przeprowadzeniu małego śledztwa, ma miejsce następujący związek przyczyn i skutków:

Jak mogłoby być?

Długoterminowym celem mogłoby być oczywiście doprowadzenie do sytuacji, w której każdy jest wspomnianym "developerem", ale o tym na początku lepiej nie mówić głośno:)

Co pomiędzy?

Sądzę, że w takiej sytuacji kluczowe jest, nie tyle męczyć ludzi, aby byli idealnym zespołem, co wydobyć tu i teraz to, co najlepsze. Bardzo dobrym początkiem będzie przeorganizowanie sposobu planowania. Otóż:

• Planujcie podgrupami dzielonymi względem testerów, np. tester+2*programista
• Każda grupa otrzymuje swoje US, które dzieli na zadania
• Analityk chodzi i doradza :)
• Wyodrębniajcie zadania: programistyczne, testerskie, analityczne
• Po zakończeniu dekomponowania grupa przedstawia swoje US, a reszta zadaje pytania kontrolne Czy uwzględniliście to, a to? i jeśli nie, to dodajemy kolejne zadania (uwaga celowo jest tu odwrócenie: grupa nie przedstawia swoich zadań, lecz odpowiada na pytania kontrolne zespołu, gdyż w przeciwnym razie zamęczycie się i zanudzicie

Pytania retrospekcyjne po wprowadzeniu w/w zmiany (po jednej bądź dwóch iteracjach):

• Jak oceniam współpracę między testerami a programistami?
• Czy wciąż mówimy o sobie my-wy?
• Czy będziemy mieli spady w najbliższej iteracji?
• Jak dużo zadań doszło w trakcie iteracji? Jakiego rodzaju były to zadania?

Kilka słów o roli analityka
Analityk bywa w Scrumie czasem zagubiony. W jaką rolę ma się wcielić Proxy Product Owner, Scrum Master, Product Owner? Jedną z powtarzanych przyczyn zmieszania analityka są te cholerne straty w projekcie. No bo jeśli jedyna wartością jest "działające oprogramowanie", reszta to strata, a jemu kazali pisać dokumentację, to ma poczucie, że wykonuje bezsensowną i bezwartościową pracę.

Myślę, że te "straty" wymagają małego komentarza. Analityku, jeśli w założeniach projektu stoi napisane, że ma być dokumentacja analityczna w projekcie, bo tak wymaga klient, ustawa czy ktokolwiek inny, to dokumentacja również jest wartością w projekcie i również dodaje punty do business value.

Przykładowe zadania, w których analityk może wspierać zespół:

• współpraca i mediacje:) z PO
• backlog grooming
• prowadzenie Product Canvas; ciekawe linki: tutaj, tutaj i tutaj.

Conversation Patterns: Słowa są ważne w User Stories

This article is part of my work on Conversation Patterns for Software Professionals

---

Wprowadzenie, którego nie trzeba czytać :)

Minął prawie rok od chwili wydania Oprogramowania szytego na miarę.... Prowadziłem sporo warsztatów w oparciu o tę książkę i mailowałem z czytelnikami. Z zadawanych pytań wnioskuję, że nie jest do końca jasne, w jaki sposób stosować techniki zadawania pytań w szczegółowych kontekstach. Opisane sposoby prowadzenia rozmowy z klientem są często widziane w izolacji od "reszty świata".

Rozmawiamy sobie, zadajemy pytania, konkretyzujemy, ale co dalej? My przecież posługujemy się: user stories, taskami, use cases, bounded contexts, architekturą itd. Jak to skleić z technikami zadawania pytań? Przecież w tych wszystkich wymienionych obszarach zadawanie pytań, konkretyzowanie, definiowanie problemu ma swoje zastosowanie. Albo inaczej: user stories, taski, use cases, bounded contexts, architekturą są efektem zadawania pytań. A zatem pytanie brzmi: jak zadawać pytania, aby otrzymać: USs, UCs, tasks, BCs, zdekomponowaną architekturę?

Tę umiejętność zadawania pytań prowadzących do w/w artefaktów nazywam conversation patterns. Termin ten ukuliśmy podczas iDDD Tour w Krakowie, kiedy Vaughn Vernon dał nam parę minut na przedstawienie paru spostrzeżeń nt. wyodrębniania modelu dziedzinowego podczas rozmowy z ekspertem. Tak powstała krótka prezentacja Conversation Patters for Ubiquitous Language (jeśli nie było Cię na iDDD Tour, musisz użyć wyobraźni, aby złapać o co chodzi:)).

Tyle tytułem wstępu. Zacznijmy od User Stories.

---

Literalne stosowanie szablonu

Krótki przegląd przez historię rozwoju US możesz przeczytać na stronie Scotta Amblera. W każdym razie popularną obecnie ich formą jest As a...I want...so that....
Ten bardzo sprytny schemat formułowania US ułatwia ekspertowi formułowanie myśli i oczekiwań. Jest bardzo prosty, lecz pod tą prostotą kryje się mnóstwo niuansów, bez zrozumienia których, powstają karykatury US. Zobaczmy do czego może doprowadzić literalne stosowanie tego szablonu:

1. Jako Użytkownik chcę się zalogować, aby się zalogować :)
2. Jako Użytkownik chcę się zalogować, aby skorzystać z systemu
3. Jako Użytkownik chcę kliknąć prawym przyciskiem myszy i zobaczyć menu kontekstowe po to, aby wybrać interesującą mnie opcję
4. Jako Likwidator chcę zwiększyć rezerwę szkodową, aby postępować zgodnie z wewnętrzną procedurą T-1000
5. Jako PO chcę dodać pracownika do bazy, aby mieć go w systemie

Kilka słów komentarza. (1,2) słabują jeśli chodzi o precyzyjne sformułowanie korzyści (frazy po so that...). Czy korzyścią dla użytkownika jest to, że się zaloguje? Wątpliwe. Że skorzysta z sytemu? Być może, ale możliwe, że użytkownikowi chodzi o to, aby dostać się do swojego konta?

Jeśli chodzi o (3) również jest kłopot z korzyścią. Jasne, że wybranie interesującej opcji ma sens, jeśli mówimy o tworzeniu menadżera okien, albo biblioteki GUI, lecz a aplikacji biznesowej wybranie interesującej opcji nie jest korzyścią lecz specyfikacją interfejsu użytkownika.

W (4) jest lepiej. Czy postępowanie zgodnie z procedurą T-1000 sprawi, że dzięki oprogramowaniu będziemy mogli odnosić więcej korzyści? pozyskać więcej klientów? zarabiać więcej pieniędzy? Bez szerszego kontekstu trudno jednoznacznie stwierdzić. Brzmi dobrze.

Nieco inaczej jest w (5). To, że PO wypowiada US, nie oznacza, że to on chce danej funkcjonalności, i że on odniesie z niej korzyść. Oczywiście warto używać US do opisywania potrzeb interesariuszy (brzydkie słowo:)) -@see Stakeholder Stories, lecz w tym przypadku rola nie została właściwie dopasowana do potrzeby i korzyści. PO może chcieć np. ładniejszy layout, poprawę bezpieczeństwa. Funkcjonalności raczej rzadko.

Słowa są ważne w US [@see rozdział: Co to znaczy myśleć biznesowo?]
Tak naprawdę US nie jest niczym innym niż parafrazą [@see Technika parafrazy] tego, co ekspert powiedział, spisaną w ustandaryzowany sposób. Posługując się strukturą rozmowy [@see rozdział Sztuka zadawania pytań], formułujesz pojedyncze wypowiedzi rozmówcy w jak najbardziej konkretny sposób.

Tak jak sugeruje tytuł posta i akapitu, słowa których używasz w spisywaniu US mają znaczenie. Zerknij na rysunek. To, co mówi Twój ekspert możesz zapisać co najmniej z użyciem słownictwa trojakiego rodzaju:

Biznesowego - słowa pochodzą z dziedziny biznesowej np.: Jako Klient chcę obejrzeć możliwe do założenia lokaty, aby wybrać najodpowiedniejszą do moich potrzeb
Rozwiązań - słowa dotyczą konkretnych rozwiązań i sugerują j a k coś ma działać, np.:Jako Klient, chcę wejść na zakładkę możliwych do złożenia lokat, aby zaznaczyć najodpowiedniejszą do moich potrzeb.
Technikaliów - słowa pochodzą z żargonu technicznego np.: Jako Klient, chcę wyświetlić listbox ofert, aby najlepszą dodać do mojego rachunku.

Oczywiście to tylko typologia. Więc Twoje parafrazy tego, co mówi rozmówca, mogą miksować słownictwo różnego rodzaju. W tym miejscu chcę Ci zasugerować, abyś używał przede wszystkim słownictwa bizensowego. Dlaczego?

Powód 1. Tak jak na rysunku między tymi grupami słów występuje relacja podrzędności. Najwyżej umieszczony jest biznes, najniżej technikalia. Zmiany również przebiegają z góry na dół. Daną potrzebę biznesową można zrealizować na kilka sposobów, które mogą się zmieniać. Jeśli więc klient stwierdzi, że woli nowe strony zamiast zakładek, to spowoduje to dużo zmian w wymaganiach. Jeśli będziesz trzymać się słownictwa biznesowego, to zmiany w konkretnych rozwiązaniach nie będą aż tak bolesne.

Powód 2. To zespół jest odpowiedzialny za proponowanie klientowi rozwiązań i za znalezienie najlepszego. Klient jest odpowiedzialny za swoje potrzeby. Pamiętaj: User Stories są efektem konwersacji.

Powód 3. Używając żargonu technicznego kastrujesz domenę. Gubisz ważne pojęcia biznesowe, reguły za nimi stojące. Jest duża szansa, że stworzysz architekturę nieadekwatną do wymagań (@see Jak zniszczyć swój kod?).

Zatem celem jest to, aby wejść na poziom biznesu, z jego perspektywy sformułować US i używając swojego doświadczenia technicznego, zaproponować konkretne rozwiązania.

Ćwiczenie dla zespołu

Retrospekcje dość często opierają się na wrażeniach. Dyskutujemy o naszych spostrzeżeniach i o zmianach. Wrażenia dają wiele informacji, lecz dla równowagi chciałbym zaproponować Twojemu zespołowi retrospekcję opartą na liczbach.

W najbliższej iteracji podejmijcie jedną praktykę: ilekroć karteczka trafi do kolumny IN PROGRESS, oznacz datę umieszczenia w tej kolumnie oraz datę umieszczenia w kolumnie DONE.
Podczas retrospekcji wybierzcie zadania, które przebywały w IN PROGRESS maksymalnie jeden dzień (typ A) oraz te, które przebywały tam trzy dni i więcej (typ Z), i odpowiedzcie na następujące pytania:

• Ile było zadań typu A? Ile było zadań typu Z?
• Na ile początkowo były szacowane zadania typu A oraz Z?
• Dla których zadań, A czy Z, błąd oszacowania jest mniejszy?
• Czy zadania typu A są sformułowane inaczej niż zadania typu Z? Na czym konkretnie polega różnica?
• Które z zadań są formułowane pełnym zdaniem? (z czasownikiem i rzeczownikiem)
• Czy któreś z zadań sformułowane jest w trybie rozkazującym?
• Które z zadań przechodzą Test Copy-Paste?*

I na koniec wnioski: w jaki sposób następnym razem należy formułować zadania.


*) Test Copy Paste - to dość dobry sposób weryfikowania konkretności zadania. Jeśli przeniesiesz swoje zdanie do innego kontekstu i wciąż ma ono sens, to prawdopodobnie jest mało konkretne. Na przykład zadania: Napisz test, Przygotuj dokumentację, Zaimplementuj serwis wyszukujący pasują wszędzie. Nieważne czy pracujesz nad CRM, portalem e-bankowości, czy sterownikiem klapy od sedesu - te zadania mają sens, w każdym z wymienionych kontekstów. Aż się prosi o ich zdekomponowanie.

Lecz zadania: Napisz test do porównywania dochodów klienta na wniosku z danymi biura nieruchomości, Zaimplementuj podgląd wniosku windykacyjnego zdefiniowanego w BAF po przeniesieniu do innej przestrzeni problemu tracą swój sens. Tracą go ponieważ ich sformułowanie jest na tyle związane z tym konkretnym kontekstem, że bez niego trudno jest zadania zrozumieć. Takie zadania mają bardzo wysokie actionability, są na tyle konkretne, że łatwo je wykonać OD RAZU. Oczywiście Test Copy-Paste nie jest zero-jedynkowy, lecz wyznacza pewne continuum konkretności i actionabilitności :) zadań.

Bug-Driven Development

- Ale tego nie było w specyfikacji.
- Ok, ale to przecież oczywiste, że powinniście to zrobić.
- Jak to oczywiste?
- No, kurcze...

Niezliczoną ilość razy z pewnością słyszałeś powyższy dialog.
Chyba wciąż chodzi o to samo - o niedostateczne sprecyzowanie wymagań, a potem o zepchnięcie odpowiedzialności. Przyczyny wspomnianego stanu rzeczy są znane i maglowane wciąż na nowo: trudności komunikacyjne, brak czasu, brak zaangażowania klienta itd, itp. Pewnie chodzi o to, że z wymienionych powodów wymagania nie zostały dobitnie i jednoznacznie sformułowane.

A jeśliby tak ustawić sposób współpracy, że brutforsowo wymusi jednoznaczne formułowanie wymagań? który nie będzie polegał na dobrej woli i chęci zaangażowania, ale po prostu uniemożliwi sformułowanie niejednoznacznych wymagań? I tu jest właśnie miejsce dla Bug-Driven Development :)

No, wyobraź sobie następującą scenę:

Zaczyna się rozmowa z PO na temat nowego sprintu
- Skończyliśmy! - krzyczy uradowany Zespół
- Jak to? Pokażcie!

Zespół z namaszczeniem odpala przeglądarkę, na której widać...białą przestrzeń.
Zmieszany PO jąka - Ale tu nic nie ma...
- Jak to nie ma? - odpowiada pewny jak McGyver siebie Zespół.
- No, nie mogę się zalogować.
- Ok, mamy pierwszy bug - zespół skrupulatnie notuje coś na kartce.
- Czekaj, wrócimy za dziesięć minut.
- ?? - odpowiada PO.

Po chili grupa programistów wpada do sali spotkań.
- Już mamy! - wrzeszczą uradowani.
- Czyli co?
- Jak to co? Soft dla Ciebie! Co z tobą, Łosiu?

Odpalają przeglądarkę z pięknym ekranem logowania. PO z nadzieją w oczach loguje się do systemu i....
- Aaaa! $^!@#&(!
- Czy coś nie tak? - pytają z zaciekawieniem programiści.
- A gdzie panel użytkownika, do cholery!!

Na to szczęśliwy jak nigdy dotąd SM:
- Ok, chłopaki mamy drugiego buga!, spadamy.
Po czym rzuca przez ramię, do oniemiałego PO.
- Pół godzinki i jesteśmy, buźka!

i tak przez najbliższe cztery tygodnie.


To tak, pół żartem, pół serio, ale czuję, że coś w tym jest :)

13/2 = 8 + 8 [ setny post:) ]

Jakiś czas temu zaproponowałem w trakcie planowania z pewnym zespołem, aby historyjkę podzielić na dwie mniejsze. Na to szybko zaoponował Product Owner - O, nie nie. Jak ostatnio podzielili 13SP na dwie historyjki, to wyszło im dwa razy po 8. Niech lepiej nie dzielą.

Ale to właśnie o to chodzi! Ta złożoność tam jest, tylko że ukryta. Jeśli nie wyjdzie podczas szacowania jako dodatkowe SP, to pojawi się na wykresie jako spuchnięcie zakresu albo na koniec sprintu jako item, który nie jest "Done".

Na zakończenie rozmowa między, PO a programistą nt. kryterium akceptacji:

PO: No, co ty nie da się wygenerować umowy z bez danych w deklaracji.
Programista: Da się, bo mogę zahakować.
PO: Mów do mnie po polsku.
Programista: No, mogę Cię oszukać...

---

To jest setny post na tym blogu. Przez 62 miesiące pisania, daje to ok 1.61 posta na miesiąc. Kurcze, pisanie to żmudna robota.

Wrażenia po Confiturze 2013

Rodzinna atmosfera jest dla mnie tym, co bardzo w Confiturze lubię. I w tym roku, to również wisiało w powietrzu. Pierwszy raz byłem obecny na zakończeniu i muszę przyznać, że było świetne. Zabawne, na luzie i z pomysłem. Oficjalnie uznaję Bartka za mistrza konferansjerki. Stary, rzuć programowanie, zajmij się prowadzeniem imprez masowych :). Acha, no i klima super:)

Krótko o prezentacjach, na których byłem.
Masz już dość bycia szambonurkiem? Czyli o tym, co robić, aby praca w projekcie "utrzymaniowym" dawała satysfakcję Zaintrygował mnie ten "szambonurek" w tytule, więc poszedłem. Dla mnie ta prezentacja była nowością na konferencji. Do tej pory z katedry słyszałem: u nas jest super, jesteśmy liderami na rynku, róbcie tak jak my, itd.. Niby takie prezentacje są ok, ale zwykle dziwi mnie świat, w którym każda firma jest liderem w swojej branży, a każdy sklep jest "centrum". Myślę, że wychodząc z teorii ciągów liczbowych, stereometrii i słowotwórstwa, można by dowieść, że lider może być tylko jeden i centrum może być tylko jedno. No nic...odpływam od tematu:).

Ta prezentacja była inna. Przedstawiała succes story wychodząc od kompletnej porażki na początku. Usłyszałem historię o błędach, uczeniu się na nich i o sukcesie. Usłyszałem historię RZECZYWISTOŚCI. Dziękuję Prelegentce, za to, że nie uraczyła mnie kolejnym malowaniem trawy na zielono, a krawężników na biało, tylko prosto i ciekawie opowiedziała trudną historię pewnego projektu.

Potem miałem w planach: Emancypacja pracowników. Dlaczego spaliliśmy karty zakładowe? oraz W jaki sposób zatrzymać najlepszych ? Kluczowe aspekty motywacji zespołów deweloperskich. No, ale najpierw zagadnął mnie Pan Kamerzysta i zwierzałem się kamerze ze swoich konferencyjnych wrażeń. Potem zagadnęła mnie Pani z karieraplus.pl z prośbą o wywiad. W życiu nie udzielałem wywiadu i chętnie się zgodziłem. A ponieważ wypytywała mnie również o BNS IT, to natchniony pierwszą prezentacją, opowiedziałem całą naszą historię, nie pomijając niczego. Rozgadałem się, więc jeśli ten wywiad się ukaże bez skracania, to chyba zajmie z pół magazynu:).

Droga po wiedzę – jak zbudować Continuous Learning Culture. Aaa, bardzo fajne. Najciekawsze były przykłady stosowanych rozwiązań. Mam jedno mocne zastrzeżenie. Prowadząc ten blog, zdarzyło mi się parę razy czepiać się prelekcji i wydaje mi się, że jednak lepiej czepiać się w 4oczy. Więc jeśli Autor jest zainteresowany to zapraszam na priv.

Java Developer Career Unplugged. Statystyki pokazywane przez Wojtka na początku prezentacji, jasno dowodzą, że jego wystąpienia można uwielbiać albo ich nie znosić, nie można za to pozostawać obojętnym:) Mnie się akurat bardzo podobają, chyba dlatego, że są one, jak i sam Autor, bardzo wyraziste. Można się zgadzać, można nie, ale wiadomo jakie Prelegent ma stanowisko i czego można się po nim spodziewać. Być może wspomniana polaryzacja wynika stąd, że Wojtek mówi to, o czym wielu myśli, ale nie ma odwagi powiedzieć na głos?

Test Driven Traps
Gdybym miał jednak wybrać najlepszą, to stawiam na tę. Powód jest prosty: samo mięso. Slajd po slajdzie, Jakub przedstawił, bardzo konkretne porady, przemyślenia i pułapki związane z TDD. Niestety musiałem wyjść pod koniec, aby złapać parę oddechów przed swoim wystąpieniem.

Mały tip dla prawie wszystkich prelegentów: koledzy, zmieńcie zdjęcia, postarzeliście się;P i już nieco inaczej wyglądacie ;)

Załączam swoją prezentację. Ponieważ preferuję hasła na prezentacji, więc jeśli nie było Cię na konferencji, chyba będziesz musiał poczekać na filmy.



Dla uzupełnienia wrzucam jeszcze ostatnie dwie konferencyjne prezentacje. Z resztą naszych wystąpień możecie zapoznać się tutaj.

[4 developers] Jak zniszczyć swój kod - podstawy lingwistyki dla programistów from Michał Bartyzel

[33rd] x driven-y niczego nie zmienią from Michał Bartyzel