敏捷项目管理

任何一个领域都遵循从新人到熟手，从熟手到专家的路径。在成长过程中，DevOps人经常会陷入没人带，没人管，找不到职业方向的迷茫。 DevOps是在商业演进与企业协作的进化过程中诞生的一个全新职业，被很多人看成是一个“全栈”岗位，是能开发、会运维的复合型人才，但想要从事DevOps工作要从哪学起？如何入门？又该如何精进？ 我们对101名DevOps专家进行调研，问题只有一个：从入门到熟手，再从熟手到专家的成长路径中都看了哪些书？最终选出了39本推荐度最高的书籍，分成基础敏捷实战、敏捷测试、精益系列、技术工程、DevOps、教练、引导、大规模敏捷这8大部分，建议每一个DevOps从业者收藏阅读。 基础敏捷实战 《Scrum要素》 本书以一种轻松易懂、简洁精练的方式，介绍了Scrum 方法的核心要素。Scrum 入门级读物，内容精练，轻松易读，是帮助软件开发人员认识、初步了解Scrum 方法的佳作。通过阅读本书，可以厘清Scrum的相关知识和概念，为采用和实践Scrum 方法做好充分准备。 《敏捷革命：提升个人创造力与企业效率的全新协作模式》 本书由Scrum创始人写就，以讲故事的方式，讲述Scrum的由来，并逐步推进的过程。同样是入门级读物。 《Scrum精髓：敏捷转型指南》 如果想用Scrum来开发足以引爆流行的产品和服务，本书就是你梦寐以求的完全参考。

前言 现在软件领域三大俗，说的是敏捷、大数据、云，说的越多的往往也是处于成熟中，或者需求强调的，我所遇到的项目有幸几乎都触及到这些俗气的元素。 不得不说，市场竞争和各厂商客户意识的提升，现在的用户已经被宠坏了，以前我们叫挖掘需求，也就是客户是有自己需求的只是表达传递的完整性问题，通过一定的需求工程的方法把这些需求给定义出来，变成软件需求就好了。现在客户往往是不知道自己想要什么的，他们往往会提出"高大上"的需求，比如："我要一款软件，使我的业务管理水平达到行业的标杆，至少这个软件具体应该有什么功能我也不知道，我们预算是要多少有多少，关键是要做好，要在最短时间内最好是明天交付出来，否则后续取消与你们的合作。"，相信很多开发人员听到这些"需求"都会感到无所适从。 不幸我就遇到类似的一个项目，客户需求就是一句话："在国家批下来的预算范围内，给我们做一个本行业标杆性的软件，需求嘛你们自己研究研究，我们就看效果，但必须在 1 个月内上面领导下来参观前完成"，经过初步分析，参考这个行业的同类软件，至少涉及到集群数据存储与分布式检索、广度爬虫、自然语言识别，当然还有面向客户的业务应用系统。而且作为公司的战略项目，关系公司后续的市场开拓，老板发话："必须成功，还要注意成本"。 大家现在知道了，又遇到有中国特色的项目了，"需求范围不确定，资源限死、时间限死"，大家会说不是战略项目吗，资源怎么会限死呢

1. 什么是 Scrum 　　Scrum 是一种轻量级的框架，适合于小型的、结合紧密的团队开发复杂的产品。 Scrum 是二十世纪后期一些软件工程师协同努力的脑力劳动的成果，现已成为技术领域最具魅力的方法。但 Scrum 并不因此而复杂难用，相反，它不仅适用于技术领域，你还可以轻易将本文中介绍的工具和实践应用于其他领域。 　　一个 Scrum 团队通常由 7 人± 2 人组成，他们在固定的周期用迭代开发的方式一起协同工作。在每个迭代中，他们有充分的时间来评审和反思。“ 检查和调整 ”是 Scrum 的口头禅之一， Scrum 团队还有一个显著的特点就是非常关注 持续改进 ——既包括他们采用的过程，也包括他们的产品。 2. 角色（ Roles ） 　　Scrum 中有三种角色：产品负责人（ Product Owner ）、 Scrum Master 和团队成员。 2.1. 产品负责人（ Product Owner ） 　　从企业的角度看，一个开发团队代表了一笔重大的投资，包括：人员工资、办公室租金、计算机和软件的采购和维护费用等等。 产品负责人的责任在于帮助企业获得最高的投资回报 （ ROI ）。 　　其中一个最大化 ROI 的方法是引导团队做最有价值的工作，同时远离那些低价值的工作。产品负责人控制团队的待办列表中待办事项的优先级顺序。在 Scrum 中

