产品设计体会（3014）敏捷实践的一些过程项

上次说到了我们在 项目中“敏捷沟通”的实践 ，顺着再补充几点项目过程中的敏捷实践。

任务认领 ， 我们没有完全实施，现在是利用开发经理对工程师能力的了解安排任务。任务认领的假设是：每个人都是足够聪明和职业的，应该被安排在最合适的工作上，所以最 了解自己能力的就是自己，于是应该每个人制定自己的工作计划，其他人帮着定都是不优的。相对而言，任务认领更适合工程师文化的特种部队式团队，比如Google 。

需求评审 ，有的团队在需求评审会的时候，让开发工程师来讲述他要开发的那部分功能的PRD （含UC ），PD 来提问。对比更经典的PD 讲述，开发提问的方式，这样做有两个好处：一是逼着开发认真看PRD ；二是可以省去设计评审，相对PD 讲述PRD 的传统方式而言，开发讲述的方式下，不做设计评审的风险降低。

结对编程 ，我们还没魄力尝试，相信国内也很少有团队敢尝试。一位开发经理对我说其本质是两个人互相监督，没法偷懒以提高效率，更重要的是，这种效率的提高还伴随着代码质量、可读性的提高，从而完全可以抵消表面的“做事的人少一半”带来的损失。

测试驱动 ，我们有很强很严谨的测试，会利用TC 编写、TC 评审、甚至测试执行的过程来补充和细化需求，比如一些限制条件、异常流程等等，往往都是测试的同学提出来的。

冒烟测试 ，编码完成后，测试的同学会马上做 冒烟测试 ，目的是确认产品基本功能正常，可以进行后续的正式测试，冒烟完成后立即进行产品演示会，叫上项目干系人来查看产品是否符合期望，符合“尽早交付”的概念。

关于加班 ，我一直让开发经理、测试经理评估资源的时候留一点余量，甚至我在排项目计划的时候会再留一点，但每次看上去仍然还是在加班，也许是大家不习惯一下班就走，反而喜欢上班时不时看会新闻，晚上时不时做点工作的方式吧，不管给多少时间，任务总是在最后一刻完成，呵呵。

你在的团队有什么好的实践么，不妨也说出来给大家看看。

iamsujie猜你还喜欢：

• 产品设计体会（3013）项目的“敏捷沟通”实践 (4)
• 产品设计体会（7009）敏捷估计与规划 (0)
• 产品设计体会（3004）项目外包不适合“敏捷” (0)