Agile Methodologies the “Nirvana” of an SOA
6 July 2011 2 Comments
How many of you know the development of an SOA requires lead times ranging from 2 to 5 years, this is because systems need to convert everyone here who maybe are already in use uniformali at the company and under a single structure which is precisely the SOA.
This brings the company to support many high costs that have been be repaid by the same SOA in terms of ROI or the project would fail. To do this you need so that applications that make Our SOA are immediately available in order to have the first economic returns immediately. One of the methodologies that I consider more valuable to achieve this
Agile methodologies are the goal, the choice of using a methodology Agile falls mainly in ways of working that accompany these methodologies.
Two things in particular I find very interesting:
- The Continuous Integration
- Test Driven Definition
Only these points are certainly very limiting for the choice of a management methodology over another, but if we go to agile methodologies to analyze lunge find many points that
make, in my opinion, better than a classical technique project management.
In particular, the management of a project “Agile” expects meetings day of no more than 15 minutes in front of the dashboard activities, now that many more may be an unnecessary waste of time reality is revealed in all its importance as soon as a member of the group encounters an unexpected obstacle. Now project managers can say that pure must be the resource raise the issue, which is true even in agile methods, the
difference is that they speak together, this means that the problem can be solved directly by another colleague who has encountered the same problem or similar in other areas
allowing to solve the problem quickly without necessarily need to move a resource from a task to solve the problem.
How many of you have already experienced one of the worst that can happen to a programmer is going to change careers an activity that even if connected to another is still different from what you are doing which necessarily implies a time “Adaptation” to new activities, this is normal in the methodologies Project Management is not allowed in classical Agile methodologies.
So let’s see what it takes to manage an Agile project and what is useful in an SOA.
Characteristics of an Agile project
Let us now describe what and how a project is composed Agilewith particular reference to Scrum.
The roles that characterize the Scrum methodology are 3:
- Product Owner
- Scrum Master
There are also 3 artefacts:
- Product Backlog
- Sprint Backlog
- Burn down chart
And finally 4 ceremonies:
- Sprint Planning
- Daily Scrum
- Sprint Review
I do not want to disclose too much about how an Agile methodology, but I want to step on some points that I consider important for management of an SOA.
One of the highlights is the Daily Scrum, this is a time when the whole team meets to coordinate work and manage the risks pointing out any obstacles during the Daily Scrum, which lasts maximum of 15 minutes are usually 3 questions addressed to each member of the Group:
- What did you do yesterday?
- What will you do today?
- What obstacles you encountered?
This is used to update the Burn Down Chart, ie the graph shows the evolution of the group in terms of Sprint, ie deliveries.
One of the focal points that makes me choose it are the Scrum Sprint In fact, each sprint is releasing a new feature and consequently a brick that goes to build our SOA.
These “bricks” and then allow to begin to use immediately SOA enabling you to have in terms of economic returns short.
These returns are used to increase the ROI of SOA, enabling then the same as “self-financing” thus making it less consideration of the development itself.
The development of an SOA is always a very complex operation, next are flanked by technical problems and project management problems management.
For the success of the project and the success of a SOA is in fact there must be an immediate payback that to increase ROI and justify the choice of Architectural.
One of my favorite methods for this are those Agile and Scrum particular, because this allows me to have returns immediate on what done and what has yet to be done, allowing
then decide what to develop and when to achieve the goals set by the SOA.