1704234490
1704234491
八、可以工作的软件是进度的主要度量标准[4] 。
1704234492
1704234493
九、敏捷过程提倡可持续开发。
1704234494
1704234495
十、对卓越技术与良好设计的不断追求将有助于提高敏捷性。
1704234496
1704234497
十一、简单——尽可能减少工作量的艺术至关重要，最好的架构、需求和设计都源自自我组织的团队。
1704234498
1704234499
十二、每隔一定时间，团队都要总结如何更有效率，然后相应地调整自己的行为。
1704234500
1704234501
在具体操作中，敏捷思想认为我们应该和利益相关方、核心团队共同维持一个稳定的节奏，以对抗敏捷造成的随时可变、心里没底的状况。通过一个月左右的时间，让大家形成一种习惯，每一个迭代周期里，第一天做什么、哪几天开发、哪几天测试、什么时候Review……这样建立起来的确定性能够大大增加每个人的心理舒适感。
1704234502
1704234503
8.3.2 敏捷项目管理的实践
1704234504
1704234505
说完了对敏捷方法的理解，再聊聊实践。我经历过的团队，最常采用的是以Scrum方法为原型，再根据实际情况略做调整。下面，先说一下对几个Scrum关键概念的理解。
1704234506
1704234507
►团队角色
1704234508
1704234509
PO（Product Owner）通常是产品经理，要对各种利益相关方负责。
1704234510
1704234511
SM（Scrum Master）充当教练的角色，一般由对流程、方法论比较熟悉的人来担任，不建议这个角色和PO重叠。
1704234512
1704234513
Team由核心成员组成，其中的某一个人是可以担任SM的。
1704234514
1704234515
►关键产出物
1704234516
1704234517
Product Backlog指比较长期的产品任务表，即第06章提到的功能列表。
1704234518
1704234519
Sprint Backlog在Scrum里指当前这个迭代里面的任务点。
1704234520
1704234521
Burndown Chart是燃尽图，用来监控任务是不是在按期推进。
1704234522
1704234523
►重要的会议
1704234524
1704234525
首先是每个迭代的计划会 ，经常和需求评审会 合并，主要目的是明确任务，以及评审这个迭代里需要做的功能。
1704234526
1704234527
每天的站立会议 ，是重要的信息同步手段。
1704234528
1704234529
功能评审会 用来评估做出来的东西是不是想要的。
1704234530
1704234531
回顾会 的目的是为了过程改进，因为Scrum和敏捷最核心的思想就是不断优化，以优化出一个最适合当前团队的方法论。
1704234532
1704234533
►日常管理工具
1704234534
1704234535
看板 是一个非常重要的实用工具，很多公司的办公区里都会有，在硅谷创新公司里也被广泛应用。比如，有一块写着当前迭代关键信息的白板，或者有一面用来粘贴任务卡片和便利贴的玻璃墙，如图8-2所示。
1704234536
1704234537
接着，再说一些Scrum实际应用的具体做法。
1704234538
1704234539
2015年下半年，我孵化的一个项目，采用的就是以Scrum为原型的敏捷方法。
[
上一页 ]
[ :1.70423449e+09 ]
[
下一页 ]