If you want to buy the project management book mail
[email protected] for
more details or call any of our book shops MUMBAI-22078296/97/022-22070989,
KOLKATA-22826518/19 HYDERABAD-24756967,24756400,BANGALORE-25587923,
25584641,AHMEDABAD-26421611,BHATINA(PUNJAB)-2237387,CHENNAI-28410796,28550491,DELHI/NEWDELHI-23254990/91,23325760,26415092,24691288.If
you want to write to the author directly email at
[email protected]
Agile modeling defines set of practices which can show us the way towards becoming successful Agile modelers. These practices are divided in to two sections one the “Core Principles” and other “Supplementary Principles”. Below figure ‘Agile Model Principles’ shows the same in a pictorial format.
Figure: - Agile Model Principles
Let’s understand one by one what those principles mean.
Core Principles
Simplicity: - Do not make complex model keep it simple. When you can explain your team with a pen and paper do not complex it by using modeling tool like rational rose. Do not add complexity to show off something. If the developer understands only flow chart then explain him with a flow chart, if he understand pseudo-code then use pseudo-code and so on. So look at your team what they understand and prepare document in a similar fashion.
Welcome Change: - Requirements grow with time. Users can change the requirements as the project moves ahead. In traditional development cycle you will always hear the word “Freeze the requirement”, this has changed with Agile coming in. In Agile we welcome change and the same is reflected in the project.
Incrementally change: - Nothing can be right at the first place itself. You can categorize your development with “The most required”, “Needed features” and “Luxury features”. In the first phase try to deliver the “The most required” and then incrementally deliver the other features.
Model exists with a purpose: - Model should exist for a purpose and not for the sake of just existing. We should know who our target audience for whom the model is made. For instance if you are making a technical documents it’s for the developers, a power point presentation it’s for the top management and so on. If the model does not have target audience then it should not exist probably. In short “just deliver enough and not more”.
It should be light: - Any document or artifact you create should be also updated over a period of time. So if you make 10 documents then you should note that as the source code changes you also need to update those documents. So make it light as possible. For instance if your technical document is made of all diagrams existing in UML, it becomes important to update all diagrams over a period of time, which is again a pain. So keep it light weight make a simple technical document and update the same when you have logical ends in the project, rather than updating it periodically.
Keep multiple models: - Project issues vary from project to project and the same project behavior can vary from organization to organization. So do not think one model can solve all issues keep yourself flexible and think about multiple models. Depending on situation apply the model. For instance if you are using UML for technical documentation then every diagram in UML can reflect the same aspects in different way. For instance a class diagram shows the static view of project while a flow chart a dynamic view. So keep yourself flexible by using different diagrams and see which best fits your project or the scenario.
Software is the most important thing:- The main goal of a software project is to produce high quality software which can be utilized by your end customer in a effective manner. Many projects end up with bulky documents and management artifacts. Documentation is for the software and not software for the documentation. So any document or activity which does not add value to the project should be questioned and validated.
Get Rapid and regular feedbacks: - Software is finally made for the user. So try to get feedback on regular basis from the end user. Do not work in isolation involve the end user. Work closely with the end customer, get feedback, analyze requirements and try to meet there need.
Supplementary principles
Content is important than presentation: - The look and feel is not important rather the content or the message to be delivered by the content is important. For instance you can represent project architecture using complex UML diagrams, simple flow chart or by using simple text. It will look fancy that you can draw complex UML diagrams but if the end developer does not understand UML then it ends no where. A simple textual explanation could have met the requirement for communicating your architecture to the end developer / programmer.
Honest and open communication: - Take suggestion, be honest and keep your mind open to new model. Be frank with the top management if your project is behind schedule. An open and free environment in project keeps resources motivated and the project healthy.