ü  我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？

ü  是否有充足的时间来做计划?

ü  团队在计划阶段是如何解决同事们对于计划的不同意见的？

ü  用户量, 用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么?

网站基本定位

面向CS/EE领域的垂直搜索引擎

网站创新形式

首先，按照《构建之法》中创新类型的划分，在创新的类型上，我们的产品是改良型的创新，而非颠覆性的创新

用户基本定位

计算机及相关专业学生，其中以大学生群体为最主要的用户群

用户的知识层次

用户具备基本的编程基础，并具备使用通用搜索引擎（百度、谷歌等）的能力

网站的基本功能

网站能够采集专业化社区中的问答数据、高质量课程资源、专业技术文档中的内容，为使用者提供一体化的、精准的、高质量的搜索内容

同时，用户能够通过网站直接参与到上游社区的讨论中

Alpha阶段BugPhobia团队基本定位

Beta阶段BugPhobia团队基本定位

完善？搜索引擎架构？

组间协作！重构兼容！继续的开发迭代！

完善的用户个性化管理、完备的问答资源爬取、完善的搜索引擎架构，我们将用户精确定位于计算机系的“对专业课程、概念和软件使用有着大量需求”的学生群体，和非计算机专业的“对计算机相关概念和理解有着问答需求”的学生群体

周，BugPhobia团队、Dream团队、PowerTeam团队之间协商后端开发接口、SOLR字段开发文档、SOLR配置和解决方案文档等，后期的组间协作也初步完善

重构兼容：Alpha阶段，团队仅考虑本身的实现效果；而Beta阶段为保证其他协作组的开发进度，团队从前端的React单页应用到后端的JSON数据定义完成了全部代码的重构

继续的迭代开发：Beta阶段，在后续的开发过程中考虑到重构、沟通的高昂成本，因此团队尽可能保证技术栈的优先搭建；无论是共用后端（Django）、FLUX单页开发模式均完全搭建成功；同时，团队不仅保存开发过程的必要文档，也留下Semantic UI、Django部分的开发文档和心得，保证后续的迭代开发能够顺利开展；

数据处理能力的可扩展性：

n  SOLR本身具备分布式支持的特性

n  单页应用模式对于服务器的计算压力较小，前端对CDN加速的技术适应性较强

基本项目说明

燃尽情况描述

高昂学习成本的消化曲线

但从issues的角度分析，团队共添加5个issues节点任务用以完成高昂学习成本的消化（Semantic UI、ReactJS、Django框架的审查和学习成本消化）；因此，在初期的燃尽阶段，直线段的燃尽曲线主要作用域高昂学习成本的消化

任务分工粒度缩减

考虑到Alpha阶段的燃尽图生成，几乎完全依据前端页面和后端功能进行任务和issues的划分，因此在Beta阶段，团队尽可能将任务划分为多节点的子任务从而使得开发工作的任务粒度较为细致，能够加快后续的Scrum燃尽效率

团队成员的责任明确化

事实上，在此次issues的统计中，近一个半月的开发时间，团队共提供50个issues记录和31次commits记录；而issues则明确了基本的标签和直接的责任人，在commit时会链接到相应的issues记录，方便后续查看时能直接依据issues记录找到负责的团队成员

最终解决方案

可以选取的解决方案

l  ReactJS的数据单向流动框架/开发模式

l  JSON数据封装而非Django模板渲染

l  Solr平台的数据插入

l  搭建中间层，兼容数据组数据库，直接根据数据库的SELECT查询操作完成封装

用户实际注册数

访问流量统计

活跃用户量

——

——

——

这里BugPhobia团队为您的支持表示感谢，但经历了沟通过程的高昂成本消化后，后期实际开发过程中，即便学霸项目四组间最终完成了项目的对接工作，但从用户的角度，Beta阶段迭代后的产品版本无法面向用户，部分功能受到数据组数据类型的限制、后期开发时间的严重缩减，导致重构后的产品只能把必要的技术栈填充。

因此，考虑到继续迭代开发的过程，团队Beta阶段的项目并不面向最终用户，而面向了继续迭代和开发的人员；因此，仅从团队本身的意向出发，团队此阶段的工作已全部顺利完成；后续的开发人员能够从三方面入手：

