![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
shadowspar) wrote in ![[community profile]](https://www.dreamwidth.org/img/silk/identity/community.png){kind=small}
growstuff2012-08-02 03:24 am
Proposed development process
So, the previous post outlined the philosophy and reasoning behind agile development as a whole. Now, we need to decide what we want our specific agile development process to look like.
Before I lay this all out, bear in mind, this is the proposed development process. Nothing is ever written in stone, and we really want feedback on what could be better, especially now!
Infrastructure: We've set up the Growstuff project repository on github as a place to host some of the project infrastructure, like the issue tracker and project wiki. The plan is to use the issue tracker to keep track of both bugs and user stories (proposed features), and the wiki for documentation and resources. (The wiki seems to support different formats, but so far we've been using markdown -- here's a cheat sheet.)
Iterations: What we're thinking of is a development cycle based upon 3-week iterations, with iterations starting and ending mid-week, probably on Wednesdays.
An iteration would go something like this:
- Start: On the first day of the iteration (Wednesday), the coach(es) for that iteration kick off the planning process on the mailing list.
- Planning: We have about three days to write user stories and decide which of them are most important to finish next. By Friday or Saturday, we should have a consensus and have pretty well squared away what we'll be working on.
- Doing: The body of the iteration gives us about 2 clear weeks to work on implementing stories.
- Integration: Around Sunday of the last week, we start rounding everything up, make sure it's all integrated, and merge the work into the milestone branch.
- Release: Tuesday or Wednesday, the milestone branch gets pushed to our test environment, and the previous branch from the test environment goes to production.
- Retrospective: Around this time, the the coach(es) kick off a discussion on the mailing list about how the iteration went. What worked well? What didn't? What new things have we learned?
- Next iteration: We integrate the feedback from the retrospective into the planning stage of the next iteration, and the cycle begins again.
If someone comes along mid-iteration and wants to get involved, they can either a) watch what's happening 'til the cycle turns, b) pair with someone who's already working on something, or c) if they can find someone to pair with them, they may pick up a small task.
Current outlook and schedule:
As it stands, here is our proposed schedule:
- Right now, we're kind of in an "Iteration pre-0" state where we're try to get the project and infrastructure organized.
- Iteration 0 kicks off Wed, 8 Aug. If we can get something built, that'd be great, but really the goal for Iteration 0 is to square away our development process and get everybody on board.
- Iteration 1 kicks off Wed, 29 Aug. Hopefully, by the time this rolls around, we'll be ready to start drafting the first few stories and getting concrete things done!
Is this something that sounds workable and that you'd sign on to? What would you change? Anything that's been left out or doesn't make sense?
no subject
Notes on the post itself:
- integration: of course we should be doing continuous integration, so the end-of-cycle bit is more about merging any branches that haven't been and double-checking everything.
- coaches: I'd like to have paired coaches on each iteration, and I've asked
- iteration 0: I suspect that that first iteration will have one user story, something like, "When I visit growstuff.org I see our website." Figuring out *how* to do that (deployment process, etc) will take most of our effort. That -- and trying out the process for the first time -- is why it's iteration 0.
- estimation: in the github issue tracker, I've set up labels marked "effort: small", "effort: medium" and "effort: large". We'll label stories according to these, based on our estimate of how much work they'll take to complete. At the end of an iteration, when we go to look at how much we finished, we'll assign small = 1, medium = 2, large = 5 and count up the resulting sum. That will give us our "velocity" -- perhaps, say, 15 points -- which we can use as a rough guide to how much is reasonable to take on for the next iteration.
no subject
Has anyone yet figured out how to watch a page on the Github wiki? Grumpy old me still prefers MediaWiki.
Your comment about people arriving mid-iteration implies things about required commitment, people finishing bigger stories, etc. How do you see all of that working?
no subject
What have your experiences been like using Github issues/wiki for AO3? You sound less than delighted so I presume it doesn't do everything you'd like? I'd love to hear about it, since so far we haven't found anyone working on a comparable project who's had relevant experience to share.
With regard to commitment, XP suggests that no story should be larger than can be completed in one iteration (3 weeks). If it's larger, then you split it. That means that if someone wants to take on a large (by our standards) task, they're only signing on for 3 weeks, and after that they can back out if they don't want to keep going. Continuous integration and making sure that we have a working feature at the end of each iteration means that we shouldn't get ourselves into that situation where someone bites off a task that's larger they can chew, and winds up going off for months at a time working on a huge feature set. And hopefully our refactoring, pairing, etc will mean that if someone does have to drop out for whatever reason, others will be able to pick up where they left off without too much trouble.
Hope that answers your question... if I didn't cover something you wanted me to, let me know.
no subject
Wiki-wise, the most difficult thing has been that you can't watch a page, and can't get email notifications that it's changed, which severely inhibits asynchronous collaborative editing, and leaves us with a lot less protection against malicious edits.
I think that makes sense for the rest. So if someone who's been around for a while takes a break and then wants to come back in, they have to either synchronise with an iteration, or pick something small enough for them to do in the amount of time that's left in the iteration?
no subject