【敏捷开发】浅谈对Agile Scrum的认识

摘要: 从项目角度浅谈主流敏捷开发之Scrum。

今天是农历二零一六年腊月二十八，依旧工作日，周三，多云，但工作不忙碌了，继续在这里记录农历2016年最后一篇学习博客了，然后在这里提前祝各位新年好，大鸡大利过大年，工作顺利，心想事成，新的一年里更多新收获哦~~~[烟花]

说到敏捷开发，相信从起初的瀑布模型到XP以及到现在的Scrum，软件项目管理人员都是很熟悉的。瀑布模型作为经典理论是必学的，所以对此的认识也有一定的深度了，而作为一枚菜菜鸟，在浪潮之巅的交替之中已然错过了当年时尚前锋敏捷开发的极限编程，但核心思想还是敏捷核心价值，原则及实践，更简单，灵活适应变化，交流，透明。接触敏捷开发之Scrum也有一年多的时间，从开始实习工作第一个敏捷Scrum项目的前端开发到结合公司实际Agile项目增多而需求的Agile流程制定，对Agile Scrum也有了一些自己的实际体会，和资深的开发，测试，管理，质量前辈们一起讨论学习了很多，在此表达深深的谢意，谢谢。

有句话叫做理想是理想的，现实是现实的。就像是我们听过很多道理，依旧过不好这一生，类似地，Integrate theory with practice，理论结合实践，道理都懂，但是实际情况总是充满着不同的挑战。

（PS：对Scrum感兴趣的盆友可以先学习了解一下offical的基础理论：http://www.scrumguides.org/）

从业界理论框架上来说，Scrum的核心3+5+3及其他rules实施理想状态下项目肯定会及时交付，那项目管理理论就没用了，所以现实就是，项目管理十大模块中成本进度技术风险等控制是项目及时交付的要点。

在Scrum中有3角色6事件3工件，要求3角色组成的Scrum Team水平沟通交流，加强合作，以做到团队及时响应，灵活适应变化。Ｏ(≧口≦)Ｏ让我怎么来翻一下，验收下wuli双修英的果子[捂脸]。

3Roles: Product Owner（PO项目持有者，地头蛇登场，撒花），Scrum Master（项目经理，对是大哥大），Dev Team（开发团队，搬砖工人就绪，当然不限于此，如果还有BA，测试，DBA）（PMO）

实际中的角色肯定不限于这些，只是理论简单分为三个任务角色，为了更好地说明团队工作中的主要角色的透明沟通交流，追求平等合作，实际有PM和PMO的撕逼，以及Dev团队中测试开发之间的撕逼，以人为本的核心，对于企业来讲，敏捷开发有利于发展，而对于项目组来讲并不轻松，于管理方式极其重要，沟通交流更是重中之重的，所以这也是项目组在一起工作的原因。

6Events: The Sprint, Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospective, Sprint Refinement（官方现有文档中写到了前五个，但需求梳理的会议也是其中一个）

通常情况下，Agile Scrum的实施需要SM的有效监控才能将6事件落实好，才能更好地进展下一个sprint单元，实际中很难做到。举个栗子，Daily Scrum很多开发人员包括我之前也觉得好像是时间的浪费，但后来我们项目经理让我们每天站会，我认识到这确实有效的加强工作的，对于管理者来说也能很好了解项目当前状态，而实际中站会落实的项目组并不是很多，这也是质量监控中值得去关注的一点。

3Artifacts: Product Backlog（产品目录项）, Sprint Backlog（单元产品目录项）, Increment（可能调整的增量）(对项目中需求过程的管理)

项目十大风险，对于开发人员来说无疑是需求像不定时炸弹一样来个爆炸变动，特别UI全部推翻重来一次的时候，相信大多数开发内心是奔溃的，所以对于需求的管理，在Scrum中实际项目上很难做到说需求的freeze，所以只有项目经理（同BA人员）在分析需求之后对需求的把控是十分重要的。另外一个重要的点就是对于一个sprint里及时接受完成的产品目录需要PO的及时响应，也有利于开发进度的推进，其实也是站会可能带来的好处。

总的来说，敏捷开发的特点也正是offical理论中所写的......

Scrum is:

Lightweight

Simple to understand

Difficult to master

在项目管理和质量管理中，有很多相通的理论，而质量管理中涉及的点更细节些，不同的是，两者关注的工作点是不一样的，继续学习Agile Scrum方法结合CMMI高成熟度实施项目管理。

lalala..... 再次恭祝盆友们新年快乐，2017一起向前吧~

邮箱：guineverelemon@gmail.com