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

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:// 10.2.26.67

 

0x01 ：敏捷开发原则评估

0x0100：敏捷开发的基本原则

（1）尽早并持续地交付有价值的软件以知足顾客需求。 （2）敏捷流程欢迎需求的变化, 并利用这种变化来提升用户的竞争优点。 （3）常常发布可用的软件，发布间隔能够从几周到几个月，能短则短。 （4）业务人员和开发人员在项目开发过程当中应该天天共同工做。 （5）不管团队内外，面对面的交流始终是最有效的沟通方式 （6）以有进取心的人为项目核心，充分支持信任他们 （7）可用的软件是衡量项目进展的主要指标 （8）敏捷流程应能保持可持续的发展。 领导, 团队和用户应该能按照目前步调持续合做下去。 （9）只有不断关注技术和设计才能愈来愈敏捷. （10）保持简明 - 尽量简化工做量的技艺 - 极为重要。 （11）只有能自我管理的团队才能创造优秀的架构, 需求和设计. （12）时时总结如何提升团队效率, 并付诸行动。

 

0x0104：敏捷开发的团队评估

从基本的论述方案中，BugPhobia团队通过严谨论述，分析认为对于如下三方面的原则，团队在敏捷开发阶段感觉最为深入：

（5）不管团队内外，面对面的交流始终是最有效的沟通方式 （9）只有不断关注技术和设计才能愈来愈敏捷. （12）时时总结如何提升团队效率, 并付诸行动。

实际在学霸在线系统Alaph阶段的开发工做中，不妨首先去借用《构建之法》中总结的敏捷原则，去印证团队在软件开发过程当中对效率和讨论的专一调研。

在团队敏捷开发的实践过程当中，团队自己时刻总结有利于提升咱们团队效率的方法，而且切实实践，咱们在提高效率的过程当中密切关注技术和设计，以使得咱们的开发流程总体敏捷效率较高，并呈现稳步上升的趋势。所谓“磨刀不误砍柴工”，基于集市方案的配置，团队架构师致力于尝试新的技术和工具，而且在面对面的交流之中将其推广给团队的全部的开发人员，虽然前期的学习成本不容忽视，甚至因为团队管理疏忽而没有正视高昂的学习成本，使得在软件开发的前期阶段一度陷入“力不能及”的消极工做状态，但尽管万事开头难，一段实践与磨合后开发人员与架构技术获得了很好地融合，从而能够将工具的性能极大地发挥出来。正如《构建之法》中强调的观点，“创造和使用工具是人类和普通动物的最大差异”。咱们由于关注技术和设计，勇于尝试新的符合咱们需求的技术和工具，咱们的团队在开发的过程当中愈来愈能感觉获得强大的技术架构带给开发人员的生产力的大解放，而在遭遇Scrum Meeting事件危机后，团队自己迅速机动处理，采用了组内结对编程的方式，进一步提高了效率。

 

图 1 BugPhobia团队在Alaph阶段结束的过渡期间的“反思与展望“聚餐（捂脸）

 

在总体的开发流程中，正如“不管团队内外，面对面的交流始终是最有效的沟通方式“所言，经过真正例会的反思和总结，团队自己可以从架构、设计、开发、测试的方向依次评估，从不一样角度把握进度自己的影响，尽量保证此前设计的”流水线“工做方案可以稳定而高效的执行（关于流水线方案的执行效果，详情分析请参阅0x04：设计与实现工做评价），而不一样方面的评估，才能依据各流水线的执行情况，不只能够解决当下的问题，并且也能让组员了解下一步要完成的任务对项目自己的意义所在。这在很大的程度上提高了咱们的效率。

暂且抛开书上总结的敏捷原则，Martin Fowler总结的敏捷方法的两个特征在咱们组上都有明显的体现：

首先是适应性优于预测性。众所周知，咱们的团队的产品是“爬虫—数据处理—在线系统“这条开发流的最末端，按照预测，咱们应该是顺着这条“完美无缺”的流程华丽地完成咱们的既定任务的，可是很遗憾因为组间协调的部分问题，团队自己并无及时得到相应的数据，可是咱们能够迅速应变紧急制定出一套自主提供数据的框架方案，在既定路线未正常执行的状况下，可以迅速变动需求，紧急完成Solr和Nutch框架的总体部署和开发，完成独立的数据提供模块，虽未完美，却也心安理得。

