0x00：序言
1 universe, 9 planets,
204 countries,809 islands, 7 seas,
and i had the privilege to meet you.
To the searching tags, you may well fall in love with http:// xueba.nlsde.buaa.edu.cn
0x01：设想与目标概述
|
ü 我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？ ü 是否有充足的时间来做计划? ü 团队在计划阶段是如何解决同事们对于计划的不同意见的？ ü 用户量, 用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么? |
0x0100：团队需求与实现评价
在此阶段，BugPhobia团队本身再次引用此前的团队需求和分析表格：
|
网站基本定位 |
面向CS/EE领域的垂直搜索引擎 |
|
网站创新形式 |
首先，按照《构建之法》中创新类型的划分，在创新的类型上，我们的产品是改良型的创新，而非颠覆性的创新 |
|
用户基本定位 |
计算机及相关专业学生，其中以大学生群体为最主要的用户群 |
|
用户的知识层次 |
用户具备基本的编程基础，并具备使用通用搜索引擎（百度、谷歌等）的能力 |
|
网站的基本功能 |
网站能够采集专业化社区中的问答数据、高质量课程资源、专业技术文档中的内容，为使用者提供一体化的、精准的、高质量的搜索内容 同时，用户能够通过网站直接参与到上游社区的讨论中 |
|
Alpha阶段BugPhobia团队基本定位 |
Beta阶段BugPhobia团队基本定位 |
|
完善？搜索引擎架构？ |
组间协作！重构兼容！继续的开发迭代！ |
|
完善的用户个性化管理、完备的问答资源爬取、完善的搜索引擎架构，我们将用户精确定位于计算机系的“对专业课程、概念和软件使用有着大量需求”的学生群体，和非计算机专业的“对计算机相关概念和理解有着问答需求”的学生群体 |
组间协作：Alpha阶段开发过程中，学霸项目各团队均忽视了组间协作的高昂成本，各自模块的完成不等于对接成功！因此，即便在Beta阶段的沟通过程长达2周，BugPhobia团队、Dream团队、PowerTeam团队之间协商后端开发接口、SOLR字段开发文档、SOLR配置和解决方案文档等，后期的组间协作也初步完善 |
|
重构兼容：Alpha阶段，团队仅考虑本身的实现效果；而Beta阶段为保证其他协作组的开发进度，团队从前端的React单页应用到后端的JSON数据定义完成了全部代码的重构 |
|
|
继续的迭代开发：Beta阶段，在后续的开发过程中考虑到重构、沟通的高昂成本，因此团队尽可能保证技术栈的优先搭建；无论是共用后端（Django）、FLUX单页开发模式均完全搭建成功；同时，团队不仅保存开发过程的必要文档，也留下Semantic UI、Django部分的开发文档和心得，保证后续的迭代开发能够顺利开展； 数据处理能力的可扩展性： n SOLR本身具备分布式支持的特性 n 单页应用模式对于服务器的计算压力较小，前端对CDN加速的技术适应性较强 |
BugPhobia团队在Beta阶段的基本需求和定位同Alpha迭代相比有着较大的功能上的差异：
n Beta阶段团队共用后端的接口搭建成功，且单元测试覆盖率根据Django Unit Test的计算达到91.7%，基本覆盖了其接口测试的主要分支，其正确性在网站的发布时的测试也基本得到验证
n Beta阶段重构工作和历史迁移工作基本完成，按照功能上的划分，可以综合评价整体的需求和实现方面的映射关系：
l 用户模块的设计：Alpha阶段需求分析映射的用户管理功能基本完成，但用户的积分制度（Profile页面）和用户的消息机制（Message页面）尚未搭建完成，此部分功能可以作为用户管理模块的扩展功能继续开发
l 问答模块的设计：Beta阶段BugPhobia团队重点完成问答模块的搭建工作，后端的接口已经搭建完成，但由于工作时间的压缩，编辑删除问题等操作尚未与后端接口完成对接；这里请翻阅团队的技术文档，在前后端同期维护的技术文档中可以进行翻阅（https://team.oschina.net/Bugphobia/document）
l 课程模块的设计：Beta阶段此部分功能未进行任何处理，由于数据组和爬虫组未提供此方面的数据，因此其页面仍为Alpha阶段的展示功能页面
l Phobia助手的设计：Beta阶段此部分功能未进行任何处理，但后期的开发团队可以考虑通过基础知识库的搭建完成个性化AI的设计和搭建工作。
0x0104：时间计划安排和执行情况
从燃尽图的安排中，团队本身对此次整体的任务分配情况进行了一定程度的阐释：
|
基本项目说明 |
燃尽情况描述 |
|
高昂学习成本的消化曲线 |
但从issues的角度分析，团队共添加5个issues节点任务用以完成高昂学习成本的消化（Semantic UI、ReactJS、Django框架的审查和学习成本消化）；因此，在初期的燃尽阶段，直线段的燃尽曲线主要作用域高昂学习成本的消化 |
|
任务分工粒度缩减 |
考虑到Alpha阶段的燃尽图生成，几乎完全依据前端页面和后端功能进行任务和issues的划分，因此在Beta阶段，团队尽可能将任务划分为多节点的子任务从而使得开发工作的任务粒度较为细致，能够加快后续的Scrum燃尽效率 |
|
团队成员的责任明确化 |
事实上，在此次issues的统计中，近一个半月的开发时间，团队共提供50个issues记录和31次commits记录；而issues则明确了基本的标签和直接的责任人，在commit时会链接到相应的issues记录，方便后续查看时能直接依据issues记录找到负责的团队成员 |
因此，在Beta阶段，团队本身消耗大量的时间成本针对Alpha阶段的团队沟通问题，同Dream团队、PowerTeam团队之间完成了诸如协商后端开发接口、SOLR字段开发文档、SOLR配置和解决方案文档等团队沟通工作，并从底层的架构中给出了基本的解决方案，重构了学霸的WEB前后端工作，保证了组间衔接工作的正确性和高效性。
|
最终解决方案 |
可以选取的解决方案 |
|
l ReactJS的数据单向流动框架/开发模式 l JSON数据封装而非Django模板渲染 l Solr平台的数据插入 |
l 搭建中间层，兼容数据组数据库，直接根据数据库的SELECT查询操作完成封装 |
而在此阶段，架构师也选用了JSON格式封装的新的数据传输格式以及新的前端框架，从而将前后端解耦，使得学霸WEB组能够同学霸APP组共同使用团队搭建的后端接口，且数据处理组也能够快速完成数据的采集和插入工作，最终将学霸项目完全对接起来。
最终，依赖全栈工程师兼架构师的GNU_Linuxer驱动，依赖独立后端开发成员Fizhero（http://www.cnblogs.com/Fengzr）的驱动，团队依旧处于高速的运转之中，而在后期近三天的对接工作，几乎承担了绝大多数的工作，最终团队完成了基本的重构工作：
n 架构的可扩展性、可维护性相对较高，技术栈整体较易适应于分布式等方面的加速
n 学霸APP组和学霸WEB组能够完成共用后端的操作，且经过团队的测试，后端接口单元测试完全通过，而测试时也并未发现较大的异常
n 代码可读性和复用性大幅提高，且文档齐全并包含部分用于上手的的学习文档
0x0108：Beta阶段用户注册和访问量说明
|
用户实际注册数 |
访问流量统计 |
活跃用户量 |
|
—— |
—— |
—— |
|
这里BugPhobia团队为您的支持表示感谢，但经历了沟通过程的高昂成本消化后，后期实际开发过程中，即便学霸项目四组间最终完成了项目的对接工作，但从用户的角度，Beta阶段迭代后的产品版本无法面向用户，部分功能受到数据组数据类型的限制、后期开发时间的严重缩减，导致重构后的产品只能把必要的技术栈填充。 因此，考虑到继续迭代开发的过程，团队Beta阶段的项目并不面向最终用户，而面向了继续迭代和开发的人员；因此，仅从团队本身的意向出发，团队此阶段的工作已全部顺利完成；后续的开发人员能够从三方面入手： n 共用后端的接口扩充：其可扩展性较强，数据库和后端接口的相关文档也全部保留（建议添加课程部分） n 适用于CDN加速：FLUX单页模式即ReactJS的开发模式，由于其架构本身和SOLR的架构本身均支持分布式的搭建，特别地对于CDN加速的搭建也有很大的帮助 n FLUX单页开发模式：在ReactJS的单页应用开发架构下，团队本身预留了充足的学习文档和开发文档可以提供给后续的开发人员继续迭代 |
||
0x02 ：团队协作与计划核定
|
ü 你原计划的工作是否最后都做完了? 如果有没做完的，为什么? ü 有没有发现你做了一些事后看来没必要或没多大价值的事? ü 是否每一项任务都有清楚定义和衡量的交付件? ü 是否项目的整个过程都按照计划进行，有什么风险是当时没有估计到的，为什么没有估计到? ü 在计划中有没有留下缓冲区，缓冲区有作用么? ü 将来的计划会做什么修改？（例如：缓冲区的定义，加班） ü 我们学到了什么? 如果历史重来一遍, 我们会做什么改进? |
0x0200：计划完成情况
在1月1日的Scrum Meeting记录中，团队Beta阶段的项目的对接和发布尚处于微妙的状态：
ü 前端ReactJS页面已经由“举步维艰”的摒弃jQuery机制，迁移大量CSS和JS/JSX的过程，过渡到基本完工的工作状态
ü 后端Django的基本接口书写完成，但由于数据库的完整性约束条件的限制，正处于紧张的单元测试和错误排查阶段
ü 前后端的基本对接工作，从理论上，由于此前协商的定义应当不存在任何问题，但由于后端的测试过程因此尚未进入成功对接的阶段
ü 文档方面，由于此前工作的部分延误，大量的文档积累在complete文件夹，未完全排版和整理
而在最后一周的短暂开发时间中，此前疑虑的“前后端对接可能会浪费大量时间”由于单元测试的完备，此部分时间被大量节省，因此在开发后期，团队能够专注完成此前预计的各方面工作，虽然与此前Beta阶段初期预想的最终结果有所差距，即由于开发时间的急剧压缩，数据量的积累程度未达到预期。
|
项目说明 |
Alpha阶段功能展示 |
Beta阶段功能添加 |
|
用户管理 |
用户信息查看 |
用户信息查看（保持不变） |
|
用户信息修改 |
用户信息修改（保持不变） |
|
|
用户标签管理：添加、删除（无） |
用户标签管理：添加、删除（新增） |
|
|
用户查看推荐标签（无） |
用户查看推荐标签（新增） |
|
|
搜索单元 |
基于TAGS云的搜索 |
基于TAGS云的搜索（删除） |
|
基于TAGS标签栈的搜索（无） |
基于TAGS标签栈的搜索（新增+完善） |
|
|
输入框关键字搜索 |
输入框关键字搜索（保持不变） |
|
|
课程单元 |
课程视频展示 |
课程视频展示（保持不变） |
|
课程PDF展示 |
课程PDF展示（保持不变） |
|
|
Phobia助手 |
聊天查询 |
聊天查询（保持不变） |
|
问答 |
查看问题（无） |
查看问题（新增） |
|
添加问题（无） |
添加问题（新增） |
n 附注：有没有发现你做了一些事后看来没必要或没多大价值的事?
n 事实上，在Beta阶段，团队的开发进程基本处于稳定的状态，由于团队成员之间的协调与配合，因此此部分工作相对较少，这里仅就Alpha阶段和Beta阶段的部分对比给出说明
|
UI细节优化说明 |
UI优化前劣势设计 |
|
修复了TAGS云和右侧标签栏重复的UI展示效果，同时为右侧标签栏增加分页功能，保证多标签的正常浏览效果 |
增加TAGS云以动态刷新标签供用户选取 |
|
修复了用户管理页面对问题、标签的下拉栏过长问题，采取分页的JS代码机制保证多条浏览记录的快速分页 |
将用户的问题、关注的标签等细节全部展示了用户自主页面，下拉pusher即可发现平铺于页面的具体信息 |
|
修复了搜索结果展示的UI优化，保证搜索结果的提示信息更为人性化 |
将搜索结果的URL直接展示于用户 |
0x0204：任务的定义和交付衡量
u 团队在Beta阶段将完成使用Team@OSC进行任务的管理（https://team.oschina.net/Bugphobia）和Github本身的Issues进行关联
u 任务具体的发布流程 ◦团队全部成员均能够发布任务，但必须保证任务标签、任务说明均完备，在发布后任务将自动进入待办中状态
u 所有预定任务均会在两天前发布任务，团队成员在完成任务时应当首先将任务状态更改为进行中状态，而任务完成后可自行将任务状态更改为已完成（或者在Scrum Meeting上说明状况，由其他人归为“已完成”状态）
u 状态进入“已完成后”，任务管理将进入“审阅阶段”，此阶段将由项目经理审阅后更改为“已验收”状态，此后项目经理将同期发布代码复审工作
u 而任务的审查或出口条件为：子任务模块已被代码复审人员确认为符合规范、任务所关联的文件已具备完整的注释和相应issues的维护文档、commit记录已与issues进行了关联和绑定操作
0x0208：风险评估与分析
|
时间 |
困难描述 |
|
12月13日 |
n 关于ReactJS和Semantic UI的javascript冲突状况 n 关于Solr本身的配置和插入问题 n 关于对接的终稿交付说明 |
|
12月16日 |
n 沟通问题的协商和解决 n 学霸爬虫组与需求的不对称 |
|
12月23日 |
n 关于Solr的数据插入的解决方案 n 关于Seamantic UI本身的BUG解决方案 |
|
备注 |
这里仅给出部分苦难的描述，对于详情的分析，请翻阅BugPhobia团队的Scrum Meeting篇章进行查看和翻阅 |
前端的风险在初期并没有被正确地认识和估计，设想是将HTML通过ReactJS本身的约束和限制模板将其更新为JS/JSX风格的代码；但实际操作室，由于需要封装纯粹的JS而非jQuery代码段，因此Semantic UI本身封装的大量的jQuery均处于停滞状态，大量当时直接引用的库函数或方法难以继承了JS/JSX代码段中，因此前端的开发过程耗费了开发人员大部分的精力。而谈及后端的接口可用性测试，在数据的存储方式和调用方式之间存在着不同，使用时需要转变，这个风险同样是没有预料到的。再者就是当初的后端数据库里面有很多的与数据处理组不相关得当初测试用的文件，有时会被当成搜索结果返回，违反了调用的正确性，导致了不可预料的错误，这个也是一个没有预料到的风险。
|
挑战 |
n 需要和APP组公用后端 n 前端需要支持通过JSON与后端交互 n 单页应用技术较新，以前从未接触过 n 需要对几乎所有代码进行重构 |
|
机遇 |
n 优化Alpha阶段的细节 n 重构不合理的页面 n 抛弃在Alpha阶段结尾写成泥球的代码 n 将代码组件化，增加代码重用，整理代码结构 |
0x020c：其他问题的简要说明
|
问题 |
回答 |
|
在计划中有没有留下缓冲区，缓冲区有作用么? |
由于开发时间和沟通时间均被大幅度压缩，因此在缓冲区上未设置开发过程中的缓冲区；但同样，在开发阶段考虑到编译原理课程设计的冲突情况，团队在开发过程中嵌入了大量的缓冲区，用以保证工作进度不至于单向阻塞而难以继续执行 |
|
将来的计划会做什么修改？（例如：缓冲区的定义，加班） |
在将来的计划中，重点仍在与文档的描述与备案；因为学霸项目是不断迭代的过程，作为遵守职业道德的攻城狮，必须保证后续接手的团队能够快速完成项目的搭建工作 |
|
我们学到了什么? 如果历史重来一遍, 我们会做什么改进? |
在Alpha阶段，团队就能坚持Beta阶段的架构设计，通过一系列的接口实现组间的互联互用，从而避开Beta阶段繁忙的大作业冲刺时间；合理利用时间，是BugPhobia团队对下一届接受我们项目的团队最大的希冀 |
0x03 资源
|
ü 我们有足够的资源来完成各项任务么? ü 各项任务所需的时间和其他资源是如何估计的，精度如何? ü 测试的时间，人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度? ü 你有没有感到你做的事情可以让别人来做（更有效率）? ü 有什么经验教训? 如果历史重来一遍, 我们会做什么改进? |
0x0300：集市管理的资源制度分配
|
集市管理的重要责任 |
具体执行方案说明 |
|
合理组间协作沟通负责人 |
在开发过程中，遇到组间协作的部分，尽可能通过某一架构完成两方面团队工作的协作；而团队建议在此部分架构上安排特定的某一人，去解决这一部分对接工作的全部问题，去直接和下游的团队进行对接，尽可能降低组间沟通消耗的成本 |
|
开发的直接负责人 |
实际上，在开发过程中必须确保每一部分工作的质量均由特定的人进行管理，遇到变更时再优先和负责人讨论后作出妥协或决定 |
|
时间节点的设置 |
各任务必须给出预算的时间节点，供项目经理搭建出流水方式的工作进度管理 |
|
依赖关系的重视 |
确保架构上的依赖关系，进度上的时间依赖关系有足够的容错能力，保证在后续的调整过程中，不会出现集市的空档期 |
因此，基于集市管理的基本方法，在团队整体的项目管理中采用“局部流水处理”和“整体并行处理”的方式进行管理，其基本的贡献和资源分配情况可以如下图所示，这里做出一定的说明：
n 圆点的面积代表任务的燃尽情况，同总任务的比率；而此图以3天为时间粒度进行划分，展示每3天的团队开发进程
n 其中面积较大的点：此阶段处于局部流水区域；后端开发、前端开发、前后端对接工作积累至模块对接阶段，此部分工作主要涉及子任务的对接，前后端的代码复审，因此此部分任务量相对较大
n 其中面积较小的点：此阶段处于局部并行区域：由于三部分开发工作能够分割为独立的开发工作，因此此阶段工作处于局部的并行区域
0x0304：团队开发模式评估
|
项目 |
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的文档版本和测试报告） |
0x0308：团队基本分工职责
|
王鹿鸣 |
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 学习文档整理、技术平台整理 |
0x030c：团队部分问答解释说明
|
问题描述 |
回答说明 |
|
我们有足够的资源来完成各项任务么? |
从基本的资源分配中可以看出，经历两轮迭代和技术栈更新的团队，在开发效率几乎与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阶段必须开展 |
0x04 ：变更管理
|
ü 每个相关的员工都及时知道了变更的消息? ü 我们采用了什么办法决定“推迟”和“必须实现”的功能? ü 项目的出口条件（Exit Criteria – 什么叫“做好了”）有清晰的定义么? ü 对于可能的变更是否能制定应急计划? ü 员工是否能够有效地处理意料之外的工作请求？ |
0x0400：消息传递机制
|
消息传递机制 |
具体说明 |
|
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记录进行查看并进行小范围的修改和维护 |
0x0404：紧急计划和变更说明
|
职能说明 |
具体工作评估 |
|
团队项目进度协调 |
“不管是开源还是商业化，都必须要有一个人对整个项目负责。不是两个人，不是三个人，而是一个人“，这里笔者经过两轮迭代的开发暂时不予支持这一观点。这里负责的概念，笔者从技术和进度上给出负责的定义： l 技术负责：团队能够依据目前的开发状况，更新技术栈，并稳定基础架构，针对不同情况给出不同的解决方案 l 进度负责：团队能够根据目前的进度状况和预期计划，更新进度日程和前后端对接进度，保证开发模式和进度呈现稳定发展 因此，笔者所处的团队基本处于两人的负责的阶段，技术负责交付架构师，进度负责交付笔者，而平台的对接沟通工作交付平台对接人员，三方面对团队进行负责，最终保证Beta阶段团队项目能够稳步进行，完成最后的预期开发 |
|
团队项目进度的干预 |
团队的全部成员本身从态度和能力上都非常靠谱，交付的任务和挑战都能尽力完成且交付的版本都几乎和最终归档的版本相差不大。但团队同样会经历部分任务的“卡壳“阶段。 在开发中期，团队的前端页面的迁移工作一度陷入迟滞，由于前端迁移人员纠结在主页面的标签云迁移工作，而正常的工作难以继续开展；因此此时项目经理需要适时干预进度，将此部分任务标签后移，并提供不同的解决方案供技术负责参考，并完成进度的迁移 |
0x05 ：设计与实现工作评价
|
ü 设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？ ü 设计工作有没有碰到模棱两可的情况，团队是如何解决的？ ü 团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？ ü 什么功能产生的Bug最多，为什么？在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况? ü 代码复审（Code Review）是如何进行的，是否严格执行了代码规范？ ü 我们学到了什么? 如果历史重来一遍, 我们会做什么改进? |
0x0500：设计工作安排
|
王鹿鸣 |
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 结对编程、前端 |
|
0x0504：测试部分以及bug修复
n 用户管理模块（手工测试）
|
测试项目 |
BUG测试说明 |
修复情况说明 |
|
正常注册 |
—— |
—— |
|
正常登陆 |
—— |
—— |
|
提示信息出现错误，此BUG经调研涉及Semantic UI框架本身标记的BUG |
已修复 |
|
|
错误信息登陆 |
后端验证中提示信息出现错误，此BUG提供网页前端验证的解决方案 |
已修复 |
|
非法信息注册 |
—— |
—— |
|
资料查看 |
可能出现部分资料属性返回空值的情况，经调研此问题涉及部分POST机制，交付Exception模块处理即可 |
已修复 |
|
资料修改 |
—— |
—— |
n 标签搜索模块（手工测试）
|
测试项目 |
BUG测试说明 |
修复情况说明 |
|
搜索存在的标签 |
搜索结果未进行分页，页面显示过长 |
已修复；前端开发人员重新设计布局并使用分页布局JS和CSS完成BUG的校服 |
|
搜索不存在的标签 |
为搜索到返回结果，无提示信息；特别说明，此BUG属于后期测试时用户提供的BUG标签，因此在Beta阶段完成此BUG的修复工作 |
已修复 |
|
对搜索框进行注入 |
—— |
—— |
|
直接点击Tag进行搜索 |
—— |
—— |
n 问答模块（手工测试）
|
测试项目 |
BUG测试说明 |
修复情况说明 |
|
问题搜索 |
—— |
—— |
|
回答展示 |
此部分展示效果根据用户的反馈，其UI美化相对较差，因此可能需要重新布局和排版 |
未修复 |
|
问题提出 |
—— |
—— |
|
相关问题推荐 |
—— |
—— |
0x0508：团队Beta阶段的架构反思说明
Beta阶段我们的设计方案是这样的，我们可以将整个项目理解为这样：APP和网页全部是学霸项目的一种前端， 也就是说，我们可以做一个统一的后端，然后，前端只负责展现以及处理必要的用户逻辑。 这样，APP和WEB页面都通过URL调用统一的后端，我们不但接口能够统一 ，而且还能够实现完美的互操作。那么前后端之间如何沟通呢？回忆起老师当初提及的XML，我们联想到了现在很多网站都在使用的JSON。 前端应用和后端之间采用JSON进行交互，前端的所有功能均通过调用后端API来实现。同时，这里特别回顾Alpha阶段社团平台的“WoWoTou“团队，他们采取了前后端分离的设计方案，从最终展示效果观望，这样的开发整体效果很理想，团队的组织很有序。前后端的开发工作就可以实现解耦。同时，由于我们团队本身和Dream组共同开发后端，双方共享了一部分开发力量，所以后端整体的开发成本会降低很多， 可以实现双赢。
因此，基于以上基本情况的铺垫，目前整体的开发流程能够接近于Flux的开发思路。首先回顾之前的方案，若仍然沿用现有的结构，将前端理解为通过AJAX向后端请求数据的单页应用，很有可能导致项目崩溃，而页面也堆叠为由各种JS和CSS混杂的大泥球。因此，我们将前端进一步工程化、专业化。引入更现代的前端开发技术：Webpack和ReactJS，而将页面设计为Flux架构的单页应用。Webpack用于处理各个模块间的依赖关系，处理ReactJS、ES6等，并最终将其编译为可以使用的静态资源；ReactJS是目前我们所能找到的最强力的用于构建数据变化频繁的应用的框架，上手容易，设计简洁；在前端工程化并转换为单页应用后，我们可以获得额外的一些好处：
ü 前后端开发耦合性降低，相互间更为独立
ü 混乱的JS代码可以被整合起来了
ü 后端的代码重复可以得到一定程度的解决（因为后端的重复主要是为了渲染模版。现在前端主动从后端获得数据了，相应问题得到解决）
ü 开发效率提高
Flux架构的思路较为清晰，可以很简单地理清现有前端代码混乱的思路。由官方网站可以看到，Flux架构是对MVC模式的一种创造性的改进。Action由全局唯一的Dispatcher分发到各个Store。 Store负责处理业务逻辑，并更新其所维护的数据。数据的改变最终流向View。View获取到用户输入后触发Action。整个数据流沿着单一的方向流动，程序逻辑十分简洁清晰。
0x05 ：测试工作计划评价
|
ü 团队是否有一个测试计划？为什么没有？ ü 是否进行了正式的验收测试？ ü 团队是否有测试工具来帮助测试？ ü 团队是如何测量并跟踪软件的效能的？从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？ ü 在发布的过程中发现了哪些意外问题？我们学到了什么? 如果历史重来一遍, 我们会做什么改进? |
0x0500：团队部分问题说明
|
问题描述 |
回答说明 |
|
团队是否有一个测试计划？ 是否进行了正式的验收测试？ |
此部分内容具体可以翻阅团队的测试报告，这里给出详细的链接： |
|
团队是否有测试工具来帮助测试？ 团队是如何测量并跟踪软件的效能的？从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？ |
n 团队的测试代码经过协商，其关于压力测试、安全测试等方面的脚本均为闭源代码，此部分工作沿用Alpha阶段的工作继续进行 n 团队的网站的相关测试直接通过手动测试完成了相关内容，具体的信息仍翻阅团队测试报告即可（http://www.cnblogs.com/bugphobia/p/5117731.html） |
|
在发布的过程中发现了哪些意外问题？我们学到了什么? 如果历史重来一遍, 我们会做什么改进? |
n 开发前期整体进度较慢，及因此有充足的时间进行代码复审，代码完成的质量也比较高。而进入后期的最终冲刺阶段后，功能更新速度提升，每天都会有很多新的代码，因此复审的工作便落后于代码编写的进度，这直接导致了一部分代码未经过复审就上线发布。然而问题是，这些直接发布的代码质量普遍偏差，可扩充性不好，不满足后期开发的需求。因此，这一段代码我们将在整理阶段进行删减和部分重构。 n 同时，在Beta阶段的开发中，单元模块测试明显不足，大量的测试不足以覆盖模块中的所有代码。后期也存在了一部分没有经过单元模块测试就迁入的代码，这都将对应用的稳定性造成很大影响。 |
0x06：总结
|
问题描述 |
回答说明 |
|
你觉得团队目前的状态属于CMM/CMMI 中的哪个档次? |
笔者观点，团队处于其中的最多可以算上管理级，在Alpha阶段我们的团队用行动证实了我们可以实现完成级的突破，在本次的Beta阶段我们认为我们的团队实现了明确任务，细化责任的工作，通过结对编程我们将成员的任务具体化、明确化。每一个模块都有专门的成员负责完成。因此，笔者认为这个可以算上是处于管理级的。 |
|
你觉得团队目前处于 萌芽/磨合/规范/创造阶段的哪一个阶段? |
整体团队目前是处于规范的阶段，因为在Beta阶段正是通过一系列的规范的制定才实现了最终的4个组之间的衔接 |
|
你觉得团队在这个里程碑相比前一个里程碑有什么改进? |
整体团队更加懂得分享和合作了，在这个阶段我们通过组间的合作将以前孤立的系统进行了融合我们摈弃了我们之前爬取的所有的数据将数据处理组的数据作为我们后台数据的全部，成员之间也更加熟悉，相互的孤立使得彼此能在“恶劣”的大作业纷飞的环境下依然为软工尽心竭力。 |
|
你觉得目前最需要改进的一个方面是什么? |
时间规划是我们一开始的劣势，如果有可能的话我们希望我们现在的Beta阶段成为我们当初的Alpha阶段，然后在现在的基础上进行更深入的开发。所以我们希望留下尽可能多的文档和资料让后来的开发者能够尽快达到我们现在的层次从而在此基础上进行开发和创新。 |