封闭式开发

上传人:今*** 文档编号:105972058 上传时间:2019-10-14 格式:DOC 页数:27 大小:382KB
返回 下载 相关 举报
封闭式开发_第1页
第1页 / 共27页
封闭式开发_第2页
第2页 / 共27页
封闭式开发_第3页
第3页 / 共27页
封闭式开发_第4页
第4页 / 共27页
封闭式开发_第5页
第5页 / 共27页
点击查看更多>>
资源描述

《封闭式开发》由会员分享,可在线阅读,更多相关《封闭式开发(27页珍藏版)》请在金锄头文库上搜索。

1、一、封闭式开发的基本装备 金秋十月,丹佳飘香,正好有些时间整理下在山里的日子,大家一直在寻找银弹现在一起讨论下封闭式开发,真的能成为银弹吗,一起来讨论下吧。上个月公司上了个新项目,公司决定在全公司内选出一个Team,由一个技术经理和一个产品经理带队,去山时面做封闭式开发。问了问同学朋友,他们公司有的项目或产品也搞过。不过,几辆车,十几个人,十几个笔记本,就风风火火上山啦。我发现人到了一个与世隔绝的地方,会变得开朗一些,自由一些,也会BT一些哦,其中有苦有甜,先从前期准备说起吧。 前期准备主要有以下几个东西: 笔记本:14台 台式机:5台,其中三台服务器,2台是给数据处理人员使用。 无线路由:三

2、个(回来的时间都没带回来) 白板:一个 A4纸:两包 纸的垫板:若干 网线:若干 系统盘:两张 移动光驱:一个 这里特别要提醒一下,一定要带好备用的机器,由于山路崎岖,路漫漫其那个啥,所以难免会有些机器受不了,会被震掉。我们这次去山里面就震掉两台机子,一台怎么也开不了机。一台老是花屏。还有一个特别要注意的地方就是,一定要记得分两三批人过去。一定会有乱七八糟的东西没有带,后面一批人正好可以带过来。 花了一个上午的时间把东西搬到指定的地方,然后没等休息,我们就坐到一起开个会, 令人期待的十五天就要开始啦,一切都准备完毕,一个小型的网络还有一个大桌子,接下来真的会有什么不同吗,以前各自都属于其它项目

3、组或其它部门。现在是新的开发模式,新的管理方式,新的Team,一切都是新的,在激动之余又有些担心.PS:先写到这吧,下篇会介绍一下作息时间表,争取在这个国庆,把这个系列写完,也算把这次难得的体验分享给大家吧,希望也有过封闭式开发的朋友们,也一起加入进来讨论咯。二、封闭式开发的时间安排项目启动会议上,时间安排如下所示,一看上去可能有点像高中的复习高考的时间表,不在太激动哦,我们其实也是在比赛,和自己在比赛。详细时间表如下: 早餐:7:008:00 上午:8:0012:00 午餐:12:0012:30 午休:12:3014:00 下午:14:0017:30 晚餐:17:3018:00 交流:18:

4、0019:00 晚上:19:0022:00其实,说真的,我们早上真的没有吃一个小时的早餐还有,只有开头的晚上几天是按时下班的哦,一般都到2点吧这里特别说明一下哦,上面没有安排一些运动和一些娱乐活动哦,其实可以在吃完晚饭时候去找些地方活动一下哦,比如打打乒乓球或者看看电视之类的不过不建议剧烈的活动,这样的话,晚上几乎会没体,毕竟还要到这么晚是吧其实,这份时间表里面最种要的那一个小时的交流时间,其实,大家的工作都比较独立,特别一开始的时候,大家对整个项目的轮廓都不太清楚,所以听的也是云里雾里的基本上也提不出什么建设性的意见所以大家有时候都是继续做自己这块,但是为了整体的节奏感,还是要让大家的大方向

