Ideas on Enterprise Information Systems Development

This blog is devoted to ideas on Enterprise Information Systems (EIS) development. It focuses on Lean Thinking, Agile Methods, and Free/Open Source Software, as means of improving EIS development and evolution, under a more practical than academical view. You may find here a lot of "thinking aloud" material, sometimes without scientific treatment... don't worry, this is a blog!
Every post is marked with at least one of Product or Process labels, meaning that they are related to execution techniques (programming and testing) or management techniques (planning and monitoring), respectively.

Saturday, September 11, 2010

Why Agile for EIS? - Part II

In the previous post my arguments were a bit intimate - yes, I was called "too nerd"/"too academic"/"too non-real-world" when started using object oriented programming, then free software, then open source ERP, and now Agile methods in EIS.

Now I am going to use more technical arguments (or questions to make you think) in favor of Agile Methods:
1) What guarantees that your code is working well and according to client's requirements when your Quality techniques are based on filling a lot of forms? Filling a form makes the code correct?

2) Do you really need to keep all your models always in synch with code, even if nobody is using these models? Have you ever heard of Reverse Engineering?

3) Do you know that putting a Quality Team to test software after it is "finished" is called "Quality Control"? And do you know that people in (tangible goods) industry know for decades that this is not the better way of assuring quality, because you are going to waste time and money correcting things that should have been corrected steps ago (and you have already consumed resources without aggregating value to the product) ?

4) Do you believe that the better way of checking if a requirement is "finished" (and thus can be delivered to the customer) is by hand, reading a document? Have you ever heard of automatizing acceptance tests?

5) Do you think that the better way of keeping track of changes in you code base is by filling forms? What guarantees that the person that checked the change worked properly?

6) Do you really believe that a lot of internal documents, used only by the development team (to check things that should have been checked automatically), will aggregate value to the user?

Finally, here goes some challenges (related to the process, not the product, like the previous ones):
a) Show me where PMBoK says that you must fill all those documents of each knowledge area to have a successful project.

b) Tell me how can you use metrics such as Use Case Points in an (really) Iterative & Incremental project (remember that real I&I cycles only details Use Cases when needed, so how are you going to count the number of steps for every use case and then get a "precise" effort estimation?).

No comments:

Post a Comment