|
文∣阿安，PMP，NPDP，敏捷教练，欢迎关注，一起学习产品开发管理 从上世纪中期开始，传统项目管理发展了近70年，在工业时代大家都遵循泰勒的科学管理方法的传统项目管理方式，新世纪进入互联网时代，创新型企业发现这种传统项目模式越发不再适合尤其是软件产品开发。 《精益创业》的作者埃里克说到：“现在是管理的新世纪，从社会层面而言，我们已经拥有了一整套管理制造实体产品的最佳方式，但谈到初创企业和创新，我们还在摸索中前行。我们依赖愿景，追随能创造奇迹的“伟大人物”。” 2001年17位世界级软件实践大师提出新的时代应遵循彼得.德鲁克的人性化管理，正式提出了'敏捷宣言'。 1、敏捷的4个价值观 (1)个人与互动胜于过程与工具 过程与工具固然重要，但人与人之间的互动比过程与工具还重要； (2)可用的软件胜于复杂的文档 可用的软件比复杂的文档重要,文档够用就好。 (3)与客户协作胜于合同谈判 开发团队与客户是一个团队,彼此协作比凡事都只通过合同谈判还重要。 (4)响应变更胜于遵循计划 根据客户的需求响应变更,比遵循原计划重要,这样才能为客户创造最高价值。 新型的敏捷开发不在一种简单方法论而是综合了许多方法和技术,能够帮助企业根据开发期间不断变化的特性，进行调整并且能够降低风险，完成为客户创造最高价值的软件。 以前传统开发都是产品做到开发团队认为的完美才上市,但结果依然还是会不断收到客户的抱怨， 而现在的做法是做出最小价值的产品后就上市，然后根据客户的反馈不断修改升级产品，决定产品最终形态的并不是制造团队，也不是设计团队，而是真正的客户。 在全球敏捷项目管理中，主要包含了Scrum、XP、Kanban 、Lean四种敏捷方法论及其实践模式。
2、4种主流的敏捷开发模式这里主要介绍这4种主流的敏捷开发模式 1.Scrum 美国施瓦布和萨瑟兰参考美国空军作战时面对战斗的快速反应的方法：观察、面向、决定和行动提出的Scrum。 Scrum的基本价值观,主要有:  (1)专注( Focus) Scrum团队应专注于交付潜在的可发布，可增量产品上的工作。 (2)尊重( Respect) Scrum团队不分你我,开发团队内的成员只有开发者的称号,没有其他工作等级职称。 (3)承诺( Commitment) 承诺就是对交付成果的保证、誓言及义务。 4)勇气( Courage) 有勇气公开,放弃不透明的作风。 (5)公开( Openness) 团队中每一个人都要知道彼此的工作哪些已经完成,且要能善于接受新的想法,成为学习型组织和高效率团队。  对于 Scrum主要有4个项目工作定义 1) Scrum是一个可以让我们关注于在最短时间内交付最高商业价值产品的框架。 2)这个框架让我们可以快速并持续检验真正可用的软件。 3)开发方式根据商业价值来调整工作顺序，是团队自我组织决定能交付最高价值功能最为有效的工作方式。 4)每两周到一个月,任何一个人都能看到真正可用的软件而非文档。 Scrum是用于开发与持续支持复杂性产品的管理框架，在这个框架中,人们可以解决复杂的适应性问题,同时以高效生产力与创造性的方式,交付最高价值的产品。 2、XP极限编程(XP)是由肯特·贝克,罗恩杰弗里斯和沃德·坎宁安共同开发的一种敏捷方法. 极限编程主要价值时推动团队成员与客户保持高度互动，其核心为13个实践。  (1)全队 客户代表及开发团队都是XP团队成员,，并且客户代表与开发团队要在一起工作。客户有两个主要职责:编写用户故事和确认功能验收测试。 (2)规划游戏 规划游戏是全队共同参与,以游戏或活动的方式,规划在特定的迭代的用户故事,并有效估算所需的工作量。 (3)最小的发布 要快速将功能交付到客户手中并聚焦在最小可售功能或称为最小可行产品MVP，让客户可以更频繁地进行调整和应对变化。 (4)客户测试 软件产品需要经过彻底的测试,最好在交给客户之前已经有自动化的验收测试。 (5)编程标准 编写内容包括文档名称、变量名称、程序缩排、括号、备注等,同一个团队要遵循相同的编程标准,才有办法做到程序代码共同拥有。 (6)程序代码共同拥有 所有程序是XP所有团队成员共同拥有的,不是某个开发人员所独自拥有的,意思是所有的程序除了自己看得懂之外,必须让任何个团队成员都看得懂、都可以进行修改。 (7)持续集成团队 工作的成果要每天集成到系统,有时候可以一天集成几次。 (8)隐喻 用隐喻的共同愿景来描述团队是如何工作的,这样比较生活化可以激发创意思考。 (9)持续步伐 传统的软件开发,一开始的时候工作时间比较规律,但快要收尾时,却要每天加班,而且到最后加班时间越来越久,项目反而越拖越长,甚至无法验收。 XP就是要维持一个可走得远的持续步伐更有规律地完成增量成果。 (10)测试驱动 在编程之前,团队就已经写好测试用例,以确保通过的程序就是客户需要的。 (11)结对编程 两个人一起编程，而不是一个人写好程序再交给另一人做测试。 (12)简单设计 编程的方法越简单越好,不要为了增加个人效率,而写了大部分人都看不懂的程序,增加后期维护的难度。 (13)重构 在不改变程序代码的外部行为,同时提高内部结构,改善程序代码设计的过程,通常是改为比较有效率或以后比较好修改的程序。 3、精益精益软件开发源于日本丰田汽车生产制造过程,精益的主要概念是以客户为主,所有的工作产出应该要为客户创造最高价值。 精益的7个基本原则也适用于软件开发，其核心价值与敏捷开发不谋而合。  (1)消除浪费 对客户或产品没有增加任何价值的行为都是一种浪费,包括在组织、过程、系统及其他方面的各种可能形式的浪费,都应该被消除。 研发过程应该通过利用价值流图方式分析每项活动,辨识出浪费的地方,并消除浪费。 (2)强化学习 精益追求持学习和改善、无论团队表现多好,总有还可改进的地方。 例如,学习用简单的逻辑编程,所有的变量命名都让自己和别人看得懂。学习做适度的分解和估算,让自己和团队能实现自己的承诺,如期完成合乎质量的成果。 (3)尽可能晚做决策 等到真正需要做决策的时候,再做决策,提前的变更只会增加无形的成本。等到要做决策所需要的信息充分获得了,到了最后负责时刻,再做决策,判断会比较正确。 (4)尽可能尽快交付 主管、客户都喜欢看到尽快交付产品，团队尽快把可靠功能交付给客户,获得客户的反馈,再据以修订系统,尽快交付也意味着更快的满意。 (5)授权团队 管理者该做的事是制定可以让团队创造增值的措施。精益项目是授权团队做决策,让团队自我管理从而在工作上获得最佳的效益。 (6)建构完整性 就感知外部完整性而言,要每天都能持续把客户的价值观转换成细节设计给开发团队，系统要能稳定内聚且能发挥整体的作用 (7)着眼整体 开发团队要考虑组织整体利益,而不能只考虑团队局部利益。团队要了解最初引发项目的商业需求，并检查团队的解决方案如何实现项目目标,而且必须是完整的解决方案,而不是几个分裂解决方案的堆积。 4、KANBAN看板是由大卫·安德森发现的方法,他是受到日本丰田汽车及时交付( Just-in-time Delivery)的启发。 看板的原意是招牌或看板，丰田汽车及日本百货业喜欢将客户要的产品有哪些、正在生产中的产品有哪些、已经完成可以交付的产品有哪些,这些价值信息放在一个大看板上进行显示。 其用意在于及时交付客户要的产品，团队成员即不会做太多,也不会做太少,所有的工作可视化,也不会让团队的工作超量。  看板方法的主要原则 (1)从过程开始 变革最大的阻力是人，变革成功的关键是变化越少越好,从既有的过程开始是反省、检讨,而不是变革,大家的接受度会比较高。 (2)同意增量渐进的改变 变革式的改变通常会导致失败，抵抗和恐惧的力量可能远比改变带来的好处强很多,看板奉行的是渐进式的改变,每隔一段时间就看到更进一步的成效。 (3)尊重当前角色的头衔和职责 对于现有的过程、角色、职责及头衔应该给予肯定,目的是要能顺利推行看板方法,让原本的组织做很少的改变,就可以开始接受看板。 (4)鼓励各层级的领导行为 要能够层层负责,各阶层真正了解看板方法,并鼓励成员自动担任领导角色,让全员都能自我约束,团队进行自我管理。 5、敏捷方法价值除了以上4种最为常见的敏捷方法以外，还有动态开发系统、水晶家族等敏捷方法。  敏捷方法论有很多种,每一种即可以单独使用,也可以混合使用，甚至在同一组织，公司内部,根据所开发产品的不同的特性采用不同的方法论。 敏捷方法论没有说哪一种比较好,哪一种比较不好,而是要选择适合的方法论。 |
|
|