n  共用后端的接口扩充：其可扩展性较强，数据库和后端接口的相关文档也全部保留（建议添加课程部分）

n  适用于CDN加速：FLUX单页模式即ReactJS的开发模式，由于其架构本身和SOLR的架构本身均支持分布式的搭建，特别地对于CDN加速的搭建也有很大的帮助

n  FLUX单页开发模式：在ReactJS的单页应用开发架构下，团队本身预留了充足的学习文档和开发文档可以提供给后续的开发人员继续迭代

ü  你原计划的工作是否最后都做完了? 如果有没做完的，为什么?

ü  有没有发现你做了一些事后看来没必要或没多大价值的事?

ü  是否每一项任务都有清楚定义和衡量的交付件?

ü  是否项目的整个过程都按照计划进行，有什么风险是当时没有估计到的，为什么没有估计到?

ü  在计划中有没有留下缓冲区，缓冲区有作用么?

ü  将来的计划会做什么修改？（例如：缓冲区的定义，加班）

ü  我们学到了什么? 如果历史重来一遍, 我们会做什么改进?

项目说明

Alpha阶段功能展示

Beta阶段功能添加

用户管理

用户信息查看

用户信息查看（保持不变）

用户信息修改

用户信息修改（保持不变）

用户标签管理：添加、删除（无）

用户标签管理：添加、删除（新增）

用户查看推荐标签（无）

用户查看推荐标签（新增）

搜索单元

基于TAGS云的搜索

基于TAGS云的搜索（删除）

基于TAGS标签栈的搜索（无）

基于TAGS标签栈的搜索（新增+完善）

输入框关键字搜索

输入框关键字搜索（保持不变）

课程单元

课程视频展示

课程视频展示（保持不变）

课程PDF展示

课程PDF展示（保持不变）

Phobia助手

聊天查询

聊天查询（保持不变）

问答

查看问题（无）

查看问题（新增）

添加问题（无）

添加问题（新增）

UI细节优化说明

UI优化前劣势设计

修复了TAGS云和右侧标签栏重复的UI展示效果，同时为右侧标签栏增加分页功能，保证多标签的正常浏览效果

增加TAGS云以动态刷新标签供用户选取

修复了用户管理页面对问题、标签的下拉栏过长问题，采取分页的JS代码机制保证多条浏览记录的快速分页

将用户的问题、关注的标签等细节全部展示了用户自主页面，下拉pusher即可发现平铺于页面的具体信息

修复了搜索结果展示的UI优化，保证搜索结果的提示信息更为人性化

将搜索结果的URL直接展示于用户

时间

困难描述

月13日

n  关于ReactJS和Semantic UI的javascript冲突状况

n  关于Solr本身的配置和插入问题

n  关于对接的终稿交付说明

月16日

n  沟通问题的协商和解决

n  学霸爬虫组与需求的不对称

月23日

n  关于Solr的数据插入的解决方案

n  关于Seamantic UI本身的BUG解决方案

备注

这里仅给出部分苦难的描述，对于详情的分析，请翻阅BugPhobia团队的Scrum Meeting篇章进行查看和翻阅

挑战

n  需要和APP组公用后端

n  前端需要支持通过JSON与后端交互

n  单页应用技术较新，以前从未接触过

n  需要对几乎所有代码进行重构

机遇

n  优化Alpha阶段的细节

n  重构不合理的页面

n  抛弃在Alpha阶段结尾写成泥球的代码

n  将代码组件化，增加代码重用，整理代码结构

问题

回答

在计划中有没有留下缓冲区，缓冲区有作用么?

由于开发时间和沟通时间均被大幅度压缩，因此在缓冲区上未设置开发过程中的缓冲区；但同样，在开发阶段考虑到编译原理课程设计的冲突情况，团队在开发过程中嵌入了大量的缓冲区，用以保证工作进度不至于单向阻塞而难以继续执行

将来的计划会做什么修改？（例如：缓冲区的定义，加班）

在将来的计划中，重点仍在与文档的描述与备案；因为学霸项目是不断迭代的过程，作为遵守职业道德的攻城狮，必须保证后续接手的团队能够快速完成项目的搭建工作

我们学到了什么? 如果历史重来一遍, 我们会做什么改进?

