软件工程驻足篇章：第十七周和BugPhobia团队漫长的道别-白红宇

软件工程驻足篇章：第十七周和BugPhobia团队漫长的道别

阅读量：4994 次

发布时间：2019-06-12

本文共 12048 字，大约阅读时间需要 40 分钟。

0x01 ：序言

I am a slow walker,

but I never walk backwards.

成长于被爱，学着爱人

成长的故事

也是年少的星期六结束的故事

就仿佛我和BugPhobia团队共同的成长

从模仿到拒绝模仿

任由挑灯、辗转、迷茫、前进的无数日夜

令那些岁月的烦恼和喜悦控制住自己

在耳边轻唱

祝你万事胜意

一切终比想象的，好一点点

——致以BugPhobia团队的Beta阶段软件开发的终结篇章

0x02 ：软件工程项目经理的理解

To the world,you maybe a person.

But to a person,you maybe the world.

0x0200：软件工程Beta阶段的工作模式

在团队项目从Alpha阶段到Beta阶段的开发过程中，笔者由前端设计/开发工作转型为团队的项目经理。在这篇文字的初稿定型时，团队Beta阶段的项目的对接和发布尚处于微妙的状态：

ü 前端ReactJS页面已经由“举步维艰”的摒弃jQuery机制，迁移大量CSS和JS/JSX的过程，过渡到基本完工的工作状态

ü 后端Django的基本接口书写完成，但由于数据库的完整性约束条件的限制，正处于紧张的单元测试和错误排查阶段

ü 前后端的基本对接工作，从理论上，由于此前协商的定义应当不存在任何问题，但由于后端的测试过程因此尚未进入成功对接的阶段

ü 文档方面，由于此前工作的部分延误，大量的文档积累在complete文件夹，未完全排版和整理

而在最后一周的短暂开发时间中，此前疑虑的“前后端对接可能会浪费大量时间”由于单元测试的完备，此部分时间被大量节省，因此在开发后期，团队能够专注完成此前预计的各方面工作，虽然与此前Beta阶段初期预想的最终结果有所差距，即由于开发时间的急剧压缩，数据量的积累程度未达到预期，但已尽力而为，问心无愧吧~

同Alpha阶段的前端开发成员不同，在Alpha阶段，笔者本身更注重去后端驱动、架构驱动模式下的前端开发，在此阶段，如何根据具体的用户调研情况进行设计，并时刻注重与后端进行一定的沟通，保证后端所提供的基本数据能够完全展示在前端页面，这里笔者也将当时自己写的一部分感想链接此处：http://www.cnblogs.com/panacea/p/4966144.html

但在Beta阶段，以项目经理的身份去参与BugPhobia团队的Beta阶段的开发。在经历了Alpha阶段相对集市式的开发模式，Beta阶段更倾向于采取教堂模式为基础的集市开发，因此，笔者作为项目经理首先确定基本的沟通方案和团队进度管理。在初期，笔者对项目经理的职务仅限于文档的整理、进度的协调，但真正参与其中却又不尽相同，笔者也就项目经理本身的参与的全部开发过程进行说明：

0x0204：团队Beta阶段的身份转换

事实上，在Alpha阶段，团队本身已经经历了基本代码的全部重构工作，当时团队在讨论的过程中，简单浏览了学长的部分代码，考虑到学长所留存的代码的相关的说明和开发文档缺失，而历史代码的测试和调试也会耽搁团队的开发进度等问题，直接选择了采用新的技术栈：Semantic UI的前端页面，Django渲染模板方式的后端架构，Solr完成搜索引擎搭建的全部更新；同时，团队所包含的更多的是初生牛犊不怕虎的倔强，无论是沟通或是协作工作都充满着强势的感觉，直接向其他团队提出采用SOLR架构和NUTCH插件开发完成最后的对接工作，而在其他团队中途“弃坑”放弃这一计划方针的时刻，选择独立完成数据库的搭建、SOLR数据的插入工作，极大地增加了工作量，但也确实独立完成了基本需求的解决方案，甚至笔者当时还有种“愤世嫉俗”的感觉，认为是其他组没有配合上游团队提出的需求。