Scrum是一种用于开发创新产品和服务的敏捷开发方式，我们首先来看一下敏捷开发过程和特点，并着重介绍Scrum框架的角色、活动和工件等内容，然后介绍团队利用TAPD中的需求管理、缺陷管理、迭代管理等应用功能来帮助团队有效实践Scrum敏捷开发。 何为敏捷开发？ 敏捷开发所倡导的是通过若干个短期的迭代周期（也称为冲刺sprint，范围一般是1周- 1个月），按一定的优先级不断增量开发和实现产品功能，每次迭代获得一个可运行的产品增量功能包。 敏捷开发首先需要建立一个按优先级排列的产品列表，其中由产品需求、功能优化或功能缺陷等类型清单项组成，排在前面的是优先级高的项，优先纳入迭代计划进行实现，这些项在纳入迭代计划前进行分解和细化，达到满足开发团队实现的粒度。 越往后排的项优先级越低，这部分需求暂时不会提上开发实现日程，当前阶段可以粗略描述，也不必急于细化，以应对可能的变更。 每次迭代开始阶段，从产品列表中选取一定数量的清单项作为本次迭代需要完成的目标任务，通常是由各方利益相关者讨论决定的，数量的多少视开发团队的情况而定，尽量匹配开发团队的开发节奏。 迭代过程中开发团队每天通过站立会的形式沟通工作进展和面临的问题，在这期间一般不再接受新的产品项或其他开发任务，特殊情况可以接受任务的置换。 在每次迭代结束时，团队一起评审已实现的产品功能等工作项，并根据反馈优化当前的工作和开发方式。在这过程中

第1章 为什么需要敏捷 第2章 敏捷和敏捷项目管理定义 第3章 敏捷项目管理价值和原则 第4章 生命周期选择 第5章 敏捷实施-创建敏捷环境 第6章 敏捷实施-在敏捷环境中交付 第7章 敏捷项目管理过程框架 第8章 关于项目敏捷性的组织考虑因素 第9章 敏捷各流派框架介绍 第10章 敏捷术语解析 来源：博客园 作者： 斗哥哥 链接：https://www.cnblogs.com/smileberry/p/11664796.html

需求变更是项目管理的重点，也是最头疼的一个点之一。 因为变更需求一般都是客户提出来的，你响应客户的需求，答应他，那代表着团队的开发工作量会变多，增加了成本。 不答应他，他毕竟是客户，显得面子过不去。所以在现实的项目交付中经常会遇到这样的问题。甚至有的客户刚开始在签合同时 故意隐瞒需求，报着少讲少说一些，到项目立项签合同后再提需求，这样项目成本可能会少一些。哈哈 那怎样解决那？其实根据不同的项目情况，不同的客户关系都是事在人为，解决方式也不同。 那今天给大家对接的解决方案是，如果客户前期需求不是太明确，并且要求产品早些上线，其实建议使用敏捷管理的方式。 这样大家可以基于明确的需求去投入已知的产品研发，不明确的放到产品开发的后面迭代里。 那怎样管理迭代，使用 项目管理工具 来进行需求的管理那，给大家推荐下 项目家 ，里面包含了轻量好用的敏捷项目管理方法。 还有更多的敏捷 项目管理经验 可在社区里去探讨沟通。 来源： https://www.cnblogs.com/iwangjun/p/11759152.html

