• 即将更新图形学,编译原理,机器学习等文章,谢谢关注~
  • 由于算法限制,搜索时注意简化关键字,谢谢支持~
  • 网站不兼容IE5.0及以下,请使用主流浏览器访问.
  • 软件工程-软件小组的组织形式

    为什么要形成软件小组

    大多数软件产品由一个软件专业人员不可能在有限时间内单独完成。因而,产品必须分配给一组专业人员,形成一个小组。在具体说软件小组的组织形式之前先介绍一下布鲁克斯法则。

    布鲁克斯法则

    布鲁克斯是上世纪60年代IBM System/360的操作系统OS/360的开发负责人,这之后基于当时的经验写了《人月神话》一书。

    有这样一个项目需要12个人月,那么3个人4个月就能完成该任务。然后,在每个月设定观测点A/B/C/D。

    但是一个月就需要结束的A结果花了两个月完成。这相比于预估时已经是两个月之后了。怎么办?管理者有下面的对策。

    1. 虽然当初的估算是对的,仅仅是最初的工程弄错了。也就是说推断剩下9人月。因为有9人月的工作,两个月完成的话需要9/2=4.5人。追加两个人到这3人团队中。
    2. 当初的估算弄错了,不是12人月而是需要24人月。因为已经花了6人月的时间了剩下需要18人月。2个月完成的话,需要18/2=9人。追加6人到当初的3人团队。
    3. 重新安排任务。追加充足的时间到新的计划了。
    4. 调整工作目标。减少工作。

    那么,应该采用什么方法呢。最开始的二个方法,不修改工作目标和工作进度表的话最初4个月完成目标的期望就破灭了。

    假如追加2个人,这两人的培训成本,3人完成的工作用5个来做,就需要重新安排工作,这些成本没有被追加到估算中,结果的话最终期限无法完成。追加6个人的情况,这种成本加的更多。

    这就是布鲁克斯法则。「追加人员到延迟的项目更会影响项目的进度

    如布鲁克斯所写的那样,无法按进度完成工作的话,只能降低工作目标作业。

    这是软件产品开发中50年前发现的法则现在也是正确的。但是,几乎所有的开发者都不了解布鲁克斯法则,就算知道也不会去实践。

    软件小组的组织形式

    民主小组

    优点:由于积极地寻找错误,因而代码质量高,特别适用于解决难的问题。

    缺点:有经验的人反感新手的评价不能从外部强加。

    传统的主程序员小组

    缺点:不实用

    修改的主程序员小组

    优点:有许多成功的范例

    缺点:没有与《纽约时报》项目可比拟的成功范例

    现代分级编程小组

    优点:小组经理/小组领导结构避免对主程序员需求,可扩展,必要时支持分散决策

    缺点:除非明确小组经理和小组领导间的负责范围,否则容易产生问题

    现代分散决策形式下的编程小组

    实例:开发一个军用的通信软件

    同步-稳定小组

    优点:鼓励创造性,确保大量开发者为共同目标工作

    缺点:在Microsoft公司之外还没有该方法应用的实例

    敏捷过程小组

    优点:程序员不测试自己的代码,如果一个程序员离开不会有损失,经验欠缺的程序员可以向其他人学习,代码具有小组所有权

    缺点:还没有更多的实例证实它的功效

    开源小组

    优点:少数项目非常成功

    缺点:应用面窄,需由出色的有号召力的人领导,需顶尖高手的参与

     

    读者评分
    [评分人数: 4 平均分: 4.5]

    评论

    OmegaXYZ