Scalable Development Process

From Open Source Ecology
Jump to: navigation, search

The key requirement to start the development process, which is scalable to any number of modules, is:

  1. Effective modular breakdown. The most important key to large-scale development is breaking down a project into the smallest task possible. To allow for effective parallel work, modular breakdown should occur at a chunking level where each task takes 10 hours - or one full day of work. This level of effort is a reasonable expectation for volunteer effort. It is also a good fit for the time that any significant task may take. If a breakdown has occurred but the task takes much more than 10 hours, then the task should be broken down further. The breakdown may also depend on available human resources. The 10 hour standard is reasonable in that it is a significant contribution that allows visible progress to be tracked.
  2. Defining the requirements for 100 modules, and for the 50 machines. Each module - a part of the 50 GVCS tools - must be specified to meet the OSE Specifications. The requirements-producer - the OSE Lieutenant - needs to understand OSE Specifications fully, while the people executing the design need to have only a basic knowledge of OSE Specifications. When project requirements are specified with sufficient detail, the path to the design should be straightforward. The bottleneck in the 1 year Civ-from-Scratch design is the detailed specification - where the difficulty lies in the translation of OSE Specification to specific design parameters. The part that makes this particularly challenging is the product ecology aspect - where new developments in product system integration will require iteration as some modules are updated based on new learnings of product ecology. Tutorials on the application of OSE Specifications must be available to increase progress.
  3. Defining the 100 steps to product release, including open source enterprise. A detailed project architecture must be present to coordinate everyone’s effort. The steps of product development are universally understood in the field of product development. These must be adapted to the specific procedures used by OSE, so that people are using standard tools and procedures throughout. Critical tools are found in the OSE Linux distribution, and new tools are being developed to facilitate OSE progress - such as FreeCAD tools, project management tools, website and marketing tools, product fulfillment tools, communication tools, and others. Each step of the collaboration architecture must be documented carefully so that standards are kept throughout. Currently, the wiki serves as a Documenation and freeCAD file repository, and we use cloud documents embedded in the wiki for realtime team collaboration where people can do conceptual design in parallel. Once the different steps are documented and tools are available, and documentation standards are clear - then many people can take any of the steps and work on them in parallel across different projects and their submodules. Critical to the success of the development process is to design it such that as many parts as possible can be developed at the same time - and for the dependencies - a Process Manager is needed. The PM is required to understand the workflow at a sufficiently deep level to make on-the-fly decisions about which steps or iterations of steps should be done at any given time. Ideally, everyone on the team would be really familiar with the workflow to make those decisions themselves. To accelerate progress on projects, it is helpful to train additional process managers so that they could provide the strategic intelligence of what to do next - allowing task oriented people who do not have the PM overview themselves to work effectively as part of a much larger team. Another critical aspect that makes for effective developmet is effective modular breakdown.
  4. Documentation and Burndown. For transparency of the development process, it is critical that each Development Template (ref) is posted for a development project. This way, status of completion is clear - as each of the 100 steps is marked with 0-10 for the level of completion, which gets tracked for every single project and module. It is useful to track burndowns for individual modules - such as wheel drive unit of a tractor or a 3D printer extruder - as well as the burndown for the entere machine - the tractor or the 3D printer. The burndown also can boost morale as clear progress is seen by many people, and burndown can be quite rapid if many people are working on the same project.
  5. Commits and Part Libraries. Officially accepted CAD files are the formal commits. Project lieutenants approve commits. Part libraries are a great starting point for a lot of development - in that any parts in the official part library for a given project are admissible parts in future designs. Thus, development of iterations is successively easier as more admissible parts are available to build upon, and people are not starting from scratch. When full part libraries come into place - then the part libraries begin to serve as construction sets for many variants of a mchine.