给一个团队写的敏捷实践方案

  刚接触敏捷时，感受挺好，当实际执行时，倒是半敏捷半传统的路数，毕竟要实行真正的敏捷须要超强的队员，对口的研发环境，以及广泛的承认度。敏捷在国内已推行多年，实施起来难度仍是很大，应该说不少团队都不算是真正的敏捷。既然不算，我给X团队写的一篇方案，自当书面文档，固然据我所知也没有实行推进起来，毕竟每一个团队都有本身的现状。

        内容大体以下，也算是对我以前的两个团队敏捷实施的总结吧，虽然说实施效果有时候也走样，毕竟也是个经历。

      

    大前提 : 要求全员总体参与产品的研发过程，从需求，设计，到开发测试等等。

准备阶段

        分析原始需求，整理大致流程，画原型图/为提升全员对需求的理解程度，可全员参与，初步分析出数据结构，搭建开发环境等开发过程当中所必备的技能，各岗位角色安排到位。肯定总体迭代过程，及第一迭代的内容。测试可肯定测试计划。

        每日站会，内容只涉及昨日工做内容，今天准备作什么，目前有什么问题。切忌深刻讨论细节问题，占用你们大量时间。

        看板，工做完成后，主动更新看板，将工做进度时刻暴露在外，你们心中有数，一旦工做进度没法保证，可协调其余队员帮助完成或移至下迭代开发。

        开发习惯的问题，开发节奏较快，要求你们尽可能保持良好的习惯，好的注释，变量命名，日志输出，面对面交流等等，一切提升效率的作法都应该被提倡。

        迭代按两周一个周期。

迭代

        迭代首日，开迭代计划会，人员，全员参与，包括开发，测试，产品，业务等相关干系人。内容，由产品业务人员讲解本迭代内容，全员讨论需求存在的问题，记录有歧义内容。全员评估本迭代需求任务复杂度，肯定工做量。基于现有状况可肯定本迭代可否完成。各开发人员认领需求，并复述需求内容，确保与产品要求一致，开发拆解需求为具体任务，并肯定工做量。会后录入系统中，统一管理。测试人员可离场编写本迭代测试案例。

        周二至下周三周四，是实质开发阶段，开发前不着急编码，须要有必定的设计识别过程，较复杂的状况，须要评审事后再开工。

        开发完成作好单元测试，更新任务状态并口头通知测试、产品人员测试。验证功能。

        测试在此期间编写完案例，开展测试，并与产品业务讨论下迭代需求内容。

        中间可穿插半天讲解下迭代需求，提早熟悉内容。

        周三周四可部署稳定版本，全面测试，并修复bug。若上迭代遗留bug影响关键流程的，立刻解决，其他可按时间安排修复。

        周五

        上午迭代验收会，开发确保所有功能开发完成，不要遗漏功能。下午迭代回顾会，回顾本迭代流程中存在的问题及可改进的地方，再下迭代中完善。

        迭代过程当中若需求有变更，工做量不大的可动。大的须要评估，移到下迭代或某个周期内完成。

        集成测试，所有迭代结束后，安排一段时间作系统性测试，测试，产品，用户都可参与进来。

        投产演练，为确保上线顺利，上线周期及一旦上线失败后的还原措施，都须要在此阶段不断尝试，以防在正式投产时出现意外。

    

        敏捷实施具体某一个迭代，仍是传统瀑布开发，从需求分析，概要设计，再到开发测试。两种过程相辅相成，切不可割裂开来。