打字猴:1.704234482e+09
1704234482
1704234483 能力不足、新手太多的团队没有办法照搬敏捷的各种做法。比如,没法让新人“认领任务”,只能自上而下地指派任务,因为新人对工作量的评估常常不准;再比如,过于木讷的工程师无法和客户顺畅沟通,只能通过产品经理来传递信息。
1704234484
1704234485 职业精神不强会造成更大的问题。典型例子是,绝大多数国内运动员能理解“第二天要比赛,前一天晚上不应该去泡吧”的合理性和科学性,但有的运动员则必须真有这么一个规定来约束自己。我也碰到过一些职业素养不高的互联网企业开发人员,承诺交付日期后屡屡拖延。
1704234486
1704234487 所以,敏捷在具体操作层面上,要根据团队情况做一些调整,接着看后六条敏捷原则。
1704234488
1704234489 七、在开发小组中最有效率也最有效果的信息传达方式是面对面的交谈。
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和敏捷最核心的思想就是不断优化,以优化出一个最适合当前团队的方法论。
[ 上一页 ]  [ :1.704234482e+09 ]  [ 下一页 ]