软件制胜之道精彩观点聚合

前端之家收集整理的这篇文章主要介绍了软件制胜之道精彩观点聚合前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。

原文: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发现错误少是一种不好的征兆????必须切实的付出时间和精力去检测代码,而不是敷衍发现不了错误

原文链接:https://www.f2er.com/javaschema/288325.html

猜你在找的设计模式相关文章