5、都确定也为了能让大家有团队的感觉,还是放在一起开比较好。到了后期,当项目的轮廓慢慢清楚了,大家对问题认识得也比较清楚了,这时候对问题的讨论往往也比较深入,这时候可能占用其它人比较多的时间在会议上,有时候一个比较纠结的问题可能会拖到9点,也是会把讨论的时间从一个小时托到两小时。在这么静的地方开发不会被打扰,在讨论的时候也不会被打扰哦,所以问题的边界也会被越放越大。下次我们进行讨论的时候,还是要像以前的半小时原则。如果半小时讨论不定,说明没有准备好。如果是群体会议,每个小组之间的接口常常被无意识的置后,这个也要被关注。附:会议如何改善1.谁应该参加?.-人需分: 必须参加人员,要发言的和随意参加的

6、人,可发言可不发言.2.谁主持? -“主席”副总; 导言人经理; “观察员”总经理人力资源3.谁控制? -“主席”是控制秩序的;”导言人”是控制时间的; “观察员”是控制全场的.4.开会的时候谁先发言?-由下而上. 先外后内. 的发言顺序.5.谁负责跟谁追踪? - 开会一定要有决议的负责人,还要有负责追踪的人. 总经理只负责决策,做事的是其他人. 谁召集会议,谁负责.6.谁在浪费时间? - 资料应在会前发给并阅读,一进会场就是直接讨论和表决.7.谁结论?- 没有更好的办法,就用”主持人”的方法.(导言人主席观察员)开会必须要有答案. 没有答案,会议不要开.三、封闭式开发的人员配备上篇写到时间表

7、,现在看了觉得还在松了,呵呵。前两天,阿日在自己的文章中写到关于“提高软件质量的十个环节”,总节的非常不错。不过有一点可能也要被重视,后面的回贴中也有人提到,就是软件开发的质量重在两个人字,一个是“人”字,另一个是“心”字。当然这和我们的软件工程的理念是相围背的,西方的“工程化”的人件思想也是有一定基础的,特别大项目在操作的时候,就要做到可替换性,我们就是一颗颗经过ISO9001认证过的镙丝丁。不过,在封闭试开发中,可以用来替换的镙丝丁比较少,因为我们这个Team是被公司选中去要在指定的时间,指定的人员,完成指定的任务的。目标清晰,资源有限,时间紧迫。所以在人员安排的时候,不能分太细,几个人的

8、技术储备要有一定交叉。这样,表面上,大家是不同小组,也有各自相对独立的任务,其实,如果一个小组忙不过来,而其它小组够快,那么,还是可以互相帮助的。言归正转,下面来聊聊这次封闭式开发中的人员安排和分析。人员安排如下:技术经理一名、产品经理一名、数据处理人员两名、开发人员10人,测试人员(无),UI(交互设计师)一名,WEB框架开发人员一名。分析上面的人员安排:有以下几点要说明的地方:第一、技术经理。把握技术选型和人员分配。他知道每个人开发人员的技术重点和开发效率。也知道这次产品开发需要的新技术和架构。对技术这块的实现难易程度有个很好的把握。在Team需要做技术调整或人员调调整的时候,可是迅速做出

9、判断。后期还有代码审查、高难度技术攻关等工作。第二、产品经理。主要任务付责一些前期需求。主要和UI讨论这些前期搜集过来的需求如何让用户有最好的用户体验。产品经理思路广阔,常常会冒出有创意的想法。常常关注一些大的网站或知名产品,需求的把控者。第三、交互设计师(UI)。以用户为中心的产品设计,付责界面原型和高精度的成品图。需要让用户有较好的用户体验,也需和主流网站的用户体验有交叉的地方。这样让用户学习接近零成本。第四、没有测试人员。一个Team竟然没有测试人员,不是吧。一眼看过去,可能会感觉到不可思议,其实,这次我们没有独立的测试人员,但是我们有开发人员的单元测试。我们的开发模式的偏敏捷开发,所以

