From CitconWiki
Jump to: navigation, search

the team should have the responsibility to decide when the product is done

gilles mantel: for each user story consider "done" if all corresponding source code is in configuration management and the user story is deployed on acceptance platform and corresponding business model is captured in the wiki (whatever format) and at least 80% code coverage by unit tests with tools.

making all requirements measurable and see if everything is testable and; fully acceptance tested and released.

electric cloud ("eat our own dog food") - the skunk goes on your desk if you break the build and fail to follow the right process. pre-commit automated test. whem we release the product and number of open bugs and severity, do they have high likelyhood to manifest ; known defects.

user stories validated; but integration phase on the end. if integration is challenge then switch to feature-oriented teams. painful at first (esp with legacy) but pays off on the end.

AM talked about a model where off-shore partners got integrated better: - getting key off-shore people to come by and work onsite, - send on-site people off-shore to work - video conferencing, pairing over webex to promote pairing and better work integration

AM: It was considered done when the team shows it to the customer. The team and the customer need to agree that the spirit of the story is complete. initially agree at the beginning of an iteration (examples), not a contract, just what people currently think. This gets reviewed regularly (after each story is implemented).

Done might have a different meaning for projects which are already in maintenance. Late in the project, you also need to tell operators what's changed etc.

AM: when it feels right for everybody that matters

the important thing is that we had a discussion to have an understanding what a done is; checklist is there just to have a discussion.

if your customer thinks that the project can be shipped now.

Some additional notes (by cirilo)

1.when the project manager says? pro's knows all the ins and outs + stakeholders knows the business value of shipping (missing out on marketing moments etc..) con's: everyone should be aware of release moments, it can not be a surprise (entire team should push forward to that moment).

2.What would be the definition of done from a testers point of view (if it was up to him)? user story is deployed on the acceptance server documentation is place 80% unit tested functionally tested manuals tested (rollout scripts) “when we ship the product” quality indicators (nr of open bugs, severity, likelyhood of occurence, after the integration phase is done (big difficult integrated systems) lowest level services should be delivered early or slice it up in a more suitable steps feature teams for different levels of services whenever a test passes (each story has a full test in advance bdd

3. what metrix can be used? - sustainable pace by clean code/code coverage/complexity

4.when is done (personally done) when is my task done as a person. fear/confidence is the driver unit tests are not good/understandable to communicate Defining “done” criteria in advance (can depend on the situation).

writing tests with the product owner/or him participating in writing/validating them The collaboration is key to understand each other

additional criteria: not just automated tests, also exploratory testing/user testing/user experience/ performance level of involvement Functional done over business value (need to be ahead of competitors). state of the art/versus $$$ When it feels right! Both personal and depending on the business

Statement by Jtf (outside the session): When real users are using the software.