最近半年，公司开始自上而下推行敏捷开发，就像之前讲的，软件工程是分析问题、解决问题的一套方法论，我的理解是，敏捷开发也是类似的一套项目开发的流程或者方法论或者工具。
应该来说，公司的安排是比较系统的，也是符合人性的。从前期的概念传达，大规模的培训到，敏捷开发过程中收集一些反馈，再到后续概念的细化，让我逐步加深了对敏捷的一些理解。
在开发过程中，遇到了这样一个情况----最近的一个迭代周期（sprint）里，预定的四个feature，一个都没有完成，相比于往常的80%以上完成率，明显是有极大地反常。加上各领导们都在关于敏捷报表这块，因此，这个问题，在我们team被放大了。
在每个sprint结束的总结会议上，我作为team里的唯一一个开发人员，和PO,SM一起反思总结，理由有很多。PO主要是负责需要输入和制定计划，敦促开发完成feature，完成交付任务。SM主要是评估和监督工作是否能够按计划完成，一般由熟悉敏捷流程的开发负责人担任。member主要是做开发的任务。
1）时间被其他模块占用。
导致自己模块开始时间不能达到预期，严重影响了开发进度和交付。从这一点来看，之后开发过程中，一定要学会拒绝，要能够把控好自己与他人工作上的关系，不能当老好人。SM说的很有道理，帮别人干活，出彩了又不是你的，干的不好到可能惹得一身腥。哪怕是老板，也要看是不是老板真正想做的，如果是被迫找人解决问题，那也可以果断拒绝。
2）计划制定不够合理。
整个sprint的计划在开始时，未能合理地评估是否能按期完成。当然，在后来我和PO的争论中，我反思，PO是负责feature交付的，自然是期望feature能越早完成越好，所以，每个sprint开始安排计划时，一定要仔细评估每个feature的工作量，然后及时的给予反馈，制定适量的工作计划，而不能随PO添加feature。
当然，对feature本身也要尽可能的明确，不清楚的需要及时和PO确认，模糊不清的feature最好不要制定在计划里面，避免到时候无法完成目标。
简而言之，明确feature<->制定feature导向的计划<->拆分feature，评估工作量。
一切跟着PO走，关键时候吼一吼。
3）让架构拍板
我这边遇到的尴尬情况是，整个平台是一个全新的ICC gloabal项目，对于特定模块，架构一开始的理解可能不是那么深刻，尤其camera模块是需要特殊设计的模块，导致了我在安卓平台化的基础上设计的东西需要被推到重来。
这里主要讲的是在架构完成模块的架构设计后，一定要先跟他确认模块的框架设计图（主要是宏观的设计，比如模块架构图，部署图，组件图等），然后，在进行更精细的细节设计，比如类图、时序图等的设计，不然，很有可能白忙一场。所以，以后遇到类似的情况，一定要多次找架构review，让他进行确认，不能嫌麻烦。
网友评论