1) PM of each team need to write a blog, sharing the spec of your most important/challenging feature (deadline: 12th week)
2) Tester of each team need to share out your test plan to the world, in your team blog. (deadline: 13th week)
3) You had borrowed books to read, now please return them. make sure you write a blog about them first. (deadline: 13th week)
4) Code Complete: after 10 day scrum, each team should reach code complete. Which means your product is ready to be tested! (13th week) please write a blog about it.
5) Bug bash, to make sure we have thorough coverage of testing and fun, we will do a bug bash (小强大扫除).
a. Team 1 will test team 2’s product
b. Team 2 will test team 3’s
c. Team 3 … 4
d. Team 4 will test team 1’s product
Time: 3 days.
Each team should make their product/site ready for testing before 11/23 noon.
Score: the team logging most bugs will win.
Please read <移山之道>, my blog, or other doc for the guidelines of open a good quality bug.
| For bug bash, a bug must meet the following criteria: 1) A subject started with “Bug Bash: …” the subject should summarize the problem. 2) In the body of the bug, report your “steps of reproducing the bug”, a short form is “repro:” 3) then report what do you expect. Start with “expect:” 4) Then report what happened, start with “result: “ If your bug doesn’t meet such criteria, it will not be counted as a “bug bash” bug. |
6) ZBB
After you get so many bugs from bug bash, you should be very happy… now you need to reach a state of “0 bug”.
Please triage all the bugs, all team members look at each bug and decide one of the following:
Must fix (P1)
Important to fix (P2)
Nice to have (P3)
Won’t fix (for many reasons)
You will use the next several days to fix ALL bugs, and get to 0, then you can have a Zero Bug Build, your product in this build is called Release Candidate 1 (RC1), you then test it to make sure it’s great, if not, you fix more bugs, and have a RC2, RC3, etc.
When you’re sure you got a good enough product, you will turn the RC into a real release.
7) Release
In this stage, You will be able to release the product (internally or externally).
You need to write a blog about your release, and let your target users know about your product.
Post your app to marketplace/download site for download
8) Postmortem and Beta Stage Team Contribution Score
a. Your team should organize a POSTMORTEM (template) to go over team’s beta stage, and post the result in your blog (deadline: 12/14 noon).
b. Use similar rules, calculate the team contribution score of each team member in beta stage.
Besides the standard template for Postmortem, each team should also report the following:
1. 每个成员在beta 阶段的实践和alpha 阶段有何改进?
2. 列出每个人具体的改进。
3. 团队在beta 阶段吸取了那些alpha 阶段的经验教训?
4. 3. 12 条敏捷开发的原则中, 团队做得最好和最不好的各列举 2 点。
http://www.cnblogs.com/xinz/archive/2010/12/11/1902849.html
http://www.cnblogs.com/xinz/archive/2010/12/10/1902725.html
http://martinfowler.com/articles/newMethodology.html
5. 对照 The Cathedral and the Bazaar (大教堂和集市), 软件团队的模式 (link) 你的团队开发模式是哪一种, 优势/劣势在哪里?
http://en.wikipedia.org/wiki/The_Cathedral_and_the_Bazaar
http://www.catb.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/ar01s13.html
9) Final review (16th week)
a. TA will book a room for students + reviwers.
b. each team need to have app, video recording, spec, etc. ready.
c. each team should have real user’s feedback to show how good your product is.