前言
当你应用敏捷一段时间之后你如何能够知道团队对当前尝试的新的工作方式的认可程度？如何能够了解团队成员每个人的真实想法？回顾会是一个有效渠道，不过有时候大家的腼腆和多虑，还有时间限制，可能还是会有一些关键问题无法暴露出来。今天推荐另一个大家熟悉也很容易的方法——调查问卷。
正文
今天我会展示一个应用在我的团队的问卷来介绍一下我从中得到的针对目前团队对敏捷应用的真实看法，并分享我如何考虑对接下来的工作进行调整。一个问卷，限定时间是2天，让大家有时间的时候填写，问题足够精简避免引起答题者的反感，这样既有时间思考也能够充分的搜集反馈。要查看完整问卷调查统计请在此处下载“工作方式问卷调查”。
NPS
我的团队应用应用的敏捷方式是Scrum，首先在问卷中我加入了”净推值”(NPS),用这个来测量大家对当前Scrum工作方式的认可程度。下图是我的调查问卷中的NPS值：
从目前来看负数，说明大家并不是很接受Scrum这种工作方式，或者说不会主动推荐这个方法给其他同事或者团队。从侧面让作为ScrumMaster的我明白不要自己觉得一切都应用的挺好了，表面大家也都在按照scrum的3355在做，但其实还是有很多地方需要了解大家的真实想法，找出臭味道并做出进一步改进。
团队幸福指数
在图一中有一个三颗星的团队幸福指数来反应大家对当前工作方式的满意程度，从这一项调查看团队在Scrum应用中工作感觉还不错的。这让我很欣慰，希望继续保持并能更加提高。
对敏捷认可的因素
从下图中的几个问题能够看出Team比较认可敏捷带来的改变，同时也给我们指出需要调整的地方。如下图所示：
带来如下思考：
- 目标更明确
每次迭代团队的目标更明确，大家能够共同努力协作实现最后产出有价值的产品或功能。 - 自身得到成长/能够体现自我价值
这两点印证了敏捷12原则中的“激发个体的斗志，以他们为核心搭建项目。提供所需的环境和支援，辅以信任，从而达成目标”。敏捷希望激发内驱力让每个人都能够自管理从而达到团队自管理。 - 需求梳理会能够对团队效率提升起到很大作用
这体现出大家对每次迭代的需求明确的渴望，同时也体现了强烈的需求讨论的参与欲望。我曾经做过一次小的改进尝试，让团队参与AC的编写，而不是以往PO自己编写，这之后的改进效果明显，具体请参看我之前的文章 验收标准如何写。 - 回顾会成为最浪费时间的活动
哈哈，这一点倒是让我意外，以往感觉每日站会经常被人诟病，而两周一次的回顾会怎么会让人觉的浪费时间呢？是不是每次2~3个小时的会议并没有让大家真正参与进来？并没有找到迭代中的关键问题而失望？并没有让大家觉得回顾后对今后的工作产生了那些正向的推动？而这些将是作为ScrumMaster的我在今后工作中需要探索和改进的方向。我也会将我实践过的有效果的回顾会分享到这里。
对敏捷的期望
我对大家希望敏捷能够解决团队的问题做了调查，从问卷中能够看出，大家还是期待满满，同时从大家的期待中也能够发现这些就是我们敏捷落地中仍然需要调整改进的方向。因为很多期望其实都是敏捷一直希望要给我们带来的与传统方式不同的变革之处，而现在仍然是大家心中的痛点，那就说明我们需要调整了。下图是大家的回答：
- #2,#3,#9 提到了个人成长与敏捷的关系。如何让个人在敏捷中不只是忙于应付Task，而是可以体现个人价值，并能从中提升个人技能？研究型任务和工作任务的结合；自由创新时间的设立等等，这些都是可以尝试带给大家更多机会和挑战。
- #4,#5,#6,#7 提到了对团队工作效率的期待，结合之前的浪费时间会议统计，可以体现团队对于一些无效的工作方式的厌恶，例如考虑如何让需求更明确而不用每天都要花时间讨论，如何让开发和测试人员对功能验收有一致的验收标准等。
- #8,#10,#11 表达了对迭代价值交付的期望。如何提高交付效率，缩短交付周期，提高交付质量这些都是应用敏捷的首要目标——交付有效价值给客户。而如何能够做到这些方面呢？就要考虑如何应用最新的敏捷实践方法，例如：CI/CD流水线的建立，自动化测试的应用程度。考虑测试覆盖率，线上故障率，需求交付周期等这些因素，考虑如何提高他们从而提高团队的价值交付能力。
心目中的敏捷样子
最后是一个发散性的问题，只是想看看团队中大家对敏捷的向往程度？从结果看大家是承认敏捷带来的改变并愿意继续探索，这也给敏捷继续生根发展保留了土壤。
总结
ScrumMaster定期对团队做一些敏捷应用调查，适当调整一些问题侧重验证当时团队的实际情况，这种方式对团队和ScrumMaster都是一种低成本但高效率的方式，让整个团队能够客观公平的获得全局的状态评估，并暴露出一些关键问题方便做进一步的调整。我个人建议问卷调查使用匿名，这样更能构建安全分为，让大家敢于说出真实想法。不过如果您的团队足够公开和透明也是没问题的。
