接（四），未完！
一、章程
有过项目管理经验的小伙伴们应该清楚，对于传统项目，为了让团队成员了解项目的重要性、项目目标和前进方向，在项目开始前项目经理都会先完成项目章程，以此来约束项目团队的相关活动。
而在敏捷团队中，由于该团队的组建是自发的，虽具有很强的凝聚力，但相较而言其规范性方面则会差一些，为了尽可能大的调动团队成员并发挥成员的能力，除了项目章程外，还需制定协调团队成员的团队章程。
敏捷项目章程需要包含如下内容：
1）项目愿景。为何而做？2）受益方及受益方式？3）项目发布标准？4）预期工作流？
团队章程包含：
1）团队价值观。如何可持续的开发速度和核心工作时间？2）工作协议。定义诸如‘就绪’‘完成’等事项；3）基本规则。如会议发言时间等；4）团队规范。
二、敏捷实践
2.1回顾
定期反省如何做到更有效，并相应的调整团队行为。对于何时回顾较好呢？可以选择如下时间点：
1）完成一个发布时；2）上次回顾之后的几周；3）团队出现问题时；4）达到某个里程碑时。
从上面的回顾时刻我们知道回顾并非只有在项目结束时才进行，可以在项目进行中。但无论是何时回顾，我们都需要从定性及定量两方面出发。先讲定性的感觉，再从定量的数据分析近期的项目情况，然后制定相关对策与行动计划（‘先礼后兵’）。
注意：回顾不是责备。当我们项目完成度不如预期时，回顾的目的是怎么去解决它，而并非责备团队成员，敏捷主管需要做的是鼓励。
2.2待办事项列表的编制
该列表是所有工作的序列表，以故事的形式呈现。比如开发某个产品有数项工作需要完成，我们便通过优先级将其罗列出来（开始时无需完整的进行罗列，只需确需要交付的第一项的正确性即可）。产品负责人可能还会制定相关的产品路线图，用于观测交付的成功的预期性。
2.3待办事项列表的细化
在基于迭代的敏捷中，由于前期需求的不够明确，在早期制定的待办事项列表中的用户故事与实际有可能会有偏差或范围过大的情况，而随着项目的进行，产品负责人会对迭代中的故事（功能）进行细化，因此便需要与团队成员一同细化待办事项列表，细化会议一般每周不超过一小时。
如下图便是一个基于迭代的敏捷发布计划，开始时会有预测的版本，然后针对首次要交付的产品完成待办事项列表，随着项目的进行可能需要对迭代中的故事进行细化。
图1 敏捷发布规划
2.4每日站会
首先每日站会的主持可以是团队中的任何人，其次每日站会的时间不超过15分钟，最后每日站会不分析具体问题或解决具体问题。在基于迭代的敏捷中，可以通过任务板每个人轮流回答：
1）上次站会以来（其实就是昨天）我完成了什么？
2）从这次到下次站会（就是今天）我计划完成什么？
3）我的风险或可能的阻碍是什么？
如果是基于流程的敏捷，那么我们将注意力集中在团队上：
1）我们还需要做什么来推进一下这个工作？
2）有人在做任务板上没有的工作吗？
3）我们需要完成什么？
4）工作流程是否存在瓶颈？
注：每日站会的目的是通过简单的交流发现问题。针对具体问题可以在站会之后理解召开新的会议以解决问题。
2.5展示/评审
当我们团队完成一项特定的功能时，需要通过评审来决定该成果是否可被接受。这个频次至少是每周一次。
2.6规划基于迭代的敏捷
不同的项目，不同的团队，其需要完成的工作量是不同的。产品负责人与项目团队在划分工作内容时需要考虑自身情况，避免任务过大而无法完成的情况。同时对于团队成员不可用时（比如请假等），对于任务的大小需及时做出调整。
2.7交付执行
产品的质量非常重要，若只在乎交付时间而不重视质量，在我们执行项目过程中会发现，不出几个交付节点，便无法再进行按时交付，因为需要解决的问题会越来越多。
为了避免不重视质量所带来的风险，我们需要：
1）持续集成。在完成一项任务后，将其集成到整体中，然后重新测试，以确定产品的功能正确性；
2）不同层面的测试。通过自动化测试完成模块测试、集成测试、单元测试、系统测试、整车测试等；
3）验收测试驱动开发（ATDD）。针对验收标准，编写测试代码，通过自动化方式完成测试。对于非软件项目，我们需要考虑当团队完成大量工作时对其进行测试。
4）测试驱动开发（TDD）和行为驱动开发（BDD）。这是一个反向驱动的方法，通过先编写自动化测试的过程可以帮助开发人员深入认识到所需开发产品的相关标准，防止不确定的错误。对于硬件或机械结构类的非软件项目，我们也常通过先模拟再设计的方法，便是测试驱动开发。
5）刺探。在评估、验收标准的制定和通过产品了解用户行为中使用，可以刺探出深层的需求。
三、敏捷项目中的困难
通过敏捷方法中的各种技术及工具，以解决预测法中的相关若干问题，可参考下表：
图2 敏捷项目的衡量指标
四、衡量指标
诸君应该都见过项目的状态报告，对于传统的预测型项目，我们常会遇到项目在临近交付前发生与预期不同的状况，比如各模块单独工作时一切正常，但在最后集成到一起时却效果不如预期，此时项目的状态便会从绿变为红，这种无预警的‘西瓜项目’正是由于项目数据是直到最后时间才被集中到一起。
但敏捷是对于每一次的成果进行衡量，将客户的价值直接进行展示，通过这种微量的交付对已完成工作进行反馈，同时可及时调整即将到来的工作，因此对于团队去掌握项目的基准、估值、投资回报等会更加有把握。
这过程中会使用燃尽图或燃起图查看项目的进展情况。
图3 剩余故事的燃尽图
如上图‘剩余故事点’折线出现‘水平’，说明交付遇到了问题。
图4 燃起图
燃起图与燃尽图正好相反，是从已完成故事点出发的。
基于流程的敏捷团队通过使用交付周期、周期时间、响应时间来衡量，并通过看板方式展示，团队可通过衡量周期时间发现瓶颈和延迟问题。
图5 看板
通过将已完成工作、剩余工作以及待办事项工作整合到一起，团队可以更好的评估和估算自己的工作，如此便可以得到如下功能图：
图6 功能图
在敏捷中的挣值是基于已完成的功能，对于有许多故事点的大功能来说，可以用待办事项列表燃起图来显示已完成的工作与预期工作总量的对比。
图7 产品待办事项燃起图
对于挣值的衡量可以使用燃起图
图8 敏捷下的挣值（左：故事点，右：项目支出）
基于流程的敏捷团队可结合累积流图对看板上的工作进行显示，可对各部分工作内容进行管控，更直观的对整个开发工作进行评估。
图9 已完成功能的累积流图。
看图方法：纵坐标为已完成功能点数，横坐标为时间，图中内容解释：
1）队列，任务进入看板形成的排列模式。
2）分析、开发、测试，任务开始并进行中。
3）部署，任务完成。
4）周期时间：任务开始到完成的时间。如功能点2，开始时间是1月中旬，完成时间是10月中旬，就是说该任务花费了9个月时间。
5）交付周期：任务进入看板时间到完成时间；
6）响应时间：任务进入看板到开始工作的时间（有些任务进入看板，但由于优先级问题，并未第一时间开始，在看板上的等待时间便是此处的响应时间）。
分析方式：如果某项工作点任务数量变多（如图中的分析）那么该图就会向上‘拱’（阴影面积变大），那么剩余的任务自然会变‘高’，在同等资源下，横轴便会被‘拉长’，则项目恐会延期。
要使得项目按照正常时间完成，那么同样时间内需要完成的任务数便会增加，如此一来，团队成员的压力便会增大。因此如何合理的安排任务，是敏捷团队成员需要思考的问题。
通过该图，将任务在看板上进行调整，可以直观项目的变化，并作出合理的调整。
公众号文章链接：汽车项目管理之敏捷方法（五）——过程及交付
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 举报，一经查实，本站将立刻删除。