其次是以人为本。说起以人为本，这里按照大众的思路应该都是将“人“设定为”用户“，然而在敏捷开发的阶段，这里Martin Fowler所总结的人，更主要关注的是”开发者“。在总体的开发模式中，团队始终采用集市式的方式进行团队项目的基本管理和开发，由于首先咱们的项目是有一个基础原型的（虽然遗留的代码框架被推翻重构，但基本的创意和功能定位仍能体现于具体的代码中），其次咱们一直采用集市式的方式进行咱们的团队项目，大多数任务几乎都是本身主动要来的。团队内部的大部分人都很积极，任务也大多数都有明确的人真正去负责，每一个人选择其本身感兴趣的任务去进行。咱们顺利地采用集市式的模式完成了几份高质量的做品。一我的初稿、一我的复审迭代更新、一我的再度审核排版等等，每一个人都出于我的的责任、荣誉以及兴趣等复杂情感，深刻地参与到了整个过程当中。虽然没有很是明确的安排，可是你们都主动承担了某一部分的任务。咱们用集市搭建起了一座教堂，团队开发人员的热情很是高，团队的关系很是融洽，你们一块儿工做斗志十足，效率很高，每个成员都能在这个团队的协做过程当中得到充分的价值体现和归属感。

 

图 2  BugPhobia团队在Alaph阶段的集市式开发剪影

 

对于集市式的开发，更为具体的反思与思考同时也能够关注团队内部成员博客反思的展现：

GNU_Linuxer：http://www.cnblogs.com/fzyz999/p/4963681.html

Fihezro：http://www.cnblogs.com/Fengzr/p/4963514.html

PocketPanacea：http://www.cnblogs.com/panacea/p/4966144.html

Whenever：http://www.cnblogs.com/whenever/p/4963109.html

-OwO-：http://www.cnblogs.com/-OwO-/p/4961662.html

Someonefighting：http://www.cnblogs.com/someonefighting/p/4963118.html

SummerMTY：http://www.cnblogs.com/summerMTY/p/4965973.html

 

0x02 ：设想与目标概述

ü  咱们的软件要解决什么问题？是否认义得很清楚？是否对典型用户和典型场景有清晰的描述？ ü  是否有充足的时间来作计划? ü  团队在计划阶段是如何解决同事们对于计划的不一样意见的？ ü  用户量, 用户对重要功能的接受程度和咱们事先的预想一致么? 咱们离目标更近了么?

 

0x0200：团队需求与实现评价

在此阶段，BugPhobia团队自己再次引用此前的团队需求和分析表格：

网站基本定位	面向CS/EE领域的垂直搜索引擎
网站创新形式	首先，按照《构建之法》中创新类型的划分，在创新的类型上，咱们的产品是改良型的创新，而非颠覆性的创新
用户基本定位	计算机及相关专业学生，其中以大学生群体为最主要的用户群
用户的知识层次	用户具有基本的编程基础，并具有使用通用搜索引擎（百度、谷歌等）的能力
网站的基本功能	网站可以采集专业化社区中的问答数据、高质量课程资源、专业技术文档中的内容，为使用者提供一体化的、精准的、高质量的搜索内容 同时，用户可以经过网站直接参与到上游社区的讨论中

从网站的基础功能上，参照此前学长搭建的网站功能（http://www.cnblogs.com/ourteam/p/4225596.html），简单概述而言，完善的用户个性化管理、完备的问答资源爬取、完善的搜索引擎架构已经基本搭建完成，而与此前搭建网站的Beta版本相比，基本功能的实现已经达到50%左右，而目前主要的需求和实现集中于：“学霸后端数据组的数据规范化”（25%的工做量，但在沟通成本上会很是严重，因此这里采起前端两组联谊共同开发后端的方式，而后订制统一的数据接口，以下降此前其余组所说起的工做量），“课程、问答的具体展现页面优化”（25%的工做量，此部分工做比较“泛化”，主要是将此前的模块从新布局，保证符合用户体验），而在此基础上，团队还额外完成了外部搜索引擎的搭建工做、Phobia助手的交互工做、流媒体的播放预览功能等方面。

所以，综合评价总体的需求和实现方向的映射关系：

ü  用户模块部分的设计：用户模块缺少概念模型的基本构建，但对于已经说起的基本属性已经覆盖；Beta阶段将依据沟通文档（详情请翻阅0x07：沟通工做的进度评价），对这一部分的数据进行json的结构化处理，从而展现与前端的单页应用中

ü  问答模块的设计：基础功能基本搭建完成，从后续的沟通文档中回顾，此部分的设计模型基本符合预期，目前只须要完成Semantic UI向ReactJS的代码迁移工做便可，此部分截至笔者撰写此文时，迁移工做已完成30%左右

