概要
这篇文章的目的是指导Link-Cooperation项目的管理和开发过程，内容不会涉及到具体的开发技术，也不讨论产品的性能和安全性问题，不过可能会探讨一些开发时使用的方法、设计模式。团队打算从传统软件开发模型、OKR管理方法、DevOps开发方法论、敏捷开发过程（Scrum和看板）以及极限编程XP的技术实践等多方面借鉴、吸取、融合制定适合团队自身的敏捷过程。本文有个人的见解，也参考部分书籍、资料，这些会尽量在文末标注出来。关于敏捷方面的知识主要来自：《Scrum精髓：敏捷转型指南》和《看板实战》。
这篇指导性文章即使在本项目结束后也永远不会被定义为最终形态，这与Scrum敏捷过程采用或转型工作没有“完成”的定义是一致的（敏捷没有成熟度模型，这是一种持续改进形式，它的使用始终都要与动态的软件开发世界保持一致），该文章将会在不断的冲刺中持续的改进和完善，因为不能够保证文章的当前版本是否存在错误，也不能够保证在实际的项目冲刺时文章的指导方法能够完全适用。
文章的结构分成两大部分：
- 在前面部分整理相关的知识（不会做到全面细致，但尽量保证正确性），主要包括：OKR、传统开发模型、软件测试模型、敏捷相关知识和DevOps等内容
- 总结并提出适用于Link-Cooperation项目的初步敏捷开发过程
Notes：文章中的内容，用在指导开发过程时也不需要盲目地遵守，要根据实际情况灵活的变动。另外很多知识，光靠文章中这点不完全保证正确性的总结性内容，可能是远远不够的，最好是直接找与特定内容相关的、比较权威的书籍来看看。
Notes：文章中很多术语会附带对应的英文，这是为了能够方便的到外网查资料
为什么要写这篇文章？
为什么要写这篇文章？换种说法应该是：为什么需要制定Link-Cooperation项目专门的项目开发流程？
为了让Link-Cooperation项目能够顺利、流畅、稳定的进行下去，最终产出具有价值的产品，避免Link-Cooperation最终做坏，导致项目失败。照之前协作的项目失败的经验来看，我们需要一个能够控制项目、控制团队、使产品开发流程可控的、避免流程僵化、规避不必要的风险的开发方法，同时要兼顾轻量、灵活性。另外在项目上线之后，产品的运维同样非常重要，如何监控产品的质量问题、线上服务器的状态等方面，都需要制定一些良好的实践和指导方法。
