「项目敏捷」 为什么说项目综合管理敏捷首先要看得见？ 爱问知识人

项目敏捷： 为什么说项目综合管理敏捷首先要看得见？ 爱问知识人

在项目之初，曾想到在项目里面导入敏捷开发的一些好的实践，但是仔细分析了一下，项目组的成员大多在经验上还不是很丰富，硬要上敏捷的话，会得不偿失。考虑来考虑去，还是一点点来。先从“看得见”做起。所谓“看得见”就是让任何需要管理的东西，...展开全部

项目敏捷： 项目团队管理怎么建设敏捷团队？ 爱问知识人

每个人都会梦想自己的理想工作。做技术的开发人员要求的更是简单：一个能够不断学到新知识和新技能的职位，一个融洽的团队，一个舒适宽松的开发环境，一份成长的空间。而这些简单的需要，恰恰是许多公司所忽视的地方。这些东西，很多时候就是一个人...展开全部

项目敏捷： 敏捷项目管理都有哪些阶段？

目前项目管理流程分为6大阶段：1项目计划、2需求调研、3概要设计、4详细设计、5开发、6测试（并且每个环节会有审核）。用日事清把紧急重要的事情罗列在最前面，把重要不紧急的事情排在后面一些，把重要不紧急的事情排在后面一些，实施了项目管理流...展开全部

其他答案:它适用于软件，因为软件是软的，可以改。要是硬件，改起来就没那么方便了，它适用于客户不知道自己要啥的情况，其实，这样的客户占绝大多数。因为客户不知道要啥，所以你需要不断帮客户弄明白他到底想要啥，换句话说，你需要和客户沟通，合作，倾听反馈，持续改进。 它适用于快速变化的市场，你在埋头造一辆汽车的时候，客户已经想开飞机满天飞了，这就需要你能一步步的把汽车改成飞机，还能按时交付。它适用于在一个地方办公的小团队，一般10个人以内。这样能使敏捷中主要的沟通方式“face to face” 是可行的。 日事清是以gtd时间管理方法为主导的管理工 具，收集、整理、组织、回顾、执行，让你每天的日程管理安排都会井井有条。

项目敏捷： 敏捷项目管理的内容简介

《敏捷项目管理（第2版）》内容简介：如今，项目管理的步伐越来越快。项目管理需要更灵活、更积极地，向应客户的需求。使用敏捷项目管理方法，项目经理可以在不影响价值、质量和商业规则的前提下实现所有目标。《敏捷项目管理（第2版）》全面更新了...展开全部

其他答案:<img src=＂ 搜一下：敏捷项目管理的内容简介

项目敏捷：敏捷开发到底是什么？

概括来讲，敏捷开发就是一种以用户的需求进化为核心，迅速迭代、循序渐进地进行软件开发的方法，核心是快速响应和持续迭代。要保证在迭代周期内，团队成员思想保持高度一致、以共同的节奏和共同的周期完成周期性运转，保证在每一个周期的同一时间点，团队中的每一个人做的事情是相对一致的。迭代也让团队内外有着共同的预期，知道什么时间点该做什么，该交付什么出来。

或许这样理解起来仍有些抽象，那么让我们来看传统的开发是怎样进行的。传统的开发有个专有名词叫“瀑布式开发”，分为5个阶段：需求分析、设计、编码、测试和维护。这套方法定义了很完备的过程规范、严格遵从这种方式会使得研发运作过程十分严谨。但是，在瞬息万变的互联网和移动互联网时代，市场环境、用户需求、竞争对手等因素都在时时发生着改变。传统的瀑布式开发要求针对客户需求写出详细的分析说明书，仅仅这一点就耗费了大量时间，严格遵循规范但不够灵活的流程管理的结果可能是研发人员在开发过程中按部就班，产品技术上没有太多瑕疵，但是正式推出市场时可能部分功能已经落伍。

和瀑布式开发相比，敏捷开发的特点就是“小步快跑、尽早交付”。在市场环境和客户需求变更非常迅速的情况下，为了让需求方尽早地看到结果，并给出反馈，以小步快跑进行开发并尽早地交付新的版本不失为一种好的解决方式。毕竟在互联网时代，可用的产品一定胜过完备的文档，并且及时的迭代可以不断修正问题。

而要做到“小步快跑、尽早交付”，对团队也提出了一定要求：

（1）准确分析市场需求

这一点也是很多人对敏捷开发的误区。敏捷并不意味着不做项目计划，只是不一定拘泥于形式，一定要拿出完备规范的开发计划书，有时候敏捷开发的计划就是团队人员在白板上画出的原型和点、甚至是口头计划。这种计划不代表分析不严谨，事实上，敏捷开发比瀑布式开发更加注重需求的分析和计划的制定。因为敏捷开发的核心就是为了及时响应用户和市场的需求，所以并不会死守着计划不进行调整。一旦市场发生变化，即使到了开发后期，敏捷团队也应该对需求的改变持欢迎态度，对原先的计划进行调整，利用变化来为产品创造竞争优势。