ü  课程模块的设计：基本的展现功能搭建完成，但对于具体的数据类型尚无良好的数据结构，所以，此部分须要根据沟通文档对前端方面进行必定程度布局的修改，而非“新功能模块”的开发

ü  Phobia助手的设计：基本功能迁移完成，基础的知识库考虑搭建；若沟通进度进展紧张，此部份内容将维持现状

 

0x0204：时间计划安排和执行状况

 

燃尽图具体数听说明

系列1：预约目标（蓝色直线），是指代预期目标 系列2：实际日均（橙色直线），按照团队自己的实际开发天数，天天应该作到的量 系列3：实际完成（灰色直线），实际完成的工做量

从燃尽图的安排中，团队自己对这次的总体任务分配状况进行了必定程度的阐释：

        高昂学习成本的低估

在项目开展初期，项目自己并未忽视高昂学习成本，但却严重低估了各框架自己的学习成本，Solr、Nutch、Django、Semantic UI框架自己的配置和学习占用了大量的开发时间；而对应到开发阶段，没有很好地把握学习成本和进展之间的平衡，致使开发前期出现了“先后端脱节”“代码复审质量下降”等问题；所以，在Beta阶段，已经开始将学习任务落实到团队的各个成员的工做上，如ReactJS、Semantic UI等框架的学习工做（分别给出3~5天的学习成本用以中和后期的开发工做）。

        任务分工粒度庞大

在这次的燃尽图中，任务按照开发的模块进行划分，例如此前说起的“主页面 —— 用户页面 —— 搜索页面”等方式的模块。但从分工的角度，此阶段的分工粒度较大，致使前期因为数据的匮乏，总体的项目进展缓慢，甚至致使环境配置所有完成后，任务粒度划分较大。所以，在Beta阶段，这次任务分工采用协商的方式，由开发人员完成学习任务的Demo后，给出必定的时间参考，而所有任务排列后，再和具体的负责人协商时间的延长或缩短；进度耽搁后，将严格按照绩效管理进行处理，同时将部分工做量进行转移，保证团队总体进度可以基本按照预期进行燃尽。

        学霸总体系统的流水线需求沟通缺失

今后次的学霸总体组别展现效果，因为缺少必定的协商和沟通，或者说在和另外两组几番讨论后仍未肯定数据的基本结构，团队总体的开发陷入了尴尬的停滞阶段（具体细节能够参阅0x0404：流水线开发的冒险与暂停），而此阶段中，团队出于展现效果和严峻的开发周期，最终额外而独立完成了展现数据的结构化爬取和设计。同时，此问题也出现于开发“学霸APP”的Dream组中，根据数据组的基本抱怨，“因为缺少沟通，咱们和APP组的数据定义相差太多”，而致使数据组“爱莫能助”。所以，在Beta阶段，团队自己将严重重视沟通这一问题，在Alpha阶段向Beta的过渡期（2015/11/17~2015/11/24），团队自己和Dream团队也已经进行了大幅度的沟通工做，从而保证前端组之间可以定义完成的数据接口，并共同同一套后端，以此来充分整合前端两组的工做量，从而保证数据组和爬虫组在数据的格式化和爬取上，下降压力，从而实现团队共赢。

而对于爬虫组、数据组，因为在展现和沟通时，存在“团队自己不提供需求”的误解，这次团队将在近期内发布统一的先后端数据接口，并将需求真正定位到数据层次，再作进一步的讨论。带接口调研完成后，预计于2015/12/1往后开展数据组的沟通工做，此部分沟通工做中，项目经理将全程进行文档备案，并充分保证沟通的高效执行。

        团队成员的责任明确化

在这次的团队分工工做中，因为团队总体处理基础的磨合期，致使团队成员对于责任的制度不清晰，在某些事件上（例如经典的BugPhobia’s Scrum Meetings事件），团队成员的对于责任制不存在清晰的定位，致使大量已经完成的Scrum Meeting文档草稿没有按时发布。所以，考虑到集市式自己的弊端，在Beta阶段，项目经理将特别明确任务的警惕时间和基本负责人，一旦这一段时间内的工做进度并没有转机，将额外选定有足够能力、且适合完成这一任务的人，进行责任的明确化，从而避免集市式模式失效后直接的崩盘。

 

0x03 ：团队协做与计划核定

