《敏捷开发》阅读笔记2

《轻松Scrum之旅》这本书主要是以关毅团队的实例来展开对敏捷开发的讲述的。

在读这本书前，已经对敏捷开发有所耳闻。相比于传统的项目管理，敏捷开发更注重的是灵活与跟随计划的变化而变化。

最开始我以为的敏捷开发是以团队展开的，所有人都有决定权，带入过以多数否决少数这样的结论。看完书才发现这种做法的害处。轻松之旅书中提到过一个游戏，叫做计划扑克。充分地解决了我的疑惑。

当一个团队没有Product Owner的时候，大家更喜欢用扑克牌的办法来解决问题，可是在实际操作中，当谁也说服不了谁的时候，大家更喜欢用少数服从多数的方法作出决策，但事实往往是真理掌握在少数人手里，这些人在少数服从多数的情况下没有机会表达自己。

以上这段话出自轻松之旅这本书。确实，当大家意见不合时，往往会采取少数服从多数这种简单粗暴的手段，但是这样的手段并不能真正的解决问题，只会使眼前的问题得以暂时放下，很有可能之后付出更多的代价，甚至于这个办法本身就不是最优化。

以上所述，其实就是想说一个团队，不论多么敏捷也是需要一个Product Owner的，只是说他的职责可能不像一个领导，更像一个有一些决定权利的合作伙伴。更注重提醒与帮助，而不是命令和掌控。

“我们经常会发现时间不够用，尤其是在争论比较多的时候。所以 Scrum Master一定要控制好时间，避免偏离方向的争论。如果真的时间不够用，也不要应付了事，可以另找时间讨论。但我建议最好不要这样。”
这是原文中David对于扑克计划给出的建议。

在这里插入一个老师在课堂上提出的问题，那么传统的项目经理和Scrum Master的区别在哪呢？

整理了网上的回答以及自己的思索，大概被概括为：1、传统的项目经理扮演的角色是项目的领导者、决策者、计划者，他是负责达成项目商业目标的人。而Scrum Master扮演的是教练、引导者、训练者的角色，他负责Scrum流程在团队中能够正常实施和执行。2、传统的项目经理负责团队成员具体任务的分工，而Scrum强调的是团队的自组织，自我管理，Scrum Master很重要的内容是帮助每个人的能力提升，不负责实际工作内容。

那么曾经的传统项目经理适合当敏捷管理的master吗？答案大概是不一定，传统的项目经理更注重的是更为细微的管理，无法实现真正的团队自我管理，他们关注的重点可能更多在签收以及跟进上，以确保团队可以按时交付承诺的产品。

但答案是不一定，并不是不可能。项目经理如果具备开放的心态以及如果团队对这次转变做好了充足的准备，那么想要实施敏捷，大概也是磨合上会花费的时间比较多，最终还是能完美的转变成敏捷的Scrum。

接下来敏捷开发这本书讲述的最多的就是每日例会的问题。每日例会是敏捷框架里的一大特色。每日例会的具体规则有，根据团队是否跨国，上班时间等性质规定例会开始时间，例会开始后，大家都站着一起发言，会议基本在15min左右结束。由Scrum master主持，总的来说会议内容大概被概括为三个内容：（1）昨天我完成了什么工作？ （2）今天我打算做什么？ （3）我遇到了什么障碍？

关毅团队第一次召开会议时花了1小时左右，这样做是不好的，解决其他问题应该单独找专门解决问题的时间。站着开会就是为了防止会议时间过长，时间过长不仅达不到了解进度的效果，反而会让大家感到疲惫！所以得注意时间。而每日例会之所以不可取代则是因为每日 Scrum 会议的团队所有成员都通过这个会议同步信息，每天的问题都能及时发现，并能用最快的速度解决。另外，能够形成一种相互之间的压力，每个人要对自己当天承诺要完成的事情负责，每天都不敢怠慢。Daily Scrum 给整个团队带来了凝聚力，每个人都觉得自己是团队不可缺少的一员。

总而言之，以上所述的这本书更像是在分享一个成功的敏捷案例吧，通过过程告诉我们一些可以避免的错误。而另一本《硝烟中的Scrum和Xp》更注重于方法，按照敏捷思想的方法对里面的步骤加以描述与解释。先看第一本能更多地了解到，哦！原来这就是敏捷带来的好处，接着看第二本就能知道，具体要怎么做才能实现敏捷。

说了那么多敏捷的好处，那到底什么样的项目才适合敏捷思想呢？（这是老师课上提出的另一个问题）。课堂上根据大家对敏捷的理解，认为复杂的项目也许适合，因为对复杂的任务进行拆解，也能将复杂简单化等等。老师又问，那操作系统适合吗？

其实，在复杂的项目之中。敏捷的意义并不大。复杂的项目应该在开始阶段就多多考虑完善，多在架构方面留有余量。而敏捷的特点则在于尽快给出客户一个可用的功能。但是操作系统极其复杂，很容易考虑欠缺，如果按照敏捷来做，很有可能适得其反。最适合敏捷方法的项目是那些有着激进的时间期限限制，那些有着高度的复杂程度，以及那些有着高度新颖性（独特性）的项目。