封闭式开发

一、封闭式开发的基本装备 金秋十月，丹佳飘香，正好有些时间整理下在山里的日子，大家一直在寻找银弹现在一起讨论下封闭式开发，真的能成为银弹吗，一起来讨论下吧。  上个月公司上了个新项目，公司决定在全公司内选出一个Team，由一个技术经理和一个产品经理带队，去山时面做封闭式开发。问了问同学朋友，他们公司有的项目或产品也搞过。不过，几辆车，十几个人，十几个笔记本，就风风火火上山啦。我发现人到了一个与世隔绝的地方，会变得开朗一些，自由一些，也会BT一些哦，其中有苦有甜，先从前期准备说起吧。   前期准备主要有以下几个东西：    笔记本：14台    台式机：5台，其中三台服务器，2台是给数据处理人员使用。    无线路由：三个（回来的时间都没带回来）    白板：一个    A4纸：两包    纸的垫板：若干    网线：若干    系统盘：两张    移动光驱：一个    这里特别要提醒一下，一定要带好备用的机器，由于山路崎岖，路漫漫其那个啥，所以难免会有些机器受不了，会被震掉。我们这次去山里面就震掉两台机子，一台怎么也开不了机。一台老是花屏。还有一个特别要注意的地方就是，一定要记得分两三批人过去。一定会有乱七八糟的东西没有带，后面一批人正好可以带过来。   花了一个上午的时间把东西搬到指定的地方，然后没等休息，我们就坐到一起开个会，   令人期待的十五天就要开始啦，一切都准备完毕，一个小型的网络还有一个大桌子，接下来真的会有什么不同吗，以前各自都属于其它项目组或其它部门。现在是新的开发模式，新的管理方式，新的Team，一切都是新的，在激动之余又有些担心.PS：先写到这吧，下篇会介绍一下作息时间表,争取在这个国庆，把这个系列写完，也算把这次难得的体验分享给大家吧，希望也有过封闭式开发的朋友们，也一起加入进来讨论咯。二、封闭式开发的时间安排   项目启动会议上，时间安排如下所示，一看上去可能有点像 高中 高中语文新课程标准高中物理选修31全套教案高中英语研修观课报告高中物理学习方法和技巧高中数学说课稿范文 的复习高考的时间表，不在太激动哦，我们其实也是在比赛，和自己在比赛。详细时间表如下：     早餐：7：00~8：00     上午：8：00~12：00     午餐：12：00~12：30     午休：12：30~14：00     下午：14：00~17：30     晚餐：17：30~18：00     交流：18：00~19：00     晚上：19：00~22：00其实,说真的,我们早上真的没有吃一个小时的早餐．还有，只有开头的晚上几天是按时下班的哦，一般都到2～３点吧．这里特别说明一下哦，上面没有安排一些运动和一些娱乐活动哦，其实可以在吃完晚饭时候去找些地方活动一下哦，比如打打乒乓球或者看看电视之类的．不过不建议剧烈的活动，这样的话，晚上几乎会没体，毕竟还要到这么晚是吧．其实，这份时间表里面最种要的那一个小时的交流时间，其实，大家的工作都比较独立，特别一开始的时候，大家对整个项目的轮廓都不太清楚，所以听的也是云里雾里的．基本上也提不出什么建设性的意见．所以大家有时候都是继续做自己这块，但是为了整体的节奏感，还是要让大家的大方向都确定．也为了能让大家有团队的感觉，还是放在一起开比较好。到了后期，当项目的轮廓慢慢清楚了，大家对问题认识得也比较清楚了，这时候对问题的讨论往往也比较深入，这时候可能占用其它人比较多的时间在会议上，有时候一个比较纠结的问题可能会拖到9点，也是会把讨论的时间从一个小时托到两小时。在这么静的地方开发不会被打扰，在讨论的时候也不会被打扰哦，所以问题的边界也会被越放越大。下次我们进行讨论的时候，还是要像以前的半小时原则。如果半小时讨论不定，说明没有准备好。如果是群体会议，每个小组之间的接口常常被无意识的置后，这个也要被关注。附：会议如何改善1.谁应该参加?. ---人需分:必须参加人员,要发言的 和随意参加的人,可发言可不发言.2.谁主持? ---“主席”—副总;导言人—经理;“观察员”—总经理人力资源3.谁控制? ----“主席”是控制秩序的;”导言人”是控制时间的;“观察员”是控制全场的.4.开会的时候谁先发言? ---由下而上.先外后内.的发言顺序.5.谁负责跟谁追踪? ---开会一定要有决议的负责人,还要有负责追踪的人.总经理只负责决策,做事的是其他人.谁召集会议,谁负责.6.谁在浪费时间?---资料应在会前发给并阅读,一进会场就是直接讨论和表决.7.谁结论? ----没有更好的办法,就用”主持人”的方法.(导言人¨¤主席¨¤观察员) 开会必须要有答案.没有答案,会议不要开.三、HYPERLINK"http://www.cnblogs.com/dtdnh520/archive/2010/10/04/1841865.html"封闭式开发的人员配备上篇写到时间表，现在看了觉得还在松了，呵呵。前两天，阿日在自己的文章中写到关于“提高软件质量的十个环节”，总节的非常不错。不过有一点可能也要被重视，后面的回贴中也有人提到，就是软件开发的质量重在两个人字，一个是“人”字，另一个是“心”字。当然这和我们的软件工程的理念是相围背的，西方的“工程化”的人件思想也是有一定基础的，特别大项目在操作的时候，就要做到可替换性，我们就是一颗颗经过ISO9001认证过的镙丝丁。不过，在封闭试开发中，可以用来替换的镙丝丁比较少，因为我们这个Team是被公司选中去要在指定的时间，指定的人员，完成指定的任务的。目标清晰，资源有限，时间紧迫。所以在人员安排的时候，不能分太细，几个人的技术储备要有一定交叉。这样，表面上，大家是不同小组，也有各自相对独立的任务，其实，如果一个小组忙不过来，而其它小组够快，那么，还是可以互相帮助的。言归正转，下面来聊聊这次封闭式开发中的人员安排和分析。人员安排如下：技术经理一名、产品经理一名、数据处理人员两名、开发人员10人，测试人员(无),UI（交互设计师）一名,WEB框架开发人员一名。分析上面的人员安排：有以下几点要说明的地方：第一、技术经理。把握技术选型和人员分配。他知道每个人开发人员的技术重点和开发效率。也知道这次产品开发需要的新技术和架构。对技术这块的实现难易程度有个很好的把握。在Team需要做技术调整或人员调调整的时候，可是迅速做出判断。后期还有代码审查、高难度技术攻关等工作。第二、产品经理。主要任务付责一些前期需求。主要和UI讨论这些前期搜集过来的需求如何让用户有最好的用户体验。产品经理思路广阔，常常会冒出有创意的想法。常常关注一些大的网站或知名产品，需求的把控者。第三、交互设计师(UI)。以用户为中心的产品设计，付责界面原型和高精度的成品图。需要让用户有较好的用户体验，也需和主流网站的用户体验有交叉的地方。这样让用户学习接近零成本。第四、没有测试人员。一个Team竟然没有测试人员，不是吧。一眼看过去，可能会感觉到不可思议，其实，这次我们没有独立的测试人员，但是我们有开发人员的单元测试。我们的开发模式的偏敏捷开发，所以整体的功能测试和边界测试和其它测试都放在后面。我们在其中只做新功能的演示和单元测试。第五、开发人员。HYPERLINK"http://www.qikan.com.cn/Article/dddy/dddy200811/dddy20081119.html"\t"_blank"铁打的营盘铁打的兵，一个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共有下面几句话:1.      REST是URL驱动的,URL的变化代替了内部的状态变化2.      REST让WEB项目更像Winform项目了.3.      REST对数据的依赖大于业务逻辑.在业务逻辑确定之后,可以按业务逻辑和流程,结合状态变化先订好URL地址,这样可以防止不同小组间的冲突.4.      REST是个数据提供者,展现方式你自己决定.5.      REST不适合处理复杂的业务逻辑和大量的状态迁移.6.      REST不仅仅可以走HTTP,也可以走TCP,或者HTML5中的Websocket.只要是按照前面的那几种原则来.例子: 下面简单基于描述一个登录注册的例子,使用的是html5中的websocket说明:1.      WS是使用websocket协议.2.      一共有增加用户,更新用户信息,登录,和检查用户状态等功能.3.      其中更新用户信息和登录都会指向下一个url,即检用户状态的url.也曾看过几篇关于REST的不好之处的文章,个人觉得有每个模式不是完美的,也有各自的优点和缺点,关键是你有那么多资源和时间吗?或者你能在尽可能短的时间内向TEAM的程员讲清楚,又能满足项目或产品的进度需求吗?如果上面几个问题都没问题,那用什么也没问题了.我们不是使用最完美的架构,而是此时此刻最适合的.引用CRUD不适合REST吗？HYPERLINK"http://www.infoq.com/cn/news/2009/08/CRUDREST"http://www.infoq.com/cn/news/2009/08/CRUDRESTHYPERLINK"http://www.cnblogs.com/weidagang2046/archive/2009/05/08/1452322.html"REST构架风格介绍之一：状态表述转移HYPERLINK"http://www.cnblogs.com/weidagang2046/archive/2009/05/08/1452322.html"http://www.cnblogs.com/weidagang2046/archive/2009/05/08/1452322.html五、封闭式开发的敏捷开发   封闭式时间紧、任务急，而且是好不容易向老板那里要来的资源。还有，没有其它的干扰，所以对于我们这个Team来说，应该是没有任何借口的，不管这是一个产品研发，还是一个项目开发，都不容许有任何差错。 但是在前期没有客户直接接触，确切的说，只有一个产品经理获得了一些基本的客户需求时，我们怎么做出成绩，或者相对的能做出一些被认可的东西来了呢？思来想去，我们没有按原来的从需求分析到测试到编码的传统流程。我们使用了敏捷。这里不敢说完全按照了Scrum，或者其它的敏捷过程管理，因为在敏捷开发的群集中，我们毕竟还算新手，但是为了能轻装上阵，速度取胜，我们尽量的把一些省时省力的，而且轻文档的好的实践引入到封闭式开发中。在这个时间段，我们只有把减轻文档，从开发的平行化转为开发的纵向化，即从流程为主导转向以业务为主导。                            瀑布过程    原来的以过程为主导就是先把需求做细，向各方确认，然后由产品经理汇总，再交于界面交互设计师和架构师，再经确认后再交给开发去编码，最后功能点全都达标后，再交给测试，最后是QA。这样有个问题，好多文章都说了，错误到最后才这发检查出来，或者直接被否定了，郁闷。封闭式开发是不容许出现这种问题的，我们只有一个目标，做出客户想要的。所以，我们只能从业务导向，把一个需求从基本的描述到开发，到测试，深入的做好一个个需求，到给客户看的时候，我们就能拿得出手，讲的好听点，我们可以随时拿出一个可以演示的版本来给产品经理去做演示。而不是原来的到提交测试前一天，开发人员的代码都是写好的，可是没有经过验证，因为测试没过。每个功能点的完成度都是90%多，没有一个版本是拿得出来的。客户急了，我们的老板更急。                           scrum过程  上面讲了一些闲话，主要是说明了为什么在我们在封闭式开发中要引用敏捷，下面着重介绍几种比较好用的几条建议：1.      轻文档描述不要复杂的，重量级的需求说明书。每个需我们简单的用一段话，或一个小小的流程图来说明，有时候直接写到了笔记本上，根本没有电子化。下面是简单的一个用户故事。假设我们开发的是一个类似于QQ的即时通讯项目，这里描述的是一个创建群的故事：故事描述：作为一个使用我们产品的客户，我需要建立一个群组，并且选定群组的人数和群组名称，以用来向这些群组内的所有人发送相同的消息，而不用为每个人发送。简单流程图：用户接受测试：点击创建群组按扭，输入群名称，指定群成员，创建群，系统返回成功或失败。 2.      单元测试每个小组对于自己开发的模块在给其它小组调用的时候，都要至少通过单元测试，这里特别要强调对于输入验证和输出格式返回。有时候当接口的参数十分特别的时候会减少反复的时间。如果Team中的其他人调用到你的接口，出现了问题，你可以及时把这个bug转化成单元测试，下次提交的时候则同一样的错误不会重犯。如果有时间多的话，可以提高下代码覆盖率，也是一种不错的选择哦。同理，如果你发现了其它小组提供的接口中有些bug，则也可以为这个bug编写一个单元测试用例。这样，使这个bug重复出现的成本变成零，也方便验证那个小组在重构后会反复的问题。3.      代码交流（TDD）如第2点所示，我们之间的调用和被调用，都被固化在了单元测试中，不用直正到产品中的代码中才能发现或被调试。小组间不再花更多的时间在争吵或者改没改上面，只要原来的测试能满足，现在却不能满足了，谁的问题，也就没有争的必要了。4.      每日构建这个十分十分的重要，要及时给大家汇报，我们现在完成的故事是多少了，现在能看到结果是哪些，时间安排HYPERLINK"file:///F:\\qprojects\\_%E5%8D%9A%E5%AE%A2\\%E5%B0%81%E9%97%AD%E5%BC%8F%E5%BC%80%E5%8F%91%E5%B0%8F%E8%AE%B0%E5%90%88%E9%9B%862.doc"\l"_msocom_2"[l2]，我们每天都有一个小时专门用于汇报和讨论，在这里大家能及时看到完的业务故事情况。也方便进行讨论。如果一个版本比较稳定，我们会打一个版本，并且发布到外网上去。并在源码上做好版本的标记。5.      编码 规范 编程规范下载gsp规范下载钢格栅规范下载警徽规范下载建设厅规范下载 我们是用REST的模式进行开发，所以要对URL进行规范，每个小组在开发时，都需提前把自己的URL头，和可能用的到列表都发给一个人进行管理。功能说明URLQQ/增加群HYPERLINK"http://abc.com/qq/addgroup"http://abc.com/qq/addgroupQQ/增加用户HYPERLINK"http://abc.com/qq/adduser"http://abc.com/qq/adduserQQ/登录HYPERLINK"http://abc.com/qq/login"http://abc.com/qq/loginWeather/查询本地天气HYPERLINK"http://abc.com/weather/local"http://abc.com/weather/local?areacode={0}Weather/查询温度差http://abc.com/weather/tmp?areacodes={json:0}代码编写和命名规范是直接用公司的统一规范。6.      主动索取任务原来是经理对所有开发人员说，你的任务是什么，你的是任务是那些。现我们一开始在讨论会中把所有的任务都列了出来。然后，我们自己规划这两周能做哪任务。化备动为主动。7.      互相帮助由于每个开发人员开发效率不同，可能有的先完成任务了，有的还没完成。由于我们不再像原来的那样，数据库开发只管数据库开发，前台只管前台，框架只管框架。如果后台人员完成开发任务了，会主动帮助前台进行开发。像我虽然是后台通信开发小组的，可是在完成自己的开发任务后，我也参与了样式布局和前台脚本的开发。任务是我们自己选的，一定要一起完成他。8.      代码审查按照编码规范去查看代码，一个迭代大概花半天时间。再半天时间重构代码和用测试去验证。9.      白板讨论我们讨论的时候不再纸上画，我们也可以用白板。画简单的流程图或序列图。这样让更多相关人员都能进来。不足之处：1.      集成测试由于我们是基于单个故事开发，到集成测试的时候，可能由于每个小组进度不一，而时间会有所拖延。所以至少要花半天时间来做这个工作，而不是原先期望的半小时内。在这个时候，接口会有所调整，要及时编写对应的单元测试进行验证。2.      代码覆盖率由于时间不足，这部份没有达到理想的90%以上。只能80%多吧。3.      文档不足我们大多以代码为文档，把命名做好了后，几乎没有写什么文档，需要多方确认的需求除外。如果有时间多，还是需要把这些基本的故事整入backlog中。以备做战斗力评估和团队成长的 记录 混凝土 养护记录下载土方回填监理旁站记录免费下载集备记录下载集备记录下载集备记录下载 。六、封闭式开发的文档管理在封闭式开发中，我们要尽量把花在写文档上的时间减到小，这样才能保证更多的时间用于实现业务需求上。只能尽可能短的时间做出可以演示的需求，才能让客户满意。但是虽然没有原来需求说明和详细设计那么多。但是基本的用于落实需求和用于交流的文档还是要的。其实个人认为最好的文档就是代码了，关于代码既是文档可以参考《cleancode》,下面着重介绍一些不可再省的文档了：用户故事（userstory）：定义：以人为中心用业务语言简要描述客户需求。对最终用户来说最有意义的一个功能。主要包括以下三个部份：卡片（用卡片来记录）：对话（用客户的语言，关注客户关注的问题）：验证：（记录一些用可以检查这个用户故事是否通过）格式：作为…我需要…以便…范例：做为一个产品经理,我需要查询产品列表,然后,以便给最紧密的联系人打电话.范例分析：目标用户是产品经理，他希望按一定的条件查询产品列表，并且把查询的数据集进排序，对关键字权重高的要排到前面。并且显示的联系人信息不要求太全，但最重要的就是他的电话。且望Arycard间用于实现业务需求上。不同的人对应同样功能可能有不同的要求，如仓库操作人员想通过使用查询产品列表完成仓库的拣选商品的操作，以提升仓库工作人员的工作效率。其中受众是仓库操作人员，业务操作是使用手机进行商品的拣选，目的是提升仓库操作人员的效率，实现商业目标。用户接收测试（uat）：这个用户故事如何演示，才能让客户明白，这个功能是实现的。接上面的这个查询的例子：用户在文本框中输入对应的关键词，多个关键词是以空格或逗号隔开。点击查询按扭后，页面上显示所有相关产品列表，其中和关键字最相关的产品显示在最前面，且每个产品后面都对应显示出联系人的电话号码。参与人员：测试人员、产品经理、真实用户、交互功能设计人员用例(usecase)：定义：由特性分解而来的一个可以用来做功能测试的小情节。每个用例可以转化为一个单元测试。在每次重构后可以用来验证。格式：用例名应该是一个用主动语态动词短语来表示的用例目标>使用语境：<目标较长的描述，如果需要，还包括触发事件>范围：<设计范围，在设计时将系统作为一个黑盒来考虑>级别：<概要、用户目标、子功能三者之一>主执行者：<主执行这的角色名称或主执行者的描述>项目相关人员和利益：<用例中项目相关人员和关键利益的列表>前置条件：<我们所希望的，周围环境已经达到的状态>最小保证：<在所有退出操作前，如何保证得到必须的信息>成功保证：<目标完成时环境的状态>触发事件：<什么引发了用例，可能是时间事件>主成功场景：<在这里写出从触发事件到目标完成以及清楚的步骤><步骤编号#><动作描述>扩展：<在这里写出扩展，每次写一个扩展，每一个扩展都指向主场景中的特定步骤><被改变步骤><条件>：<动作或子用例><被改变步骤><条件>：<动作或子用例>技术和数据变化列表：<在这里写出场景中因技术或数据变化而引起的可能分支><步骤或变化编号#><变化列表><步骤或变化编号#><变化列表>相关信息<项目所需要的所有附加信息> 注：除了使用相关的文档外，其它建模方式可以是UML，可以是Word文档，也可以是白板上的图。只要让参与各方都能确认，并且能记录下来就行了。看自的习惯了，在前一篇可以看到，我们基本上都用时序图的方式，这样比较好理解。范例：请参考《编写有效用例》P110页《UML团队开发实用手册》参与人员：产品经理、开发人员、测试人员（可无）代码签入时备注(checkinnote)：当出现两个开发人员同时编写一个源代码文件时，清楚的注释能够快速定位一些因交叉签入和测试不彻底造成的bug。有一次，和我配队开发的同事他有事请假一天，然后我发现他有一个项目文件是签出的状态，然后我撤销签出后，把新的源码签入后填写了备注。第二天他来的时候，由于看到获取最新版本的时候发现了这个备注，然后合并修改了。最后特别果注明多个版本同时更新时的同步信息，尽量保证版本号、bug号等的完整。特别要注意和任务号的对应，这样能按bug查找版本号，再查到对应的业务需求（任务）。日报\周报(dailyreport\weeklyreport)：以周报为例：今天的任务是什么，今天完成的任务（未完成的可以加上百分比），明天的任务。代码复查报告(codereviewreport)按小组分开，按编码规范一条条过。注意要把多余的文件给删掉。 PS：代码既是文档。但是代码终究还是语言，是语言就可能多种口音和方言，虽然都是属于汉语。不排除口吃的人除外呢。特别，实现还不是那么清楚的时候，我们只能通过文档，把实现尽量放到后面，这样才能防止较多的反复和争吵。本文还少了一个最为关键的部份，就是工作量的估算和记录，这是一个团队成长最重要的环节。由于可以独立成篇，这里不再赘述。七、如何和谐沟通、提高士气（结合开发实际冲突来深入讨论合作与沟通）老板和经理关注结果、基层管理关注质量。一个生产力高的Team，除了技术行之外，好的气氛和好的沟通方式是Team战斗力提高、凝聚力提高的不二法门。本节主要讨论关于要主要内容是谈谈如何提高团队的士气，如何提高团队意识，如何解决在沟通中出现的问题等。这几个问题往往在项目开发中期，十分的明显，而我们又是在封闭式开发中，大家想快点出成绩，心情有些急迫。同时各个小组开发都走过了摸索和技术储备的过程，架构也都基本确定，各小组的成员都专心于自己的模块，各个模块的接口部份也都逐渐清晰起来，沟通问题也随之而来。归根到底，沟通问题主要以下两个原因：其一、对结果不能统一。是对于需求的不理解和标准定义不同导致了这些问题的发生，主要存在于产品经理和开发人员之间。其二，对于结果可以统一，对细节不能统一。主要存在于开发人员之间。其三、当没有预料的问题出现后谁该负责，或者谁该出来解决的问题。如果以上三个问题出现次数较多，则会出现第四个问题：士气低落。这几个问题如果要钻牛角尖，则否十分浪费战斗力和时间，特别是第二个问题，开发人员往往会由于面子问题或者工作量的问题会浪费争吵的时间。下面把几个问题分开开来讨论。问题一：对结果不能统一。描述：在做即时通信中。在有一次讨论中，老大提出来要把所有的可其它业务功能都像QQ一样集成到我们的即时通信子系统中，像QQ一样在左边栏中都加入一排竖着的快捷按钮。我们现阶段的时间压力下，是无法实现这个功能的。当然，这个需求是在汇报的时候老板才提出来的，因为在我们的团队中，都是对结果的问题都比较统一，我们都想快速的结束掉封闭式开发，完成任务。解决办法：会把这种需求写入到故事列表中，设置较低的优先级。因为对于即时通信系统来说，有其它的任务优先级较高，如发送群消息，好友查找等等。问题二：对结果能统一，但对实现细节不能统一。描述：还拿即时通信做举例子吧，有一个需求是查找好友列表，这时候有两种实现方式。在选择群内的好友时，可能有两种展现方式，一种是以列表分页方式。如下图所示。另一种是在左边以树型的方式显示,有点类似下面的左半部份。只是实际的需求更复杂一些。因为QQ中的好友和分组都是相对固定的。如果我们要去所有好友中查询的话，那么他所属的组织机构可是我们没有的。如果查出来的10个人分别各自属于10个不同的机构，则左边的树型就要生成10棵子树。如果查出来有1000个不同的部门的人。性能可想而知。后台开发人员认为性能底，后台实现复杂，用户体验也不好。前面开发人员由于有类型模块，如果使用树型，则开发代码较少。于是，两边“讨论”了一些时间，没有把这个问题给定下来。解决办法：找出已有的几种用户列表的展现方式，如China人网、人人网。包括QQ本身，大多采用列表方式，也就是前一种。这样用户体验十分友好，性能也能达到要求。遇到这种问题，一定要用事实和实例说话，不能一股劲的坚持自己的观点。如果你站在圈内的时候，都会认为自己是对的，只有走出自己的圈子，才能看到整个问题的全貌。接着，要从对方的观点入手，把问题再分析一遍。如下图所示：当我们都坚持自己的观点时，我们常常看到只有冲突。   但是，我们如果把自己的观点先放着，试着想想我们的目标：完成客户要求查询好友，然后组建群组的故事。那么我们就能看到共同的目标，而不是冲突。如下图所示。站在点方的角度，我的理解是先放下自己的观点，然后找到共同目标，再理解对方难处。先把心情给摆平了，再谈问题往往比较顺。一味的深入讨论实现方式往往会迷失目标，有人说，我们一直匆匆忙忙的走，却忘记了为什么要走下去。问题三：出现无法预料的问题。描述：项目快提交客户演示了，由于网速过慢，要换一个地址来部署我们的系统。在重新部署的过程中，出现了一个配置问题。这个问题原来都没有遇到，可是说是测试的灰色地代。马上就要演示了，全部的开发人员都很紧张。有的人开始否定当初定的演示 方案 气瓶 现场处置方案 .pdf气瓶 现场处置方案 .doc见习基地管理方案.doc关于群访事件的化解方案建筑工地扬尘治理专项方案下载 。。。有的人。。。解决方法：第一，冷静。没有什么问题解决不了，只是环境变了而以，不会有什么大问题。第二、少说话。不要说和解决问题无关的话，不要讨论是谁的问题。按配置手册一个一个的排查。看调用的配置接口是否是过时版本，或者配置有冲突。如果这时候互相推卸责任，那那么演示时间必然拖延，而且也会大大影响士气。第三、不要抱怨。好的习惯会传染，坏的习惯也会传染。特别是抱怨，有时候一两句无心的抱怨真的很伤人。问题四：士气底落。描述：前三个问题没有处理好，加上高层压力不减，每个人的神经都很紧。这时候就会出现士气低落的问题。解决办法1.          创建和谐气氛，弱等级化。在封闭式开发中，我们不要过分强调权力和等级，我们都是平级的关系，而是一个球队。开开玩玩笑也不要太认真。2.          培养互助精神。开发快的小组帮开发较慢的小组。这也适合在结队编程中。3.          任务主动获取。把故事都列出来，看一个迭代能完成多少任务，由开发人员自己按优先级获取，化被动为主动。4.          让开发人员参与到设计中来。在进行设计时，可以召集开发人员讨论接口设计和一些基本模式设计，让开发人员能感觉到在成长。5.          做好代码审查。这又是一个让开发人员学习和成长的机会，会让开发人员的重构技术和单元测试技术都有所提高。6.          多组织一些好娱乐节目。这点在封闭式开发中不太可能，只能自娱自乐咯，呵呵。小结：有人曾说过“只要沟通，世上就没有解决不了的问题。”这点在一个新的团队，大家都不是十分了解的时候，而压力又十分的大时，我们往往会等不及听对方的观点，也不想去管那么多，只想让对方快点接受自己的想法。与此同时，还会想自己的解决方案这么全面，性能也很高，为什么你就不接受呢，然后就是一阵阵的扭结，甚至争吵。真是得不偿失呀。八、封闭式开发的项目讨论项目讨论的主题大多是需求，项目讨论的主要目的也是为了理清需求。项目讨论主要集中在两个阶段：第一个阶段是全员参与，讨论项目的功能需求。由于封闭式开发到了一定阶段，框架基本稳定，但是初步的需求还不太稳定，由于封闭式结束日期的限制，所以需求在不断的裁减之中。那些被规定的需求是必须要完成的，当然，在故事列表中，还有好多，可能由于优先级和时间压力被推后了。第二阶段，各自开发小组细化需求和流程。这个阶段是实际的开发阶段，每个小组在这个迭代选取了各自的任务后，都要进行故事的拆分工作，把大的故事（复杂的需求）拆分成可执行的任务，这里各个任务的时间估算工作。开发人员的估算会和结果有点出路，但如果不估算，那么实际的时间可能会更多。这里估记有一种心理做用在，毕竟我们在这次会议中还有制定在迭代最后一天对应每个故事进行演示的简单流程。所以这次需求细化讨论会议，基本确定了能完成的故事点和对应的接口调用规范。可能的问题：第一：任务太多做不完。你开发的模块可能是核心模块，可能是集成性的模块，可能用户使用率最高的模块，可能已有成熟应用的模块。那么，产品经理或其它开发人员对此模块的需求更多，或者要求更高。如果你开发及时通信，那么就会和QQ比，如果你开发门户，就会被拿来和网易新浪比。但是，要求高意味更高的提高。能增加思考问题的全面性。如果你写的代码或构架是可质量比较好的，有覆盖率较高，用例较全面的测试，那么可能减少你的任务量，也能把需求以代码的方式确定下来。我们的单元测试或才测试驱动而编写的代码，就相当于是可以重复验证的需求说明书，如果结合每日构建的测试，跑一遍后，可以把好多问题都扼杀在摇篮里面。而且，重复执行的成本也十分低廉。我们不需要有太多太多的功能，我们需要提交的功能是没有问题的。第二：容易跑题，没有结果。在进行项目讨论的时候，有些实现方式没有对错，如果把所有人放在一起，则会浪费不相关小组的开发人员的时间。所以细化需求的会议可以在各自小组开展。全员参与的会议时间尽量的短，这样不会激起成员对会议的反感，也会增加会议的有效性。PS：会议有时候是浪费时间和降低战斗力的主要原因。九、HYPERLINK"http://www.cnblogs.com/dtdnh520/archive/2010/10/11/1848278.html"封闭式开发的最后一天(开发中的一些心情记录，和开发无关)这篇主要是一些杂记，主要记录一些封闭式开发最后一天的小事。最后一天大家的心情既激动又疲惫。可能是连续几天加班到两三点导致反应有一点慢。或者身体的抵抗力都下降了不少。不过，经过一番调整后，马上清楚了许多，可能想在结束封闭式开发之前，给公司汇报之前，把一些问题都处理完毕吧。所以动作有意识的加快了不少。如果有困的时候，就去洗手间用冷水冲冲脸。深呼吸下，还好，我们的开发房间有些音乐，可以听一些放松心情的音乐。虽然很小声，但至少化解了一些紧张。最后一天做东西特别的杂。特别是接口的部份，可能有这样，或那样的事，特别你把流程走过一遍后，会发现一大堆的小问题，由于没有测试的缘故。有人说，在走之前，要放一首回家，那样才够味。还有，中午吃饭时候，要把饭都吃完，还有，要把所有东西都收好，带回来。发哥说，要不然，你还是要进来的。于是我们打完包，把之前带的网线，和电脑都收好，然后打包上车。在上车之前，我们在门口拍张照合了影。大家都笑得很开心，我想多半是因为可以下山了吧。这些天的加班，从一开始分房间时的激动，到点抢饭吃时的狼吞虎咽，晚上到处找泡面的时惊喜，有人还把牛奶到水喝，有人天天打蜘蛛，好多好多的小事，都随着颠簸的山路，一点点的遗落在各处，像是在做记号。这时，车窗开了，呼呼的风真的很爽，吹吧，吹走一切。   进了市区，不知道是累的没有力气，还是别的什么。反而会觉平静，如果真的有点什么不同，可能是觉得有点吵而以。看来我们还是喜欢这吵吵闹闹的环境，呵呵。十、封闭式开发的项目汇报(10.11)十一、封闭式开发的测试发布(10.12)