ü  你原计划的工做是否最后都作完了? 若是有没作完的，为何? ü  有没有发现你作了一些过后看来不必或没多大价值的事? ü  是否每一项任务都有清楚定义和衡量的交付件? ü  是否项目的整个过程都按照计划进行，有什么风险是当时没有估计到的，为何没有估计到? ü  在计划中有没有留下缓冲区，缓冲区有做用么? ü  未来的计划会作什么修改？（例如：缓冲区的定义，加班）

 

0x0300：团队集市式管理评价

集市式管理方式积极端

高效且积极的开发效率 ü  初期根据高昂的学习成本，制定了架构师和团队其余成员的结对编程方案，同时立会时特别依据各人的疑问和困惑进行解答，保证了团队在重构轮子的初期不会由于高昂的学习成本而严重拖延进度； ü  中期根据他组的协商结果，制定了依据“必定原则”的尽量独立效率编程，虽然说在最终的耦合结果并不理想，但这次尝试也基本确立了团队各成员的基本开发方向，开发沟通渠道的思路； ü  后期，根据敏捷开发的剩余需求，采用先后端对接方式的结对编程，极其高效地完成了各部分的收尾工做。         管理方式灵活高效 ü  自主申请任务，确保思路灵活，开发高度积极 ü  各任务均存在必要负责人

 

集市式管理方式弊端

缺少高度的责任制管理 ü  每日立会、每日例会、每宿舍例会均是正常进行，不管是初期的结对编程“培训”或是中后期的数据对接上，此方面的立会均能有效保证先后端的高效对接，在必定程度上弥补了中期任务分配失衡的错误；但最核心的问题，就是负责人的指定，也就是责任的单一化！所以，手中积累了大量的松散记录和项目草图，却一直未能有效整合；同时，负责维护的少年也对内容审核过于严苛，致使文档发布拖延形成了严重的后果。如今回顾，若当初可以将责任高度单一化，并确保能力足够，可能进展会更为顺利         用集市搭建了教堂，却忽视了“兴趣”和“责任”的非等价关系 ü  咱们顺利地采用集市式的模式完成了几份高质量的做品。一我的初稿、一我的复审迭代更新、一我的再度审核排版等等，每一个人都出于我的的责任、荣誉以及兴趣等复杂情感，深刻地参与到了整个过程当中。虽然没有很是明确的安排，可是你们都主动承担了某一部分的任务。咱们用集市搭建起了一座教堂。 ü  以前的成功使得咱们没能认清楚上面所叙述的一些本质性的东西，从而致使了后面的问题。我认为其中最主要的是第一条：项目必须首先是你感兴趣的，最终对其余人有用的。以前构筑的一系列文档，源自团队中对于文字有执着追求的青年的努力，也源自团队自身开发设计的需求，所以，你们参与得较为深刻。特别是一些每一个成员都可以用到的文档，好比设计文档、需求分析等等。然而，咱们没有认识到'每日立会'的会议记录的做用，于是也没有人对其感兴趣。你们都以为，这个东西彷佛没那么重要，没有给予太多的重视。如今回想起来，我以为这确实是违背了上面的第一条条件：项目必须首先是本身感兴趣的。没有人愿意关注的东西，天然难以采用集市式的方式进行。因而，在这一次，集市没有起到任何做用，咱们一直所倚靠的集市式成了低质量的罪魁祸首。

 

在经历了这样许多以后，我认为，咱们依旧须要坚持咱们所一直依赖的集市式模式，它是咱们成功的基石。但在此之上，咱们必须另想办法解决那些不适用于它的情景。在我看来，一个适合咱们团队状况的开发模式是这样的：对于每个任务或者需求，首先应当尽可能采用集市式的思路去完成它。但同时，咱们应当设置一个警惕时间。若是超过这个时间依旧没有任何转机，那么就说明集市模式已经再也不适用于这个任务或需求了。咱们应当综合各方面意见，选定一个特定的，有足够能力的且适合完成这个任务的人。让他为此事负责，这样才能产生足够的质量。从而避免集市式模式失效后直接崩盘的惨痛结果。

 

0x0304：前端AND 后端

前端—后端对接

“半独立开发”形成冗杂交流 ü  从项目自己的架构出发，Seamantic UI的前端框架和Django框架相比，学习成本相对较低，所以不可避免遇到设计—前端的组合进度提早于后端进度；所以，在经过必定的协商规则，让设计—前端组合优先整理需求，并反馈给后端调研可行性，但也致使后期，先后端对接过程两方均作出了必定的修改，同时对接也更加依赖“全栈工程师”协调；

所以，在第二轮迭代的过程当中，团队将优先保证设计层次的对接。扩展来说，先后端将优先以相似“E-R图”的方式进行逻辑层次的设计，同时，尽量采起阶段性的结对编程，实时完成需求变动的编码实现，具体

 

