BugPhobia回顾篇章：团队Beta 阶段工做分析

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：团队部分问题说明

问题描述	回答说明
团队是否有一个测试计划？ 是否进行了正式的验收测试？	此部份内容具体能够翻阅团队的测试报告，这里给出详细的连接： http://www.cnblogs.com/bugphobia/p/5117731.html
团队是否有测试工具来帮助测试？ 团队是如何测量并跟踪软件的效能的？从软件实际运行的结果来看，这些测试工做有用么？应该有哪些改进？	n  团队的测试代码通过协商，其关于压力测试、安全测试等方面的脚本均为闭源代码，此部分工做沿用Alpha阶段的工做继续进行 n  团队的网站的相关测试直接经过手动测试完成了相关内容，具体的信息仍翻阅团队测试报告便可（http://www.cnblogs.com/bugphobia/p/5117731.html）
在发布的过程当中发现了哪些意外问题？咱们学到了什么? 若是历史重来一遍, 咱们会作什么改进?	n  开发前期总体进度较慢，及所以有充足的时间进行代码复审，代码完成的质量也比较高。而进入后期的最终冲刺阶段后，功能更新速度提高，天天都会有不少新的代码，所以复审的工做便落后于代码编写的进度，这直接致使了一部分代码未通过复审就上线发布。然而问题是，这些直接发布的代码质量广泛误差，可扩充性很差，不知足后期开发的需求。所以，这一段代码咱们将在整理阶段进行删减和部分重构。 n  同时，在Beta阶段的开发中，单元模块测试明显不足，大量的测试不足以覆盖模块中的全部代码。后期也存在了一部分没有通过单元模块测试就迁入的代码，这都将对应用的稳定性形成很大影响。

 

0x06：总结

问题描述	回答说明
你以为团队目前的状态属于CMM/CMMI 中的哪一个档次?	笔者观点，团队处于其中的最多能够算上管理级，在Alpha阶段咱们的团队用行动证明了咱们能够实现完成级的突破，在本次的Beta阶段咱们认为咱们的团队实现了明确任务，细化责任的工做，经过结对编程咱们将成员的任务具体化、明确化。每个模块都有专门的成员负责完成。所以，笔者认为这个能够算上是处于管理级的。
你以为团队目前处于 萌芽/磨合/规范/创造阶段的哪个阶段?	总体团队目前是处于规范的阶段，由于在Beta阶段正是经过一系列的规范的制定才实现了最终的4个组之间的衔接
你以为团队在这个里程碑相比前一个里程碑有什么改进?	总体团队更加懂得分享和合做了，在这个阶段咱们经过组间的合做将之前孤立的系统进行了融合咱们摈弃了咱们以前爬取的全部的数据将数据处理组的数据做为咱们后台数据的所有，成员之间也更加熟悉，相互的孤立使得彼此能在“恶劣”的大做业纷飞的环境下依然为软工尽心竭力。
你以为目前最须要改进的一个方面是什么?	时间规划是咱们一开始的劣势，若是有可能的话咱们但愿咱们如今的Beta阶段成为咱们当初的Alpha阶段，而后在如今的基础上进行更深刻的开发。因此咱们但愿留下尽量多的文档和资料让后来的开发者可以尽快达到咱们如今的层次从而在此基础上进行开发和创新。