标签：制造 pre 进度 目标 nba 适合 应对 投资回报 开放
达尔文曾说过“留下来的物种往往不是最强的，确实最先进化的”，从传统的“瀑布式”到“迭代式”，最终再到敏捷型研发团队。无数组织、团队都在进行思考、变革。
研发团队一定要通过无尽的加班，才能交付产品，不能一边享受生活一边交付产品吗？
产品一定要尽善尽美后再推向市场，是否可以通过小的版本快速推向市场？
答案是可以的，是时候来场变革了！
在本系列，我将和你一起探索敏捷项目管理的知识和实践。
最终客户价值在销售时交付，不是在计划时交付。敏捷商业目标
持续创新
关起门来造轮子，已经无法适应当今复杂的商业和技术环境。开发产品和新服务都需要新意识。
特别是随着大数据、人工智能、工业互联、5G的发展，编程步入了一个高速发展的时期，从C语言到python，从低级语言到高级语言层出不穷，从成人编程教育到少儿编程的兴起，市场给了我们更大的机遇和挑战。
持续创新能力随着环境的变化显得尤为突出，当大家都在聊4G，5G已经悄然来临，快速占领行业浪尖--这就是持续创新的一种表现，带来的机遇和收益往往是巨大的。
创新思想并不会是模式化的、独裁的环境中产生，一定是在开发的组织、组织成员自我的约束下不断的适应当下的环境中产生。
产品适应性和缩短交付进度
产品研发周期越短、产品实施交付能力越快，仍然是项目经理和企业要优先考虑的企业目标。看起来似乎是矛盾的，产品研发周期短意味着缩小研发功能范围。
其实一点也不矛盾，我们有做过市场调查，70%的功能很少使用，频繁使用的功能模块只有20%，意味着我们付出大的代价，无法适应客户的需求，造成极大的浪费。
通过排除用处不大的功能，避免过度研发，减少总体工作量。精益研发的引进，简化开发流程、详尽的文档使其效率更高，将重点放在最有价值、增值的活动上，排除那些合规而无意的的活动上。最后，敏捷项目注重让每个成员都发挥其特长、增设防火墙杜绝无意义的打扰和压力从而提高研发效率。
人员和流动适应性
敏捷是一种思想、一种能力。其最终体现在团队成员的意愿上，组建一支适应能力强的团队--成员愿意自我改变、乐意突破极限而不是秉承固有的工作模式。
可靠的结果
质量是好产品的硬性条件之一，作为研发团队，交付质量可靠的产品，不仅可以鼓舞团队气氛，还可以扩大产品的附加价值。
敏捷定义
敏捷是一种思想、一种能力--敏捷最精简的定义
敏捷领导价值观
敏捷《相互依赖声明》中明确的阐述了我们的信仰，即核心价值观和永恒的目的。团队为何存在、要创建什么产品、为谁而而创造以及如何共同工作，这些组成了敏捷项目管理的原则。
一款优秀的产品背后一定有一个优秀的团队，一个优秀的团队一定是由优秀的人员组成，如何吸引留住优秀的人才，是当今企业普遍思考的问题。
最近网络上某某平台，运维人员因公司上级不人道的对待，一怒之下删库与公司同归于尽，事件导致该公司市值缩水几亿以上，对公司和人员、客户、社会造成极大的不良影响。--这就是传统型管理模式
相互依赖声明
通过持续为客户创造价值来提高投资回报；
通过不断地与客户交互、共享所有权限来交付可靠的结果；
预测不确定性，并设法通过迭代、预防、适应来应对不确定性；
个体价值是团队价值的源泉、创建个体卓越的环境，实现创造和创新；
通过激发成员的使命感和责任感来提高团队的绩效；
通过使用根据具体情况而定的策略、流程和做法来提高效率和可靠性。 敏捷型领导的价值观念：仆人式领导是一种非常社会化的领导风格。虽然传统的领导力是关于“金字塔顶端”的人积累，囤积和锻炼（通常会堕落为滥用）权力，但仆人式领导是与团队分享权力，识别，优先考虑和满足他人和帮助人们尽可能地发展和表现。
仆人式的几个特性
总结：Scrum Master 采用仆人式领导需要将团队的需求放在首位。仆人式领导者主要关注团队的成长和福祉：首先为他人服务，对于希望在团队成员中发挥最大作用的现代管理者来说，仆人式领导是一个强大的工具。
敏捷项目管理架构
构想、推测、探索、适应、结束
敏捷架构过程
**总结
敏捷管理是最新出现的吗？不是，在2000年左右已经出现了。敏捷项目管理通过--做法、价值观、原则、概念架构组合形成了敏捷项目管理，继承了项目管理的丰富遗产，取其精华去其糟粕；敏捷也吸收了丰富的管理、制造、软件研发理论和时间经验（精益产品开发、KanBan等等）融合了最适合激动性和速度的世界观和思想体系。
敏捷项目管理并不是适用于所有人和所有项目，不是万事通的最佳实践**。
标签：制造 pre 进度 目标 nba 适合 应对 投资回报 开放
原文地址：https://blog.51cto.com/14082130/2474684