在Alpha阶段，团队就能坚持Beta阶段的架构设计，通过一系列的接口实现组间的互联互用，从而避开Beta阶段繁忙的大作业冲刺时间；合理利用时间，是BugPhobia团队对下一届接受我们项目的团队最大的希冀

ü  我们有足够的资源来完成各项任务么?

ü  各项任务所需的时间和其他资源是如何估计的，精度如何?

ü  测试的时间，人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?

ü  你有没有感到你做的事情可以让别人来做（更有效率）?

ü  有什么经验教训? 如果历史重来一遍, 我们会做什么改进?

集市管理的重要责任

具体执行方案说明

合理组间协作沟通负责人

在开发过程中，遇到组间协作的部分，尽可能通过某一架构完成两方面团队工作的协作；而团队建议在此部分架构上安排特定的某一人，去解决这一部分对接工作的全部问题，去直接和下游的团队进行对接，尽可能降低组间沟通消耗的成本

开发的直接负责人

实际上，在开发过程中必须确保每一部分工作的质量均由特定的人进行管理，遇到变更时再优先和负责人讨论后作出妥协或决定

时间节点的设置

各任务必须给出预算的时间节点，供项目经理搭建出流水方式的工作进度管理

依赖关系的重视

确保架构上的依赖关系，进度上的时间依赖关系有足够的容错能力，保证在后续的调整过程中，不会出现集市的空档期

项目

Alpha阶段开发模式

Beta阶段开发模式

面向群体

面向用户的开发模式

面向开发人员的开发模式

架构开发

Semantic UI前端和Django后端结合

Semantic+ReactJS前端和Django共用后端结合

车祸系数(单核心依赖系数)

在Alpha阶段，团队出于基础的磨合阶段，因此在一定程度上，由Alpha团队内的组内协作可知：

n  团队技术栈是以架构和后端作为驱动的开发模式，因此团队内的协作是以架构师GNU_Linuxer为基础，因此很可能由于架构师传递信息的“不确定性”，导致项目车祸发生

n  团队前后端对接工作完全依赖后端人员对前端代码的理解，因此两者需要一定时间进行结对编程，导致两者之间的耦合相对较差

在Beta阶段，经历Alpha阶段的开发，团队成员本身对项目和架构的认知相对较深，因此团队的分工呈现多层次的递归发展：

n  团队技术栈开发分离，SOLR架构、前端ReactJS、后端Django开发组均能正确独立地完成相应模块的开发，因此对接成本降低

n  团队前后端的对接工作相互独立，后端人员完成相应接口的设计后，只需通过Django本身的单元测试框架即可完成正确性的验证；而前端人员可以直接根据接口文档完成调用，无需理解具体的原理过程

流水线开发模式

n  在Alpha阶段，团队整体的开发呈现基础的流水线工作，设计、前端、后端、测试、复审、验证的流水机制高速运转，其整体的开发模型符合瀑布模型的流水工作，整体的代码严谨性较强

n  但同时，流水线的阻塞也是开发过程不可避免的阶段，部分工作的延误将有可能导致其他人员的进度延误

Beta阶段，考虑到流水线机制本身的问题，团队的开发呈现局部流水、整体并行的开发机制：

n  在局部上，项目本身将各功能模块进行分割操作从而保证了局部的开发模块能够以流水的形式继续开发，即前端和后端的对接，测试的验收等部分工作；而结对编程也同样发挥了应有的作用

n  在整体上，项目本身处于整体并发的开发机制，一旦某一开发人员开发陷入阻塞态，其他成员能够依据自身的并行开发序列继续开发，从而避免整体开发进度阻塞的问题

文档管理

Alpha阶段未强调文档的基本管理

Beta阶段，团队制定了完整的文档管理计划（更多细节可以浏览github的文档版本）：

n  团队内的文档尽可能使用Markdown文本编辑，允许使用扩展的Markdown语法，但必须保证GIT@OSC或MarkdownPad能够支持相应的扩展语法

n  对于部分必要的新技术，必须同时维护一份技术入门文档

测试说明

Alpha阶段未强调单元测试和部分性能测试的问题

Beta阶段制定了完成的测试方案和计划说明（更多细节可以浏览github的文档版本和测试报告）

