传统团队的模式:
传统的团队的模式,由Constantine[CON93]提出的四种"组织范型",如下表。
首先:"封闭式范型"更类似于官僚模式,人与人之间存在着:明显的阶级关系,这种方式更像我们在平时上班中的工作关系,你的行为必然会受到你的顶头上司的约束,虽然规则性和秩序性变得更好,但在这种模式下,很容易变成"老板驱动"的工作模型。
个人认为开放式泛型,可能是比较稳妥的一种开放方式,比封闭式稍具活性,又比随机式更具有一定的约束性,但同时打破了同步式泛型的无交流,无约束的特点。
当下的团队模式:
由于我们现在还没有进入到实战的模式(进行一个实际软件的开发),所以恰逢罗杰老师(另一个实战的班级),所以通过13级的学长们的博文,总结下初步的感悟:
从极限编程说起:
极限编程(eXtreme Programming,XP):在传统的开发过程中,增进沟通和交流的典型方式是通过文档,但XP的提倡者们建议用比较随意的交流和沟通方式。不编写单独的文档,反之加强关键的软件产品(例如软件代码和测试数据)。
在代码复审(就是让别人来看自己的代码,是否在"代码规范"的框架内正确解决了问题),通过此点,可以发现:在逻辑、算法、潜在和回归性的错误的基础上,互相传授经验,在了解别人代码的基础上也不断提高自己的能级,而代码复审即是极限编程中的一个重要的观点,下面,引出我们的"重头戏"——结对编程。
什么是结对编程?
结对编程是指:一对程序员肩并肩、平等地、互补地进行开发工作。在现实生活中,也有这样的例子:驾驶飞机(主驾驶和副驾驶)。所以这两个人的具体工作分工为:
1、"主驾驶"负责具体任务的执行(驾驶飞机,编写程序)。
2、另一个人负责导航,建议,维护。
有一点需要注意:在结对编程的过程中:两个人之间的角色要经常互换,避免长时间被人注视所导致的压力和长时间的复审所引起的审"美"疲劳。
为什么结对编程?
结对编程:就是把后期的软件测试和软件复审的工作挪到了在代码编写时,就同步的进行不间断地复审。而好处可以这样理解:让别人在代码已近完工的情况下,再去做代码的测试还不如:在代码的编写阶段进行代码可行性和逻辑正确性的检查,一方面:这样的代码是两个人中能力较好的完成品(当然是结对编程人员的心血与结晶),另一方面:结对编程有助于:在互相讨论,互相合作的基础上进行编码,尤其狮是在遇到问题时:可以一起解决,有助于提高效率和互相学习;
结对编程真的好吗?
在这里说说笔者的看法:笔者是一个工作时相对独立的人(不喜欢和认识的人坐在一起自习),基于此种性格:结对编程尚有一定的难度系数。这种透明了程序员的全部工作细节与生活方式,在两个不是很熟悉的情况下,需要有一段时间去磨合。此外,在双方实力差距较大,或者基本不能有效的沟通交流的情况下,效果不一定理想,如果"领航员"没有发挥到自己的实际作用,那么结对的意义便不大了。
结对编程在现实中,很多大型IT都是两个人合作开始的,例如:Jerry Yang & David (Yahoo! 创始人),况且:从某种意义上,:结对合作也是团队合作的基础,更为重要的是:结对过程中,两个人之间是平等的关系,交流与反馈,是结对编程的核心吧!(话说:我这学期好像是和某个人在结对编程哎:怎么才发现)
另一种团队: 敏捷开发
敏捷开发的主要流程有:
第一步:找出完成产品需要做的事情
第二步:决定当前冲刺要解决的事情
第三步:冲刺
第四步:得到软件的一个增量版本,发布给用户。然后在此基础上不断的发布新功能
敏捷团队的主要特点有:自主管理(自己不断反思并改进不足),自我组织(在自己事情做完后,帮助其他人),多功能型(负责多项工作)
可以看到:敏捷团队适用于CMM层次比较高的团队,是一种对开发技术人员更高层次的要求。
三、能力评估
软件过程能力描述了一个开发组织开发软件开发高质量软件产品的能力,此过程能力包括能够达到的质量、效率、工期、成本等。现行的国际标准主要有两个:ISO9000.3和CMM。
ISO9000.3是ISO9000质量体系认证中关于计算机软件质量管理和质量保证标准部分。
CMM(能力成熟度模型)是美国卡纳基梅隆大学软件工程研究所(CMU/SEI)于1987年提出的评估和指导软件研发项目管理的一系列方法,用5个不断进化的层次来描述软件过程能力。
ISO9000和CMM的共同点是二者都强调了软件产品的质量。所不同的是,ISO9000强调的是衡量的准则,但没有告诉软件开发人员如何达到好的目标,如何避免差错。CMM则提供了一整套完善的软件研发项目管理的方法。它可告诉软件开发组织,如果要在原有的水平上提高一个等级,应该关注哪些问题,而这正是改进软件过程的工作。
CMM描述了五个级别的软件过程成熟度(初始级,可重复级,已定义级,已定量管理级,优化级),成熟度反映了软件过程能力的大小。
笔者观点:
软件过程能力更多的说的是:软件的开发能力和软件的质量,质量方面已在上文讨论过,而开发能力更多的与团队中人员的因素有关,一个团队中人的能力。
一个团队中不能仅仅因为:一个人的工作量的多少,或是工作时间的长短,或是一个人职位的高低,这些评估方法都欠妥。一种比较好的方法,是利用两个维度完成任务的等级与贡献率)来综合评价,得到一个较为中和的结果。个人认为CMM的级别体系是一个不断上升,演化的阶段。
软件项目管理,软件项目是为了达到目标,必须满足真实的需要。本博文从简单的几个方面对软件项目管理进行介绍,还请诸君一阅~,资历尚浅,还请多多指教!