0x0308：NOT 任务责任集中/他组协商工做

NOT 任务责任集中

详情可翻阅0x0300：教堂OR集市模式

 

NOT 他组协商工做

考虑中间层的搭建工做（鉴于第一轮迭代的Nutch插件开发思路未被采纳）         优先整合另外两组原有的接口         协商额外需求的特性         及早进行接口、功能方面的沟通和整合         经过交换人员来创建更有效的沟通渠道

 

0x04 ：设计与实现工做评价

ü  设计工做在何时，由谁来完成的？是合适的时间，合适的人么？ ü  设计工做有没有碰到模棱两可的状况，团队是如何解决的？ ü  团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其余工具来帮助设计和实现？这些工具备效么？ ü  什么功能产生的Bug最多，为何？在发布以后发现了什么重要的bug? 为何咱们在设计/开发的时候没有想到这些状况? ü  代码复审（Code Review）是如何进行的，是否严格执行了代码规范？

 

0x0400：团队原定的开发流程

在Alpha阶段的团队开发流程中，团队自己为了减小沟通交流成本，制定了一个流水线式的开发流程：

设计：由团队中的原型设计人员梳理需求逻辑，利用Pencil原型工具制做出简易的原型。这个原型图主要展示出页面布局，各个控件、内容的布局，以及总体的页面逻辑。

前端：原型设计图完成后，交付前端人员实现。前端人员把原型图制成静态页面。用Semantic UI框架来实现原型图中的各处设计。

后端：页面完成后交付后端人员。后端人员实现后端的功能，而后将静态页面整理成Django模版，并最终让页面“动起来”。

测试：“动起来”后的页面交由测试人员负责测试（蕴含的单元测试天然由开发人员首先覆盖完成）

这样的一套开发流程最主要的意图有两个：减小沟通次数，下降学习成本。

在这种流水线式的开发流程中，前端人员能够彻底不用接触动态网页部分的知识，只需真正实现清楚的静态页面；然后端人员只须要看着前端人员的页面，将全部的部分整理为Django模版，并在后端实现对应功能便可，无需再和前端人员作太多沟通。同时，利用流水线式的开发让你们的工做尽可能能够并行地进行，提供人力资源的利用率。

 

0x0404：流水线开发的冒险与暂停

什么是流水线的冒险和暂停：在计算机组成中，流水线CPU设计式，先后两条指令若是都使用了某个寄存器，则可能致使数据冒险。遇到这种状况，CPU就不得不暂停，即在流水线中插入空指令以规避冒险。

团队自己设计的流水线式开发流程也遇到了如同定义所描述的相似问题，然而，在团队开发的初期，因为缺乏必定的处理，致使了此流程的流水线被迫陷入流水线的暂停工做。

首先将团队问题映射到“页面设计“阶段，在最初的开发阶段中，因为流水线式开发的核心理念没有传达得太明确，设计人员试图作出一份至关完整的界面设计，甚至将配色和模块精确到像素级别。然而，咱们约定使用的Pencil原型绘制软件是绝对作不出相似效果的，并且也并不须要作出那样。因为这样一个传达上的失误，致使了大约半天的拖延。而在此后的设计阶段，团队自己的流水线缺少了必定的交互，致使设计图自己出的也较慢，这里最重要的交互在于”前端技术实现“和”设计理想实现“的差别，设计人员自己不了解Semantic UI具体的特性和效果，致使前端人员和设计这里很难接洽。所以，在最初的开发阶段，前端人员连同设计的工做一同承担，是流程自己的第一处问题。

然而，团队流程进一步的问题集中到“数据来源“的问题，团队自己并不了解其余两组如何将数据反馈给咱们。而通过和另外两组几番讨论，这件事仍旧未能肯定下来。致使了整个后端处于彻底的停滞状态。咱们的流水线开发流程暂停了大量的时间（数天），最后才决心采用本身的数据和框架结构来推进开发稳定实现。而团队自己设计数据和规范数据部分的内容，团队开发才继续执行，而此时距离开发的结束期限已然很少。

总览而言，用最通俗的话语去解释，Alpha阶段开发初期最大的问题就在于数据供给这一部分的停滞。因为和其余组沟通带来的问题，团队的开发节奏略微自乱阵脚。部分同窗不知道该去作什么，部分同窗想作些事情又迫不得已。

 

0x0408：结对编程：流水线开发的起色

