CCHIT MU 2011 Project

2011 Objectives

Project Management

• CCHIT MU Sprint Tracking

Project References and Rules

1. Tony McCormick is the designated project manager.
2. We will be using a modified version of SCRUM Agile Development to manage this effort. Modifications are based on EVO and are related to the geographically and timezone distribution which makes whole team/daily SCRUM hard to do.
   • We will use a weekly update meeting which will be held on Mondays at 6:30pm PST, 9:30 EST, 8 AM Tuesday in India.
   • The iteration for a SPRINT will be bi-weekly instead of the monthly standard to promote more adaptive development.
   • The artifacts (backlog, burnlog, SPRINTs etc.) will be posted here on the wiki, daily by the team leader
3. All work will be based on the OpenEMR development tip and merges from the tip will occur prior to the delivery of each iteration
   • SVN Owner can do a regular review based on volume and report weekly
   • Team decide based on complexity
4. Major functional releases will be posted and available to the public for review, testing and comment at least monthly
5. Each unit of work product will have it's own wiki page and discussion about the work will happen on the 'discussion' tab, all comments must be signed using the 'signature/time stamp button' as in: --Tony - www.mi-squared.com 00:36, 30 November 2009 (UTC)
6. The SourceForge.net forums should be used to get community feedback on all design choices.
7. Design guidelines should be followed where they exist, use the best-of OpenEMR currently when they don't. :-)
8. Coding guidelines should be followed where they exist, use of generally accepted good coding practices where they don't.

The following are some general practices of Scrum:

• Customers become a part of the development team (i.e., the customer must be genuinely interested in the output).
• Scrum has frequent intermediate deliveries with working functionality, like all other forms of agile software processes. This enables the customer to get working software earlier and enables the project to change its requirements according to changing needs.
• Frequent risk and mitigation plans are developed by the development team itself—risk mitigation, monitoring and management (risk analysis) occurs at every stage and with commitment.
• Transparency in planning and module development—let everyone know who is accountable for what and by when.
• Frequent stakeholder meetings to monitor progress—balanced dashboard updates (delivery, customer, employee, process, stakeholders)
• There should be an advance warning mechanism, i.e., visibility to potential slippage or deviation ahead of time.
• No problems are swept under the carpet. No one is penalized for recognizing or describing any unforeseen problem.
• Workplaces and working hours must be energized—“Working more hours” does not necessarily mean “producing more output.”