“敏捷”这个字眼包含的意义太多了。每个人理解都不一样，它到底意味着什么。我可以形容一只狗很敏捷。敏捷，已经退化为一种符号，只是人们谈论时的一种外衣，已经不具备任何意义。在软件开发范畴中中，敏捷不是终点，而是达成目的的一种手段。XP好？Scurm好？Lean好？FDD好？如果不结合到某一个上下文谈的话，都是瞎扯。敏捷方法学里边的各种实践也一样，对有些公司合适，有些公司不合适；有些团队合适，有些团队不合适；有些个人合适，有些个人不合适。也就是说，很少有人能说清楚，它真正适合的地方。公司里应该自己来实施，不要指望咨询师，他们没有你自己更了解公司和团队遇到的问题。既然他是context-oriented，我们还空谈它干什么呢？
我们能不能不谈敏捷，看看迷雾背后的东西。
1）团队气氛。
和谐的团队有共同的目标，每个人都积极沟通，主动反馈。在高兴时，一起疯；在悲伤时，互相支持和鼓励。反过来讲，如果一个团队中勾心斗角，推卸责任。有问题也不反馈，信息堵塞，一潭死水。再好的方法学，对这样的团队来讲也没用的。方法学不是包治百病的良药，它需要土壤，在越优秀，越开放的团队里越能发挥作用。如果团队的气氛很差，任何方法学都止步于此了，game over了。好的团队气氛，是每个人激情饱满，目标明确，干劲十足，用语言已经无法形容。
2）积极沟通
沟通永远不够。先不说沟通的激励作用，沟通最主要的是传递信息。现代社会分工明确，软件开发涉及到的角色太多了，各个角色彼此关联紧密。要完成一件事，需要多个角色紧密配合。如果信息有一点的错漏，都可能会影响相关角色的行为。比如，开发人员理解的需求和需求分析员理解的不一样，对功能的实现就走偏了。如果通过早期沟通发现还好，否则就在错误的道路上越走越远，返工成本越来越高。软件开发中的信息传递，往往都是控制行为的信息。知道不知道，做法完全不一样。理想的沟通是所有角色对同一个问题有一个共同的理解，讨论有一个共同的上下文。
3）持续关注
不是项目经理需要持续关注，也不是开发负责人，技术负责人需要持续关注。团队中的每个人，对团队中的问题都要持续关注。 只有这样，才能编织成一个密不透风的网，不使任何祸根埋下，消灭问题于萌芽之中。持续关注，该重构的时候就重构，不使软件腐化；持续关注，不断识别项目中的风险，建立风险环节措施；持续关注，互相提醒，保证每个人都在正确的方向上；持续关注，别人的问题，我能不能提供帮助。
4）持续改进
“改善，改善，再改善”，这是丰田生产方式的哲学。不以善小而不为，凡是能影响我们效率的地方，我们就要改；凡是能提高软件质量的做法，我们就要尝试。没有改变就意味着我们的失败，我们就会被竞争对手超越。实际上，真正的改善是一种思维方式的变革，是一种永不满足的心态，更是一种不断追求更高目标的自我挑战。它需要坚韧的态度，持续的努力，远大的理想，更需要踏实的步伐。
5）减少浪费
减少浪费是丰田生产方式的精髓，Lean敏捷开发方法学就出于它。因为信息传递不畅，会产生浪费。任务分工不合理，会产生浪费。bug不用说也是一种浪费。开会效率低，是一种浪费，这种浪费在很多公司都很常见。不断的打扰是一种浪费，是对注意力的浪费，它软件开发最昂贵的资源。
6）不要完美
完美的心态会束缚你实践的脚步。完美是一种过程，是渐进的。举例来说，不要等需求完全确定，才开始后续的沟通，确定部分内容，就可以开始沟通。从最简单可以看到结果的事情开始做起。好文章是改出来的，好的代码结构是重构，不断调整出来的。不要完美的心态，使你始终保持前进，在动态中思考，在动态中进步，在动态中矫正。
最后，我要说的是，个人是团队的基础，团队是公司的基础。软件过程要想起作用，必须以个人和团队为基础。否则过程就是个花架子，空中楼阁。看看国内的情况，ISO被做烂了，CMMI也被做烂了。听很多人说过，CMMI未使软件公司的效率和软件质量得到明显提升，却听到有些人说，它破坏了原有的节奏和实践，适得其反了。那么，这是为什么呢？我不是帮日本人吹牛，很多日本公司，ISO实施的效果就非常好，本质的区别就是人和团队的成熟，价值观的统一，企业文化的支持。
方法学不能机械的被实施，对待敏捷也一样。我并不喜欢严格按照XP，Scrum，Lean中的某一种方法学来实施，我喜欢把他们打散成最佳实践的粒度，去尝试，去反思，甚至去改造部分实践，看看到底哪些东西适合我们，哪些根本就不适合。最终让它们成为团队能力的一部分。
什么是好的项目管理,就是用最少的成本,最少的时间,最少的资源,来实现最好的质量，用什么方式,什么方法,都不必苛求
项目管理是一种实践。各种理论很多，都有这种理论的范围和实践的基础。但没有万能的理论。这些都是项目的特点决定。敏捷的特点中，有一点我觉得值得提及一下，那就是关注客户价值，和客户一起工作。
我们能不能不谈敏捷，看看迷雾背后的东西。
1）团队气氛。
和谐的团队有共同的目标，每个人都积极沟通，主动反馈。在高兴时，一起疯；在悲伤时，互相支持和鼓励。反过来讲，如果一个团队中勾心斗角，推卸责任。有问题也不反馈，信息堵塞，一潭死水。再好的方法学，对这样的团队来讲也没用的。方法学不是包治百病的良药，它需要土壤，在越优秀，越开放的团队里越能发挥作用。如果团队的气氛很差，任何方法学都止步于此了，game over了。好的团队气氛，是每个人激情饱满，目标明确，干劲十足，用语言已经无法形容。
2）积极沟通
沟通永远不够。先不说沟通的激励作用，沟通最主要的是传递信息。现代社会分工明确，软件开发涉及到的角色太多了，各个角色彼此关联紧密。要完成一件事，需要多个角色紧密配合。如果信息有一点的错漏，都可能会影响相关角色的行为。比如，开发人员理解的需求和需求分析员理解的不一样，对功能的实现就走偏了。如果通过早期沟通发现还好，否则就在错误的道路上越走越远，返工成本越来越高。软件开发中的信息传递，往往都是控制行为的信息。知道不知道，做法完全不一样。理想的沟通是所有角色对同一个问题有一个共同的理解，讨论有一个共同的上下文。
3）持续关注
不是项目经理需要持续关注，也不是开发负责人，技术负责人需要持续关注。团队中的每个人，对团队中的问题都要持续关注。 只有这样，才能编织成一个密不透风的网，不使任何祸根埋下，消灭问题于萌芽之中。持续关注，该重构的时候就重构，不使软件腐化；持续关注，不断识别项目中的风险，建立风险环节措施；持续关注，互相提醒，保证每个人都在正确的方向上；持续关注，别人的问题，我能不能提供帮助。
4）持续改进
“改善，改善，再改善”，这是丰田生产方式的哲学。不以善小而不为，凡是能影响我们效率的地方，我们就要改；凡是能提高软件质量的做法，我们就要尝试。没有改变就意味着我们的失败，我们就会被竞争对手超越。实际上，真正的改善是一种思维方式的变革，是一种永不满足的心态，更是一种不断追求更高目标的自我挑战。它需要坚韧的态度，持续的努力，远大的理想，更需要踏实的步伐。
5）减少浪费
减少浪费是丰田生产方式的精髓，Lean敏捷开发方法学就出于它。因为信息传递不畅，会产生浪费。任务分工不合理，会产生浪费。bug不用说也是一种浪费。开会效率低，是一种浪费，这种浪费在很多公司都很常见。不断的打扰是一种浪费，是对注意力的浪费，它软件开发最昂贵的资源。
6）不要完美
完美的心态会束缚你实践的脚步。完美是一种过程，是渐进的。举例来说，不要等需求完全确定，才开始后续的沟通，确定部分内容，就可以开始沟通。从最简单可以看到结果的事情开始做起。好文章是改出来的，好的代码结构是重构，不断调整出来的。不要完美的心态，使你始终保持前进，在动态中思考，在动态中进步，在动态中矫正。
最后，我要说的是，个人是团队的基础，团队是公司的基础。软件过程要想起作用，必须以个人和团队为基础。否则过程就是个花架子，空中楼阁。看看国内的情况，ISO被做烂了，CMMI也被做烂了。听很多人说过，CMMI未使软件公司的效率和软件质量得到明显提升，却听到有些人说，它破坏了原有的节奏和实践，适得其反了。那么，这是为什么呢？我不是帮日本人吹牛，很多日本公司，ISO实施的效果就非常好，本质的区别就是人和团队的成熟，价值观的统一，企业文化的支持。
方法学不能机械的被实施，对待敏捷也一样。我并不喜欢严格按照XP，Scrum，Lean中的某一种方法学来实施，我喜欢把他们打散成最佳实践的粒度，去尝试，去反思，甚至去改造部分实践，看看到底哪些东西适合我们，哪些根本就不适合。最终让它们成为团队能力的一部分。
什么是好的项目管理,就是用最少的成本,最少的时间,最少的资源,来实现最好的质量，用什么方式,什么方法,都不必苛求
项目管理是一种实践。各种理论很多，都有这种理论的范围和实践的基础。但没有万能的理论。这些都是项目的特点决定。敏捷的特点中，有一点我觉得值得提及一下，那就是关注客户价值，和客户一起工作。
284
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