当开发时间急剧缩短时，流水线开发自己的模式已经难以适应具体的开发工做，所以，考虑到问题自己在于先后端的交流和数据依赖相对缺失，所以，开发流程总体趋向于“结对编程“的方式进行调整。在此阶段，因为团队自己的的Solr和StackExchange自己爬取的数据已经基本到位，而且可以知足开发和展现的部分需求，此时，阻碍后端进展的最大问题已经被妥善解决，进一步所需的工做，就是以最快的速度解决完全部的问题。

此时，咱们采用告终对编程这种方案。而在功能的定位和划分上也尽量经过面对面的交流和文档传递的方式进行解决，同时对于新功能，也采起团队Scrum Meeting协商开发时间和需求定位进行平衡，所以，在敏捷开发阶段，学霸在线系统的基本功能稳步开发和上传，同时，新功能的提议和开发也稳步部署于服务器端和系统端。在此阶段，敏捷开发的效能真正的体现出来了，积蓄已久的“开发势能”，恰到好处地迸发出来。此前，总体的前端页面已经彻底准备就绪，而仅仅缺乏后端对页面的“动态化“处理，而结对编程颇有效地发挥了咱们积蓄已久的积极性。

通过了长达几周的磨合，团队成员间相互也很是熟悉了。同时，对于需求的理解也基本达成一致。所以，现实的压力又迫使咱们高效地完成余下的任务。结对编程正好有了用武之地。其结对编程效率呈现高度的高效性真正地体现出来，以致于测试人员在这一阶段感慨“敏捷到测试都没法彻底执行“

 

0x040c：Alpha阶段的总结概述

过后总结起来，Alpha阶段最主要的问题还在于先后端耦合度过高，先后端人员无法单独进行开发。咱们试图让后端人员接收前端中和后端相关的部分。结果后端开发工做的问题显得十分明显。后端进行不下去的时候，前端只能写写静态页面，而无法帮忙制做Django模版。先后端的分离很差。何况Alpha阶段的最后，团队迫于项目压力，进行了一轮“大跃进”式的开发。结对编程高效是高效，但代码质量着实通常。这轮开发达成的成果是显著的，但与此同时，粗放式的开发也为Beta阶段遗留了必定的问题

 

0x0410：Beta阶段的过渡与重生

在Alpha阶段，团队对敏捷开发过程的主要问题进行了基本的梳理工做：

ü  VIEWS代码存在重复，不少函数用于渲染模版的字典是类似的 ü  DJHTML的代码有大量重复，主要是不少模版都很是类似 ü  JS代码混乱，CSS和JS缺少有效整理 ü  先后端开发都没有留下相对有效的接口文档 ü  须要其余组统一接口，数据以及APP组都须要可以接到一块儿 ü  部分UI效果须要重写

所以，在基于以上的代码“历史问题“，团队权衡后也给出了必定的解决之道：

首先回顾数据组的基本抱怨：“因为缺少沟通，咱们和APP组的数据定义相差太多“，所以数据组认为目前想支持都很是困难。而学霸APP组自己也在困扰数据的类型和结构等问题。所以，在Beta阶段，如何有效衔接成为了摆在咱们这四个组面前的最大问题。所以，基于数据沟通的问题，在过渡阶段，团队自己首先选择了和APP组进行沟通，力图统一咱们两组的接口。而统一必然要带来必定的重构。 如何下降重构成本，以及如何沟通，都成为了摆在咱们面前的大问题。最终，咱们提出了一个相对合理的方案，而且获得了APP组的承认。 双方正在就具体细节进行进一步的沟通。Beta阶段咱们的设计方案是这样的，咱们能够将整个项目理解为这样：APP和网页所有是学霸项目的一种前端，也就是说，咱们能够作一个统一的后端，而后，前端只负责展示以及处理必要的用户逻辑。这样，APP和WEB页面都经过URL调用统一的后端，咱们不但接口可以统一 ，并且还可以实现完美的互操做 。那么先后端之间如何沟通呢？回忆起老师当初说起的XML，咱们联想到了如今不少网站都在使用的JSON。 前端应用和后端之间采用JSON进行交互，前端的全部功能均经过调用后端API来实现。同时，这里特别回顾社团平台的“WoWoTou“团队，他们采起了先后端分离的设计方案，从最终展现效果观望，这样的开发总体效果很理想，团队的组织颇有序。先后端的开发工做就能够实现解耦。同时，因为咱们团队自己和Dream组共同开发后端，双方共享了一部分开发力量，因此后端总体的开发成本会下降不少， 能够实现共赢。

