rajen kumar wrote:one of the key approaches in agile is defining a sprint.
Let say the initial sprint which I had defined works fine, but once I move on to the next sprint i.e sprint 2, I realize there will be major changes in the design and development of existing modules that have been developed in sprint 1.
If I look back I see that It would have been better and more productive if I had taken both the sprints in one go which would have saved me design and development efforts.
So division of sprint is a challenge in itself.
I think agile is very hot now but I really doubt whether its methodology to go about(based on my limited knowledge of agile), a combination of waterfall and agile is something that makes more sense. Also then someone has to write a book on when to use agile and when to use waterfall :-)
rajen kumar wrote:
The refactoring part is something thats need to be understood and getting used to working in this mode.
Refactoring code is ok , but design is something I always hate to do.
And while using agile methodologies , waterfall approach is used in each iteration on a smaller scale.
Vyas Sanzgiri wrote:First let me clarify - I work in a manufacturing environment where the only thing that is constant is change. Agile here - does not work for me.
I have to change my design in between each sprint.
Projects are so short (sometimes not scoped) that I can't even define a sprint. If I try to imagine a sprint I would end up with useless code.
I work in Mfg so I know Kanban but in terms of software??
Would agile work for shirt projects weeks - 1 month??
rajen kumar wrote:Refactoring code is ok , but design is something I always hate to do.
Mary Poppendieck wrote:...the people in the lean product development space are moving in exactly the opposite
I think we are in danger of throwing the baby out with the bathwater here - there is a middle ground. ... Let's not get to the point where we allow for no learning at the front, however. There is a balance, and it will differ in various domains.
I'd be happier if the effort on producing bloated up-front system-level design (not architecture) was expended on better understanding of existing business rules, domain-level modeling, and transformation of needs into acceptance test specifications. Inability to communicate exactly what we should be building (and what we have!) is a far bigger crime in many places.
If I take architecture as a tool to manage risks the user stories should define how much architecture I need in a Sprint.