实际，项目经理的身份更需要注重组间协作的沟通劝导，和决策。因此，抛却基本的个人情感因素，在Beta篇章的启程工作时，作为项目经理，笔者总结了基本的组间协作的矛盾，记录如下表：

优势说明

矛盾说明

ü 团队目前的架构基本能够承载基本的需求

ü 团队的需求设定与预期目标基本相同，而基于标签的搜索模式也能使得搜索成本相对较低，且利于分类管理

ü 团队和学霸APP团队间接口无协调关系，下游团队很可能妥协其中某一团队设计，而另一组需要完成中间层的搭建，工作量增加且耦合度增强，不利于后续团队的开发

ü NUTCH插件的开发难度较高（主要在于相关的文档较少），而由于Beta阶段的课业压力相对严重，很可能下游团队对新技术的接受时间较长

ü 数据组和爬虫组的对接一直处于相对模糊的状态，上游团队始终无法梳理清楚两团队的职能

因此，最终，BugPhobia团队依据矛盾的说明，最终完成了矛盾的协调工作，并真正以合理的架构完成了学霸全部项目的高聚合低耦合的设计，而非“愤世嫉俗”的抱怨工作；

这里也非常鸣谢其他团队共同的努力（学霸爬虫组：http://www.cnblogs.com/cnmxfd/，学霸数据组：http://www.cnblogs.com/cheneygroup/，学霸APP组：http://www.cnblogs.com/groupofdream/）

矛盾说明	具体决策
团队和学霸APP团队间接口无协调关系	BugPhobia团队和Dream团队共用后端开发，数据组仅需完成同一后端的对接工作
NUTCH插件的开发难度较高	放弃NUTCH插件的开发思路，建议采用SOLR架构由数据组插入案例，而本团队提供SOLR的入门、插入案例等多方面文档，尽可能降低工作难度
数据组和爬虫组的对接一直处于相对模糊的状态	团队不关注两组间的对接工作，由数据组直接和爬虫组进行对接，完成基本的沟通、协作等方面因素

因此，团队的项目经理需要根据团队整体的开发程度和需求，完成基本的调研工作，并给出合理的解决方案；同时，与其他团队不同，团队技术方面的决策基本交由团队的架构师GNU_Linuxer（http://www.cnblogs.com/fzyz999/，这里致敬团队的架构师，能够从技术的角度提供非常完善的解决方案~），而项目经理仅根据进度做出部分的干预工作，这大抵是由前端开发人员向项目经理转型努力的第一步吧~

在笔者看来，团队项目间的协作，重点在于真正的信任和工作进度的基本对接；既然将基本的任务和进度交付其他团队共同协作，就应当对另一团队的工作致以全部的信任，而最理想的方式是双方能交换一部分成员参与到结对开发的过程中，能大幅降低团队间的沟通成本；当然，信任并不等价于放任不管，毕竟笔者在Beta阶段的开发阶段也曾因编译原理、数据库等焦头烂额的课程而一度陷入“伪罢工”状态，因此能够保持定期的进度交流和对接，能使得最终的对接工作，快速完成

0x0208：团队Beta阶段的重构工作的得失

这里首先引用团队架构师的部分博客，其对重造轮子、架构方面的见解简洁易懂：

“原因我们自认为很充分：学长代码里坑多，分析代码需要很多时间，技术栈太老等等。现在看来，这个决定有些初生牛犊不怕虎的感觉。当时没怎么纠结就定下来了，我们并没有觉得重写的成本有多高，而且对于自身团队的力量极度自信。如果现在要我重新来做这个决定，我肯定不会再像当初那样轻率，虽然，我依旧可能倾向于用全新的技术栈重构整个项目。迁移方案，如何与其他组兼容协调，开发能力，团队组织能力等等，各方面因素都应当考虑进去。而当时，仅仅考虑了很少的几个点，就决定了重写整个项目。直到后来才慢慢地理解到，有些东西的成本和代价是相当高的”