所以，基于以上基本状况的铺垫，目前总体的开发流程可以接近于Flux的开发思路。

首先回顾以前的方案，若仍然沿用现有的结构，将前端理解为经过AJAX向后端请求数据的单页应用，颇有可能致使项目崩溃，而页面也堆叠为由各类JS和CSS混杂的大泥球。

所以，咱们将前端进一步工程化、专业化。引入更现代的前端开发技术：Webpack和ReactJS，而将页面设计为Flux架构的单页应用。

Webpack用于处理各个模块间的依赖关系，处理ReactJS、ES6等，并最终将其编译为能够使用的静态资源；ReactJS是目前咱们所能找到的最强力的用于构建数据变化频繁的应用的框架，上手容易，设计简洁；在前端工程化并转换为单页应用后，咱们能够得到额外的一些好处：

ü  先后端开发耦合性下降，相互间更为独立

ü  混乱的JS代码能够被整合起来了

ü  后端的代码重复能够获得必定程度的解决（由于后端的重复主要是为了渲染模版。如今前端主动从后端得到数据了，相应问题获得解决）

ü  开发效率提升

Flux架构的思路较为清晰，能够很简单地理清现有前端代码混乱的思路。由官方网站能够看到，Flux架构是对MVC模式的一种创造性的改进。Action由全局惟一的Dispatcher分发到各个Store。 Store负责处理业务逻辑，并更新其所维护的数据。数据的改变最终流向View。View获取到用户输入后触发Action。整个数据流沿着单一的方向流动，程序逻辑十分简洁清晰。

 

 

图 3 Flux框架的基本思路和流程图

（特别鸣谢来源：http://facebook.github.io/flux/img/flux-simple-f8-diagram-with-client-action-1300w.png）

 

0x05 ：测试工做计划评价

ü  团队是否有一个测试计划？为何没有？ ü  是否进行了正式的验收测试？ ü  团队是否有测试工具来帮助测试？ ü  团队是如何测量并跟踪软件的效能的？从软件实际运行的结果来看，这些测试工做有用么？应该有哪些改进？ ü  在发布的过程当中发现了哪些意外问题？

 

0x0500：基本测试计划

 

功能测试	模拟用户的使用方式进行的测试，属于黑盒测试。在这一阶段的测试中，不经过阅读代码的方式反复尝试全部用户可能的使用方式，探索可能出现的问题。在M1阶段，全员参与到了这一阶段的测试中。测试的项目包括但不限于：全部输入框的输入、页面之间的跳转关系是否正常、资料修改的结果可否保存、Tag云可否进行有效点击、对于通常错误请求可否给出响应等。除此以外，咱们还使用修改过的爬虫对网站进行整站连接的访问，确保每个连接都指向了有效的地址。 测试中出现了一些Bug，其中影响主要功能的均已修复完成，但依然有少许非功能性bug尚待修复。
安全性测试	安全性测试主要进行的是注入测试和csrf攻击测试。在M1阶段，网站存在的主要注入点是输入框（登陆注册框和用户资料框）和页面跳转连接。注入测试主要使用了功能全面的Sqlmap和BSQL Hacker，在手工注入阶段使用Burp进行抓包并修改。首先尝试对数据库进行盲注入，探测数据库类型及存在的表，均得不到结果。随后，尝试使用部分信息注入的方式，发现存在有效注入点，反馈给后端人员进行修改。对于csrf攻击，因为django的框架自身存在反攻击措施，均未成功。
白盒测试	在进行完功能测试和安全性测试后，我开始了白盒测试。前段实现采用了Sementic-UI的响应式布局，测试时着重测试了响应式布局的实现是否正确。经过阅读代码不难发现，实现的方式确实知足响应式的方式，可是一些细节的控制还欠缺问题，如Text的宽度可能超过一个grid，致使在响应式生效时可能超出区域，显示出现问题。后端实现使用django框架，功能实现基本正确，可是缺乏一些基本的安全防御措施，如对于用户输入的限制只在前段进行，后端不作检查。多数问题在后期反馈后已修复。
服务器压力测试	使用Pylot进行服务器的压力测试。pylot能够指定链接到服务器的客户端数量以及持续的运行时间，能够获得在一段时间内的请求数以及服务器的平均相应时间、各比例的相应时间和无响应数。使用LoadRunner模拟用户的请求，进行连续访问，获得测试结果图。 在所有服务迁移至新的服务器以前，咱们使用的阿里云的性能太低，不足以支撑咱们须要的功能，所以缺失率极高（保持在50%左右）。在切换至新的服务器后，能够确保知足200用户的并发访问，基本不会出现拒绝服务的状况。

 

