现代软件工程 第十一章 【软件设计与实现】 练习与讨论

1  如何避免在产品开发后期不断有重大修改,导致其它模块的连锁反应? 

DCR Tell mode vs. Ask mode设计变更

在项目早期,如果大家觉得要做一个设计变更,便可以采用告知模式(Tell-mode)的形式,也就是说,修改方必须通告所有关系人:“我在这里修改了某某界面, 我在某个API 增加了一个参数。”但是修改方不必取得其他关系人(或者模块)的事先同意,就是说可以先行设计并编码。当然,如果其他关系人不同意,修改还是不能签入。

当项目进行到稳定阶段,例如达到了代码完成(CC)阶段,Tell-mode 要改为请求模式(Ask-mode),这时,修改方必须先问“我是否可以在这里修改某某界面?”(当然还要有更详尽和充分的理由),得到肯定的答复后,才能进行修改。这时的默认回答是“不”。

2  每周进度报告——还有多少事没做完

小飞: 我们每天都在签入新的代码,每人都很忙,但是我总觉得不太对劲。感觉事情越做越多,我们离最终目标到底是更接近了,还是更远了呢?

阿超: 这时我们可以看看各种报表,首要推荐的是TFS 的“Remaining Work”,可以看敏捷流程的“燃尽图”(Burn down chart)。如果你看到每个人每天花费的时间在不断增加,但是真正需要解决的任务(Task)和缺陷(Bug)都没有变化,甚至缓慢增加,这意味着团队离最后目标越来越远了。

可以在TFS报表设置的控制板中,进一步选择你要报告的内容,如:Iteration,选择里程碑;Area,选择项目的不同部分,也可以修改报告的起始和终止日期等[i]

3  如何避免诧异的反应

问:     每次里程碑结束后,我们向客户汇报的时候,客户总是会惊讶地说,某某功能不是我们当初商量的那样啊,而PM却也同样一脸诧异地说,不对啊,当时咱们就是这么说好的啊,有文档为证。客户不干了,威胁不加/不改xx功能就如何如何,这时PM该怎么办?

阿超: 我们在合同里要写明到底我们要交付的是什么,这就要看PM的分析和说明能力了。有时要对客户说“不”。同时,我们在需求说明中也要从用户的角度去描述问题和解决方案,这样用户才能了解他们最终会得到什么,另一个方面是,当你给用户演示一些界面的时候,要说明哪些界面只是示例而已,哪些界面是大家同意的最终设计。敏捷的开发流程鼓励用户经常参与设计和计划,如果有条件这么做,那当然很好。

问:     项目开发中后期,开发人员用工具一统计,乖乖,足足xx万行代码,xx千个存储过程,可是每到给客户演示时,却不时出现程序的各个功能相互不配合,不能自圆其说的尴尬场景,Dev leader很郁闷,想想自己可是没少加班啊,代码量也够多,可是问题究竟出在什么方面呢?

阿超: 一个原因是每个人都沉浸在“我要写出最强大的某某类或某某模块”中,不停地优化一些没有人用的功能,但是真正能够为其他模块使用的功能却未能实现。他们忘了他们写的代码是给别人用的,而且是为了解决用户问题的。所以这个时候我们要想想“用场景驱动”的方法,保证典型的用户场景能够实现。如果从“场景”出发,各个模块的互相集成就能得到充分的测试,按照场景演示起来就更有保障了。

问:     在项目开始之前, 有很多队员还没有接触过编程语言(例如C#),导致PM在分配任务时很难用时间来衡量,就拿写一个Web Service这一模块来说,一个熟练的程序员可能只需要两个小时,而对于初学者来说,就得先花两天来理解Web Service的实现机制和原理。在有限时间的催促下,导致一些紧急的任务不断向高手集中,而初学者的任务越来越少。这时应该怎么办?

阿超: 对于这些队员,可以考虑在他们自己的任务估计值之上再乘以4。另外,如果你是写一个商业项目,请不要让连开发语言都没有接触过的队员进行开发工作。并不是非得 “写” 程序才是对项目有贡献,有时不写也有很好的贡献。如果他们有热情,就从测试开始学习吧。请参看前面提到的“大马哈鱼洄游模型“

 

4. 在这个时候是否碰到 “团队成员不给力” 的问题?  请看别的同学的吐槽:

http://www.cnblogs.com/xinz/archive/2010/11/27/1889935.html 

 
5. 我们是在写代码解决问题呢,还是在搭建宏伟的架构?
6. 好的修改/重构是什么样的?  请看几个例子:
 
 

[i]      VS2010以及之后的版本还提供了燃尽图等功能,请参见相关同学的博客,例如

http://www.cnblogs.com/OMG-Team/archive/2011/09/30/2196150.html

 

7. 不同建模工具的特点:

我们讲了好几种建模和设计工具,它们在以下的方面有什么特点呢?

1)容易理解,特别是对于非专业人士来说。

2)不仅能处理非常简单的问题 (如计算一个文件的行数),还能扩展到处理复杂的现实世界的关系,实时系统,复杂的商业逻辑,等。

3) 能非常精确地描述问题

4)能精确地把这个模型转换为代码

5) 能很好地应对变化 (如果我们改变了设计,代码和模型能很快地跟随变化)

 

8. 软件设计的工具
创作需要工具,有些学科只需要简单的纸和笔,有些需要专门的工具。
1) 请调查一下你周边的同学在写软件的时候都使用什么工具 (IDE, 测试工具等)
2) 请采访有两年以上工作经验的软件工程师在使用什么开发/测试工具
3) 请采访有三年以上经验的产品经理在使用什么项目管理工具,这些工具有什么优缺点
4) 很多和信息处理相关的应用都是 “增删改查” 操作的组合, 那么能否抽象出这些操作, 找到规律,自动生成基本的信息应用呢? 请分析这个软件工具:
  http://garrylachman.github.io/ElectroCRUD/   
 
9. 不同的设计方法有各自的适用范围,OO 也是这样
    很多同学都上过 《面向对象的程序设计》这门课,请阅读下列文章,谈谈你的看法:
    http://www.vaikan.com/object-oriented-programming-is-inherently-harmful/ 
    http://doc.cat-v.org/programming/bad_properties_of_OO 
    http://harmful.cat-v.org/software/OO_programming/why_oo_sucks
    http://harmful.cat-v.org/software/OO_programming/_pdf/Pitfalls_of_Object_Oriented_Programming_GCAP_09.pdf 
 
posted @ 2014-07-19 20:48  SoftwareTeacher  阅读(1519)  评论(17编辑  收藏  举报