以人为本 | 如何保证高质量的软件交付

软件团队想要保证高质量的软件交付，一般情况下会想到以下几点：

– 多的测试人员

– 高薪资、福利

– 各种质量管理工具和手法

– etc…

我们有大量的实际经验表明，这些方法往往没有达到预期值，更有甚者，会不那么有效。

为何会如此/p>

通过不断的事后回顾，我想导致这类问题发生的原因在于：我们往往是从一个功能模块代码完成后才开始通过各种方法去保证我们的软件质量，对开发、对开发测试工程师等大体都是如是。

按照完成软体一个功能实现的过程来看，在如下阶段中：

/p>

想对应测试的完成工作分别有开发人员自己、开发测试工程师、测试人员完成。填补开发阶段的质量把控方法和过程在现在科技公司中越发迫切。

如何做/p>

在这里，我的感悟是:开发人员就好比一家餐厅的厨师，他们参与一个项目就好比炒一个菜；需求人员就像就餐人员，点单；测试人员就像管事，上菜前得先品过，决定能不能上。

厨师（Dev）完成一道菜需要：

– 好食材(代码)

– 好配料(工具、硬件等)

– 好餐具(架构)

– 好火候(熟练度)

我们发现同一位厨师（Dev）在前面所列条件一模一样的情况下，最后的成品仍然会存在不一样。最典型的例子在星爷的“食神”中可见一斑。

为什么/p>

感谢星爷的“食神”，它已经告诉了我们答案：心情、心境。

心情愉悦的厨师在条件有所缺失的情况下做出来的东西仍然美味无敌；而心情槽糕的厨师即使在外部条件样样完美的情况下，做出来的东西虽不至于难以下咽，但肯定是达不到预期的。

所以对软件质量的追求，包含开发过程在内，我们经常本末倒置，忽略了根本原因。软件质量管理的正确打开方式应该是：以人为本，让每一位成员在工作中是快乐的，甚至是享受的。由此所交付出的软件最后必会是高质量、创造性的。

以人为本，我们该如何做呢/p>

nbsp;改变绩效考核方法。

        目前主流的绩效考核方法是由GE倡导的“活力曲线”，360度考评。这种特定时代下，反人性的产物对如今科技公司是不适宜的。具体分析，大家可以参看最近讨论很火的文章《后GE时代，绩效管理的存与废》。

nbsp; 改变我们用于软件质量评估的指标，这里可以参看我以前的文章《代码质量评估的新方法》

nbsp; 定义好团队愿景与使命(目标)

nbsp; 清晰的定义好软体生命周期的每一阶段及关注点

nbsp; 让每位团队成员觉得他们的贡献是重要并且有价值的

nbsp; 每位团队成员的诉求—“职业上升渠道、薪资、岗位等调整”都能够找到解决渠道

nbsp; 引入高效、并能减少团队成员“参与指数”的工具及方法。（参与指数=影响团队工作的非请求干预数量）

nbsp; 在团队的合作中不断的调整合作方法，创建高融合的团队。

当每位成员都能快乐并富有激情和创造性工作的时候，这种质量保证就是从内到外的，涵盖了软件了软件所有生命周期。

这理应是我们scrummaster 对软件成功孜孜不倦的追求。

来源：与code无关的反思