敏捷项目管理--价值胜过约束

交付价值胜过满足约束—敏捷价值观。

---

事实上也符合当今的商业价值。那位说了：“我只是搞研发的，有必要了解这个吗？”，有，太有了。

传统的项目经理总是关注要求（定义范围），致力于如何达到哪些要求。尽管成本、进度这样的约束很重也，为客户创造价值也很重要。通常大伙总是愿意关注容易考量的因素，而忽略了真正至关重要缺难以量化的特征。

我们总是把精力花费在交付范围和成本上面，按照这种传统做法，开发团队根本不去控制结果和价值，我们会越来越依恋约束。约束本应随着项目的进展而发生改变，然而，一开始我们就为其制定评估指标，往往是固化额，不变化的。

那么，随着项目的进展，现有的约束已经不能很好的适用了，需要作出调整。客户的关注点在更改，项目方却依照固定约束，拒绝改变，客户价值无法得到保障，自然，客户对我们的信任度也会大打折，导致项目烂尾。

---

敏捷关注最重要的因素，而排在首位的是价值。

敏捷项目领导通过一下几种方式来关注产品价值：

• 与客户一起确定价值（客户合作）
• 价值优先排序（product log）
• 价值创造（迭代开发）
  尽管价值确定是业务经理和产品经理的职责，但项目领导、客户也要经常参与成本/效益分析和价值的判断（特别是自有产品公司）。

价值创造指的是客户合作、需求分析（用户故事、用户画像、产品优先级确定等等）、减少技术债务（保证质量和价值交付）等活动，这与传统的以范围、进度、成本为导向的理念截然不同。

---

通过持续创造客户价值来提高投资回报–《相互依赖宣言》

持续和价值是投资回报的一对关键词。价值是指企业或组织产出的结果，往往和营收有关。持续是指价值经得起时间的考验–无论是现在还是将来，特别是软件的设计，适时地交付软件的第一个版本固然重要，但交付高质量的软件更为重要（经得起考验的架构设计、零BUG的产品），诺基亚的手机无疑是最好的写照，这里不讨论它的战略布局。

• 增量交付：产品越早推出市场，可以带来丰厚的早起收益。
• 创新
• 执行
• 精益思维

---

对于一些产品连续的功能交付带来的最大好处就是，增量发布可以带来早起的收益。相比12个月或者18月等待新的软件功能，增量交付可以每季度甚至更频繁的交付软件的新功能。增量交付有利于提高投资回报率，因为它让产品经理抓住了18个月的等待后可能失去的机会。

频繁增量交付需要客户、相关干系人、产品经理、研发经理、研发团队共同合作，又各自有着特定角色、职责、和责任。新产品研发是一个高度变化、不明确、不确定的过程，在此过程中就需要客户和研发人员同理合作。

谁是客户？答案：利益相关方，和项目相关、协助定义产品商业价值和其他约束的个人。如果希望交付的产品有重大的价值，就必须在客户和研发人员之间建立关系，很多研发团队往往不和客户或者业务建立良好的管理，也很少邀请客户/业务一起参与。

双方都必须承担一定责任，只有双方都承担责任，天平才是平衡的。任何产品都要满足客户和研发团队自身的期望值。要求和期望值最大的区别，即要求是有形的而期望确实无形的，最终评估实际结果是，依据的是无形的期望值，培养忠诚的客户和利益相关方意味着需要讨论需求和期望。
知道何时坚持、何时退出、何时走开以及何时逃离–项目经理必须具备这方面的商业头脑

---

创新

师夷长技以制夷，是魏源在其著作《海国图志》中提出的著名主张。
无数前辈努力扔掉的”东亚病夫“的帽子，却被蔡××之流成功的捡起来了。
据说收到很多人的追捧，这种创新不鼓励。

创新与优化不同：创新不拘泥任何形式，可以使新的产品、新的商业模式、新的流程、新的业绩。创新提供我们想象不到的产品，丰富着我们的衣食住行。

读书时曾听老师讲过“美国硅谷”是由IC组成，I就是印度、C中国，意思呢就是，美国人思维能力强，有好的点子，交给印度和中国程序猿去完成。
这也从侧面反映了一个事实，不过目前国人的创新能力那是刚刚的，新“雷神山、小汤山”首创世界之最。
吾辈仍需努力！

---

精益产品研发的引入
旨在去除浪费，提高价值。

---

简化流程，敏捷不是不做文档，敏捷提倡刚好够用即可，避免过度的会议、流程阻碍产品的研发。

---

要实现价值，就必须要求团队成员有卓越的技术，从SAAS、PASS、微服务等平台的兴起，技术从JAVA spring cloud、.net core等技术的出现，对实现产品的价值提供了最佳的保障。

---

写在最后“程序员的生活，往往是朴实无华 且枯燥！”