Last week in this Cordys project

This is my last week in a Cordys project I did.. It was a high pressure Cordys Case Management project with an Agile approach. The things I learned (again) and in random order:

1. You need Cordys consultants
2. Introspection after each iteration
3. Invest in automatic testing
4. Invest in setting up your Services
5. Invest in the Domain Model
6. Requirement management (user stories)
7. Consult a scrum master
8. Assign responsibilities

Cordys consultants

The Cordys (BOP4.1) still contains bugs and this is not remarkable given the young produkt. However this means that you need to know if it is a programming error or a Cordys bug. For this you really need a Cordys  consultant who really knows the core produkt. 

Introspection 

Within each (Agile) project you will have difficulties with the development process. This is not a problem as long as you are open for introspection. This will help the project in what goes wrong and what goes well. If you do not do this then the process will not approve.

Automatic testing

Because we had to implement a lot of requirements in a few iterations, it was advised to invest in automatic testing that could be used for regression testing. However this was acknowledged by the customer too late. This way it was very risky to refactor code. In the beginning it takes some effort but in the end it is very much worth the effort.

Services

Within Cordys you can use WS-AppServer to implement abstraction to your databases and also to implement the Domain Objects. On these Objects you can generate (web)services. The ws-appserver generates a lot of generic services on top of your database and it is easy to use them. However it is not recommended. Please take some time to think about the service architecture so that you put the right business logic at the right place and that you can reuse the services. Think about the granularity of the services because they have direct impact on the performance of your application.

Domain Model

Before you can Model your BPMs, Case Management Models and UIs, it is good to model the Domain Model. This is not the technical database model, but the Common Data Model that is used within the BPMs. In fact these are the business objects that the business knows.
It also important to model your database good, of course because this can have direct performance consequences.

Requirement Management

What the customer wants is not always (actually almost always) clear. In the beginning the high level requirements are clear and they are planned within the iterations. Then these requirements must be detailed out (and User Stories can be used to describe it). Also it is good practice to group these requirements so that they can be used for testing. This is a big job but must be done especially for large projects. Otherwise it will not be clear what is tested and what is actually finished.

Scrum Master

Sometime a customer has no experience with Agile way of working. In this case it is advised to consult a Scrum Master that can explain and guide the process.

Responsibilities

When responsibilities with its duties and rights are not clear, it is difficult to work. It must be clear who is responsble for architecture, quality, etc. Otherwise no one takes responsibilities and the project is doomed for failure.

I could also have mentioned risk management, but all these practices seem so evident, but are not in practice.