封闭式开发.docx - 冰点文库

资源描述

封闭式开发.docx

《封闭式开发.docx》由会员分享，可在线阅读，更多相关《封闭式开发.docx（23页珍藏版）》请在冰点文库上搜索。

封闭式开发.docx

封闭式开发

一、封闭式开发的基本装备

金秋十月，丹佳飘香，正好有些时间整理下在山里的日子，大家一直在寻找银弹现在一起讨论下封闭式开发，真的能成为银弹吗，一起来讨论下吧。

上个月公司上了个新项目，公司决定在全公司内选出一个Team，由一个技术经理和一个产品经理带队，去山时面做封闭式开发。

问了问同学朋友，他们公司有的项目或产品也搞过。

不过，几辆车，十几个人，十几个笔记本，就风风火火上山啦。

我发现人到了一个与世隔绝的地方，会变得开朗一些，自由一些，也会BT一些哦，其中有苦有甜，先从前期准备说起吧。

前期准备主要有以下几个东西：

笔记本：

14台

台式机：

5台，其中三台服务器，2台是给数据处理人员使用。

无线路由：

三个（回来的时间都没带回来）

白板：

一个

A4纸：

两包

纸的垫板：

若干

网线：

若干

系统盘：

两张

移动光驱：

一个

这里特别要提醒一下，一定要带好备用的机器，由于山路崎岖，路漫漫其那个啥，所以

难免会有些机器受不了，会被震掉。

我们这次去山里面就震掉两台机子，一台怎么也开不了

机。

一台老是花屏。

还有一个特别要注意的地方就是，一定要记得分两三批人过去。

一定会有乱七八糟的东西没有带，后面一批人正好可以带过来。

花了一个上午的时间把东西搬到指定的地方，然后没等休息，我们就坐到一起开个会，

令人期待的十五天就要开始啦，一切都准备完毕，一个小型的网络还有一个大桌子，

接下来真的会有什么不同吗，以前各自都属于其它项目组或其它部门。

现在是新的开发

模式，新的管理方式，新的Team，一切都是新的，在激动之余又有些担心.

PS：

先写到这吧，下篇会介绍一下作息时间表,争取在这个国庆，把这个系列写完，也算把

这次难得的体验分享给大家吧，希望也有过封闭式开发的朋友们，也一起加入进来讨论咯。

二、封闭式开发的时间安排

项目启动会议上，时间安排如下所示，一看上去可能有点像高中的复习高考的时间表，不在太激动哦，我们其实也是在比赛，和自己在比赛。

详细时间表如下：

早餐：

7：

00~8：

上午：

8：

00~12：

午餐：

12：

00~12：

午休：

12：

30~14：

下午：

14：

00~17：

晚餐：

17：

30~18：

交流：

18：

00~19：

晚上：

19：

00~22：

其实,说真的,我们早上真的没有吃一个小时的早餐．还有，只有开头的晚上几天是按时下班的哦，一般都到2～３点吧．这里特别说明一下哦，上面没有安排一些运动和一些娱乐活动哦，其实可以在吃完晚饭时候去找些地方活动一下哦，比如打打乒乓球或者看看电视之类的．不过不建议剧烈的活动，这样的话，晚上几乎会没体，毕竟还要到这么晚是吧．

其实，这份时间表里面最种要的那一个小时的交流时间，其实，大家的工作都比较独立，特别一开始的时候，大家对整个项目的轮廓都不太清楚，所以听的也是云里雾里的．基本上也提不出什么建设性的意见．所以大家有时候都是继续做自己这块，但是为了整体的节奏感，还是要让大家的大方向都确定．也为了能让大家有团队的感觉，还是放在一起开比较好。

到了后期，当项目的轮廓慢慢清楚了，大家对问题认识得也比较清楚了，这时候对问题的讨论往往也比较深入，这时候可能占用其它人比较多的时间在会议上，有时候一个比较纠结的问题可能会拖到9点，也是会把讨论的时间从一个小时托到两小时。

在这么静的地方开发不会被打扰，在讨论的时候也不会被打扰哦，所以问题的边界也会被越放越大。

下次我们进行讨论的时候，还是要像以前的半小时原则。

如果半小时讨论不定，说明没有准备好。

如果是群体会议，每个小组之间的接口常常被无意识的置后，这个也要被关注。

附：

会议如何改善

1.谁应该参加?

. ---人需分:

必须参加人员,要发言的和随意参加的人,可发言可不发言.

