作为一个软件工程师，软件设计和开发是最重要的技能，但是，从整个产品的角度上讲，项目管理能力比开发能力更重要，本文摘自Robert大叔的《敏捷软件开发》，粗体是Robert大叔的话，细体是我的理解。
1.持续、尽早交付有价值的软件以满足客户，是我们优先要做的首要任务。
以逐渐增加功能的方式经常性地交付系统和最终质量之间有非常强的相关性。交付得越频繁，最终产品的质量就越高。
自顶向下地设计软件，按照功能优先级逐步开发，定期交付可运行的版本。这个原则看起来简单，但是对软件设计有非常高的要求，因为随着不断地交付，软件的feature不断叠加，如果起初设计的不够灵活，后期增加feature的难度会很大，而且也很容易出bug。
2.拥抱需求变更，甚至是在开发的后期。敏捷过程利用变更为客户带来竞争优势。
敏捷团队会非常努力地保持软件结构的灵活性，这样当需求变化时，对于系统造成的影响是最小的。
3.频繁交付可执行的软件，从几周到几个月，交付时间越短越好。
4在整个项目过程中，业务人员和开发人员必须每天在一起工作。
我的理解：业务人员能对软件项目进行持续性地引导。
5.激发每个团队成员的积极性来打造项目。为他们提供所需的环境与支持，并且信任他们可以完成工作。
比如项目室椅子不舒服，太吵闹，项目经理是不是该想办法解决一下？
6.在一个开发团队内部最有效的传递信息的方式是面对面的交流。
最好的沟通方式，就是面对面地交流。
7.可执行的软件是进度的首要检验对象。
检验软件不是文档编写了多少，代码量有多少，基础数据结构堆砌了多少，而是，总体功能实现了多少。
8.敏捷过程倡导可持续发展。赞助商，开发人员和用户应该尽可能保持一致的步伐。
9.不断地关注优秀的技能和好的设计会增强敏捷能力。
不在软件中留雷，该今天清理掉的恶心代码，今天就清理掉，不要留到以后。
10.尽量用艺术化来简单阐述未完成的工作是很有必要的。
简单！不要试图去构建那些华而不实的系统，而是采用能达成目标的最简单的方法实现软件。不要太注重明天会出现什么问题，也不要在现在的软件中对未来的问题做防卫，开发人员要做的，就是在今天以最高的质量完成最简单的工作。
11.最好的架构，需求，和设计出自于自我组织管理的团队。
不存在某个模块只有某个人最熟悉，所有人都应该对整个系统熟悉。
12.每隔一段时间，回顾反思如何让团队变得更高效，并相应地调整其行为。
尽管许多这些原则可能看起来只有直接应用到开发团队才讲得通，但是如果我们了解了这些原则的精神，我们还是可以获得一些非常有用的价值。并且这些价值能够使我们的项目管理变得更敏捷。
沟通：无论是开发人员，管理层，或是客户之间，对于任何敏捷项目来说开放的沟通是必要的。项目经理应确保参与项目的各个部门间的沟通及时、清晰、有效。包括每一个开发人员和利益相关者。记住，敏捷项目是“拥抱需求变更的”。这意味着，只有不断的沟通才是唯一的办法，从而确保变更不被丢失，并且避免出现团队成员在完成工作的时候，对于需求变更还什么都不知道的情况。
简单：一个项目成功的关键因素应该是尽可能做到最简单的形式，并且所有项目管理活动都应当做出可度量的贡献值。项目经理的职责是，与利益相关者共同来决定项目中各个任务，交付件，和交付产品的价值，从而让项目以最简单的形式体现又具有最高的价值。
反馈：“乐观主义是软件开发行业的职业病，反馈是治愈这种病的良药”。定期反馈是敏捷开发项目的关键，因为它让错误和缺乏沟通及早地被发现。降低了交付的产品与项目干系人需求背道而驰的风险。
魄力：项目经理作为领导者，其领导力需要魄力。敏捷项目常常需要不断改变开发方向，需要很大的勇气来应对这些变更所带来的后果。
透明：作为最好的项目经理，他们并不是什么都知道。相反地，他们常常依赖各个项目成员的各种专业知识，来打造一个透明化的大环境，从而让成员们互相学习，各取所长。