10、整体的功能测试和边界测试和其它测试都放在后面。我们在其中只做新功能的演示和单元测试。第五、开发人员。铁打的营盘铁打的兵,一个Team的任务执行者,产品质量好坏和进度推进最重要的一环。效率高底,代码风格好坏,直接决定项目的推进速度和BUG数。第六、WEB框架开发人员。最重要的是配合UI开发产品的首界面,和把各个模块集成到主框架中,对于样式和脚本的要求较高。第七、人员调整。有一个情况就是在这次开发中,我们有一个小组的任务实现起来比原来预想的功能要多,也要用到一些新技术,而且随着业务的扩展,那个小组可能无法独立完成这么大任务量了。这个时候,我们及时调整了小组分配,从其它不太忙,或者任务级别不太高的小

11、组调来两人,配合完成,后面也算完成了80%的任务,没有拖整个团队的后腿。小结:其实在那段时间的开发过程中,还有一系列的问题需要注意,这里由于篇幅有限,不再深入了。总之,一个新的Team,也用了好多新的技术,磨合十分重要。最后还是话,思路决定出路,我们是一个Team。四、封闭式开发的架构设计 这里主要简单介绍一下我们产品中主要WEB项目的构架思路,其它后台处理模块和通信服务端先略过.我们的架构设计是基于REST的思想,由于这里篇幅有限,不对这种思想进行详细描述,这里只描述几个REST的原则: 网络上的所有事物都被抽象为资源(resource); 每个资源对应一个唯一的资源标识符(resource

12、 identifier); 通过通用的连接器接口(generic connector interface)对资源进行操作; 对资源的各种操作不会改变资源标识符; 所有的操作都是无状态的(stateless)。其实,之所以我们选用这种架构,主要是因为,我们的业务很多是无状态的,且不需要太多的事务性原子化操作。主要的业务都是展现。只是在查询的多样性方面会有一些要求。所以,我们的开发人员可以为相应的请求(URL)进行访问指定的资源。 由于MVC的种种好处,我们把MVC的使用方式进行了改造。我们并没有使用.NET MVC默认的Viewer,而是直接自己使用通用json格式,结合模板和JS代替在走协议方

13、面,当然还是基于http协议咯,毕竟是网络应用但是我们没有使用原生的http的四个方法来实现.由于原生的http方法是GET,POST,PUT,DELETE,可以对应CURD中的增删改查,但更多的暴露了太多数据结构,而把太多的状态的工作放到的URL上. 所以个人总结REST共有下面几句话:1. REST是URL驱动的,URL的变化代替了内部的状态变化2. REST 让WEB项目更像Winform项目了.3. REST 对数据的依赖大于业务逻辑.在业务逻辑确定之后,可以按业务逻辑和流程,结合状态变化先订好URL地址,这样可以防止不同小组间的冲突.4. REST 是个数据提供者,展现方式你自己决定

14、.5. REST 不适合处理复杂的业务逻辑和大量的状态迁移.6. REST不仅仅可以走HTTP,也可以走TCP,或者HTML5中的Websocket.只要是按照前面的那几种原则来.例子:下面简单基于描述一个登录注册的例子,使用的是html5中的websocket说明:1. WS是使用websocket协议.2. 一共有增加用户,更新用户信息,登录,和检查用户状态等功能.3. 其中更新用户信息和登录都会指向下一个url ,即检用户状态的url.也曾看过几篇关于REST的不好之处的文章,个人觉得有每个模式不是完美的,也有各自的优点和缺点,关键是你有那么多资源和时间吗?或者你能在尽可能短的时间内向TEAM的程员讲清楚,又能满足项目或产品的进度需求吗

展开阅读全文
相关资源
相关搜索

当前位置:首页 > 高等教育 > 大学课件

电脑版 |金锄头文库版权所有
经营许可证:蜀ICP备13022795号 | 川公网安备 51140202000112号