semp沙龙kickoff主题讨论
TRANSCRIPT
主题讨论
• 组织遇到的问题– 软件交付质量无法满足期望或远不如竞争对手– 软件生产率无法满足期望或远不如竞争对手– 项目需求、技术等不确定因素大
– 软件工程师开发习惯差异大，导致任务完成质量参差不齐
• 原因• 可能的解决方案
原因分析原因分析原因分析原因分析
• 贝尔：国际性项目• 电信行业项目需求变更少，多有国际标准可依据• 但面临有解决方案的变化；• 软件缺陷，项目周期长，验证测试占项目周期超过1/2,
• 项目涉及多国时，沟通有效性差（层级过多）；有时甚至牵涉到硬件环境的变更；最终大集成时发现问题
• 子项目项目经理对项目细节了解不够；• 缺少进度度量，任务优先级、权重的评价标准；
• 开发人员解决bug的时间占工作时间4-5成；
• 可鲁电气：• 开发团队又是测试团队，对质量控制元素的监控模糊• 有些“质量”问题，实际上是其他因素（例如：习惯，体制，流程等）
• 公司机制问题，销售不懂业务接下的单子无法完成。• 公司机制问题，销售不懂业务接下的单子无法完成。• 验收标准不清楚• 客户不成熟，规范性不够：客户协作/分期交付
• 世范：• 内部人员对质量管理的理解有差异；
• 项目计划仅由项目经理根据个人经验完成：建议计化由下向上制定，项目经理负责汇总，计划是计化由下向上制定，项目经理负责汇总，计划是一份项目组的commitment。
• 电子政务项目：
• 与客户原有操作习惯有大差异时，导致客户对系统质量评价降低；
• 领导层的质量意识决定了该公司的质量导向。
解决方案解决方案解决方案解决方案
• 可鲁电气：• 质量标准的定义（内部的、面向用户的）：与用户达成共识（目标一致性）
• 开发过程与客户紧密互动（如用户参与，阶段性确认等）• 质量标准衍生出质量控制点• 质量标准衍生出质量控制点• 阶段评审（需求，实施方案，阶段成果等）
• 日本：每两周与客户沟通，把客户要求带回来，但沟通有原则；驻场开发，沟通有效：关键要分析哪些是当期要完成，哪些可以二期、三期再完成的。
• 应用软件与用户要密切互动
• 客户尽早加入，参与决策• 开发人员对业务的理解
• 对远不如竞争对手来说，某种程度上说不可比，就项目来说比较的基准没有。就产品来说，可以
可能的解决方案可能的解决方案可能的解决方案可能的解决方案
就项目来说比较的基准没有。就产品来说，可以通过不同客户的评价来评定。
• 新人：培养计划，公司内部有培养机制
• Infosys,过程流程改进• HP，PSP/TSP• 时代光华，企业标准• 电装，流程改进• 中远，开发部的管理• 中远，开发部的管理
• 项目抱怨人力资源不够，但管理层觉得并没有那么忙• 与其他公司做过比较，生产率有些高蛮多，经验不足导致了生产性低；经验积累需要时间；
• 行数计算非常困难，且行数与工作量之间没有很明确的关系；• 实施了CMMI，但是对质量和效率上的提高不大；• 流程没有理顺，透明和电子化；
问题问题问题问题
• 流程没有理顺，透明和电子化；
• 生产率LOC/Hour，FP/Hour去除重用、自动生成• 按照项目类型、项目规模、工程阶段和项目整体来计算生产率• 执行多次FP估算(需求、设计阶段）• 组成FP估算的专家，来估计FP• 更多的利用重用（按照业务、按照技术等），并且使用Incentive
program来激励人员提供重用；
可能的解决方案可能的解决方案可能的解决方案可能的解决方案
program来激励人员提供重用；• 不同的Tools来提高自动化；使用Excel宏工具将设计书直接生成基本代码；
• 使用减少返工（更好的评审、培训）来提升生产率；
• 建立FP和代码行统计的标准，保持一致;• 应用PSP/TSP, 减少测试时间
o 质量得到提高，生产率没有很大变化，可能是由于学习曲线导致的o 质量得到提高，生产率感性上得到提高
• 引入自动化的工数统计工具，按照WBS汇报工数，区分管理工数和非管理工数
• 尝试了Lean，通过process mapping来找出value和waist; 发现交
可能的解决方案可能的解决方案可能的解决方案可能的解决方案
• 尝试了Lean，通过process mapping来找出value和waist; 发现交流和知识的转移是主要的浪费。可以关注在knowledge management、retainment, continuous learning;
• 度量由商业需要来驱动；o Why measure?o What measure?o When/How measure?
• 进度和质量（Agile和PSP)挣值/功能
可能的解决方案可能的解决方案可能的解决方案可能的解决方案
o 挣值/功能o 质量计划（产品和过程指标），当发生问题的时候，可以有足够的数据支持分析
• CMMI and PSP/TSP and Agile
原因原因原因原因——需求不确定性需求不确定性需求不确定性需求不确定性
• 客户本身的原因客户本身的原因客户本身的原因客户本身的原因o 不同层面客户目标不同o 拍板的人不是最终用户o 需求来源于第三方
• 体制原因体制原因体制原因体制原因o 政府（国企）年度预算制度o 规划与实现的失衡o 规划与实现的失衡
• 市场原因市场原因市场原因市场原因o 市场的快速变化
• 企业内部企业内部企业内部企业内部o 销售急功近利——过度承诺o 传统开发模式下开发人员离客户太远o BA的能力不够，引导与理解不足
原因原因原因原因——技术不确定性技术不确定性技术不确定性技术不确定性
• 技术不确定性o 定位（目标、范围）不确定o 新技术的风险o 外部技术的不确定性o 技术方案会随对系统的了解而变化o 技术方案会随对系统的了解而变化
可能的解决方案可能的解决方案可能的解决方案可能的解决方案
• 需求的不确定性o 需求的签字确认？？？o 通过技术的灵活性弥补（通用框架、产品运用）o 原型法、迭代方式开发o 分阶段交付o 分阶段交付o 项目前期核心开发人员参与o 定期让用户参与原型评审o 产品化（细分领域、通用）o 开放API，鼓励用户或第三方参与客户化开发
可能的解决方案可能的解决方案可能的解决方案可能的解决方案
• 技术不确定性o 技术选型中采用POCo 技术原型开发o 延迟决定o 利用外脑o 利用外脑
• 原因– 预算有限，招聘的人不可能都是最强的– 工作分工，Junior的人员和Senior的人员分别完成项目中的不同工作，形成互补，使生产率趋于合理
– 一件好事，Junior的人员以Senior的人员为目标和方向
人员的差别 1–水平和能力的差别
– 一件好事，Junior的人员以Senior的人员为目标和方向，反而可以更好的促进团队
– 因此希望团队人员的水平是有梯度的，能够帮助团队成长
• 可能的解决– 结对、流程和机制、导师、评审
• 原因– 学校刚毕业的人员往往并不职业化，国内的高校并不具备相关课程
– 没有足够的职业培训机构– 一个团队中总有相对职业化和相对并不职业化的成员
人员的差别 2 –职业化的差别
• 可能的解决– 职业化程度高的人员的带领
• 资深的成员需要得到他人的信任和协助
• 这种信任来自于他的职业化表现和工作的结果，并不取决于他工作的年限
• 所谓“职业化”是以结果导向的，他们往往能“把事情做好”，他们总有一些好的方法
– 有一个好的导师是培养人员职业化的重要因素
• 可能的解决
– 对于人员的职业化要求根据不同的行业，要求不同的要求
– 未被污染的人员是否能够被快速的训练成为职业化的人员 –速成班 + Mentor的方式？
解决的可行性？
人员 –速成班 + Mentor的方式？
– 短期项目人员不够，外包是一种方式，但是外包公司可信吗？（职业化训练）
• 印度为什么能做到？训练有素！
– 高校？职业培训机构？是否可以纳入这些训练？• 总结
– 不主动、没意识-〉主动、有意识
– 职业训练、职业人员的带领、机制的制约、文化氛围