|
Planning
Project planning philosophy, guidelines, and roadmap formatting.
DisclaimerI (@wajiii) have not reviewed this for consistency or completeness yet, I just have stuff to do and have to save this as-is for the moment. :) I think at this point it is already ready to be separated into the master "planning" page and the individual "milestone 1" page. ContentsIntroductionThis is a road map for the first major milestone of the ORBlogs application. As future functionality is planned and roadmaps are created for other milestones, I expect that this page will be renamed to something like "Roadmap - M1" (or maybe instead of M1 we'll come up with a cool code name), and a new "Planning" page will have some of this introduction and an index of the individual major milestones' pages. I say "major" milestones because I believe in releasing the agile way -- every time your code passes all tests. I consider each successful build+test cycle to be a "minor" milestone; if you need more explanation, or think it not workable, ask Google about Flickr's release schedule. However, until we have some decently rigorous testing in place, So a "major" milestone to me is simply an arbitrary grouping of whatever functionality we deem appropriate for such a designation; it is somewhat equivalent to the "release" or "version" in traditional (non-agile) projects. For example, we may focus on one or more themes for each major milestone. I have suggested some themes for the first milestone below. Themes are merely a planning tool, though, not limitations; there is no reason you cannot do work that doesn't fit a current theme, or fits a theme for a future milestone! Finally, I strongly encourage use of the agile planning practice of "pebbling" tasks; that is, breaking down higher-level tasks into their lower-level components until you reach what Jim Shore calls the "minimum marketable feature", the point past which there is little or no value in delivering the pieces separately. This is the level at which we should create individual issues in the issue tracker. However, you should feel free to add high-level tasks without breaking them down; if what you added is worthwhile, someone will probably pick it up and run with it. :) For more information, see Jim's book, "The Art of Agile Development". FormattingInspired by Igal's OSB apps task list. Thanks, Igal! This section should be moved to the bottom of the page, or the roadmaps index page, when everyone gets familiar with it. Anything requiring more explanation or discussion than a one-line summary should have its own wiki page linked to from the list item on this page. If adding links to discussion group threads, conserve space like so: When you add an issue corresponding to a task, list it after the threads (if any), like so:
When a task is complete, do not remove it from the list, just add a strikethrough (wrap in double-tildes) to the text (not the issue number), like so:
If we decide to defer a task to the next major milestone, we should add (Deferred) at the end of the line, after any of the markup above. However, we should not have to do so very often, as it will happen organically; anything remaining incomplete on the list when we reach such a milestone will automatically roll over to the next one. Task Status
RoadmapWhat we're doing and why. Scope/Visionor, what the heck are we doing, anyway?
Themes
TasksOrganized by functional area User interface (visual)
User interface (functional)
Design Considerations
Backend
Organizational
Ancillary to Aggregator (for folks who want other work to help with)
|
Sign in to add a comment
