关闭

软件制胜之道精彩观点聚合: Winning With Software

425人阅读 评论(0) 收藏 举报

原文:http://sd.csdn.net/n/20060523/90772.html

1 team

开发人员必须是disciplined and motivated people, skilled.
只有有纪律且积极向上的员工才能开发出高质量的软件.

积极向上的团队要求:
1 队员都有娴熟的技术,并能够胜任该工作
2 团队有一个具挑战性的重要目标,只有齐心协力才能够完成它
3 队员相信目标是可以实现的,并且他们各自都在实现那个目标中有一个明确的角色
4 队员有一个统一的过程和计划,指导他们的工作和跟踪他们的进度
5 团队领导支持并保护该团队,并及时向团队成员通报有关管理问题和团队进展方面的信息

养成良好的专业工作习惯、流程并遵守它,将会终生受益。
2 质量
   质量放在首位,必须是最优先考虑的事情。没有质量保证的产品交给用户后
将会带来极大的麻烦。

   任何一种软件或者硬件工作,最有效的质量策略是力争在测试开始前生产出优质的产品,
这是持续生产优质产品免于测试的唯一途径。

   保持产品的独特性 unique,用户为什么需要你的产品
3 项目失败的原因主要是:
没有对完成工作所需的纪律引起足够的重视。
1 不切实际的实际安排
2 不恰当地人员配置
3 开发期间的需求改变
4 低质量的工作
5 相信奇迹
对于兼职型的工作分配,工程人员的典型反应是:如果管理层没有叫我承担该
工作,我为什么要承担该工作呢?

 

4 理性管理Rational Management

所有员工都是忠实的且有思想力的专业技术人员,他们愿意在解决组织面临的问题方面支持您。

制定计划,遵循计划,在问题失控前修复它们

当主管们告诉我他们正陷入危机,并且没有实际进行正常的工作的时候,我要告诉他们,
当他们却是陷入了某种危机的时候,他们不能再陷入恐慌。危机的克服需要实际,您必须以
您所能的最佳的方式投入工作。您必须制定完整的几乎,并审核这些计划,确保它们是切实
可行的、健壮的。
由员工制定计划,完善的、实际可行的,遵循计划。与工作人员商讨,确保都能竭尽全力在
规定日期内完工。
保持进度,每周评审进展,如果某些工程师在一个星期内的工作落后了,他们必须在下一个星期内补上
欠下的工作量,甚至加班加点的工作。精确跟踪进展,及时发现进度落后。 发现的越早,追赶成本
就越少。

理性管理:
1 检查当前业绩,设计满足商业要求的目标,并将其分解为短期的阶段性任务
2 制定阶段性工作计划。要求工程师制定完善的、详细有效足以指导工作的计划。
3 度量、跟踪计划,工作纪律监督,衡量工作业绩的一个基准。
4 实时监控项目运转情况,planned,measured,tracked,随时掌握项目状态,对于潜在的问题
  及时采取措施,防患于未然。
 
5  改变
1 必须设里明确而可测的目标,把它们分给特定的人员,并跟踪他们的业绩
2 经过度量的目标就会被管理起来,而管理之中的目标往往能够得以实现
3 没有经过管理和度量的目标不能得以实现,而实际性能可能会更差
4 为了提高工程业绩,必须改变员工们的行为
5 为了改为工程师的行为,工程师们必须知道如何制定详细的计划、管理质量并采用有效的工作方法
6 为了真正的改进组织,工程师必须始终如一的使用他们知道的方法,而管理人员必须在此过程中对他们进行
指导、支持和培训。
为了提高组织的效率,您必须改进员工的工作方式

为了改变软件工程师的行为,您必须既说服工程师又说服他们的管理人员,证明要求他们做的事情将
有利于他们和业务。
数据收集,估算和规划,设计和质量管理:有纪律的工程师

后来他(管理者)告诉我,他非常希望早日完成该产品,但是,如果这是工程师们所能够做到的最佳结果,那就是他
能够要求的一切。他不希望这个团队失败。
6 如何面对管理层的压力,提出合理的团队开发计划

你们不能只是推测,管理人员更加喜好他们自己的推测,而不会喜欢你们的推测。最好的做法是尽量
制定一个满足管理层目标的计划。当你有了一个坚信不移的目标以后,你将会知道是否能够满足管理层的日期。
然后,就可以再次找到管理人员,并使他们相信这是一个可行的计划。最后,你可以得到一个你坚信可以完成
的日期,也就可以尽全力去实现它了。

计划增强信心,指引前进的道路!

在管理会议上,团队领导说明了团队已经完成的工作。当他讲述进度计划的时,总经理开始提出问题。
团队领导解释了系统的规模以及他们必须完成的工作总量。他将此工作与某些项目相比照,表明该工期
实际上已经比其他类似工作的工期更短。总经历正打算表示同意时,销售经理开始发脾气了”你们在破坏
业务”,他大声吼叫,”竞争对手很快就有更好的产品投放市场了!我们不能等到18个月后才推出该产品。”

因此我就问他,”你是说竞争对手目前要完成一种更好的产品吗?”他说是的,”好,你知道对方是
什么时候开始开发这种更好的产品吗?难道是上个星期?”因为他不知道,所以我告诉他对方很可能在1年
或者2年之前就开始开发那更好的产品了。然后我又问道。”为什么你不在那时开始开发呢?在发展业务方面,
如果你不能预见市场,工程师们是不可能为你挽回市场的。”销售经理平静了下来,而总经理接收了该团队
提出的产品交付日期。

对我印象最深的是工程师们的精神和积极性,他们一直在努力的工作,彷佛工作就是他们的生活。

 

7  责任心激励:
对工程师进行psp培训,使其懂得如何规划工作,管理产品质量
管理层对工程师的尊敬,使他们明白经营、技术需求,相信这是一项重要的和令人兴奋的工作,明确了他们的个人责任
富有挑战的目标
赋予工程师完全的计划制定权,给出理由,证明计划合理、切实可行
充分信任,发挥其创造性
保持团队稳定

你要让他们认识到他们自己的重要性,而不是一个可有可无的人。自身存在的价值。
 

8  转变步骤
1 Establish a quality policy
  with software, quality work always pays
  质量策略

2 identify an improvement champion
  指定一个负责人

3 set precise and measurable goals
  设里精确可测的目标

4 hold line managers responsible
  生产线管理人员负责

5 provide improvement resources
  提供改进资源

6 establish priorities
对于改进列出优先级

7 provide continuing oversight
持续不断的监督
 
 
 

9
非常重视故障数据的收集,故障记录日志
保证工程师的故障数据是精确的、完备的。

每1kloc有5个故障就应当被认为是质量底下的

不仅记录 检查和测试故障 ,还要记录关于评审和编译故障方面的问题

代码评审

detailed design time >=     coding time
design review time   >= 50% disign time
code review time     >= 50% coding time
design review defects >= 2* unit test defects
code review defects  >= 2*compile defects
compile defects <= 10 per kloc
unit test defects <= 5 per kloc
先花时间设计,编码后手工检查, 编译检查,代码审查,应该排除97.3%的错误

单元测试后应该排除99.2%的错误

design, design review, design inspection, code review, code inspection
发现错误少是一种不好的征兆????必须切实的付出时间和精力去检测代码,而不是敷衍发现不了错误。

0
0

查看评论
* 以上用户言论只代表其个人观点,不代表CSDN网站的观点或立场
    个人资料
    • 访问:16247次
    • 积分:572
    • 等级:
    • 排名:千里之外
    • 原创:43篇
    • 转载:3篇
    • 译文:0篇
    • 评论:0条
    文章分类