事实上，本身能在两轮迭代中均进行重构的团队，可能在软件工程的课程设计中，基本不存在；而在Beta阶段，团队继承了此前Alpha阶段对学长遗留代码的重构工作，再次重构了Alpha阶段的代码的全部迁移工作。实际上，在初期的讨论工作中，团队本身提供了相对简洁的衔接方案，甚至能够使得Beta阶段团队本身的工作量大幅降低：

最终解决方案

可以选取的解决方案

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

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

l Solr平台的数据插入

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

但事实上，Alpha阶段团队所构建的页面，由于HTML代码的重复率相对较高，因此全部页面均处于混乱的泥球状态；这里仅从笔者Alpha阶段负责的前端代码谈起：

n HTML的代码复用相对较差，由于Django模板的渲染，能够通过{% include %}的方式完成一部分的代码复用，但由于后期敏捷开发时间紧迫，因此大量代码片段被复制粘贴插入其中

n CSS代码机制混乱，这里完成是前端开发人员（笔者）的锅，在代码中存在大量的<script><type/css>的代码段，使得整体代码在维护上存在较大困难，降低了可读性

n 即便在文档齐全的情况下，接手团队维护混乱的HTML页面也是巨大的负担，且对于相同的页面元素，可能需要更改多个页面才能完成最后的修改工作，即前端元素冗杂

n 若选用共用后端的解决方案，必须放弃Django的模板渲染方法，改用JSON完成数据的交互

因此，在Beta阶段，BugPhobia团队最后协商决定完成全部代码的重构工作，保证学霸全部项目的耦合和对接。

首先不得不承认，Beta阶段，团队重构的压力巨大，团队成员不仅需要协调编译原理、数据库课设等编码工作，还需要保证软工的基本进度稳步进行，而非继续拖延。因此，在第15~16周左右，团队几乎全部成员均处于刷夜状态，且尽可能细致地分割时间，保证当前任务基本完成，这里笔者感触颇深，大学的大三上学期以前，笔者仅因为某次答辩而刷夜一次，而大三上学期阶段，连续48小时睡眠不足5小时的状况在后半学期经常发生。而同时，ReactJS框架体系对jQuery的使用有着严格的限制，$document的初始化问题、javascript代码的迁移工作、部分刷新机制，由于数据单向流动和本身体系的限制，部分前端的JS代码需要迁移为ReactJS框架下的JS/JSX代码，而此部分的工作量非常巨大，在学习成本上团队几乎消耗了大量的时间去避免使用Semantic UI内封装的jQuery代码，尽可能兼容部分JS代码。

幸运地是，依赖全栈工程师兼架构师的GNU_Linuxer驱动，依赖独立后端开发成员Fizhero（http://www.cnblogs.com/Fengzr）的驱动，团队依旧处于高速的运转之中，而在后期近三天的对接工作，几乎承担了绝大多数的工作，最终团队完成了基本的重构工作：

n 架构的可扩展性、可维护性相对较高，技术栈整体较易适应于分布式等方面的加速

n 学霸APP组和学霸WEB组能够完成共用后端的操作，且经过团队的测试，后端接口单元测试完全通过，而测试时也并未发现较大的异常

n 代码可读性和复用性大幅提高，且文档齐全并包含部分用于上手的的学习文档

0x020c：团队Beta阶段项目经理的职责

这里先引用此前SivilTaram的吐槽（http://www.cnblogs.com/SivilTaram/p/4966026.html）：

这一点上让我感受颇深是因为另外一支队伍。这支队伍是我们团队初期预想的最有竞争力的一支队伍——最根本的原因是他们队伍里我欣赏的人很多。这就意味着团队里的每个人都有着独当一面的能力，独自解决问题的思路与别树一帜的想法。

但是他们的开发过程中出了一些毛病，我也能明显感受到：

n 名义上的项目经理参与不到真正的项目开发中来

n 实际上的项目经理没有完全发挥项目经理的职能，没有一个整体的规划和组织

这里是此前在Alpha结束阶段他对我们当时团队的一段吐槽内容，事实上这一部分的吐槽反映了团队当时的开发状况，但在言语上也有所区别，这里在团队的配合中也感受到Alpha阶段心得，并将其应用到Beta阶段：

