Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 10 Next »

The OpenMRS core development team uses the a semi agile sprinting mechanism for getting features written in a coordinated fashion. This allows new features to move forward at a quick pace. It also distributes the knowledge of different features to a wider audience.

Anyone interested in joining a sprint should let either the sprint lead know or just send a general request to be on one to the dev list.

Sprint Details

  • Sprints are focused on one topic, and are usually 2 weeks long
    • some could be 1 or 3 weeks long as appropriate for the topic at hand
  • Each sprint should include 2+ OpenMRS developers. We may occasionally have multiple sprints going simultaneously
    • not everyone needs to be assigned to every topic.
  • We will schedule and publicize Sprint topics ~4 weeks in advance
    • this will give developers at other organizations a chance to organize their time to participate
  • Sprints should always have a release in JIRA, unless they're around a core topic like "work on 1.9 tickets", in which case we'll use a "label" in JIRA.
    • Tickets in the release should be partially organized one week before the sprint.
    • They must be finalized by the day before the sprint. (The scope and tickets are locked-down once the sprint begins.)
  • Each Sprint has a leader, who is in charge of the ticket list, and can help assign tickets to participating developers.
  • All developers working on a Sprint should be in a real-time group chat
    • We'll start by experimenting with Skype and a dedicated IRC channel
  • To keep improving, each sprint ends with a retrospective look at what did and did not work with the previous week.

Weekly Emails

You should expect to see an email from Ben and Darius every week which will:

  • (either) summarize the status of the current Sprint
  • (or) summarize the retrospective look at the last Sprint, and preview the next one
    • this includes highlighting the developers and organizations that are participating in the Sprint
  • give the calendar for upcoming Sprints

Designing a Sprint

These are required features that must be in place before a sprint can be started (or maybe even to just be scheduled)

  • Must have a leader assigned
  • Must have X tickets for the sprint designed, not just created
    • New developers should be able to pick up the ticket and know what needs to be done
  • Must have an outcome / release for the end of the sprint
  • Must have a sprint page created

Conventions During a Sprint

  • Do not spend a large amount of time designing out a feature (most things should be designed already though)
    • If you go more than 6 hours on a ticket/feature, bring it up to the group to make sure that its going in the right direction
  •  

Schedule of Sprints

2011

From

To

Topic

Leader

 

March 21

April 3

Reporting Module v0.6

?~mseaton

?see JIRA tickets

April 4

April 10

2.x Dashboard Fragments

?~darius

Learn the 2.x UI Framework by writing patient dashboard fragments

April 11

April 17

Bug fixes

TBD

Top-voted bug fixes, primarily from OpenMRS core/trunk

April 18

May 1

1.9 Feature: Web Services

TBD

Extending Web services

May 2

May 15

Bundled Module: XForms

TBD

 

May 16

May 29

1.9 Roadmap Features

 

Order Entry? Visits? Concept Mapping?  Multiple Providers?

Potential Sprints

  • 1.9 Feature / Module: Web Services
  • HTML Form Entry Module features
  • HTML Form Entry Module bug fixes
  • 1.9 Feature: Visits
  • 1.9 Feature: Order Entry
  • Module: Sync
  • Module: Logic
  • Module: XForms
  •  
  • No labels