n  脚本型功能测试

n  手工测试

n  脚本型安全性测试及性能测试

责任明确

Alpha阶段，团队整体处于集市的开发模式，团队本身未强调相关任务责任的明确化和细致化

Beta阶段制定了明确的责任分工制度（更多细节可以浏览github的文档版本和测试报告）

王鹿鸣

n  完成Semantic UI框架向ReactJS的代码迁移工作

n  完成其他模块的具体页面的前端实现

n  架构团队整体的开发流程

u  前端开发

u  全栈沟通、架构、前端

钱林琛

n  完成功能规格说明书、技术规格说明书、绩效管理的整理和维护工作

n  Scrum Meeting期间完成Scrum Meeting的记录和更新，要求必须包含：个人的Work Issue的ID关联（已完成、计划完成、工作中的困难记录），燃尽图，照片，代码/文档的签入记录说明

n  与团队成员交流后规划各个开发时间，进行监督和“干预”

n  必须与爬虫组、数据组、APP前端组进行沟通

u  项目经理

u  功能沟通，管理

冯志睿

n  调研第三方登陆的基本环境，并在Beta阶段进一步支持第三方登陆

n  根据接口定义，实现相应接口（JSON数据格式），交付前端做进一步的解析

u  后端开发

u  全栈沟通、后端、结对编程

王文基

n  根据接口定义，实现相应接口（JSON数据格式），交付前端做进一步的解析

u  后端开发

u  后端、结对编程

赵庶宏

n  根据接口定义，实现相应接口（JSON数据格式），交付前端做进一步的解析

u  后端开发

u  后端、结对编程

李云涛

n  Javascript和DOM的学习进度规划

n  重新梳理前端页面的逻辑跳转，整理需要开发的“新页面”

n  直接以ReactJS的view渲染开始新页面的编码和设计

u  前端开发

u  全栈沟通、前端、结对编程、测试

李入云

n  Javascript和DOM的学习进度规划

n  重新梳理前端页面的逻辑跳转，整理需要开发的“新页面”

n  直接以ReactJS的view渲染开始新页面的编码和设计

u  前端开发

u  结对编程、前端

金东禾

n  整理已知的Django框架、Semantic UI框架的入门教程，通过Markdown或LaTex整理为可读性较强的文档，留作为接任此项目的团队的学习文档

u  文档整理

u  学习文档整理、技术平台整理

问题描述

回答说明

我们有足够的资源来完成各项任务么?

从基本的资源分配中可以看出，经历两轮迭代和技术栈更新的团队，在开发效率几乎与Alpha阶段相比有着较高的提升。以12月11日左右Semantic UI中期考核任务结束作为分界线，团队整体完成了技术栈的更新和学习，而后期开发工作基本以连续开发时间作为主要的影响因素。

n  若需求定位于后续迭代的技术栈维护，时间资源能够达到预期目标，而学习成本资源和人员安排也符合预期安排

n  若需求定位于面向用户版本的更新，时间资源基本不足以完成预期目标，而后端的资源分配基本充裕，但前端的开发资源相对匮乏

各项任务所需的时间和其他资源是如何估计的，精度如何?

n  在Alpha阶段~Beta阶段的过渡阶段，团队整体完成了技术栈的试验迁移工作，在此阶段，团队针对JSON的迁移工作、ReactJS的迁移工作做出了基本的demo

n  在Beta阶段，后端的开发时间相对充裕，因此时间成本基本按照前端的开发进程进行估计，后端任务划分为：后端开发、单元测试、代码复审、对接审核、接口文档归档的部分，在前端相对部分开发时需要保证前两子任务优先完成

n  Beta阶段，前端任务相对紧张，因此，此部分工作基本由团队的开发人员开发一周后自行给出进度报告，并和后端协商后完成最终进度的确立

你有没有感到你做的事情可以让别人来做（更有效率）?

由“0x0308：团队基本分工职责”的表格中可以发现，团队基本保证，各任务几乎保证了专人专任制度，根据Alpha阶段的开发方向进行归类，在整体上保证了效率的最大化

有什么经验教训? 如果历史重来一遍, 我们会做什么改进?

n  对接工作由Alpha阶段必须开展