[+] 随着敏捷开发越来越流行，人人都在谈敏捷，人人也都在学习scrum等敏捷开发方法。。。当然，自己也是敏捷开发的实施者和受益者。 背景 我们公司引入敏捷开发的时间并不长，在实施敏捷的过程还存在一些问题，自己在实施敏捷的过程也存在很多的疑惑（毕竟原来没有学过，和真实的经历，体会），所以最近一直在学习敏捷，看敏捷的视频和阅读相关资料，同时结合自己实施敏捷的经验，通过分享博文进行一下简单的总结，目的有四： 1. 详细的介绍和学习一下敏捷开发 2. 和CSDN的大牛们一起分享交流，学习，提高一下 3. 总结实施敏捷过程中的问题，不断反思，不断提高 4. 最后，希望对不了敏捷的朋友有一定的帮助 什么是敏捷开发 敏捷开发（Agile Development）不是指某一种具体的方法论、过程或框架，而是一组价值观和原则。 怎么理解呢？ 首先，敏捷并不是一门具体的技术，而是一种理念或者说是一种思想。它可以指导我们更加高效的开发。 其次，敏捷开发都具有以下共同的特征： 迭代式开发 增量交付 开发团队和用户反馈推动产品开发 持续集成 开发团队自我管理 最后，相比于“传统”的瀑布开发模式，敏捷开发是一种“现代”的开发模式。 具体方式 上面说了敏捷是一种指导思想或开发方式，但是它没有明确告诉我们到底采用什么样的流程进行开发，而具体的开发方式有哪些呢？ Scrum， 极限编程（XP） ， 精益软件开发

第1章 为什么需要敏捷 第2章 敏捷和敏捷项目管理定义 第3章 敏捷项目管理价值和原则 第4章 生命周期选择 第5章 敏捷实施-创建敏捷环境 第6章 敏捷实施-在敏捷环境中交付 第7章 敏捷项目管理过程框架 第8章 关于项目敏捷性的组织考虑因素 第9章 敏捷各流派框架介绍 第10章 敏捷术语解析 来源： https://www.cnblogs.com/smileberry/p/11664796.html

敏捷，简单的释义，即灵敏、快捷。 「合理的任务规划」 能让团队的工作即饱和而又能够有良好的应变能力（灵敏），团队需要时刻保持着良好的应变能力，因为我所了解的开发团队一直都面对着一个不确定因素——需求变化快。 「专注」 能够有效提升效率（快捷），当人在多件事情之间来回切换的时候，效率就会显得低下而且心情还很容易变得糟糕。 接下来将带给你如何使用敏捷的工具之一 Scrum 帮助你完成「合理的任务规划」和如何「专注」 。 一张图看懂 Scrum Scrum 工具包括：3个角色、3个工件、5个活动和5个价值观。 3个角色 01 Product Owner： 职责： 🔘清楚知道产品的愿景，分为近期和远期。 清楚愿景才不至于被干扰带偏道路，才可以清楚的区分重要紧急、重要不紧急、不重要紧急、不重要不紧急事件。我们可以集中精力于重要不紧急事件，这样就能减少重要紧急事件的发生。 🔘获取外界的诉求并进行整理成 User Story。 外界：用户、运营部门、其他业务方 User Story：需要实现的功能，以客户的角度，描述「我需要功能A，来达到我的什么目的」。 🔘对整理好的 User Story 所需要的资源进行各方协调并得出「是否可行、什么时候可行」的结论。 一个功能的实现，有时候牵涉各个业务系统，往往各个业务系统所对应的Team排期是不一样的，就需要提前进行沟通

如果还不知道Scrum敏捷开发的朋友们，同理，还是请出门左转，点击 Scrum 了解下。 以下是原文中提到的9个Scrum不行的理由。除此之外，作者陈皓在里面加入了自己的分析（感谢陈皓提供的精彩内容）。 Reason 1: Scrum的基石是相信人。创造一个安全的环境，这样每个人都能相互学习，相互直言。但是，这是不行的，这世上有很多人并不关心这些，而且竞争到处都是，办公室里无小事，你和别人交心，你相信他们，最终受伤的你自己。你真的以为那里有空间让你可以去犯错，去冒险吗？ Reason 2: Scrum认为只要给员工足够多的自由员工就能做得最好。这该死的理论是基于什么玩意？不可能，人的天性是懒惰的，他们才不会把事做好的，他们只会做相应报酬的工作量，还可能基本甚至达不到其相应的报酬，大多数人都在混日子。尤其是和经理比起来，谁不想能尽快地成为经理或Team leader啊，因为那样他们就可以即不干活，又挣得多。另外，你给他们自由，你就会发现，他们会只会做他们感兴趣的事，要么聊QQ，要么打游戏，看闲书，反正不干正事。直到你催了，他们才动一动。 Reason 3: 因为前面的原因，所以，我们仍然要把一个PM放在Scrum团队的上面做管理，这样才会有产出。于是，PM给团队分配任何，管得细枝末节，事无巨细，天天让你做进度汇报，等等。直至把团队拖垮。 Reason 4:Scrum只不过是一个流程