2.谁主持?

---“主席”—副总;导言人—经理;“观察员”—总经理人力资源

3.谁控制?

----“主席”是控制秩序的;”导言人”是控制时间的;“观察员”是控制全场的.

4.开会的时候谁先发言?

---由下而上.先外后内.的发言顺序.

5.谁负责跟谁追踪?

---开会一定要有决议的负责人,还要有负责追踪的人.总经理只负责决策,做事的是其他人.谁召集会议,谁负责.

6.谁在浪费时间?

---资料应在会前发给并阅读,一进会场就是直接讨论和表决.

7.谁结论?

----没有更好的办法,就用”主持人”的方法.（导言人¨¤主席¨¤观察员）开会必须要有答案.没有答案,会议不要开.

三、封闭式开发的人员配备

上篇写到时间表，现在看了觉得还在松了，呵呵。

前两天，阿日在自己的文章中写到关于“提高软件质量的十个环节”，总节的非常不错。

不过有一点可能也要被重视，后面的回贴中也有人提到，就是软件开发的质量重在两个人字，一个是“人”字，另一个是“心”字。

当然这和我们的软件工程的理念是相围背的，西方的“工程化”的人件思想也是有一定基础的，特别大项目在操作的时候，就要做到可替换性，我们就是一颗颗经过ISO9001认证过的镙丝丁。

不过，在封闭试开发中，可以用来替换的镙丝丁比较少，因为我们这个Team是被公司选中去要在指定的时间，指定的人员，完成指定的任务的。

目标清晰，资源有限，时间紧迫。

所以在人员安排的时候，不能分太细，几个人的技术储备要有一定交叉。

这样，表面上，大家是不同小组，也有各自相对独立的任务，其实，如果一个小组忙不过来，而其它小组够快，那么，还是可以互相帮助的。

言归正转，下面来聊聊这次封闭式开发中的人员安排和分析。

人员安排如下：

技术经理一名、产品经理一名、数据处理人员两名、开发人员10人，测试人员（无）,UI（交互设计师）一名,WEB框架开发人员一名。

分析上面的人员安排：

有以下几点要说明的地方：

第一、技术经理。

把握技术选型和人员分配。

他知道每个人开发人员的技术重点和开发效率。

也知道这次产品开发需要的新技术和架构。

对技术这块的实现难易程度有个很好的把握。

在Team需要做技术调整或人员调调整的时候，可是迅速做出判断。

后期还有代码审查、高难度技术攻关等工作。

第二、产品经理。

主要任务付责一些前期需求。

主要和UI讨论这些前期搜集过来的需求如何让用户有最好的用户体验。

产品经理思路广阔，常常会冒出有创意的想法。

常常关注一些大的网站或知名产品，需求的把控者。

第三、交互设计师（UI）。

以用户为中心的产品设计，付责界面原型和高精度的成品图。

需要让用户有较好的用户体验，也需和主流网站的用户体验有交叉的地方。

这样让用户学习接近零成本。

第四、没有测试人员。

一个Team竟然没有测试人员，不是吧。

一眼看过去，可能会感觉到不可思议，其实，这次我们没有独立的测试人员，但是我们有开发人员的单元测试。

我们的开发模式的偏敏捷开发，所以整体的功能测试和边界测试和其它测试都放在后面。

我们在其中只做新功能的演示和单元测试。

第五、开发人员。

铁打的营盘铁打的兵，一个Team的任务执行者，产品质量好坏和进度推进最重要的一环。

效率高底，代码风格好坏，直接决定项目的推进速度和BUG数。

第六、WEB框架开发人员。

最重要的是配合UI开发产品的首界面，和把各个模块集成到主框架中，对于样式和脚本的要求较高。

第七、人员调整。

有一个情况就是在这次开发中，我们有一个小组的任务实现起来比原来预想的功能要多，也要用到一些新技术，而且随着业务的扩展，那个小组可能无法独立完成这么大任务量了。

这个时候，我们及时调整了小组分配，从其它不太忙，或者任务级别不太高的小组调来两人，配合完成，后面也算完成了80%的任务，没有拖整个团队的后腿。

小结：

其实在那段时间的开发过程中，还有一系列的问题需要注意，这里由于篇幅有限，不再深入了。

总之，一个新的Team，也用了好多新的技术，磨合十分重要。

最后还是话，思路决定出路，我们是一个Team。

四、封闭式开发的架构设计

