Activity Team/Development Sprint

< Activity Team
Revision as of 09:41, 23 February 2009 by Mchua (talk | contribs) (New page: {{draft}} == Introduction == This is a (under-development) plan for a 4-week Activity devlopment cycle using a deployment with liasons and a remote/distributed development team. The end ...)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Pencil.png NOTICE:  This page is a draft in active flux...
Please contribute to these contents and discuss issues on the discussion page.


Introduction

This is a (under-development) plan for a 4-week Activity devlopment cycle using a deployment with liasons and a remote/distributed development team. The end product will be a tested and deployed curricular unit based around a Sugar Activity (or Activities), with supporting materials/webpages and Activities developed as needed.

We're currently in planning stages getting all the teams involved together, and should kick off with a deployment in the Philippines sometime in March 2009. This page will change regularly; add it to your watchlist and stay tuned if you're interested.

Development schedule

The schedule is based on weekly cycles, with a meeting between deployment and development teams at the start of each week, and an email check-in at the end.

Week 1: Requirements and design

Meeting: Kickoff, have a big chat with teachers and developers where the teachers drive the meeting and talk about what they're trying to teach, what their goals and constraints are; engineers and designers ask questions and try to come up with requirements.

Then go off for a frantic week of prototyping and brainstorming multiple implementation ideas, designers storyboard a lot, make some template games (likely with ugly code and graphics)

Week 2: single prototype refinement

Meeting: Teachers give feedback on the multiple designs, and pick one, describing how they'd see the Activities used in their classrooms.

The week is spent coding the backbone of the Activity, and that's when the artists start doing their work on the actual game graphics, and the content writers / curriculum folks start writing actual lesson plans.

Week 3: student alpha testing

Meeting: introduce the students to the development team. The students are facilitated by the teachers and by local techies who know about software user testing.

Their feedback is now what the devs are iterating on for this week of development (hopefully with multiple brief testing sessions and meetups throughout the week, in addition to the major "here's how to test" intro meeting of the week).

Note that the students enter the picture halfway through this cycle because we're assuming we're working with young children - 7 and below. Older students, or students with teachers willing to facilitate and guide their feedback, can participate in the entire cycle.

Week 4: code freeze and first deployment

Folks on the ground deploy, developers sit back and work on documentation of the project so that others can use what they've built.

Afterwards

Then broadcast everything in a nice written-up package to the rest of the world.

We're done.