在寻找项目管理软件之前，应该先明确一下我们的目的，希望软件能够带给我们什么价值，价值来源于需求，那么我们的需求是什么呢？需求简单来说，就是希望一款软件能够帮助我们进行管理性工作，现在的项目管理工作其实分为“项目管理”、“敏捷项目管理”这两种方式，这两种管理方式虽然在管理流程存在差异，但目标是一致的，都是让项目尽可能的实现商业价值。我们的项目适用于以上哪种方法，这个需要按照项目的特性、以及团队的水平来确定。
“项目管理”是一种预测型的管理方式，它提倡在项目开始前，尽可能的预测并计划我们要做的每一件事情，比如：
1） 预测一个商业问题可以转化为机会；
2） 预测我们设计的项目范围能够抓住商业机会；
3） 预测我们需要在3个月内交付项目才能取得较大的商业价值；
4） 预测我们依照指定的质量政策才能够满足质量要求；
5） 预测我们需要10个开发人员才能保质保量的交付；
6） 预测我们可能遇到风险有哪些、预测完成这个项目需要500万人民币。
以上的预测，是对范围、时间、质量、资源、风险、成本这几个因素的预测，它们相互制约着，并且最终影响到客户的满意度，如图：
相互制约的例子：
1） 小张本来一周内只能完成10个功能，但因为项目急，开发时间短，现在需要小张在1周内完成15个功能，小张加班加点，勉强完工，虽然进度是赶上了，但质量可能会出现问题。这是时间、范围、质量之间的制约。
2） 然后还是小张，小张在一周内能够完成10个功能，这个速度无法使我们按时交付项目，所以我们决定增加一个开发人员老王，如果老王加入后，团队每周可以完成25个功能，这样可以达到项目的进度要求，但是受限于成本原因，我们请不起老王，那老王就来不了了。这就是资源、时间、成本之间的制约。
3） 老王一个人独立开发项目，开发过程中发现某个功能的实际开发工时超出了预期工时，这导致了项目关键路径的改变，如果我们想要按时交付项目，在不加入小张的情况下，只能砍掉几个不必要的功能，延后至下一个版本上线。这是范围、时间、成本之间的制约
项目管理就是对于这些制约因素的管理，在这些制约因素的相互影响下，帮助企业实现最高的价值收益。
项目管理是一套管理体系，主要包括5大过程组：启动、规划、执行、监控、收尾。在前面说到的预测，就是启动与规划，我们可以在规划后，得到详细的计划，计划包括但不限于：
1） 范围管理计划；
2） 进度管理计划；
3） 成本管理计划；
4） 质量管理计划；
5） 人力资源管理计划；
6） 风险管理计划。
这些计划就是项目的基准，指导团队执行项目活动，有了基准就是有了目标与规范，大家在规范的指导下，向着明确的目标共同努力完成项目。
当项目执行中，我们还需要及时监控项目的执行情况，保证项目的执行方向与目标方向保持一致，这个时候就有了绩效，通过对于绩效的把控，来衡量项目团队当前时间点的任务完成情况，如果发现偏差，需要及时调整，发现偏差的方法可以是：
1） 趋势分析
2） 偏差分析
3） 挣值绩效
4） 统计抽样
可能存在的偏差有：进度偏差、质量偏差、成本偏差、范围偏差，我们通过修正这些偏差，保证项目是可控的，以实现商业价值。
范围、进度、质量、成本，这几个制约因素，在这里就被称作为“多快好省”， 因为多快好省正是衡量几个指标的目的，除掉“多快好省”之外，项目管理还需要对团队成员进行管理，管理他们的期望，管理他们的工作状态，这就要求项目经理具有一定的软技能，和人力资源相关的方法论。
风险管理，积极和消极的风险通常被称作为机会和威胁。如果风险在可承受范围之内，并且与冒这些风险可能得到的回报相平衡，那么项目就是可接受的，我们通过识别风险、定性风险、定量风险、制定风险应对策略、控制风险，这样的处理流程对风险进行监控。
在实际工作中，传统团队中的高级管理者通常认可上面这种项目管理方式，他们关注的问题诸如：
1） 项目能否完成预期价值？
2） 项目什么时候能够交付？
3） 当前的进度如何，能否按时完成里程碑？
4） 质量是否达标？
5） 我们是否需要做出调整？
他们希望以可控的方式来对待项目，这种项目管理方式在定制化项目中非常适用，因为它满足PDCA的管理循环理论，以SMART的方式制定项目计划，以挣值管理的方法监控过程，最终得到预期的结果并进行复盘。并且这套流程同样符合企业管理的流程，能够监控团队的绩效，获得团队的执行情况，这是高层管理者最希望看到的，所以必然会在企业内得到认可和推广。但是现在的互联网企业基本不做定制化项目了，如果套用这一套项目管理体系，在执行过程中会非常的难受，他们会发现来自用户、市场、销售的需求范围随时都在发生变更，无法建立详细的执行计划，如果让团队做一个月的计划是可以实现的，但是如果做半年的计划，那是痛苦的，没有详细的计划，就没有完善的监控过程，也就无法准确的评价绩效。
不同类型的项目需要不同的对待。就像我们的生活一样，吃中餐的时候我们使用筷子比较方便，而吃西餐时我们使用刀叉比较便捷。而我们再进行开发工作时，也会基于不同的环境选择不同的方法。
“敏捷项目管理”是一种适应型的管理方式，它以价值驱动交付，项目团队需要保证最有价值的功能最先被交付，然后通过用户的反馈得到改进的意见，及时调整适应，整个开发过程遵循计划->执行->调整的环状结构流程，在敏捷团队中，个体和交互大于流程和工具，这要求每个团队成员都具有良好的沟通能力和专业技能，如果每个成员都是T型人才，能够胜任产品设计、开发、测试中的每个岗位，那敏捷团队将会表现的非常高效。这样看起来，敏捷团队就像是一个特种部队，每一个成员都拥有广泛的专业技能，随时能够填补团队中的空缺，保证任务的稳定执行，如果想要尝试敏捷项目管理的，可以了解以下敏捷方法（只做介绍不做详细说明）：
Scrum：
Scrum特指一种敏捷开发的模型。它是一个迭代小、增量性的流程，适用于任何的产品开发以及工作管理。Scrum将软件开发团队比拟成橄榄球队，有明确的最高目标，熟悉开发流程中所需具备的最佳典范与技术，具有高度自主权，紧密地沟通合作，以高度弹性解决各种挑战，确保每天、每个阶段都朝向目标，明确的推进。
Scrum三大支柱：
1） 高透明性：信息的高度透明，任何方面都能被观察到
2） 检查：经常性的检查，防止重大偏差
3） 适应：当发现可交付成果不合格时，应该及时修正，减少偏差
Scrum 团队：
1） 开发团队：是自组织的、跨职能的、他们拥有创造产品增量所需要的全部技能，包括设计，类似特种部队。
2） 产品负责人：是管理产品待开发项的唯一负责人，类似军队中的军长。
3） Scrum Master：确保Scrum被理解并实施，类似军队中的政委。
Scrum 事件：
1） 迭代：一个迭代就是一个时间盒（有时间限制），在这个时间盒中至少应该有产品发布，这个时间盒的长度一般为1~6周的时间。
2） 迭代计划会议：确定在这个迭代中需要交付哪些产品以及如何达成目标。
3） 每日立会：每天15分钟的时间，开发团队需要同步他们的活动，彼此进行沟通以及提出问题。
4） 迭代评审：迭代结束时举行的会议，产品负责人决定本次迭代是否完成。
5） 迭代回顾：回顾反思整个迭代过程需要改进的地方。
Scrum 工件
1） 产品待开发项：所有需要开发的功能。
2） 迭代待开发项：产品待开发项的分解，一次可以交付的最小迭代目标。
3） 燃尽图：翻译工作量完成状态的趋势图。
极限编程（XP）：
XP是敏捷方法中的一种软件开发方法。如果说Scrum更加关注项目管理工作的话，那么XP更加关注软件开发的良好实践。XP的核心价值是监督、沟通、反馈、勇气、尊重，这些价值体现在XP的整个生命周期中。
极限偏差的核心实践：
项目团队使用FDD的方法首先可以为产品开发一个整体的模型，构建特性列表和工作计划，然后对开发的特性进行设计和构建迭代。FDD推荐了一系列的良好实践，这些都是从软件工程中延伸而来。这些实践包括：
1. 领域对象建模
2. 安装特性开发
3. 类拥有权
4. 特性小组
5. 审查
6. 配置管理
7. 定期构建
8. 可视性进度报告
动态系统开发方法（DSDM）：
DSDM倡导以业务为核心，快速而有效的进行系统开发，其的基本观点是，任何事情都不可能一次性地圆满完成，应该用20%的时间完成80%的有用功能，以适合商业目的为准。实施的思路是，在时间进度和可用资源预先固定的情况下，力争最大化地满足业务需求（传统方法一步是需求固定，时间和资源可变），交付所需的系统。对于交付的系统，必须达到足够的稳定程度以在时间环境中运行；对业务方面的紧急需求，也要求能够在短时间内得到满足，然后在以后迭代阶段中对功能进行进一步完善。
DSDM周期有7个阶段
1） 项目准备阶段
2） 可行性检验局阶段
3） 业务研究阶段
4） 功能建模阶段
5） 系统设计编程阶段
6） 实施阶段
7） 项目后期阶段
精益开发（LEAN）：
精益开发不是敏捷的方法，但是精益和敏捷的价值观是紧密相关的，精益的一系列原则是从精益生产中来的，并应用于软件开发。对于精益来说有7个核心的概念：
中消除浪费是为了最大化价值。浪费来自一些不必要的功能。为了提升我们在项目中获得的价值，我们必须识别一种方法以消除浪费。
看板方法（Kanban）：
看板开发方法是近年来最热门的敏捷和精益开发方法。越来越多的案例表明，它能够改善协作、优化管理，显著提高交付速度、质量和灵活性。看板开发方法的规则简单，但其有效的实施依赖于对原理的理解、对原则的坚持和实践的应变。
一个看板在敏捷开发中的最佳实践如图：
每个卡片代表开发中的各各流程，图中以 规划->开发->测试->发布这样的流程来进行管理，开发任务在这个工作流中扭转执行，最终被发布。整个过程显的十分灵活可控。
“敏捷项目管理”在质量保证的流程中需要借助一些自动化方式，如：
1） 持续集成（CI）；
2） 持续部署（CD）；
3） 测试驱动开发（TDD）；
4） DevOps(开发、运维、质量管理一体化)；
通过自动化的流程，提高交付的效率，减少人为出错的几率，提升质量。
与预测型项目管理相比，敏捷有他的优势，确定短期的需求，快速迭代交付、快速验证价值，采用周期性评价代替复杂的绩效管理、让整个团队的目标一致，以价值驱动。
敏捷看似简单，但想要达到真正意义上的敏捷是比较困难的，比如敏捷提倡“拥抱变化 高于 遵循计划”这在很多团队执行时往往会陷入两个极端，要么根本不做规划，要么就在计划上投入大量的精力直到自己确信计划是正确的，不做基本规划的小组可能连什么时间交付产品都无法回答，而做了大量计划的小组会自欺欺人地认为某个计划是“正确的”，他们的计划也许更全面，但并不意味更准确或更有用。这两种极端都是敏捷需要避免的，“我们实施敏捷，不再需要计划和文档了”的论调是极其错误的。敏捷不是不需要计划，相反它需要更多的规划。不确定性是影响计划正确的主要因素，对大部分不确定而言，获取知识、减少不确定性的唯一办法是开发得到一些原型，收集反馈，然后分析其价值，最后做出调整，这是规划-执行-调整的方式。一个项目的不确定性越高，敏捷开发方法对取得成功就越至关重要，不断学习和调整是敏捷开发的核心。
4、太长不看的结论性总结
在选择项目管理工具前，需要确定我们使用的是项目管理方法还是敏捷项目管理方法。如果使用的是项目管理方法，我推荐“project”；如果使用的是敏捷项目管理方法，我推荐使用
“日事清”。