Comentários (2)

1 DaliborStavek comentou às Link permanente

Hi Siddhartha, thanks for interesting and insightful article. I have 2 questions: 1) Testing in Agile - end-to-end rigorous system integration testing, performance testing, UAT - how to blend it with Agile Development methodology for big complex project in Banking industry for business critical client-facing systems like Online Banking? Do you do the testing once all the iterations are completed, so that you can test the whole system as well as all the integrations (ESB, Core Banking system..) or you do end-to-end System Integration Testing somehow within the iterations? (and I am not referring to the User testing as a quick way for the Product owner to see the application in early stages and give timely feedback) 2) Documentation - how do you handle documentation for such complex projects in order to ensure sustainability for the future operation, maintenance and development of the application? I have experience that even in water-fall, if the documentation is not properly handled, i.e. updated, then after few years nobody in the organization really knows how the application works, what are the different validations, business rules etc. and often it ends up with reverse engineering - so basically the value in terms of effort and time you save in quicker development, you loose by future problems. Any thoughts?

2 Martin Pain comentou às Link permanente

When trying to understand how people are describing their use of Agile, I always have a problem understanding the movement across two spectrums (which are highly related to each other):

1. The movement from "user story" to technical task (taking a problem/desire as a user would describe it, to a detailed understanding of the technical changes needed).
2. The movement from vague estimation (ROM), through more precise estimation, to finally knowing how long it took in the end.
My problem in how these two relate is this:
If you want to do accurate planning up-front, you need to get your estimation to a decent level of accuracy. To do this, you need to know more about how to solve the user problems. And this produces more up-front work. The more up-front work you have, the more it starts to look like waterfall, as you've got a period of time where you're doing this up-front work (possibly considering all the potential features for the project/product, as you haven't done release planning yet) before the "hand-off" to development (at which point the iterating starts).
This could be summarised as having moved along the first spectrum too early (in some people's opinions).
The opposite of this is to decide not to go into much detail at all as to the technical solution before the development iterations start, but this means you also can't estimate accurately, so this won't work with fixed deadlines. I expect people who would suggest being closer to this extreme would say that as you go through the development iterations you always learn things that will affect your estimations (and therefore your release planning), so you always need to expect either the release date or the scope to change (or the quality, which will take the hit if neither of the other change) so they would suggest that you might as well "embrace the change" and not put much effort into the up-front planning.
I need to learn more about why larger teams who are using some form of Agile don't consider this "up-front" work to be pushing them back towards waterfall (or why that's not a problem & doesn't counteract any benefit of Agile), and also more about how late those in smaller Agile teams really push their technical design work, etc (the things that would affect the estimates) and how much value they actually place on estimation. Personally I struggle to reconcile Agile with estimation - they seem to be fighting against each other as to how early you get down into details.