0x0504：测试流程反馈的问题

开发前期总体进度较慢，及所以有充足的时间进行代码复审，代码完成的质量也比较高。而进入后期的最终冲刺阶段后，功能更新速度提高，天天都会有不少新的代码，所以复审的工做便落后于代码编写的进度，这直接致使了一部分代码未通过复审就上线发布。然而问题是，这些直接发布的代码质量广泛误差，可扩充性很差，不知足后期开发的需求。所以，这一段代码咱们将在整理阶段进行删减和部分重构。

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

 

0x06 ：Bug反馈机制与TDD模式评价

0x0600：Bug分类设定与处理标准

Bug	基本诠释	解决方案
开发级Bug	我的开发和对接时遇到的BUG，其特色为阻碍开发的进度。同时此类BUG因为单元测试和架构自己，可以很快的发现，涉及的模块较少	因为咱们采用的集市化管理结对式开发，因此对于我的开发的过程当中遇到的bug就两个开发人员想办法解决就是了；而后在对接过程当中遇到的问题，你们都会聚到一块儿来讨论问题的所在，同时解决问题
测试级Bug	在测试人员进行测试时遇到的bug，其特色为隐秘，更多的涉及到安全与性能的问题	这类问题，咱们一般都是测试人员在每日例会上面说明测试发现的bug，而后当场分析多是谁的模块出了问题，而后相应的人员去进行修复
用户级Bug	在发布后用户反馈的bug，其特色为须要尽快的解决，同时在整个项目中涉及的模块比较多	当接到用户的反馈时，咱们第一时间让架构师负责，由于咱们的架构师也是项目的全栈工程师，因此经过他的分析定位出bug的所在，而后再召集相关人员快速处理

 

0x0604：TDD模式反思与评价

BUG缺乏必定的记录和备案	因为咱们的bug解决起来仍是比较快速的，因此没有去记录遇到的bug，也不明确什么程度的bug须要记录在案。可是在下一个阶段咱们会明确这个方面，增长bug的备案
BUG的解决上缺乏问责制度	虽然咱们可以将bug较快速的解决，可是这个主要缘由仍是在于咱们的全栈能力比较强。因此目前发现一个问题，因为没有明确BUG的责任人和强制的时间要求，因此不可以让bug在独立解决很流畅

这里在评价上，给出必定的BUG解决样例做为反思的基础：

ü  在问答展现模块的开发过程就出现了一个BUG，因为有一些VIEWS函数的URL映射是不一样的成员开发的，当时出现了CRSF的异常，这是因为几个静态页面致使的，可是当时因为这方面的沟通没有进行好，致使这样的小问题未在单元测试部分解决，而所以从新查找和确认

ü  在测试环节，测试人员进行安全和性能方面的测试后有发现一些问题，可是因为没有找到明确的负责人，从而致使问题最后拖延了一段时间。缘由是某些方面的BUG在分工初期是没有可以很好的分工明确的，因此出现了一些BUG以后，而集市模式下的敏捷开发没有很好地去负责

ü  发布后获得反馈的一些问题，其中有一次获得的反馈是注册登录过程会存在不肯定性的失败现象。那是咱们将不少问题归到了服务器性能上面，虽然这是一部分的事实，可是还有很大的缘由是咱们各个队员的当时在磨合状况上确实还不是很好，因此有些模块上人员不断调动，最后在BUG的处理上形成了必定的不灵活性。还有就是发布前的基础功能测试没能很好作到位。

 

0x07 ：沟通工做的进度评价           

在此前的0x01~0x06的工做进度中，都大量说起了沟通缺少这一严峻问题，所以，特别创建0x07模块来特别强调BugPhobia团队和其余团队的沟通情况，以此在Beta阶段记录项目总体的紧张，近期也会将沟通交流阶段的Scrum Meeting（沟通阶段长周期例会）发布至博客中，做为Beta篇章的启程和重生。

时间节点记录	沟通摘要	讨论成果
2015/11/17~ 2015/11/24	l  BugPhobia团队和Dream团队决定共同后端进行开发，Dream团队的赵庶宏和BugPhobia团队的冯志睿、王文基将共同开展后端工做的“结对”编程工做 l  网站和APP整合开发需求，共同协商JSON的数据类型，同时将在概念模型完成后抽象为JSON格式的数据接口，方便先后端的共同开发	https://github.com/bugphobia/XuebaOnline/ blob/master/需求分析和定位概念模型.md