（2）迭代周期尽可能短，且周期固定

“小步快跑”意味着产品的交付时间间隔越短越好，通常是2-4周，频繁地迭代能保证不断修正BUG，而迭代周期固定则能和用户形成良好的合作关系，便于客户及时反馈，不断地完善和提高产品的用户体验。小米就是一个很好的例子，MIUI开发版一周更新一次，至今已连续363周进行更新。

（3）团队规模最好也能敏捷

敏捷开发对团队的沟通要求很高，过多的人数会造成沟通成本的增高，信息在传达过程中很可能会有偏差，使团队难以保持步调一致。通常情况下，敏捷团队的人数少于20人，超过的话可以再进行团队分割。比如腾讯在管理200人或者更大规模团队时，就会按照产、研、运的组织结构进行复制，把大规模团队拆分为10个20人的团队，或20个10人的团队，分别负责产品的子模块。拆分时会保证子团队人员仍以产、研、运三驾马车组成，具备交付功能，可独立工作，再通过子团队之间的协作，完成整个大产品的研发和交付。

谦启将企业案例解析与专题研究结合，前期以读书会形式带领大家拆解相关企业书籍，并附以独有专题研究进行解析，关注我们，私信留言，或搜索关注“谦启学堂”，并在后台回复“研企社”，小谦将与各位一起解读企业案例。

项目敏捷：如何提升个人敏捷项目管理能力？

首先，拥抱变化，克服抵触，做好实施敏捷的准备。敏捷不是洪水猛兽，既然企业决定引入敏捷的变革，一定是敏捷项目管理方法有可取之处，何不加以尝试，再做决定，而不要拒绝变化，盲目抵触。

正如传统项目管理中提倡的——沟通是项目经理的基本素质，沟通也是解决变革问题的最有效手段。在实施敏捷伊始，一定要有充分的沟通，确保每一个成员都得到足够的关于敏捷的信息，可以从多方面客观地看待敏捷的优势和不足。敏捷不是神话，“敏捷不是银弹”，没有一个方法是放之四海而皆准的，所以我们采用的是敏捷的思想和针对项目环境的定制的方法。

个体成员可以寻找机会多了解敏捷的理论方法，参考敏捷社区的实践和案例分享，获取成功的经验和失败的教训，积极思考敏捷对于团队的独特性和带给自己的利与弊。同时企业也要采取正式和非正式的培训、研讨会、工作坊等方式，排除个体成员的疑惑和顾虑，目的是为实施敏捷做好准备。

其次，从管理实践角度，了解敏捷的框架，具体实施的方法，适应角色的变化。当个体成员接触一种新的方法是，尤其是技术人员经常会提出这样的问题，“采取什么框架都行，反正领导已经定了，直接告诉我怎么做就行了”。其实这是最要不得的一种态度，实施一种新的框架或方法，固然要求具体的工作指导，但是个体成员要从方法、过程、角色、职责等多个方面进行系统的学习和演练，知其然，知其所以然，而不是僵化地照本宣科。为了避免这一现象，很多组织引入了教练这个角色，用以助力个体成员对新方法的掌握和有效使用。

因为很多组织实施敏捷都是从Scrum框架开始的，而Scrum框架也是当前最为流行的敏捷方法之一，本文就以Scrum为例进行简要分析。

Scrum框架中有一种3-3-5的结构：

即3种角色——产品负责人(Product Owner)、Scrum M aster和团队(Team);

3种工件(artifact)——产品待办事项列表(Product Backlog), 迭代待办事项列表(Sprint Backlog) 和燃尽图 (Burndown Chart);

5种仪式(ceremony)——迭代 (Sprint)， 迭代计划 (Sprint Plan)， 每日站会 (Daily standup meeting)， 迭代评审 (Sprint Review)和回顾(Retrospective)。不难看出，这就是一种项目管理的框架，提供了开展工作的具体流程

项目敏捷：怎样做好敏捷项目管理？

敏捷项目管理是规划和指导项目流程的迭代方法。

与敏捷软件开发一样，敏捷项目是在叫做迭代的小型部门中完成的。每个迭代都由项目团队审查和评判；从迭代的评判中获得的信息用于决定项目的下一个步骤。每个项目迭代通常是安排在两周内完成。

我认为我们公司使用的日事清就具备一些好的特点，日事清是以GTD时间管理方法为主导的管理工 具，收集、整理、组织、回顾、执行，让你每天的日程管理安排都会井井有条。另外，在日程安排 上，日事清提供了四象限日程安排表格，你可以把日程按照重要性和紧急性整理到不同的象限，以 便更直观的安排日程的优先级，减少日程衔接的时间浪费。