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

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

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

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

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

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

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

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

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

------------------------------------------------------------如果你想第一时间看到最新内容, 就猛击此处订阅吧!

《产品设计体会(3014)敏捷实践的一些过程项》有5个想法

  1. 相比任务认领,我觉得更好的是团队计划会议,大家一起沟通上下文,最好都能了解我们要作什么。然后开是划分任务,类似Scrum的Sprint计划会议。

  2. 我觉得在项目进行中,管理和控制是另一个重要的软实力。即:
    1. 谁来负责这个项目(项目经理?);
    2. 负责人对其他人有什么权利(督促?时间控制?)和义务(申请资源?申请奖金?申请加班费?或者表扬和鼓励?)

    不然,项目就是一盘散沙,没有核心和管事的。如此,则deadline就真的是“死线”,形同虚设,项目也会被各种因素不断的拖延。

  3. 测试驱动,我们有很强很严谨的测试,会利用TC编写、TC评审、甚至测试执行的过程来补充和细化需求,比如一些限制条件、异常流程等等,往往都是测试的同学提出来的。
    ====================
    个人认为,这个“测试驱动”的理解可能和一般意义的测试驱动不太相同。
    根据我的理解,“测试驱动”一般是指“测试驱动开发(TDD)”,简单地说就是先写单元测试的代码,让测试代码来描述功能。那个时候就只有一个所有测试都失败的程序,然后逐渐完善程序代码,直到通过所有测试。如果中途发现需要补充或者完善的地方的话,先完善测试代码,再完善程序代码……这样不断迭代。

发表评论

电子邮件地址不会被公开。 必填项已用*标注