这里主要简单介绍一下我们产品中主要WEB项目的构架思路,其它后台处理模块和通信服务端先略过.

我们的架构设计是基于REST的思想，由于这里篇幅有限，不对这种思想进行详细描述，这里只描述几个REST的原则：

网络上的所有事物都被抽象为资源（resource）；

每个资源对应一个唯一的资源标识符（resourceidentifier）；

通过通用的连接器接口（genericconnectorinterface）对资源进行操作；

对资源的各种操作不会改变资源标识符；

所有的操作都是无状态的（stateless）。

其实，之所以我们选用这种架构，主要是因为，我们的业务很多是无状态的，且不需要太多的事务性原子化操作。

主要的业务都是展现。

只是在查询的多样性方面会有一些要求。

所以，我们的开发人员可以为相应的请求（URL）进行访问指定的资源。

由于MVC的种种好处，我们把MVC的使用方式进行了改造。

我们并没有使用.NETMVC默认的Viewer,而是直接自己使用通用json格式,结合模板和JS代替．在走协议方面，当然还是基于http协议咯，毕竟是网络应用．但是我们没有使用原生的http的四个方法来实现.

由于原生的http方法是GET,POST,PUT,DELETE,可以对应CURD中的增删改查,但更多的暴露了太多数据结构,而把太多的状态的工作放到的URL上.

所以个人总结REST共有下面几句话:

--[if!

supportLists]-->1.

--[endif]-->REST是URL驱动的,URL的变化代替了内部的状态变化

--[if!

supportLists]-->2.

--[endif]-->REST让WEB项目更像Winform项目了.

--[if!

supportLists]-->3.

--[endif]-->REST对数据的依赖大于业务逻辑.在业务逻辑确定之后,可以按业务逻辑和流程,结合状态变化先订好URL地址,这样可以防止不同小组间的冲突.

--[if!

supportLists]-->4.

--[endif]-->REST是个数据提供者,展现方式你自己决定.

--[if!

supportLists]-->5.

--[endif]-->REST不适合处理复杂的业务逻辑和大量的状态迁移.

--[if!

supportLists]-->6.

--[endif]-->REST不仅仅可以走HTTP,也可以走TCP,或者HTML5中的Websocket.只要是按照前面的那几种原则来.

例子:

下面简单基于描述一个登录注册的例子,使用的是html5中的websocket

--[endif]-->

说明:

--[if!

supportLists]-->1.

--[endif]-->WS是使用websocket协议.

--[if!

supportLists]-->2.

--[endif]-->一共有增加用户,更新用户信息,登录,和检查用户状态等功能.

--[if!

supportLists]-->3.

--[endif]-->其中更新用户信息和登录都会指向下一个url,即检用户状态的url.

也曾看过几篇关于REST的不好之处的文章,个人觉得有每个模式不是完美的,也有各自的优点和缺点,关键是你有那么多资源和时间吗?

或者你能在尽可能短的时间内向TEAM的程员讲清楚,又能满足项目或产品的进度需求吗?

如果上面几个问题都没问题,那用什么也没问题了.我们不是使用最完美的架构,而是此时此刻最适合的.

引用

CRUD不适合REST吗？

REST构架风格介绍之一：

状态表述转移

五、封闭式开发的敏捷开发

封闭式时间紧、任务急，而且是好不容易向老板那里要来的资源。

还有，没有其它的干扰，所以对于我们这个Team来说，应该是没有任何借口的，不管这是一个产品研发，还是一个项目开发，都不容许有任何差错。

但是在前期没有客户直接接触，确切的说，只有一个产品经理获得了一些基本的客户需求时，我们怎么做出成绩，或者相对的能做出一些被认可的东西来了呢？

思来想去，我们没有按原来的从需求分析到测试到编码的传统流程。

我们使用了敏捷。

这里不敢说完全按照了Scrum，或者其它的敏捷过程管理，因为在敏捷开发的群集中，我们毕竟还算新手，但是为了能轻装上阵，速度取胜，我们尽量的把一些省时省力的，而且轻文档的好的实践引入到封闭式开发中。

在这个时间段，我们只有把减轻文档，从开发的平行化转为开发的纵向化，即从流程为主导转向以业务为主导。

瀑布过程

原来的以过程为主导就是先把需求做细，向各方确认，然后由产品经理汇总，再交于界面交互设计师和架构师，再经确认后再交给开发去编码，最后功能点全都达标后，再交给测试，最后是QA。

