-
Notifications
You must be signed in to change notification settings - Fork 1
Architecture document
This document is "superfluous" in the sense that the only documentation should be the running code itself in source and the acceptance tests (conversation section of each user story, and in the issue queue). However, it is sometimes useful to document decisions made in the course of project development, and this document strives to capture that.
Initially at least we are going with node only, without using express or grasshopper, etc., doing all the routing, etc., using custom modules.
In terms of the front end, we must use a template engine. I am loath to use jade since I want designers to be able to work on this from their end, and they work with HTML. So I would prefer to use something like the vim zencode plugin and then use something like phptemplate or smarty or wicket. Decision not made yet. Set up as task.
An agile approach, aiming to make the github repo be a self-documenting center for the project, based on Source, Issues and Wiki. Source and Wiki are repos. Issues can be backed up, cloned to another project, etc., via the GitHub API.
Roles and User Stories -> Prioritization into Issues Milestones -> Grab a User Story -> "Realization" (Analysis & Design) -> Main Acceptance Test versioned in the wiki, results in Issues (color coded for testing and associated with Milestones).
Issues filters and color coded labels, plus the built in issue milestones and open/closed issue status, do the job of rustic kanban board.
When the user story as an issue/task is work in progress, the first thing is that in the User story Conversation section, the nouns and verbs from the current text are listed, as a first "user story realization" analysis and design step.