Project Management
Project Estimation & Control based on Use Cases
This week Sander Hoogendoorn (Cap Gemini) presented a seminar about “Estimation with Use Casesâ€. Generally, this seminar confirmed that the development method of AMIS, internally called the “Way We Work @AMIS†is still valid and up-to-date. However, there are some interesting things to learn from this seminar. The three most important ones are:
- define Smart Use Case diagrams before the Use Case documents
- use Smart Use Case stereotypes to objectify estimates
- do project iterations including customer acceptance
First a short comparison will be made between the development method of AMIS and the one presented by Sander. Second, three learning points will be described that lead to ideas to improve the “Way We Work @AMISâ€. (more…)
Agile software development, the principles. Principle 6: The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
Agile software development, the principles. Principle 6: The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
This is the sixth of 12 posts about the principles of agile software development. Purpose is to go back to the start of the agile manifesto (http://agilemanifesto.org/principles.html) and discuss the implementation of the 12 principles in real life software engineering. Goals of agility are to go deliver software of higher quality, faster, with a higher acceptance to end-users and able to follow the changing business requirements to strive for competitive advantage.
The question is: is this going to work in practice or is this only based on a nice marketing and sales story.
Principle 6: The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
The purpose of conversation/communication is to transfer a message form the sender to the recipient. In projects, conversation is either about the project process (plans, risk, approach etc) or project content (requirements). Getting your team members to understand the right More >
Agile software development, the principles. Principle 5: Build projects around motivated individuals.
Principle 5: Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
This is the fifth of 12 posts about the principles of agile software development. Purpose is to go back to the start of the agile manifesto (http://agilemanifesto.org/principles.html) and discuss the implementation of the 12 principles in real life software engineering. Goals of agility are to go deliver software of higher quality, faster, with a higher acceptance to end-users and able to follow the changing business requirements to strive for competitive advantage. The question is: is this going to work in practice or is this only based on a nice marketing and sales story.
Principle 5: Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. Motivation is such an obvious item in agile development that this is often overseen. Motivation has to be both in the field of the expertise of the developer and the developer must be motivated in applying agile methods. (more…)
Managing Java projects – A Contradiction?
We as project managers really loved managing projects using ‘conventional’ Oracle tools. Most of us actually started as software engineers in projects using these tools. We had experience, knew all the pitfalls and managed productive software development streets. Things our programmers developed were reusable and were repeated time after time. Estimating a project based on functional specs was a piece of cake. Account managers rightfully put their trust in us and our customers were never (well, almost never) disappointed (more…)
Agile software development, the principles. Principle 4: Business people and developers must work together daily throughout the project.
This is the fourth of 12 posts about the principles of agile software development. Purpose is to go back to the start of the agile manifesto (http://agilemanifesto.org/principles.html) and discuss the implementation of the 12 principles in real life software engineering. Goals of agility are to go deliver software of higher quality, faster, with a higher acceptance to end-users and able to follow the changing business requirements to strive for competitive advantage.
The question is: is this going to work in practice or is this only based on a nice marketing and sales story.
Principle 4: Business people and developers must work together daily throughout the project.
Strange, shouldn’t this be common practice? In my daily work I meet lots of developers that have never had any contact with business people. The only notice of the business they get is the constant feed of PowerPoint presentations. When they are lucky the presentations contain hard to understand schemas, “roadmaps” and high level (or extremely detailed) business requirements.
This 4th principle tries to overcome the communication and cultural differences between ICT and business. It recognizes that there More >
Agile software development, the principles. Principle 3: Deliver working software frequently
This is the third of 12 posts about the principles of agile software development. Purpose is to go back to the start of the agile manifesto (http://agilemanifesto.org/principles.html) and discuss the implementation of the 12 principles in real life software engineering. Goals of agility are to go deliver software of higher quality, faster, with a higher acceptance to end-users and able to follow the changing business requirements to strive for competitive advantage.
The question is: is this going to work in practice or is this only based on a nice marketing and sales story.
Principle 3: Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
Old school linear development methods rely upon the assumption that an extensive specifications and design phase upfront will resolve all uncertainties and specify of all possible functionality in depth. After the design phase the development team retreat to their software factory to deliver the desired software in one big bang (in many cases many months or even more than a year later).
The result of this linear approach is a system; of witch the customer thought More >
Recent Comments