这样有个问题，好多文章都说了，错误到最后才这发检查出来，或者直接被否定了，郁闷。

封闭式开发是不容许出现这种问题的，我们只有一个目标，做出客户想要的。

所以，我们只能从业务导向，把一个需求从基本的描述到开发，到测试，深入的做好一个个需求，到给客户看的时候，我们就能拿得出手，讲的好听点，我们可以随时拿出一个可以演示的版本来给产品经理去做演示。

而不是原来的到提交测试前一天，开发人员的代码都是写好的，可是没有经过验证，因为测试没过。

每个功能点的完成度都是90%多，没有一个版本是拿得出来的。

客户急了，我们的老板更急。

scrum过程

上面讲了一些闲话，主要是说明了为什么在我们在封闭式开发中要引用敏捷，下面着重介绍几种比较好用的几条建议：

--[if!

supportLists]-->1.

--[endif]-->轻文档描述

不要复杂的，重量级的需求说明书。

每个需我们简单的用一段话，或一个小小的流程图来说明，有时候直接写到了笔记本上，根本没有电子化。

下面是简单的一个用户故事。

假设我们开发的是一个类似于QQ的即时通讯项目，这里描述的是一个创建群的故事：

故事描述：

作为一个使用我们产品的客户，我需要建立一个群组，并且选定群组的人数和群组名称，以用来向这些群组内的所有人发送相同的消息，而不用为每个人发送。

简单流程图：

--[endif]-->

用户接受测试：

点击创建群组按扭，输入群名称，指定群成员，创建群，系统返回成功或失败。

--[if!

supportLists]-->2.

--[endif]-->单元测试

每个小组对于自己开发的模块在给其它小组调用的时候，都要至少通过单元测试，这里特别要强调对于输入验证和输出格式返回。

有时候当接口的参数十分特别的时候会减少反复的时间。

如果Team中的其他人调用到你的接口，出现了问题，你可以及时把这个bug转化成单元测试，下次提交的时候则同一样的错误不会重犯。

如果有时间多的话，可以提高下代码覆盖率，也是一种不错的选择哦。

同理，如果你发现了其它小组提供的接口中有些bug，则也可以为这个bug编写一个单元测试用例。

这样，使这个bug重复出现的成本变成零，也方便验证那个小组在重构后会反复的问题。

--[if!

supportLists]-->3.

--[endif]-->代码交流（TDD）

如第2点所示，我们之间的调用和被调用，都被固化在了单元测试中，不用直正到产品中的代码中才能发现或被调试。

小组间不再花更多的时间在争吵或者改没改上面，只要原来的测试能满足，现在却不能满足了，谁的问题，也就没有争的必要了。

--[if!

supportLists]-->4.

--[endif]-->每日构建

这个十分十分的重要，要及时给大家汇报，我们现在完成的故事是多少了，现在能看到结果是哪些，时间安排

--[if!

supportAnnotations]-->[l2]

--[endif]-->，我们每天都有一个小时专门用于汇报和讨论，在这里大家能及时看到完的业务故事情况。

也方便进行讨论。

如果一个版本比较稳定，我们会打一个版本，并且发布到外网上去。

并在源码上做好版本的标记。

--[if!

supportLists]-->5.

--[endif]-->编码规范

我们是用REST的模式进行开发，所以要对URL进行规范，每个小组在开发时，都需提前把自己的URL头，和可能用的到列表都发给一个人进行管理。

功能说明

URL

QQ/增加群

QQ/增加用户

QQ/登录

Weather/查询本地天气

Weather/查询温度差

代码编写和命名规范是直接用公司的统一规范。

--[if!

supportLists]-->6.

--[endif]-->主动索取任务

原来是经理对所有开发人员说，你的任务是什么，你的是任务是那些。

现我们一开始在讨论会中把所有的任务都列了出来。

然后，我们自己规划这两周能做哪任务。

化备动为主动。

--[if!

supportLists]-->7.

--[endif]-->互相帮助

由于每个开发人员开发效率不同，可能有的先完成任务了，有的还没完成。

由于我们不再像原来的那样，数据库开发只管数据库开发，前台只管前台，框架只管框架。

如果后台人员完成开发任务了，会主动帮助前台进行开发。

像我虽然是后台通信开发小组的，可是在完成自己的开发任务后，我也参与了样式布局和前台脚本的开发。

任务是我们自己选的，一定要一起完成他。

--[if!

supportLists]-->8.

--[endif]-->代码审查