n Alpha阶段团队是架构、后端驱动的TDD开发模式，因此，这里所谓“实际上的项目经理没有完全发挥项目经理的职能，没有一个整体的规划和组织“其实在Alpha阶段后期团队也已经正面了这一问题，并开始将项目经理的部分工作进行转移，交付架构师，根据团队前后端的对接情况进行项目进度的管理；

n Alpha阶段团队的灵魂并非项目经理，而是架构师，他作为团队的灵魂核心根据对接情况将前后端的进度进行协调，使得团队最后完成项目的Alpha迭代开发

n Alpha阶段对部分工作的责任相对不明确，因此，部分成员后期由于工作调度的问题，未能完全参与到开发过程中

因此，在Beta阶段，项目经理开始真正发挥其职能，尽可能保证团队在集市开发模式中能够按照教堂模式进行规模化的搭建：

职能说明	具体工作评估
团队项目进度协调	“不管是开源还是商业化，都必须要有一个人对整个项目负责。不是两个人，不是三个人，而是一个人“，这里笔者经过两轮迭代的开发暂时不予支持这一观点。这里负责的概念，笔者从技术和进度上给出负责的定义： l 技术负责：团队能够依据目前的开发状况，更新技术栈，并稳定基础架构，针对不同情况给出不同的解决方案 l 进度负责：团队能够根据目前的进度状况和预期计划，更新进度日程和前后端对接进度，保证开发模式和进度呈现稳定发展因此，笔者所处的团队基本处于两人的负责的阶段，技术负责交付架构师，进度负责交付笔者，而平台的对接沟通工作交付平台对接人员，三方面对团队进行负责，最终保证Beta阶段团队项目能够稳步进行，完成最后的预期开发
团队项目进度的干预	团队的全部成员本身从态度和能力上都非常靠谱，交付的任务和挑战都能尽力完成且交付的版本都几乎和最终归档的版本相差不大。但团队同样会经历部分任务的“卡壳“阶段。在开发中期，团队的前端页面的迁移工作一度陷入迟滞，由于前端迁移人员纠结在主页面的标签云迁移工作，而正常的工作难以继续开展；因此此时项目经理需要适时干预进度，将此部分任务标签后移，并提供不同的解决方案供技术负责参考，并完成进度的迁移
团队文档和规范的责任分化	这里摘自一段吐槽，“程序员最讨厌的四件事：写注释，别人不写注释，写文档，别人不写文档“，因此在开发过程中，部分细致的注释和文档实际上是需要一段过程去适应并习惯；因此，项目经理需要能够协调这一部分责任，在commit后根据其链接的issues查看文档和注释是否齐全，并进行评估，开始下一阶段的工作（复审、测试）；当然，团队的需求分析、代码规范等部分工作也同样包括在其中
信任成员	这里笔者附上年初自己写在笔记本扉页的第一句话，“不管是爱情、亲情还是友情，只要喜欢一个人，就不要冷冰冰的“。事实上，在软件工程以前的课程设计，很少涉及5人以上规模的团队协作，在Alpha阶段前期，团队几乎都是凭借个人的能力去协调工作，而在逐渐的配合中将任务细化，让每个人参与到开发的进程中。因此时刻知道，你并不是一个人在战斗，团队每个人都能参与到项目的搭建并完成，最终就能问心无愧~
与Alpha阶段项目经理职责的异同点说明	由于Beta阶段重点继承Alpha阶段的工作，因此，在Beta阶段并未经历大量的需求变更，而找到真需求（避免弱需求、为需求），找到产品本身的愿景和市场，分析基本功能的优先级，产品的宣传等工作重点均在Alpha阶段较为完善，因此Beta阶段的工作重心放在团队进度管理，当然项目经理的职责并不是单纯的进度管理，这里以Alpha阶段工作的异同点做出一定的说明

0x0210：团队成员，特别鸣谢的篇章