n  对接工作由Alpha阶段必须开展

n  对接工作由Alpha阶段必须开展

ü  每个相关的员工都及时知道了变更的消息?

ü  我们采用了什么办法决定“推迟”和“必须实现”的功能?

ü  项目的出口条件（Exit Criteria – 什么叫“做好了”）有清晰的定义么?

ü  对于可能的变更是否能制定应急计划?

ü  员工是否能够有效地处理意料之外的工作请求？

消息传递机制

具体说明

Scrum Meeting会议

n  团队每1~2天完成Scrum Meeting会议的基本讨论，主要探讨基本的进度问题、设计时的冲突问题、技术栈的新BUG解决方案等问题

Team@OSC团队管理

n  团队在Beta阶段将完成使用Team@OSC进行任务的管理（https://team.oschina.net/Bugphobia）和Github本身的Issues进行关联

n  任务具体的发布流程 ◦团队全部成员均能够发布任务，但必须保证任务标签、任务说明均完备，在发布后任务将自动进入待办中状态

文档沟通方式

n  此部分沟通方式主要应用于前后端的开发方面，而此时commit记录必须与前端文档的维护状况相对应，一旦后端接口出现变更后立刻对commit记录进行查看并进行小范围的修改和维护

职能说明

具体工作评估

团队项目进度协调

“不管是开源还是商业化，都必须要有一个人对整个项目负责。不是两个人，不是三个人，而是一个人“，这里笔者经过两轮迭代的开发暂时不予支持这一观点。这里负责的概念，笔者从技术和进度上给出负责的定义：

l  技术负责：团队能够依据目前的开发状况，更新技术栈，并稳定基础架构，针对不同情况给出不同的解决方案

l  进度负责：团队能够根据目前的进度状况和预期计划，更新进度日程和前后端对接进度，保证开发模式和进度呈现稳定发展

因此，笔者所处的团队基本处于两人的负责的阶段，技术负责交付架构师，进度负责交付笔者，而平台的对接沟通工作交付平台对接人员，三方面对团队进行负责，最终保证Beta阶段团队项目能够稳步进行，完成最后的预期开发

团队项目进度的干预

团队的全部成员本身从态度和能力上都非常靠谱，交付的任务和挑战都能尽力完成且交付的版本都几乎和最终归档的版本相差不大。但团队同样会经历部分任务的“卡壳“阶段。

在开发中期，团队的前端页面的迁移工作一度陷入迟滞，由于前端迁移人员纠结在主页面的标签云迁移工作，而正常的工作难以继续开展；因此此时项目经理需要适时干预进度，将此部分任务标签后移，并提供不同的解决方案供技术负责参考，并完成进度的迁移

ü  设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？

ü  设计工作有没有碰到模棱两可的情况，团队是如何解决的？

ü  团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？

ü  什么功能产生的Bug最多，为什么？在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?

ü  代码复审（Code Review）是如何进行的，是否严格执行了代码规范？

ü  我们学到了什么? 如果历史重来一遍, 我们会做什么改进?

王鹿鸣

n  完成Semantic UI框架向ReactJS的代码迁移工作

n  完成其他模块的具体页面的前端实现

n  架构团队整体的开发流程

u  前端开发

u  全栈沟通、架构、前端

李云涛

n  Javascript和DOM的学习进度规划

n  重新梳理前端页面的逻辑跳转，整理需要开发的“新页面”

n  直接以ReactJS的view渲染开始新页面的编码和设计

u  前端开发

u  全栈沟通、前端、结对编程、测试

李入云

n  Javascript和DOM的学习进度规划

n  重新梳理前端页面的逻辑跳转，整理需要开发的“新页面”

n  直接以ReactJS的view渲染开始新页面的编码和设计

u  前端开发

u  结对编程、前端

测试项目

BUG测试说明

修复情况说明

正常注册

——

——

正常登陆

——

——

重复注册

提示信息出现错误，此BUG经调研涉及Semantic UI框架本身标记的BUG

已修复

错误信息登陆

后端验证中提示信息出现错误，此BUG提供网页前端验证的解决方案

已修复

非法信息注册

——

——

资料查看

可能出现部分资料属性返回空值的情况，经调研此问题涉及部分POST机制，交付Exception模块处理即可