按照编码规范去查看代码，一个迭代大概花半天时间。

再半天时间重构代码和用测试去验证。

--[if!

supportLists]-->9.

--[endif]-->白板讨论

我们讨论的时候不再纸上画，我们也可以用白板。

画简单的流程图或序列图。

这样让更多相关人员都能进来。

不足之处：

--[if!

supportLists]-->1.

--[endif]-->集成测试

由于我们是基于单个故事开发，到集成测试的时候，可能由于每个小组进度不一，而时间会有所拖延。

所以至少要花半天时间来做这个工作，而不是原先期望的半小时内。

在这个时候，接口会有所调整，要及时编写对应的单元测试进行验证。

--[if!

supportLists]-->2.

--[endif]-->代码覆盖率

由于时间不足，这部份没有达到理想的90%以上。

只能80%多吧。

--[if!

supportLists]-->3.

--[endif]-->文档不足

我们大多以代码为文档，把命名做好了后，几乎没有写什么文档，需要多方确认的需求除外。

如果有时间多，还是需要把这些基本的故事整入backlog中。

以备做战斗力评估和团队成长的记录。

六、封闭式开发的文档管理

在封闭式开发中，我们要尽量把花在写文档上的时间减到小，这样才能保证更多的时间用于实现业务需求上。

只能尽可能短的时间做出可以演示的需求，才能让客户满意。

但是虽然没有原来需求说明和详细设计那么多。

但是基本的用于落实需求和用于交流的文档还是要的。

其实个人认为最好的文档就是代码了，关于代码既是文档可以参考《cleancode》,下面着重介绍一些不可再省的文档了：

用户故事（userstory）：

定义：

以人为中心用业务语言简要描述客户需求。

对最终用户来说最有意义的一个功能。

主要包括以下三个部份：

卡片（用卡片来记录）：

对话（用客户的语言，关注客户关注的问题）：

验证：

（记录一些用可以检查这个用户故事是否通过）

格式：

作为…我需要…以便…

范例：

做为一个产品经理,我需要查询产品列表,然后,以便给最紧密的联系人打电话.

范例分析：

目标用户是产品经理，他希望按一定的条件查询产品列表，并且把查询的数据集进排序，对关键字权重高的要排到前面。

并且显示的联系人信息不要求太全，但最重要的就是他的电话。

且望Arycard间用于实现业务需求上。

不同的人对应同样功能可能有不同的要求，如仓库操作人员想通过使用查询产品列表完成仓库的拣选商品的操作，以提升仓库工作人员的工作效率。

其中受众是仓库操作人员，业务操作是使用手机进行商品的拣选，目的是提升仓库操作人员的效率，实现商业目标。

用户接收测试（uat）：

这个用户故事如何演示，才能让客户明白，这个功能是实现的。

接上面的这个查询的例子：

用户在文本框中输入对应的关键词，多个关键词是以空格或逗号隔开。

点击查询按扭后，页面上显示所有相关产品列表，其中和关键字最相关的产品显示在最前面，且每个产品后面都对应显示出联系人的电话号码。

参与人员：

测试人员、产品经理、真实用户、交互功能设计人员

用例（usecase）：

定义：

由特性分解而来的一个可以用来做功能测试的小情节。

每个用例可以转化为一个单元测试。

在每次重构后可以用来验证。

格式：

用例名应该是一个用主动语态动词短语来表示的用例目标>

使用语境：

<目标较长的描述，如果需要，还包括触发事件>

范围：

<设计范围，在设计时将系统作为一个黑盒来考虑>

级别：

<概要、用户目标、子功能三者之一>

主执行者：

<主执行这的角色名称或主执行者的描述>

项目相关人员和利益：

<用例中项目相关人员和关键利益的列表>

前置条件：

<我们所希望的，周围环境已经达到的状态>

最小保证：

<在所有退出操作前，如何保证得到必须的信息>

成功保证：

<目标完成时环境的状态>

触发事件：

<什么引发了用例，可能是时间事件>

主成功场景：

<在这里写出从触发事件到目标完成以及清楚的步骤>

<步骤编号#><动作描述>

扩展：

<在这里写出扩展，每次写一个扩展，每一个扩展都指向主场景中的特定步骤>

<被改变步骤><条件>：

<动作或子用例>

<被改变步骤><条件>：

<动作或子用例>

技术和数据变化列表：

<在这里写出场景中因技术或数据变化而引起的可能分支>

<步骤或变化编号#><变化列表>