在第16周左右，笔者的状态几乎接近崩溃，团队的开发进程由于各事项的并行几乎进入了阻塞状态，而由于团队沟通此前消耗了大量的时间成本，开发时间也被急剧压缩，甚至一度想完全放弃软工这一项目；这里真的感谢团队成员每一个人的协作和沟通。在繁忙的考期中，并非一两个人支撑地团队，而是全体成员共同完成最后的重构到发布工作。（当然，这里也有建议，在团队初期规划设计方案、选取项目时，应充分考虑团队本身的能力）

记得当时答辩前夕，自己静坐在电脑前想着答辩时可能的细节，软工这一路团队走过来顺利吗？

是啊，顺利吗？当打出这三个字后我又写了一长篇文字，还是高中时稚嫩的排比句呢，用分号连接的，都是经历的矛盾和纠结，然后就全删了。可能2015年的自己最大的不同是删除痛苦，我永远不会将两种悲伤放在天平上评判褒贬（此时音乐：《Blessing(World Edition)》），我只是希望，新的一年，团队依然可以对自己有信息，相信我会继续努力，成为漫长道路的那个安好的人。

再见了，这场漫长的道别，和软件工程BugPhobia团队，你给我很多的矛盾和希望，挫败感和喜悦感，我很喜欢，真的很喜欢~

谢谢BugPhobia团队这一路的协作和沟通，就像自己一直喜欢星期六的自己，相对年少，尽情睡懒觉，把一切推给明天，没有忧虑，也没有愤懑；这是成长的故事，也是星期六即将结束的故事~

最后，链接如下，BugPhobia团队的致谢：

Beta阶段项目经理、前端开发的少年PocketPanacea：http://www.cnblogs.com/panacea/

平台沟通、后端开发的少年When：http://www.cnblogs.com/whenever

前端开发、页面设计的少女someonefighting：http://www.cnblogs.com/someonefighting

前端开发、测试担当的少年-OwO-：http://www.cnblogs.com/-OwO-

前后端对接、架构担当的少年GNU_Linuxer：http://www.cnblogs.com/fzyz999

后端开发、后端担当的少年Fihzero：http://www.cnblogs.com/Fengzr

Alpha阶段项目经理、颜值担当的少女summerMTY：http://www.cnblogs.com/summerMTY

0x03 ：解决的问题

To the world,you maybe a person.

But to a person,you maybe the world.

首先设置此前提出问题的传送门：http://www.cnblogs.com/panacea/p/4832903.html

阅读提问：在开发过程中的设计框架中，预留接口方便维护是讨论的重要组成部分，但如果开发过程遇到需求的急剧调整，如何设计独立性较强，模块集成较高的接口

这里阐释个人理解，首先需求的急剧调整是需要分情况探讨的；这里由于笔者的理解有限，因此只能从团队协作和设计两方面阐释这一问题；

n 对于团队协作方面：如果需求急剧改变，从项目经理的角度，只能尽可能确保整个团队在正确的时间做正确的事情；遇到紧急需求的改变，首先需要通过Design Change Request的分析，充分验证更改需求的必要性后，协商技术负责人去探讨合理的解决方案（这里引用了助教的解答）。而技术负责人需要去探讨这一解决方案的实现成本，并根据实际情况进行一定的妥协。这里笔者根据Alpha阶段和Beta阶段之间的过渡阶段，给出一定的解释和说明。实际上，在Alpha阶段到Beta阶段，团队的需求由“自主搭建“到”协调沟通“，由面向用户的开发模式，向面向开发人员对接适应接口的模式进行转换；团队整体做出重构的决定后，最重要的是留出学习成本的时间，同时架构师尝试了代码迁移ReactJS的demo试验，在经历一段时间的实践过程，最终决定完成需求的变更和搭建工作（http://www.cnblogs.com/bugphobia/p/5118599.html）

n 对于接口设计方面：笔者感觉这一问题尚未弄清，毕竟仅仅但从这一次团队的项目中不能立刻给出定论，但至少在高聚合的设计上，可以考虑成熟的架构，在数据传输时设计松耦合的接口，可能对需求变更这一问题有着较好的解决方案

阅读提问：既然软件开发是一个具有不可预知性和变化性的动态的过程，如何在初期的架构过程中合理地为可能的需求预留扩展的空间

