Practice Array Web Process

1. Practice Array Web Process By Shengli Hu

5. Wads Practice 1 • review wads everyday morning. • mail assignment everyday. • keep the status of wads reflect the real circumstance • no real time, no status. • no monitor and control, no process. • code review, no detail, no quality.(new guys)‏ • have people take his own responsibility.

6. Wads Practice 2 • wads entry is work story, driver is a writer. • wads should cover all information what required for the bug. and how driver make use of that. • Array Web, for whole view, for communication. • dispatch meeting • play multi-role.

9. Detail process (draft)‏

10. 1 Get Tasts • 1.check our maillist to collect the tasks; • 2.Ask Customer for tasks • 3.Check wads to see what new wads added. • 4.analyze the tasks then assign to some one for triage

11. 2 Triage • 1.check out the wads of the bug if have, update the wads,if none,create the wads for it. • 2.prepare the environment and resource then reproduce the bug; • 3.if the bug reproduced, diagnose the problem and append some suggestion about solving the problem. if can not be reproduced, mail the cause to customer or ask customer for help.

12. 3 Dispatch • 1.Category the bug and dispatch to the proper engineer; • 2.According to complex of the tasks and the skill of the engineer, assign special rider for the driver in interaction stage. (by email to dispatch)( see work for **-*-*)‏

13. 4 Solve • 1.check out the right code branch as the requirement of the wads. • 2.verify the debug environment and resource. • 3.if any internal technical problem, find rider or other team member to help. if customer help is needed, after discussing with rider or dispatcher, send mail to customer; • 4.after the problem fixed, have a function test and smoke test for it. • 5.make a closure and checkin the wads

14. 5 Internal Review and Wads Audit • 1.when receiving the notification of closure email,the rider or dispatch make interview with the bug and updated the auditor of wads closure. • 2.the rider or dispatcher add audit dispatchevent and set the status to “On-hold” and awaiting for customer review

15. 6 Review Upload • 1. after audit by rider or dispatcher, run “ccollab addcvsdiffs * *” command upload the diff of the bug. • 2. put the closure information and choose the right reviewer then begin customer review. • 3. login the bugtrack, modify the user to “array_on_hold”. and comment to “awaiting for ** review”.

16. 7 CVS CheckIn • 1. after receiving the review from customer or cc system. checking the version and check in the files updated if review passed. if review failed, assign the driver engineer to fix again. • 2. when checking in the files updated, write the log of “Bug ID” and “Change description”.

17. 8 Bugtrack and wads Update • 1.after check in the files updated, update the bugtrack by assigning the user to “array” ,updating the status to “resolved” and filling the resolution comment and resolution type. • 2.set wads close event and the reason.

18. 9 Internal Help • 1.Technical problem • 2.Internal resource problem

19. 10 Customer Help • 1.can not reproduce; • 2.get more resource and detailed information; • 3.needed to be verified

20. 11 Process Monitor • 1.the problem can not be fixed by one person for long time • 2.less work load • 3.resource can not be solved for long time • 4.the problem has not been responded for long time. • 5.Wads standard check.

21. Q&A

22. Thanks!