January 4, 2013
As we work to organize & improve the development work we are doing for OpenMRS, we’re starting to use (and sometimes misuse) a growing list of terminology. I thought I’d dump them out here (to get them out of my head, to be able to come back & look at them, and maybe to get comments from folks on what we’ve got wrong). Many of these are drawn from our (growing) experience with agile methodology. Since I’m not taking the time to look up “official” definitions, I’m sure these are imprecise and I wouldn’t be surprised to learn that we’re doing what others were doing 10 years ago. 🙂
What gets done:
- Ticket/Issue – a description of work to be done
- Story – a specific use case to drive development, preferably with acceptance criteria; often generates multiple tickets.
- Epoch – a feature, task, or other request that goes beyond a single use case; usually generates multiple stories.
- Theme – a feature or idea that may cut across multiple epochs/stories and/or help group them meaningfully
- Project – a well-defined target (often based on 1-to-n epoch(s) or theme(s) that could takes weeks, months, or more to accomplish.
How it gets done:
- Sprint – a product owner, dev lead, and at least 2 other devs working through a collection of stories/tickets to meat goals primarily defined by the product owner (usually ~2 weeks-ish)
- Spike – a single dev (or two pair programming) working on something for usually no more than 1-3 days either as a proof of concept that might be thrown out or as a straw man to work out design issues and/or blockers before more work is done
- Paired programming – 2 devs working on the same thing together; one coding and the other watching at any given time.
- Community Development – a group of devs working on highly voted bugs and “keeping the lights on” (answering questions, ensuring new devs have a good experience, tending to lists/answers/wiki, grabbing tickets that might be otherwise delayed or falling through the cracks, …). OpenMRS has committed to having one core dev available at all times to help lead/coordinate this effort.
- Internships – Google Summer of Code or other opportunities where a student works on a project under mentorship.
- Assignment – (I just made this one up) a task assigned to a 1-2 developers that may take days or weeks to accomplish – i.e., the “old school” non-agile approach to getting work done.
Who does the work:
- Community Developers – volunteers or people working on projects that want/need to get some OpenMRS coding done.
- Implementation Developers – developers working, at least in part, to develop & maintain solutions for implementations using OpenMRS.
- Core Developer – developers spending 100% (or very close to 100%) of their time focused on OpenMRS programming.
Thoughts or comments are welcome.