/
Reference Application Sprint - Iteration 0

Reference Application Sprint - Iteration 0

Owned by Darius Jazayeri
Last updated: Apr 02, 2013Version comment
4 min read

General Info

Topic:  EMR Reference Application - Getting Started

Type of Project (Spike, Sprint, Epic):  first sprint in the Reference Application epic

Lead (Product Owner):  @Darius Jazayeri

Developer Lead:  ???

Known Developers Assigned (amount of effort in hrs dedicated to this work if possible): 

  • Wyclif, Daniel

  • Pulkit

  • maybe +1 from TW-India

  • Breeze

  • Mario (? %)

  • Darius (50%)

Sprint Board: https://tickets.openmrs.org/secure/RapidBoard.jspa?rapidView=31

Source code at:

Date:  (tentative) 28.Mar.2013

Kickoff Video

How to Participate

Add your name to the list on this wiki page (with any comments about your availability). If you want to join after the sprint has started just join the IRC channel mentioned above and say hello.

Tasks To Be Completed Prior To Design

  • Plan how we want to set things up in CI

  • Decide what demo/staging servers we'll need

    • requisition them

Unknown macro: {composition-setup} cloak.toggle.type=wiki

Goals

Unknown macro: {toggle-cloak}

Need to know more about Goals ? Click here

Unknown macro: {cloak}

Goals: Must Have, Should Have, Could Have and Won’t Have

Must Have means we must have this as part of the solution. It is a requirement or we should rethink doing this work.  This is what we will deliver before the end of the work period this also doubles as our DOD “Definition Of Done”

Should have means we would be embarrassed not to have it. We could technically produce the solution without it but people would be surprised.

Could have means anything else we could do.  But this does not always mean low priority.  But our selection of which could haves to include or exclude (or deliver later).  Also is considered low hanging fruit (if we are in this code already for x reason wecan deliver  y with little or no extra effort) or can be items or ideas for this module that can be packaged for a later spike or sprint.

Won’t Have means this will not happen.  It might be technically impossible, a taboo for our organization or out of scope. It does not mean “might happen or would be nice”. 

Unknown macro: {cloak}

Must Have: 

  • [RA-3] A "Reference Application" distribution module for bundling modules

  • ci.openmrs.org has a "Reference Application" project

    • [RA-4] all modules bundled in the Reference Application project are in the test/deploy pipeline

    • [RA-5] a small number of scripted-browser smoke tests

    • reliable and trusted emails on every failure

  • the latest Reference Application distribution is deployed to a "latest" demo server on every passing commit to any related module

  • [RA-7] A login page

  • [RA-6] A home page that shows a list of apps

  • [RA-8] A "legacy OpenMRS" app (available from the home page) that takes you to the old UI

Should Have:

  • A "Register a Patient" app (available from the home page)

  • An "OpenMRS Reference Application UI Library" module to hold shared UI components. For now this should just hold common CSS.

  • Wiki page describing how to set up a dev environment to work on the Reference Application

Could Have:

  • Produce a downloadable artifact in bamboo on every successful/passing build

Won't have:

Design

Unknown macro: {toggle-cloak}

What should go into a Design ?  Click here for more information

Unknown macro: {cloak}

There should be multiple design meetings.  The first starts off with a small group working with the leader to determine the high level scope of the project and then to break down into smaller pieces to eventually place as tickets.  Once those meetings havehappened use of the community design meeting time should be used to refine the tickets and if possible assign them to who will be doing the work.
Risks (these should be resolved prior to or during the design meetings):

Enter anything that is still questionable or worrisome that has not been answered: (open issues, potential concerns) Once a decision is made make sure that a summarized answer is included.

Example: Q. How will we handle issues with conflicting userID’s?  A. All ID’s will have an added identifier that is unique.

Effort Accounted For: (At the end of the design call all tickets should have an estimated effort and that total should be balanced against the known available effort of the developers assigned) (Yes/No)

 If not in balance in favor of success why and the action plan for remaining items
via IRC on the [#openmrs|IRC:Home] channel on freenode.

Use this channel for ALL debugging and random questions having to do with the sprint. Please avoid direct messaging to personal contacts. If you have a question, someone else most likely does too, and our geographically distributed community benefitsfrom public group discussion.

Sprint Break down: If tickets have not already been laid out or explained this is a good place for this.

Unknown macro: {cloak}

Risks:

  • Need to have CI/CD expertise on-board before the sprint

  • Need (at least) one long-term-dedicated VM to deploy to from bamboo

Enter anything that is still questionable or worrisome that has not been answered: ?

Effort Accounted For: ?

Sprint Break down: ?

Kickoff Meeting

Kickoff meeting Date: TBD

Kickoff meeting recording:

(Meeting setup with known developers after the final design meeting, but prior to the start date):

During Project Notes


Notes (Click here to expand to Etherpad)





Post Project (Retrospective)


Retrospective (Click here to expand to Etherpad)







Resources

Additional Information: