Both agile and waterfall projects can be iterative… we can call it either sprint or iteration or release…
If you take a look at any commercial software product or system, you will find all of them offer a set of features to its users. And all of offered features are implemented by many components. In development process, these features could be documented in the form of “Use Case” in UML terminology or “User Story” in agile terminology. The components could be as big as a sub-system or as small as a member (property, method or event) in a class.
If you look at a completed system, you can map up a metrics between features and components the relationship between them are many-to-many. It does not matter if it is developed using Waterfall or Agile methodology. The end point is the same, all features are implemented, all complements are completed. The difference is how we reach to the end point. It is not true to say “in Agile methodologies people do not do design.” They do, they do design all the time. A more accurate statement for agile methodology is “they modify design all the time”
Among many other differences, the fundamental difference between agile and water fall is that Agile is feature based, water fall is component based.
When it is feature based, we will touch related components in the code many times as new features are put into development. In each iteration the features are completed but the components are not. You can demonstrate the completed features at end of each iteration.
When it is component based, we will touch related features many times as new components are put into development. In each iteration, the components get completed, but the features are not. You can demonstrate the new features when all needed components for these features are completed.
The good point about the water fall is that we do not need to refactor the code many times. Once the component is completed, it is completed. However, you only can show or demonstrate a user oriented feature for your customer when all involved components are completed. In most of case, it is close to very end of development phase.
The good point about agile is that you can show or demonstrate user oriented features for your customer at end of each iteration. However, when new features been put in development, these components participated in the feature you have showed your customer might need to be “changed”, in agile terminology, “refactored”.
If you are doing water fall, you want implement checks and reviews to ensure the correctness and completeness of you design. Hence the deliverables of the design phase must be materialized and verified. In most of case, UML are used in those design artifacts. On the other end, since you only touch each component once, repeatable automatic unit test is less valuable as comparing to these in agile methodology.
If you are doing Agile, in each iteration, features are put in design and development, as the result of it, new components are added to the system, and existing components are modified (refactored). To ensure that when new features are added to the system, the existing features are still working; people implement continuous integration, and automatic unit test to safeguard the system. However, due to the nature that we constantly modify our design when new features are been put in design and development, the effort spent on component design artifact may be seen to be less rewarding.
When you work on user story 1 you do not know user story 2 and you do not know the relationship between them. Maybe user store 2 is not written yet. If we treat user story as user case, it would be difficult to put together user case diagram or activity diagram because you do not have all use case document yet, you may not have the list yet.
The same is true for sequence diagram, as the user stories added to the system, class calling sequences are getting changed in each iteration,
In water fall mode, there are designers, there programmers, the designer put together design in writing; the programmers put the design in code…
In the agile mode, there is only one role, developers, the developer’s take the user story come out with some design and put that design into the code, with light in documentations and code comments.
I emphases the difference between agile and water fall as whether it is feature based or component based for the aspect of unit of work for developers. Surely enough there are many other aspect to distinguish. Another one is that with Agile methodology, people do design, but not necessary do design documentation.because the design getting changed every day as we refactored our code for every user story we worked on. a typical situation is that in agile projects, people spend more time in IDE(Integrated Development Environment), in water fall projects, people spend more time in Office product (word, Excel or Visio)
In conclusion: we need to define what are our deliverables based on the methodology we have chosen for a specific project. Fail in doing so; we may compromise the productivity of the team and quality of the finishing product. If you are doing waterfall (component based) development, you want to focus on design artifacts at the end of design phase. If you are doing Agile (feature based) development, you want to implement continuous integration, and automatic unit test to safeguard the system throughout the life time of the system.
No comments:
Post a Comment