和SEG Leader的对话（20070907）

最新推荐文章于 2017-07-14 00:02:00 发布

iteye_887

最新推荐文章于 2017-07-14 00:02:00 发布

阅读量58

点赞数

文：<a href="http://blog.csdn.net/kongdong/">fasiondog</a> <div lang="zh-CN" class="moz-text-plain" style="">
<pre>（注：下面的对话是有环境前提的，大致是部分开发已经提前完成，整体系统设计能力不足，多的不说，见谅） 问题1、对目前的系统设计进行一次外部专家Review，尽早识别风险，让大家能够对当前的系统设计达到的质量状况有一个清楚的认识。……。这个已经和开发经理进行过沟通，也是赞同的。 AAA：也有这个打算，并且准备请MMM和NNN的专家都参加，时间在将当前的系统 设计工作进行一个整理后进行。 me：做这次Review还要注意一点：不希望一堆专家做了Review之后，留下了成 百上千的问题就走了，必须要给出一个结论，可不可以继续，哪些问题是核心问题 必须立刻解决，我们当前的系统设计水平在哪里，以我们的能力当前做到什么程度 算是最好并且可以接受继续？希望届时Review时，我们这边必须加以引导和控制。 共识：大家对这个问题的意见一致。 问题2、已经完成开发的部分质量状况到底如何？怎么评判是否也想想办法？ me：我目前的想法：是否可以先关注代码质量和测试用例的质量，代码质量可 以由系统组帮忙组织进行审核，用例可以请测试部对异常用例是否充分进行审核 AAA：是个好问题。不过暂时也没有什么好办法，目前MMM的代码圈复杂度工具可 以先试用一下。另外，希望你们先把工具要过来，因为除了现有软件代码外，ZZZ的代码是否也可以使用这个工具，系统组这边可以安排人实验一下，因为目前ZZZ组件的质量如何评估也是问题，看看能不能用上。另外，还有两个困难： * 按以前的经验，做这样的审计，发现的问题，无法落实 * 当前的人力有困难 （注：我的看法：之所以无法落实，和操作有关，原因见问题一中的意见） 共识：先把工具拿过来，试一下。到底这个问题如何解决，大家都再考虑一下。 问题3、后续准备开一次WorkShop后，会要求各个项目组事先学习并裁剪现有的 Checklist，每个项目都要在开始前将怎么做、标准是什么弄清楚，通过Checklit作为载体在项目开始前就把标准定下来，体现在质量计划里，后续QA就以达成的共识严格执行。XXX要素表也是其中之一，需要事先整理和明确。 AAA：XXX要素表不是质量标准，属于质量标准之一。 me：赞同，我们先从XXX要素表开始。另外，XXX要素表里的检查项很多，我们目 前有很多项其实并不能真正做到，比如可靠性、ESD等，我们能做到什么程度，需 要事先确定。以前XXX要素里，只打分或者直接被裁剪，我们是否能够对一些目前无 法做到的，增加一些标识，看看我们到底哪些能做到，哪些不能完全做到，按现有 水平和能力，我们做到什么样的要求就可算达到要求？不能完全到到要求的可以作 为我们以后改进方向的一个参考。不然完完全全按XXX要素要求，大家对达到的水平 可以各自表述，如果真的以最高或最完美的要求，可以保证能让现有产品一个也不 能通过XXX。这些必须提前明确，否则到真正XXX时，发现很多不能完全做到，要裁 剪，到时再判断能不能通过，很难作出正确的判断。有些不能完全达到要求的项， 其实事先努力一下，我们现在也可以有所突破。 共识：先这样做，先对XXX要素如何标识水平考虑一下 问题4：希望SE在每个阶段结束后进行经验总结 AAA：希望暂缓考虑，让SE写文章还不是重点，也比较难 me：不是让SE写完整的文章，可以大家随便写不在乎多少，直接用邮件、会议上直接讲都可以，希望召开会议，进行讨论，大家多进行交流。另外，BBB、CCC这边其实都有很多好的想法，希望能够把这些推介出去。我们如何进行系统设计还在探索中，这些经验很重要，也是以后系统设计方法的很好积累。 共识：这样可以 其他共识： 目前系统组一些G和W无法达成一致的意见，比如需求编号和跟踪策略的确定，以后 直接提交AAA来安排 其他： 1、AAA介绍了一些目前产品排序和规划的考虑和想法，很形象也很清晰 2、…………</pre>
</div>