Development Procedure
From Dogfoodsoftware
Contents |
State of This Document
The relationship of Dog Food Software to her business partners is also yet to be fully determined, and those partners will certainly have a say in the development of the process envisioned here. The procedure outlined here is the direction we'd like to head, but there are likely to be particulars and constraints which will have varying import and impact on the individual developers concerned.
Basic Commitment
- Developers should be comfortable with at least a 10 hours commitment per month.
- Developers are expected to assist in project planning (20%), be available and responsive to communication (20%) and actually develop code (60%).
- A developer is expected to stay reasonably abreast of development, responsive to direct inquires, and moderately--though perhaps passively--active on any mailing lists to which the developer belongs.
- Our goal is to specify a minimum useful level of commitment, but to keep the commitment very "doable". Developers are encouraged to engage with the company and each other to find ways to make the process efficient and profitable for all involved.
Development Process
- The development process is centered around release cycles, which move the entire Kibbles system to the next release version number. E.g., 1.0 to 1.1 to 1.2 to 2.0, etc.
- The development team jointly plans for releases by updating the project plans and other documentation.
- The live wiki represents the transition documentation between the currently released and the next production version.
- Developers may modify the project plan according the the following:
- Any developer may add an item/goal to a plan.
- The head of development reviews and accepts estimates when it is felt everything is correctly decomposed and sized.
- Dtems with accepted estimates, or claimed items should not be edited without discussing changes with the head of development and other stakeholders.
- otherwise, any developer is free to edit or remove items as they see fit.
- Developers are expected to use their best judgment as to when changes to a plan should be preceded by a discussion with stakeholders.
- Items should be decomposed to the point that they represent an "atom of work" which can be estimated with high confidence and should generally represent no less than 2 hours and no more than 12 hours worth of commitment.
- Steps may be broken down such than they individually represent less than 2 hours worth of work, but are estimated collectively.
- Work items with estimates that have been accepted by the head of development are available for claim by developers.
- Developers claim work items by replacing the accepted notation with their own name and the delivery date.
- Once an item is claimed, the claiming developer becomes responsible for the delivery within 7 days.
Process Examples
0.3 (this is the version number of the plan)
- this is a work item in the plan with no estimate
- this is a goal/work item, which has been decomposed into parts
- this is a sub-item within a larger goal
- this is a sub-item within a larger goal with an estimate; 4 hrs.
- this is an item with an accepted estimate; 3 hrs. (accepted)
- this is an item that has been claimed; 6 hrs. (Zane; due 1/1/2099)
- alternatively, the claiming developer can link to their own wiki page; 4 hrs. (Zane; due 1/1/2099)
- if a goal is decomposed into sub-goals, only sub-goals are estimated
- like this; 4 hrs;
- if necessary, goals can be further decomposed
- in which case the estimates would go here
- like this; 2 hrs.
Head of Development
- The head of development represents the company's interest.
- The head of development acts as de-facto moderator amongst the developers to resolve contentious estimates and plans.
- The head of development shall provide (personally or through company resources) technical expertise to the development team.
Quorum of Developers
- Developers may internally organize in any way they see fit.
Developers and Technicians
- Developer, within these procedures, describes a free agent within a larger system.
- The developer's relation to the company is closer to that of partners than it is to employee/employer.
- Within these documents, an individual working as an employee or contractor is appropriately termed a technician.
Future Developments
The earlier drafts of these procedures contemplated a system of rewards and incentives and envisioned the developer/company relationship as something to be defined and governed by contract with the developer making hard commitments and the company compensating the developer with cash and equity. While not overly complex, it was felt that it was more appropriate to scale back and let such a system develop out of the relationship of the first developers. The issues mentioned in the opening statements to this document also come into play.