这里阐释个人理解，事实上，暂且不谈软件工程的课程设计，编译原理的代码优化笔者在代码生成阶段预留了一部分设计保证后期代码生成的快速修改（然而最后还是没有冲击代码优化部分，还是蛮遗憾的QAQ）

int handle_add() {

//ADD SRC1，SRC2，DST

…… //achevie value/address of SRC1/SRC2/DST

#ifdef DEBUG_OPTIMIZE

…… //Code Block with optimize in global register or temporary register

#else

…… //EAX with DST

}

实际上，笔者在设计阶段很少考虑后期优化的优化点，因为在后期维护代码时很可能会增加重构的难度且降低代码可读性；但编译原理这一部分实际上是可以预见的后期修改过程，因此预留一部分的扩展空间自然无可厚非

最后回到此问题的核心，其实此问题和第一个问题有着相似之处，仅从笔者这一阶段的理解，可扩展性尽可能搭建在数据传输时的松耦合接口，并根据需求对高聚合的其他架构做出一定的修改去适应，是较为合适的解决方案

阅读提问：开发的后期阶段，遇到用户需求的发生急剧变化的情况，应当选择重构代码，还是实行敏捷开发，尽早在更新的版本中增加一夹在前端和后端间的中间层

这里先引用当时助教的吐槽，如今回顾自己提出的问题发现果然是若合一契，“同学你对需求改变这个问题很敏感啊……“。其实这里和笔者的个人经历有关，笔者本身曾全程参与到某一智能插座的开发过程中，在初期的设计雏形时始终考虑对电器本身的芯片进行一定的函数编程，在后期的设计后则改变这一做法，用最简单的”遥控器“控制模拟过程去完成插座节点的搭建。但最后，由于需求变更这一部分浪费了一定的时间，因此最后这一项目处于流产状态，而最后将demo做出自己玩玩就不再开工了。实际上，开发后期可以暂且理解为”产品的雏形基本完成，已经处于基本的测试和宣传阶段“，那么遇到用户需求急剧变化的情况，笔者感觉这里问题应当由宣传人员和项目经理共同给出一套成型的解决方案，而非在产品上胡乱添加内容：

笔者暂时想不到一定的案例，但不妨虚构一案例以笔者的角度理解，进行大致的说明：

l 背景：现在处于一个国家，松茸是稀缺的珍馐，而恰巧国家由于资源充裕，国民整体的福利较好，松茸这种高昂的食品有着广阔的市场

l 团队：我们尝试人工种植松茸，并假设技术上取得突破，松茸价格是A万元/克

l 实例：运输成本取得突破性进展，松茸运输过来不过B千元/克，而人参反而成为了稀缺产品，显然松茸的栽培技术迁移到人参是个巨大的屏障（10B<<A，谁把<<符号当成左移位操作符了囧RZ）

l 策略：天然、现场采摘、游客参观并以纪念品的方式销售产品，以全新的需求推广产品

阅读提问：软件开发过程，在遇到文档不全面的旧代码，如何重新维护或测试保证其正确运行

这一问题笔者的确没有弄清楚，因为在整体的开发过程中，团队几乎处于重构操作，仅从需求角度分析了此前团队完成的项目；但笔者这里仅给出一未实践的做法：从单元测试的角度入手分析模块本身的输入输出，依据需求分析的结果去维护旧代码；当然，如果注释相对齐全，也可以先自己做出一部分验证，确保注释的正确性

阅读提问：软件工程是团队型的项目，那仅针对学习过程，能否提供崭新的思路保证每个人都能去担当每一角色来保证学习的完整性

实际上，这一点是针对软件工程课程设计角度提出的问题，经历了两轮迭代过程，也有一定的感触，这里将当时提出的部分意见再次在此问题上提出：

l 建立软件工程课程的GIT仓库，将技术学习文档、技术新得文档发布在其中（可以每一团队设立一文件夹），这样后继团队能够根据技术栈的情况，量力而行选择合适的项目进行开发

