软件架构设计和Scrum潜在可交付产品，我(scrum master)和他(架构师)的讨论

Following our meeting yesterday I did quite a lot of thinking because what we talked about gave me some concerns. The best way to take care of these concerns and to make sure that they are not based on misunderstandings is of cause to talk about them, so this is what the mail is about :-)

As a start let me freely tell you about some of the thoughts that ran through my head :-)

One of the first thoughts was "do you/ the team see all the architectural work as something that has been done just for my sake?". The reason for this thought was that looking at the backlog you has made it seemed almost like you wanted to start all over by breaking down the solution once again using use cases as backlog items. I could not see a direct line from the where the architectural work ended to the backlog items.

Other thoughts I had was "you are taking some of your Scrum learning a bit too literally” and “you forget that any process has to be tailored to your current context” and “you seem to miss the difference between project management models with development models”.

The reasons for these thoughts are: I my view Scrum is a project management model. It does (almost) not concern itself with development issues (engineering tasks) like architectural breakdown process, design methods, implementation and testing methods. It has focus on the execution of tasks being done as part of the architectural breakdown process, the design methods, the implementation and testing methods. And the focus is on time and on progress and constraints (impediments). This is also why Scrum is used widely outside the software development industry, e.g. in Grundfos Marketing for marketing tasks.

A development model concerns with what tasks do you need to do in order to e.g. do architectural breakdown, do design, etc., i.e. the focus is on what tasks is needed and in what sequence, but it does not concern itself with how the individual tasks are executed (i.e. time, progress and impediments).

Many companies only use Scrum when they do implementation. Before that they do architectural work and design outside the Scrum process. I don’t see why you should not do architectural work and design within a Scrum process. The reason why we haven’t done it in the E-product project is because it would take away some focus from the architectural work because this focus would be needed to handle the difficulty of estimating tasks in a new process and to avoid the frustration of not reaching you sprint goals time after time.

It is correct that when you learn Scrum they say that you should have a potential shippable product at the end of each sprint. If you are doing a typical Web application where you have a form with some input fields and an action button sending a request to the back-end function and the back-end then is responding with a new web-page, this can typically be done within one sprint. But the key differences between such a case and e.g. E-product Configuration System are complexity and the architectural work needed. If you think of when we started the E-Product project this time – if you then were to make a potential shippable product in just one sprint I would not give you much chance unless of cause you were happy to deliver something that would to be re-factored many times during the project and it would most likely not be anywhere near the qualities that we have defined.

In my view the term should not be “potentially shippable product” but “valuable delivery” because getting the architecture right – having the right qualities – has significant importance to the customer – typically they just don’t know it because they don’t realize the importance of e.g. maintainability, flexibility, …

I fully agree that with you that you should not do design down to the very last detail before starting implementation, but likewise you should not start implementation with no design at all so that you get an almost infinite number of re-factoring tasks during the project. The key is to find a balance of the right amount of overall design before starting implementation and then accepting a reasonable amount of re-factoring during the project. And just to be a bit more clear, when I say design I do not talk about class definition/diagram or collaboration diagram or anything that detailed.

As usual comments and question will be appreciated and answered and remember that the important thing is not that we agree on everything but that we can express our views openly and discuss the differences but most of all that you get the product developed :-)

Added October 27. I see 2 reasons why it is not practical (not possible) to use business use cases when starting design & implementation: • If you base your backlog items on business use cases it is like starting the breakdown of the system all over again, because typically you can’t really make sprint backlog items that is implementable within 10-20 hours from business use cases. • Typically the functionality for a given business use case will be widely dispersed in the system. This means that in order to implement a business use case you typically need to implement a large part of the system. This was confirmed in the Leonidas project where the project manager wanted to base the backlog items on business use cases. This approach was quickly abandoned because it simply does not work.

What is needed before the first sprint is to figure out what should be done first (i.e. topics like design, functionality, development system, test systems, missing specification & facts, learning about new technology, etc.). There will always be dependencies you have to take into consideration, e.g.: • you can’t test the marking functionality before you have set up your marking server test system • you have to define the overall design for e.g. Trigger adapters in order to ensure that all adapters have a common and appropriate design taking the different trigger-types into account and to ensure that all adapters have the same interface and to ensure that their responsibilities are structured according to the same design. • you have to define the overall design for e.g. Business Actions in order to ensure that all Business Actions implements the same interfaces and to ensure that their responsibilities are structured according to the same design.

You can say that what’s needed is an implementation strategy because you start out having nothing and then build up a foundation for what is coming next. In terms of functionality you would usually start by implementing the central part of the system – the core of the system (e.g. the workflow engine and the execution controller and a very simple workflow with one or to very simple Process Actions that does not need to be real Process Actions). Then you add functionality both “horizontally” (e.g. a trigger adapter, DAL/HAL functions, Geni protocol, one Process Action and one Business Action, etc.) and vertically (e.g. more Process Actions and Business Actions and Business Logic functions, UI, etc.). As you go along you can check off business use cases whenever they get completed by the functionality you have implemented. Generally as long as you can define one or more clear goal for your sprint you should not worry if the outcome of the sprint is a potentially shippable product or an overall design for specific part of the system or clarification of important issues or a mix of all these or other types of deliveries – the important thing is that what you deliver at the end of the sprint is valuable and have the highest priority.