敏捷开发初体验（下）
Posted Ann进化论
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了敏捷开发初体验（下）相关的知识，希望对你有一定的参考价值。
上周终于完成了敏捷开发的Sprint 1，过程不算坎坷但也不算完美，有收获也有反思。关于敏捷的几点思考如下（按三个角色、三个物件、四个会议的思路展开）：
Scrum角色之：Product Owner
Product Owner 负责定义、指导产品的开发方向，为团队创建待办事项列表，或者与团队共同创建。这个角色往往需要拥有相关的工作背景，会为决策提供丰富的专业知识技能。
之前有提到，在我们团队中我担任这个角色。从以上定义中可以看出其实我是不满足作为一名PO的条件，毕竟自己还是一个无知又无能的小白。因为这个因素，自己在按用户故事进行描述需求，所写需求不清晰也不够确定，开发的同事开发需要反复确认，经过他们几个反问之后就我又开始动摇不定。或者对于他们的质疑我不为所动，最后导致这个功能一点都不正路。
除专业素养之外，还有几个点也是我在作为PO做得不好的：
1.由于不重视文档，使得文档既无规范可言，也无保存价值。最无奈的是测试完全不能根据文档进行测试，需要再次与我口头确认。敏捷强调高效的沟通，但是多次重复同一话题，无形之中浪费了时间。
2.由于自己有轻微的强迫症，与一任务相关的任务我都会莫名希望一次性做完，所以多次致使故事被扩大，工作量也因此增加。这一点会导致Sprint的周期被拉长，该完成的任务不能及时完成，从而使士气低落，效率变低。
3.作为PO，没有第一时间对开发完成的功能进行体验。因为自己一度认为团队有测试，所以自己就没有必要去检验开发成果。因为敏捷最后会有评审会议，需要进行成果演示，自己在评审会前一天才开始了解开发成果，导致某些开发问题最后时刻才被发现。
Scrum角色之：开发团队（摘录大家的言论，仅供参考）
1.工作量评估不够准确，工作时间偏差较大。大的用户故事在拆解任务时需要更细化。
2.开发环境与测试环境及以后的正式环境理论上应该一致，但实际上却有区别导致一些未知问题，暂未发现其中缘由。
3.团队在Sprint中还需要不断修改生产环境中出现的BUG，不能专注于Sprint的任务。
4.因为上一次开发任务结束后测试量很大，测试人员后期才投入Sprint工作，测试工作滞后。而如果测试能第一时间投入Sprint任务中的话，最好能做到测试前置，开发完成一个story或者一个task就要开始测试。
5.敏捷迭代应更多强调Team，不应过多强调职能部门。例如，并非所有的需求都必须由产品决策，开发或测试也葆有发言权。
Scrum角色之：Scrum Master
Scrum Master 负责确保 Scrum 被理解并实施。为了达到这个目的,Scrum Master要确保 Scrum 团队遵循 Scrum 的理论、实践和规则。
他既是团队促进者，也是一种仆人式领导，需要引导、指导和消除障碍技能。
Product Backlog
Product Backlog其实应该是根据市场反应及时更新，但是自己没有一个统一的表哥。仅作零零散散的记录。到计划下一个Sprint故事时，对之前的记录不能完整的回忆。
现在总算明白了什么是需求池，Product Backlog其实可以作为需求池随时保持更新。
Sprint Backlog
Sprint Backlog在Sprint中没有擅自删减，实际如果有新增故事进入这个Sprint，按照时间盒的概念，需要对故事进行优先级排序，加入新的故事，则最好对应移除优先级较低的故事。
实际上PO扩大故事范围也会影响这个物件，所以尽量不要随意进行扩展延伸。
燃尽图
没有画燃尽图，每天SM会记录大家的剩余工作时间，相对燃尽图而言，更精细，却不够直观。
Sprint计划会议
通过计划会议团队需要明白以下两个问题：
1. 决定需要完成哪些工作？
这时需要产品负责人向开发团队介绍排好序的产品待办事项，由整个Scrum团队共同理解这些工作。Sprint中需要完成的产品待办事项数目完全由开发团队决定。做多少工作只能由开发团队决定，产品负责人或任何其它人都不能给开发团队强加更多的工作量。但是实际上在这个点上我们有些被产品需求驱动，而非仅考虑开发团队的实际能力。
2. 决定这些工作如何完成？
开发团队需要根据当前的“完成的定义”一起决定如何实现下一个产品增量。他们需进行足够的设计和计划，从而有信心可以在Sprint中完成所有工作。而由于我们在任务拆分环节就已经出现不足，所以在这一环节也有较大偏误。
每日站立会议
1.由于团队的特殊性，我们不能完全称之为集中办公。一周会有一两天时间敏捷教练与我们异地办公。致使站立会议没能如时如期召开。
2.还是之前提到过的问题，不过现象明显好转——会议期间跑题，使得会议时间会超出15分钟的设置。
3.会议大家仅口述自己的三个问题，其他队员对口述内容不够清晰直观，建议使用白板。或者及时更新TAPD任务状态。
Sprint评审会议及回顾会议
这两个会议就放在一起进行描述了，因为实际上我们几乎算是一起开的。首先用将近两个小时进行DEMO演示，然后大家就这次Sprint进行回顾总结，包括但不仅限于团队在流程、人际关系以及工具方面的回顾总结。
1.DEMO环节的问题前文有提到，作为PO没有及时跟进开发进度及结果。临时准备DEMO演示可能是评审会议最大的败笔。
2.关于DEMO大家也有发表意见，提出一些需要跟进优化的点。下次Sprint这些点可以在Sprint中就完成，不用遗留至下一个Sprint。
在回顾会议中，大家除了提到上述不足，也有分析敏捷的优点。
1.大家的工作更加透明，每天都能了解到自己队友当下的工作。尤其对于产品而言，在开发中的参与度明显提高。
2.告别厚重的需求文档，增加了沟通，促进团队的良性合作。
3.开发人员每天的工作目标更加清晰，提高了开发的自由度和开发效率。
4.同时经过回顾会议这一次的深入交流，大家更加清晰自己的成长及不足，对下一个Sprint更有信心。
啊！我这该死的拖延症，晚安！
每期箴言：
上下同欲者胜。
——孙武
以上是关于敏捷开发初体验（下）的主要内容，如果未能解决你的问题，请参考以下文章