l Beta阶段开发过程，实际上是考虑采取分工对调机制，但考虑到Beta阶段紧缩的开发时间，未能最后处理，但笔者这里给出一定的解决方案：“分工互换原则”，A和B交换工作开发一段时间，相互学到不同类型的东西，最后每个人给出在团队中两个不同位置的感想，但这样又可能导致外部换了而内部工作不换的问题，既然如此，就优化为A整理B的文档/代码，B整理A的文档/代码，各自给出互评报告

0x04 ：软件工程新的问题

To the world,you maybe a person.

But to a person,you maybe the world.

n 关于学习成本的消化问题：笔者在Alpha阶段就一直思考如何能保证技术的开发成本能够尽可能地交付成员，并快速消化和接受。在Beta阶段，笔者尝试通过Demo的考核方式用以判断成员对这一技术栈的理解程度，并尽可能让熟悉这一框架的旧开发人员带动新开发人员，进行结对编程的方式快速熟悉。但其效果较为微弱，可能成本仅缩短30%左右，与预期的估计值差距较大；软件工程中，旧开发人员应当以怎样的方式带动新的开发人员快速适应这一技术栈并投入开发中？

n 关于车祸系数的问题：团队在Alpha阶段和Beta阶段一直思考如何降低团队的车祸系数，团队初期一直依赖全栈工程师兼架构师（GNU_Linuxer）的带动，而在后续的开发过程中，一直尝试通过开发栈的分离和松耦合保证车祸系数的降低，那么在实际的团队管理中，应如何控制车祸系数维系在项目经理可接受的范围之中？

0x05 ：新体会

To the world,you maybe a person.

But to a person,you maybe the world.

实际上，在经历了两轮重构工作后，团队的开发模式也逐渐走向规范化的集市模式管理，这里笔者根据此前的理解给出集市开发模式必要的因素：

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

n 开发的直接负责人（单人）：http://www.ituring.com.cn/article/9363，实际上，在开发过程中必须确保每一部分工作的质量均由特定的人进行管理，遇到变更时再优先和负责人讨论后作出妥协或决定

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

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

0x06 ：简洁知识点总结

To the world,you maybe a person.

But to a person,you maybe the world.

以你所在方位画下一个坐标，然后跌跌撞撞杀出一条血路。

第二轮迭代的项目经理，铭记反思，愿一切安好~

项目说明	具体知识点总结
需求分析阶段	在需求分析过程中，需要首先将需求划分为刚性需求、弱需求、伪需求的基本分类；而完整的需求分析中，需要根据市场调研结果确定产品的刚性需求（核心竞争力）；根据特定群体的调查问卷梳理弱需求的分类；根据实际的SWOT分析确定基本的用户场景和用户群体，将伪需求进行筛选，确保需求满足后数据量呈现较大变动
设计阶段	设计阶段需要注重“高聚合低耦合“的基本原理，并尽可能保证搭建架构间的对接接口文档，从而使得产品基本呈现松耦合的状态，增强其可扩展性
实现阶段	在实现阶段，注意控制团队本身的车祸系数，尽可能保证团队的技术架构能够在相互遵循一定的开发原则基础上，完成相对独立的流水开发工作。而在实现阶段，项目经理更要时刻根据Scrum Meeting的进度结果进行协调，保证其开发过程的对接工作能够稳定完成
测试阶段	测试不仅囊括基础的单元测试和后续的压力、安全、性能等类型测试，更要根据实际的用户需求设计测试案例（如网页端产品在国内发布，必须要测试其对国内主流浏览器的兼容性，而非国外市场的浏览器区间分布数据）；同时，注重代码质量！代码质量！代码质量！保证可复用性的代码将极大降低后续的测试成本
发布阶段	发布阶段，一定要完成必要的出口条件的测试验证，避免极大影响用户体验的BUG出现（例如团队Alpha阶段服务器配置与网页流量不匹配导致的访问体验极差）
维护阶段	维护阶段，是继续的迭代过程。尽可能保证其设计模式/维护模式与当前技术栈匹配，从技术上保证维护阶段的功能能够适应用户需求的变化（流量的急剧增加，用户需求的调整，新功能的适配性）