OSE Open Product Development: Difference between revisions
No edit summary |
No edit summary |
||
| (6 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
The OSE [[Open Product Development]] is involves standard | The OSE [[Open Product Development]] is involves standard [[Product Development]] practice: | ||
*Concept | *Concept | ||
*Design | *Design | ||
*Build | *Build | ||
*Test | *Test | ||
| Line 14: | Line 13: | ||
*extensive review processes to catch problems earl on | *extensive review processes to catch problems earl on | ||
*modular, lifetime design, and other [[OSE Specifications]]. | *modular, lifetime design, and other [[OSE Specifications]]. | ||
The OSE process adapts standard Product Development practice to the requirements of a collaborative, scalable, open source, product development pipeline. The process is in development, and the reason for breaking the process down into so many steps is to make the requirements granular and easy to manage in a Scrum process. The smaller the steps, the more quickly can results inform other steps in the process - minimizing development risk - with the intent that many steps can be taken in parallel - especially when a team is working in real-time 24/7 around the globe. The key is high granularity for allowing massive parallel development. | |||
=Links= | |||
*[[Open Source Appropriate Technology]] | |||
[[Category:XM]] | [[Category:XM]] | ||
Latest revision as of 17:22, 8 March 2017
The OSE Open Product Development is involves standard Product Development practice:
- Concept
- Design
- Build
- Test
- Iterate
with a parcular focus on:
- transparent documentation
- open collaboration, local and global
- extensive review processes to catch problems earl on
- modular, lifetime design, and other OSE Specifications.
The OSE process adapts standard Product Development practice to the requirements of a collaborative, scalable, open source, product development pipeline. The process is in development, and the reason for breaking the process down into so many steps is to make the requirements granular and easy to manage in a Scrum process. The smaller the steps, the more quickly can results inform other steps in the process - minimizing development risk - with the intent that many steps can be taken in parallel - especially when a team is working in real-time 24/7 around the globe. The key is high granularity for allowing massive parallel development.