敏捷开发烦恼的诞生以及如何解决

　　Scrum敏捷开发，带来的不仅仅是敏捷，还有理不清的烦恼。
　　最近公司开展的Scrum敏捷开发，几个Sprint下来，碰到了很多烦恼。
　　比如说：碰到有改交互原型图，改视觉设计稿，改代码的情况，因为SPMeeting（周期计划会议），就没有考虑到交互原型图和视觉设计稿需要改几次，bug需要修几次，所以碰到这种情况，一般需要加班或者放到下个sprint再做计划。
　　又比如：本来1天可以完成的工作，但是需要计划成23天去安排，因为在某一个sprint之内，在项目的某一环节上，确实是没有什么事情可以安排的。总不能在计划上写：“1天上班，2天自由活动。”另外，在DSMeeting（每日站立会议）上，要求每个团队成员，都需要口头说一说自己昨天的工作进度，今天的工作计划。这个时候，有些同事，只能编造一些无关紧要的事情，或者把1天可以完成的事情，分成23天来汇报，因为他这个环节，这几天本来就没什么事做嘛。
　　再比如：临时有加急事情，需要下单的时候，同事之间就用SBacklog（周期工作列表）来拒绝工作。“这个sprint计划里面没有这个任务啊。”所以，本来需要加急的任务就这样被拒绝了。这时候，只好放到下个sprint再弄，或者自己加班做。其实，本来只需要在1天的工作时间里，挤挤时间，这个急单，就可以完成了。
　　下面先介绍一下Scrum敏捷开发的流程，然后再针对上面的这些烦恼，提出我个人的改进方案。
　　什么是Sprint？
　　Sprint是短距离赛跑的意思，这里面指的是一次迭代，而一次迭代的周期是1个月时间（即4个星期），也就是我们要把一次迭代的开发内容以最快的速度完成它，这个过程我们称它为Sprint。
　　如何进行Scrum开发？
　　我们首先需要确定一个ProductBacklog（按优先顺序排列的一个产品需求列表），这个是由ProductOwner负责的；
　　ScrumTeam根据ProductBacklog列表，做工作量的预估和安排；
　　有了ProductBacklog列表，我们需要通过SprintPlanningMeeting（Sprint计划会议）来从中挑选出一个Story作为本次迭代完成的目标，这个目标的时间周期是14个星期，然后把这个Story进行细化，形成一个SprintB
　　SprintBacklog是由ScrumTeam去完成的，每个成员根据SprintBacklog再细化成更小的任务（细到每个任务的工作量在2天内能完成）；
　　在ScrumTeam完成计划会议上选出的SprintBacklog过程中，需要进行DailyScrumMeeting（每日站立会议），每次会议控制在15分钟左右，每个人都必须发言，并且要向所有成员当面汇报你昨天完成了什么，并且向所有成员承诺你今天要完成什么，同时遇到不能解决的问题也可以提出，每个人回答完成后，要走到黑板前更新自己的Sprintburndown（Sprint燃尽图）；
　　做到每日集成，也就是每天都要有一个可以成功编译、并且可以演示的版本；很多人可能还没有用过自动化的每日集成，其实TFS就有这个功能，它可以支持每次有成员进行签入操作的时候，在服务器上自动获取最新版本，然后在服务器中编译，如果通过则马上再执行单元测试代码，如果也全部通过，则将该版本发布，这时一次正式的签入操作才保存到TFS中，中间有任何失败，都会用邮件通知项目管理人员；
　　当一个Story完成，也就是SprintBacklog被完成，也就表示一次Sprint完成，这时，我们要进行SrpintReviewMeeting（演示会议），也称为评审会议，产品负责人和客户都要参加（最好本公司老板也参加），每一个ScrumTeam的成员都要向他们演示自己完成的软件产品（这个会议非常重要，一定不能取消）；
　　最后就是SprintRetrospectiveMeeting（回顾会议），也称为总结会议，以轮流发言方式进行，每个人都要发言，总结并讨论改进的地方，放入下一轮Sprint的产品需求中。
　　针对本文开篇提到的烦恼，我在这里总结了3个针对性的方案。
　　1。在计划会议的时候，需要给交互设计师预留改原型的时间，给Ui设计师预留改视觉稿的时间，给开发工程师预留修bug的时间。比如：Ui设计师，平均改稿次数，为3次左右。一次就能定稿的情况，几乎不存在。
　　根据【Ui中国】发布的《UIweek6》杂志上的一份《上海Ui设计师工作现状调查》显示：一般从产品初期到产品上线所需要修改次数的比例为：改稿46次的情况占41，改稿13次的情况占40，改稿79次的情况占7，改稿10次的情况占12。为了避免后期要求Ui设计师改设计稿的时候，Ui设计师因为怕加班而不改，或随便修改应付了事的情况，我建议需要在计划会议的时候，把修改的时间，预留到计划里面。这样，Ui设计师就可以大大方方的改。
　　2。当临时有急事，需要布置加急任务的时候，一般就拖到下个Sprint去了。为了避免这种情况，我建议在计划sprint会议的时候，预留出210的时间，作为临时任务的预留时间。这样，有任务需要加急的话，就可以大大方方的给出时间嘛。
　　3。关于SprintStar的评选，一般情况，优先被选中的是，谁加班多，谁在这个sprint我接触比较多，谁被选中的机会就大。这个标准，我建议改成：谁可以在完成这个Sprint任务之外，多做一些Sprint计划之外的事情，就尽量选谁。
　　以上是我最近在敏捷开发的实施过程中，碰到的一些烦恼和推荐的方案。具体实施过程中，需要综合这4种（瀑布式开发，迭代式开发，螺旋开发，敏捷开发）开发方式的优缺点，来运用到具体的项目当中。这样，敏捷开发就可以做到取长补短的效果。