网站地图
【www.arisingsemi.com--软件系统】
醍醐灌顶怎么读 读Scrum 敏捷开发的入门书籍有感1210400631 温源
首先很高兴老师向我们推荐这份文档让我们阅读了解，因为作者别具一格的写作手法让我感觉就像在读一本小说一样，仿佛看到刚毕业的自己会和书中的男主人公有一样的遭遇以及经历。所以每当男主人公遇到很多棘手的问题的时候自己也会考虑，如果换做是我，我会怎么办、我该怎么办。相对于教科书的枯燥乏味，这本书真的是抓住了读者最想要的东西，使我受益匪浅。
说到软件开发，我们也是这一学期刚开了《软件工程方法与实践》这门课，本来完全没有概念的东西经过一段时间的学习脑海里好像逐渐形成了一些关于软件开发的模糊的概念，但说真的看完这份关于Scrum敏捷开发的文档以后，真的是感觉醍醐灌顶。
之前已经讲过了作者新颖的写作手法，就作者自己的话来说，“本书的创作完全是由 4 位作者共同完成的，整个写作过程也是敏捷的：迭代、自我管理的团队、有条不紊的进度节奏、期间收集潜在读者的反馈继而调整本书的内容。我们惊喜地发现：敏捷思想真的有效，而且不仅仅是对软件开发。
”读到这里的时候我很好奇，究竟是怎样的一种开放方法，作者竟然可以吃透到将其利用到本书的写作过程中，相对于传统的瀑布式开发究竟会有哪些不同。这些都是题外话，接下来想谈谈我从这本书认识到的新的东西。为什么说是新的东西，因为其中有的之前接触过，但是并没有吃透；当然现在也不能说完全吃透，但最起码是有了新的理解在里面。
边看书的同时遇到很多问题，我通过百度百科查阅了很多词条，收获不菲，在文章最后我会把链接附上，希望能够读这篇文章的你有所帮助。
我们先来说说关毅（书中男主人公）为什么会离开他的老东家(也就是他刚毕业就把自己的理想和热情寄托给它)X公司。男主经过几年打拼，成为开发部的Team Leader，辛苦经营却还是抵不过最后的心灰意冷。X公司采用传统的瀑布开发流程加上 CMM。 组里百十来号人，需求、设计、编码、测试，人人各司其职。流程上是一环 套一环，文档也是一堆一堆的。
而实施上，就例如F4 产品组采用的是高压政策，从 上到下，每个月都用绩效考核，让每个人的弦都绷得紧紧的。传统的瀑布开发流程需要大量的迭代，工程量大到什么程度，当你们齐心协力把用户给出的第一个版本做出来以后，由于时间太久用户又有了新的需求，又要花费大量的时间和精力投入去修改，完善，为了赶工可能代码的质量大大下跌。最终客户不满意，导致尾款不能及时付清，公司利益不说了，员工的积极性也被打压。
如此反复循环，恶性循环下去，迟早员工的流动性会越来越大，何谈业绩。何谈效益。
总之就是等级森严的管理层次，瀑布式的开发流程，中国式的 IT 企业管理文化这“三座大山”一样挡在作者的面前，让作者难以挣脱束缚，大展身手。
作者一次偶然得空的同学聚会让作者有了跳槽寻找更好发展的想法，也正是这次机遇，作者才能认识除了传统的瀑布式开发流程以外的敏捷开发流程。E公司的面试，作者的应聘之类的就一笔带过了，因为作者毕竟是有了几年的开发经验，而且还是任职过team leader 的大牛。任职之后，重要的是作者研究敏捷开发流程的过程，从一个熟悉传统开发的项目经理要转变成一个Scrum敏捷开发的Team Leader也是要经过一系列培训的，作者还去了E公司的国外总部进行了为期两周的学习。
两个礼拜像我们这种小白去应该什么都学不到，而作者是个大牛，所以收获满满的就回国了。
就算是大牛，也还是遇到了很多突发情况。
要是没有培训他的David和外国总部的Leader peter帮忙，作者肯定没有这么快速的进入敏捷的状态。所以说这里真心的说个我的体会，无论是在大学生活中，还是在以后的职场生涯里，人脉真的是很重要的，作者虽然没有在书中提及，但是细心读书，就会发现作者的各种机遇其实都是作者积累的人脉发挥了一定的作用。
这里简单提一下，只是我个人看法。
E公司不愧是外企，让作者自己选自己的开发小组，这点真的好让人羡慕，而作者也是综合了敏捷开发的特点为自己挑选了几位得力助手(看到这儿的时候我都想去啊o(*￣▽￣*)ブ)。在敏捷开发流程中我特别关注了一个点ScrumWorks。这个在敏捷开发流程中使用的工具在小组成员和Leader之间成了一个桥梁。怎么说呢，Leader就像是网游中的npc，通过ScrumWorks向外发布这起Sprint的任务，而项目小组成员通过ScrumWorks挑选自己觉的自己感兴趣也能胜任的任务，ScrumWorks要求小组成员每天花十五分钟左右更新一下，这样Leader就能清楚地知道大家的任务进度以及对任务完成时间概念的把控。这点真的是让我很向往。
当然尽管作者参加培训，请教大牛但还是避免不了许多问题的出现。
印象比较深的是作者第一次开Scrum会议，以为按照敏捷开发流程，会议应该十五分钟左右，所以都是要求大家站着开会，而作者第一次整整开了一个小时。
开始不以为然的作者在请教David
以后，慢慢开始压缩自己的会议时间。会议本应该由 Scrum Master（作者） 主持，Scrum 团队的所有成员轮流回答以下 3 个问题。
（1）昨天我完成了什么工作。
（2）今天我打算做什么。
（3）我遇到了什么障碍。但是作者和小组成员没有针对这三个问题展开会议，而是将自己在编程，检索框架过程中遇到的问题带到了本应简短的会议上，这点最让我记忆深刻。这真的是万事开头难，看到这里的时候真的是和作者共进退的心理，文章很容易把自己带进去。在经过一系列搭建编程环境，还有和调试部门沟通，以及探明弹Sprint1的成功，作者似乎在敏捷开发的路上也越来越顺利。但这个时候还是出现了一个小插曲，就是作者觉得小组成员都比较忙，所以自己一个人参加了远程会议制订了下一阶段的Sprint2，虽然是他们的 Team Leader，但是毕竟一个人的作用是 有限的，而且团队成员的意见往往更具有代表性和针对性，一个人不可能 面面俱到。要时刻记住，在敏捷的理念里面，一直都在反复强调自我管理的团队，要淡化层级观念。Sprint 任务的选择，主要决定权属于团队。需求都是 从 Stakeholder 那里来的，而 Stakeholder 包括了客户，管理层，还有自己。Product Owner 有权维护产品 Blacklog，而 Scrum 团队有权从 产品 Backlog 中选择适当的任务作为 Sprint Backlog。所以，由 Product Owner 一个人完全主导是不对的，应该参与到讨论需求和计划的活动中。这次的失误对作者的触动也很大，他亲自向小组成员道歉，好在事情最后得到了很好的解决。
最后我想再说说作者遇到上司的追问进度是怎么解决的，我觉得值得很多人学习。
作为一个Team Leader ，作者并没有向领导说自己小组的进度有多么多么快，质量有多么多么高，而是丝毫没有隐瞒整个小组在开发过程中遇到的问题以及可能遇到的障碍。不要隐瞒团队的技术实力，否则很难做切合实际的计划和评估。
领导也并没有催进度，而是根据作者很实际的反馈将能够扫除的障碍扫除，将整个项目的时间和进度再做分析。
我觉得这大概也只能是在外企中才能拥有的企业文化吧，在国内很多的企业中很多Team Leader很难做到像男主这样用事实说话，用实力说话。
我觉得这也是自己在读完文档后的收获之一，不欺上瞒下，不谎报邀功，最后整个项目出了大的问题，谁能负责的起。
读完文档，我觉得无论是哪种开发流程，作者有很多品质也是要借鉴的，当然男主的经历真的是特别宝贵的参考案例，如果自己在以后的工作中，也会面临那么多的问题，是不是能像他一样充分利用自己已经掌握的技能为团队，为公司带来最大的效益，实现个人的社会价值。
敏捷开发流程自己接触的时候能有男主那么得心应手吗。在以后，我无疑还要面对很多问题，但这份文档无疑也会是我解决问题的宝贵文献。
最后，再次感谢老师的推荐。
参见链接：
1. /link?url=4VmdLDpd44y3TYZ2c8eJla-dEshlpQDQVzwxzkbGf2lCeex-9aTfkDi88-snNiVKS0RdL5BP2nqRUCphp7tFD_
2. /link?url=BEXbZTkjBfC6k0_sCpgaGtOX5_cPV8JXkiKXpyEyzOFXndJw5rZCHO8lQooSLZAAEA_qmK51CpcMQA9sp18G5K
3. /link?url=VobYzBxNEWO03_6LM1vEAMWNxdmWmkElsnvlp_JTHUbVGTJDqT2ccoecxeOBzLM40U7An9UaoP-7jUq64gSY2q
4. /link?url=q_QYSnowmZUdegiX5-TIgi8iwB2n959j7CTULzCf6XlTZvT5w9dIXoM_27IRHI_Py9Fp2-gxqI4DE7ht-4LOJK
5. /link?url=G4GWe0fouItVj6W_mBVcY-jbGb0ys_18NuKl3YQPrlp5LsCX65NETydClD8_gjAR。