已修复

资料修改

——

——

测试项目

BUG测试说明

修复情况说明

搜索存在的标签

搜索结果未进行分页，页面显示过长

已修复；前端开发人员重新设计布局并使用分页布局JS和CSS完成BUG的校服

搜索不存在的标签

为搜索到返回结果，无提示信息；特别说明，此BUG属于后期测试时用户提供的BUG标签，因此在Beta阶段完成此BUG的修复工作

已修复

对搜索框进行注入

——

——

直接点击Tag进行搜索

——

——

测试项目

BUG测试说明

修复情况说明

问题搜索

——

——

回答展示

此部分展示效果根据用户的反馈，其UI美化相对较差，因此可能需要重新布局和排版

未修复

问题提出

——

——

相关问题推荐

——

——

ü  团队是否有一个测试计划？为什么没有？

ü  是否进行了正式的验收测试？

ü  团队是否有测试工具来帮助测试？

ü  团队是如何测量并跟踪软件的效能的？从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？

ü  在发布的过程中发现了哪些意外问题？我们学到了什么? 如果历史重来一遍, 我们会做什么改进?

问题描述

回答说明

团队是否有一个测试计划？

是否进行了正式的验收测试？

此部分内容具体可以翻阅团队的测试报告，这里给出详细的链接：

http://www.cnblogs.com/bugphobia/p/5117731.html

团队是否有测试工具来帮助测试？

团队是如何测量并跟踪软件的效能的？从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？

n  团队的测试代码经过协商，其关于压力测试、安全测试等方面的脚本均为闭源代码，此部分工作沿用Alpha阶段的工作继续进行

n  团队的网站的相关测试直接通过手动测试完成了相关内容，具体的信息仍翻阅团队测试报告即可（http://www.cnblogs.com/bugphobia/p/5117731.html）

在发布的过程中发现了哪些意外问题？我们学到了什么? 如果历史重来一遍, 我们会做什么改进?

n  开发前期整体进度较慢，及因此有充足的时间进行代码复审，代码完成的质量也比较高。而进入后期的最终冲刺阶段后，功能更新速度提升，每天都会有很多新的代码，因此复审的工作便落后于代码编写的进度，这直接导致了一部分代码未经过复审就上线发布。然而问题是，这些直接发布的代码质量普遍偏差，可扩充性不好，不满足后期开发的需求。因此，这一段代码我们将在整理阶段进行删减和部分重构。

n  同时，在Beta阶段的开发中，单元模块测试明显不足，大量的测试不足以覆盖模块中的所有代码。后期也存在了一部分没有经过单元模块测试就迁入的代码，这都将对应用的稳定性造成很大影响。

问题描述

回答说明

你觉得团队目前的状态属于CMM/CMMI 中的哪个档次?

笔者观点，团队处于其中的最多可以算上管理级，在Alpha阶段我们的团队用行动证实了我们可以实现完成级的突破，在本次的Beta阶段我们认为我们的团队实现了明确任务，细化责任的工作，通过结对编程我们将成员的任务具体化、明确化。每一个模块都有专门的成员负责完成。因此，笔者认为这个可以算上是处于管理级的。

你觉得团队目前处于 萌芽/磨合/规范/创造阶段的哪一个阶段?

整体团队目前是处于规范的阶段，因为在Beta阶段正是通过一系列的规范的制定才实现了最终的4个组之间的衔接

你觉得团队在这个里程碑相比前一个里程碑有什么改进?

整体团队更加懂得分享和合作了，在这个阶段我们通过组间的合作将以前孤立的系统进行了融合我们摈弃了我们之前爬取的所有的数据将数据处理组的数据作为我们后台数据的全部，成员之间也更加熟悉，相互的孤立使得彼此能在“恶劣”的大作业纷飞的环境下依然为软工尽心竭力。

你觉得目前最需要改进的一个方面是什么?

时间规划是我们一开始的劣势，如果有可能的话我们希望我们现在的Beta阶段成为我们当初的Alpha阶段，然后在现在的基础上进行更深入的开发。所以我们希望留下尽可能多的文档和资料让后来的开发者能够尽快达到我们现在的层次从而在此基础上进行开发和创新。