Today we held one more retrospective meeting. First we evaluated some action items from previous meeting:
| Practice | Result |
| Daily Code Demos: Each developer must spend ~15-30 minutes every day demonstrating his code to other developer. | Development teem liked this practice and decided to keep it forever. |
| Coding Deadline: Two days before Iteration end all user stories that are not completed excluded from the iteration delivery and moved to the next iteration. | Not sure whether it helped. Team decided to keep this practice for one more iteration to try. |
| Define Iteration scope and specs before iteration start. | Good practice that allows to start iteration right away. Decided to keep it. |
The major discussion topic on this meeting was the product quality. Sometimes testing is not started when required. For example, developer completes the feature on Monday, but testing starts on Thursday. The problem is in communication between development and testing teams. Two practices will be tried in the next iteration:
Developer/Tester team for user story. Each user story will have a pair of developer and tester. It will be known who is responsible for the user story testing and development and make it clear for all team members. It should help to discuss user story for interested parties.
Developer-to-QA demo. When developer completes the user story it should demonstrate the functionality to the tester right away. It will clearly identity the moment when implementation is done and help to identify initial most critical problems early. Also developer should demonstrate ready pieces of functionality during daily code demos (if he has something new to show).
Labels: retrospective
posted by Michael Dubakov @ 5:50 PM
4 Comments:
"Coding Deadline: Two days before Iteration end all user stories that are not completed excluded from the iteration delivery and moved to the next iteration."
It is the problem I've been puzzling about last several months. How to provide fully tested code at the end of iteration and to have no gaps in developers time.
I've thought about local code freeze at the end of iteration, this means that developers would spend half of their time for doing nothing during it(wait for QA to find smth).
Branching can solve it but it steals too much time (updating 2 branches when bugfixing, reconfiguring auto builds etc). In my case it is almost impossible - client insisted on 1 week iteration.
Would be grateful if you share your vision on this.
Konstantin Nosov
"Coding Deadline: Two days before Iteration end all user stories that are not completed excluded from the iteration delivery and moved to the next iteration."
It is the problem I've been puzzling about last several months. How to provide fully tested code at the end of iteration and to have no gaps in developers time.
I've thought about local code freeze at the end of iteration, this means that developers would spend half of their time for doing nothing during it(wait for QA to find smth).
Branching can solve it but it steals too much time (updating 2 branches when bugfixing, reconfiguring auto builds etc). In my case it is almost impossible - client insisted on 1 week iteration.
Would be grateful if you share your vision on this.
Konstantin Nosov
We discussed branches as well and team decided no-go with them. Code freeze helps a bit in 2 weeks iterations (did not resolve the problem completely, somehow it is hard to freeze the code :) However I think it will not work for 1 week iteration. Only automated acceptance tests may work in short iterations, for me it is a "must have" thing, otherwise 1 week iterations will not work at all.
You are right about automated acceptance tests. But it is too expensive - from my experience full manual regression testing takes less time then maintenance of automated acceptance tests unless the client is very professional in IT, knows what he needs (utopia) or the project is BOX (not my case).
Only solution I've found is treat 1 week iterations as subiterations (planning assignments etc), and make releases as short as possible to act as iterations. In other words planning aspects of agile term "iteration" are applied on 1-week iteration level, and consistency on release level.
Do not like it, but hav no better solution :)
Post a Comment
Links to this post:
Create a Link
<< Home