【2012年5月18日】
总结一下回顾会议怎么开
0.回顾上次会议中的问题top3有没有被解决
1.会议的目的是回顾过去的一个迭代，顺便发泄发泄。
2.会议内容包括但不限于表扬、批评（如case study）、叙述、吐槽、抱怨、bui等，总之想说啥说啥，大家畅所欲言
3.会议主持人讲上述话题记录到亮点、问题 以及疑问三个象限（如果有百事贴，大家写好自己贴上去，再一个个过，这样大家就更没有什么不好意思说的顾忌了）
4.投票选出最关注的三个问题，给出解决方案，分配到人头。
附上智优迭代四回顾会议会议纪要，附件可作为模板。
【2012年5月3日】
1. 质优在敏捷中的 code review 的尝试
发起 code review 的条件：单测、手工测试、集成测试完成；
每个 Story 必须有一个 Task 是 CR，每次 CR 流程，都需要标注 Story 号；
提交 Code Review 的时机为向 svn 提交代码后；
RD提交 Code Review 时，将模块负责人做为第一评审人(邮件的第一个收件人)，各模块负责人见后，第一评审人需要发表 Code Review 意见，其它评审人可选；
code review完成 作为 story 放到待测试的必要条件之一；
站会时分享 CR 过程中遇到的问题、心得等。
【2012年4月26日】
经过不断地沟通和努力，已和 RD 达成以下一致：
在敏捷开发中，为保证提测质量，QA、RD 应完成以下要求
a) ＱＡ将提测ｓｔｏｒｙ的验收条件分为两部分（ａ．新增功能、ｂ．原有相关功能）
b) ＲＤ提测之前，需保证所有验收条件全通过，否则视为提测质量不合格，产生的ｂｕｇ在迭代回顾会议中进行总结学习。
c) ＲＤ提测之前，需保证验收条件中所有新增功能的ｓｅｒｖｉｃｅ层代码，都被自动化集成测试ｃａｓｅ覆盖，若有特殊情况，提测时需做特殊说明。若ＱＡ ｒｅｖｉｅｗ时不满足新增功能全覆盖，将在迭代回顾会议上进行ｃａｓｅ ｓｔｕｄｙ。
【2012年3月31日】
拉release branch的时机
之前提到过，在上线之前，会有一个code frees环节，从主干上拉出一个release branch（简称RB），用于本迭代的上线。
RD继续在主干上开发下一迭代的story，QA在此RB中回归本迭代的内容，测试上线步骤。
原则上不在RB中的story，不会在code frees之后check in，也不上线。RB中修改的内容，仅为本迭代bug的修复。
那么，拉RB的时机什么时候最合适呢？
【RD的观点】
开发完本迭代的所有stroy，马上拉RB，这样RD能随时提交后续迭代的代码到主干，并行开发，提高效率。
【QA的观点】
在所有story都移到QA sign off区后，再拉RB，因为拉RB后，对于QA来说，所有RB上的代码提交，都会merge回主干，需要QA测试，QA的工作量会double。
【分析】
Q1：在主干上开发还是在RB上开发？
主干上开发，减小大量merge产生的风险；发布时用分支，便于追溯问题。RB中修改的内容，仅为本迭代bug的修复。
Q2：拉RB的目的是什么？
RB用于上线，如果不拉RB，所有RD都不能提交代码，会降低开发效率。
Q3：什么时机拉RB对团队最有利？
根据敏捷的经验，在所有story都移到QA sign off区后，再拉RB（符合QA的观点），因为RB拉得太早，QA的工作量会double，敏捷周期本不太长，测试和开发在stroy间也是并行的，因此开发完所有story的时间点和QA测试完所有stroy之间的时间不会很长，因此原则上在所有story都移到QA sign off区后，再拉RB，如果情况特殊，也要等QA大致过一遍stroy后，QA点头后再拉RB。否则RB上提交次数太多，工作量和风险都相对较大，拉RB的意义就不明显了。
【2012年3月28日】
智能账户优化项目涉及到的自动化测试case分类
| 类型 | 范围 | 评估 | 负责团队 |
| 单元测试 UT | 函数级 | 逻辑覆盖率--代码行 30% | RD |
| 集成测试 IT | 模块间接口 | 接口覆盖率（QA 度量方法？？） | RD主导，QA review |
| 系统测试 ST | 系统 | 功能覆盖率（主线覆盖） | QA |
其他维度分类：
- 按模块分类；
- 按重要性分类：H\L
- 按照依赖分类：外部服务依赖，数据库依赖，独立；
Quick test\Slow test 分类:
quick
所有UT，IT（前期为了提高运行性能，可选重要性H，依赖为：独立、优化后的数据库依赖），ST（H？优化后）
slow
剩余所有test
原则上我们不分quick slow test，每次提测尽量运行所有testcase。但是考虑到运行时间等因素，我们目前采取分quick和slow的策略，放在quick里面的testcase一定是重要的，性能好的，随着性能优化，我们放进去的testcase会越来越多。
【2012年3月26日】
【story状态】
story #A未开始
story #B未完成
story #C已完成
story #D~#N已完成
【案例描述】
1. 在定期上线的时间点，PM又十分希望#B能上线，想将上线日期后延，于是延后2天。
2. PM认为#A和 #C最好一起上线，方便推广，于是想将#A做完后再上线，于是提议再将上线日期后延一周，但由于FE在此周请假，无法完成#A，于是PM想取消此次迭代上线，将本迭代和下一迭代内容合并一起上线。
3.QA否决这一提议，和PM PK，最后大家达成一致，#A本迭代不上线，其余story上线，上线时间延后两天。
【案例分析】
Q1：能否调整上线时间？
从敏捷的的经验来看，如果团队足够成熟，上线周期越短越好。
但是从目前的团队状况，以及项目情况和上线成本来看，控制在两周一上线比较合适。
上线时间点可以调整，如上面提到的：如果团队足够成熟，上线周期越短越好。但如果要向后延，除非现有的个别高优先级story需要尽快上线，否则对项目和团队都不利。不允许PM在临上线前随意插入新需求，然后向后延上线时间。
Q2：随意调整上线时间会造成哪些风险，以及不良影响？
1.项目质量。
上线周期拉长，每个story的完成时，可能就很难达到上线标准，上线的风险比较大，上线story较多，上线后定位问题也会变复杂。
2.研发模式。
如果随PM意，想什么时候上线就什么时候上线，随时都能插入新需求来打断现在的发布周期，那么敏捷就可能会慢慢退化为瀑布。
【2012年3月22日】
今天测试工作比较正常，总结一下燃烧图：
| 实践名称 | 燃烧图 |
| What | 燃烧图（burn up chart）是在项目完成之前，对需要完成的工作的一种可视化表示。燃烧图有一个Y轴（工作量）和X轴（时间）。理想情况下，该图表是一个向上的折线（完成工作量），和一个水平波动的折线（总工作量）组成，随着剩余工作的完成，”燃烧“折线慢慢接近于水平线（总工作量）。
|
| How | 1、X轴为时间，一般是迭代周期的每一天； 2、Y轴为工作量，根据项目情况，可以用已完成估点或已完成story点数来表示； 3、最开始，计算出本次迭代要完成的所有工作量(作为y轴刻度，迭代天数作为x轴刻度)，然后，每天站立会议时，了解前一天已经完成的工作量，并计算出迄今为止完成的工作总量。把其画在Y轴上，以此类推(并把y点连接成线)。如果计划比较(理想)准确，燃烧图的最后一天”燃烧“折线将和总工作量折线相交； 4、燃烧图可以用excel表格或者借助工具实现。 |
| Why | 1、燃烧图向项目组成员和上级经理提供了工作进展的一个公共视图，它以图形化的方式展现了完成的工作量、总工作量与时间的关系； 2、燃烧图的分析可以揭示很多问题，比如团队的表现如何、如何进一步改进等等；它有助于把握团队的进展情况。 示例：
该团队的计划并不好，因为绿线（已完成点数）和红线（总点数）最总没有相交，这其中的原因可能有很多。他们需要更好的计划。因此，对于该团队来说，计划与自我管理方面亟需改进。 |
| more | 附件为制作好的excel |
|---|---|
【2012年3月21日】
今天遇到两个问题
1.详设环节
遇到问题：之前沟通的详设环节为开发前由RD来推动，给QA讲解详细设计，以便避免详设中存在问题，后来实施时仅是RD和QA一起进行task拆分，粒度太粗。
产生影响：有些复杂逻辑的设计如果存在问题，在此环节不会被发现，会导致story由待测试移动到测试中，QA向RD了解具体细节时，问题（比如不能满足需求，实现逻辑一些异常分支没考虑到）才暴露出来，RD需要修改代码逻辑，导致一些不必要的工作。
解决办法：将详设环节沟通的粒度变细，不止是拆分task，QA提出需要了解一些复杂逻辑的实现方法，RD进行讲解。
2.代码提交，comment规范
共五行：
Project=//svn上的项目版本号
Story|Task|Bug|Merge=//spark上的story ID、task ID、bug号或merge范围
Tested=//unit test|manual
Target=//该ci实现了什么目标；比如为了修复某个Bug改了一个方法，完成了story的某个task?
Impl=//目标是如何实现的，比如是如何修改某个方法的等
【2012年3月19日】
今天主要和PM沟通了交互的几个新需求，补充了验收标准，并进行估点和优先级的排序。
【测试进度】
完成了story58的测试，以及story43的70%
【明日工作】
完成story43，以及story76（可靠性测试）
关于估点的好处
（1）经过一到两个迭代，通过估点，可以量化一个团队的交付能力，对需求池里的需求能交付哪些，能做到心中有数。
（2）估点之后，PM也了解团队能承受多大的工作量，我们根据估点和优先级来确定本次迭代交付给PM哪些story，省去大量PK成本，并且有根有据。
（3）通过估点，能督促PM及时给出清晰的需求，否则因为需求未定而耽误的时间所导致的团队交付能力降低，需要PM承担。
【2012年3月16日】
今天处理了下昨天遇到的问题3，然后进行了策略需求的story沟通会。
下面介绍一下策略story的两种常见类型的拆分方法：
（1）流程型
上面这种流程型的程序，可以这样来拆分：
如上图，按步骤来划分story
key1：实现前面的步骤时，后面的步骤用一个PM和用户都可接受，且成本很小的简单逻辑来代替，
key2：后面的步骤划分story时，将对之前stroy中实现的逻辑的修改也加进本story中去。
按优先级实现，这样保证每个stroy可单独上线。
（2）多分支型
上面这种多分枝型的程序，可牺牲分支准确程度对story进行划分：
如上图，按主要流程来划分story
key1：实现前面的步骤时，先实现主要分支，不中要的分支用一个PM和用户都可接受，且成本很小的简单逻辑来代替，后面的story再逐步完善。
key2：分支划分story时，将对之前stroy中对已实现的临时分支的去除也加进本story中去。
按优先级实现，这样保证每个stroy可单独上线，每次上线都有东西交付。
【2012年3月15日】
今天主要进行两个之前遗留bug的回归，以及迭代一的全回归，晚上上线，第一次定期发布上线，还是蛮紧张的。
遇到三个问题：
1.有个数据操作在上线步骤中漏掉
避免办法：RD在QA回归前给出完整的上线步骤，QA按照上线步骤在测试环境中模拟部署。（因为是模拟，不能保证所有操作均无问题，如有些无法模拟的操作）
2.RD增加的和本次迭代无关的上线内容出问题，且该内容不需要QA测试
避免办法：与本次迭代无关的内容不一起上线，走单独的数据操作，RD说不需要QA测试的内容，也需要关注。
3.新账户科学性策略会比老策略多生成两个文件，此任务是下午5点半跑的，我们上线是在此之后，上线后RD没有再次跑这个任务导致了今天新策略找不到这两个文件，因此任务失败。
避免办法：凡是上线的任务都需在上线步骤中写明对其上下游策略的影响，弄清上线前和上线后的区别，QA进行review，避免此类问题的发生。目标是自动化上线。
【2012年3月14日】
今天主要做两个bug的修复工作，以及回归测试准备，问题不多。
关于story
今天遇到的问题不多，总结了下story的东东，见Story Writing
【2012年3月13日】
A。早会
早会时间稳定在15分钟，以后没特殊情况就不说早会了。
B。遇到流程问题。
1.开发前的详设沟通
Q1：做敏捷，需不需要概要设计、详细设计文档？
一般不需要，原因：敏捷开发，重沟通，轻文档，且story足够小，RD的设计相对简单，通过向QA口头讲解，比较容易达到目的。
Q2：做敏捷，没有概设、详设文档，怎么沟通设计？
之前状况：没有固定的详细设计交流环节，通过QA推动RD，RD对详细设计进行讲解。
存在问题：（1）没有固定详设交流环节保证，有可能交流不充分，存在一些设计上的问题不能在早期暴露的风险。（2）由QA推动，不能保证在开发前完成详设的沟通。
变革：针对以上情况，我提出以下解决办法：（1）在开发之前，增加详设交流环节。（2）由RD推动此环节，在开发之前主动给相关QA和关注的leader讲解，讲解后，卡片才能从待开发移到开发中。
2.code frees环节
在上线之前，会有一个code frees环节，从主干上拉出一个release branch（简称RB），用于本迭代的上线。
RD继续在主干上开发下一迭代的story，QA在此RB中回归本迭代的内容，测试上线步骤。
原则上不在RB中的story，不会在code frees之后check in，也不上线。RB中修改的内容，仅为本迭代bug的修复。
Q1：code frees后发现bug怎么办？
方案（1）主干、分支同时修改代码，QA两边都测
方案（2）分支上修改代码，上线后merge到主干，QA做回归
方案（3）分支上修改代码，修改完后马上check out主干代码进行merge，没冲突后提交到主干，QA进行回归。
比较：方案（1）RD效率低，且手动两边修改代码不一定能保证完全一致，
方案（2）能解决（1）的问题，但从拉分支到上线这段时间较长，QA会堆积较多的工作量
方案（3）能解决（1）和（2）的问题，但QA两边都测试的情况还是避免不了，后续会通过自动化case的回归来保证。
Q2:code frees后由紧急的线上bug处理怎么办？
待解决
3.两套测试环境
Q1:为什么需要两套测试环境？
由于code frees环节的存在，QA需要同时跟进本迭代上线的story和下次迭代正在开发的story，因此需要两套测试环境。
Q2:两套测试环境分别用来做什么？
（1）1套环境部署主干上的下一迭代版本，用于关注下一迭代的代码的check in情况，并跟进下一迭代story测试。
（2）1套环境部署BR上，用于回归本迭代版本的story，修复本迭代版本中的bug。
Q3：hudson上该怎么配置？
（1）copy一份quick的配置，新建一个用于RB的build，配置svn地址为RB的地址。
（2）保留原有build作为主干的build。
（3）编写新的自动化部署脚本，并配置到hudson中。
Q4:RB的build需不需要单测，以及slow build？
需要，和主干的保持一致。
4.策略需求的评审
现象：策略需求相较于交互的需求，对用户不直接可见，拆分的难度较大，且之前没有做过需求拆分，也没有明确的拆分规则，因此需要在项目中实践总结。
Q1：由谁拆？
先推策略PM对需求进行一个整体上的拆分，拆得不够细的story再在需求沟通会上进行拆分。
Q2：怎么拆？（待完善）
（1）和交互一样，每个story都需要有独立的交互价值，能单独上线，并且足够小。
（2）策略往往是一个流程，分为许多步骤，可按流程中的步骤进行拆分。
C。遇到环境问题
由于引入code frees环节，需要两套测试环境，且都需要自动化部署，因此今天完成了环境的搭建和自动化部署脚本的编写，已能正常投入使用。
【2012年3月12日】
今日一切正常。不过好忙，估计以后每周一时间都会很紧张。10：15到10：30站会，10:30到12:00例会，12：00到12:40和PM细化需求，12:40到1:00吃饭，1:00到2:00需求沟通会，2:00到3:40和PM定好验收条件，以及解决需求上的一些细节问题。4:00以后才有时间去测试。
A。早会
早会首次达到了15分钟的预期，看来大家已经适应了。
分享：为什么早上开例会?
（1）可以让所有人按时来，按时工作。
（2）可以让每个人更清楚今天自己该干什么。
（3）晚上每个人进度不一，作息时间不一样，早上说昨天干了什么更准确。
B。需求沟通会
先讲解一下需求沟通会。（ps：本人总结，待指正完善）
Q1：需求沟通会之前应该做什么准备？
（1）PM给出需求list，并且将需求写为story，完成story的前两部分（a.作为XXX我想要XXX以便XXX，b.详细描述）。
（2）PM和QA一起给出story的验收条件。
（3）RD、QA的leader对需求list进行review。
Q2：需求沟通会大概流程是怎样？
首先，循环每一个story做如下过程：
（1）PM讲解story。
（2）RD、QA提出疑问，PM解答，并完善到story中
（3）大家一起补充一下验收条件
（4）对story进行估点，估点可取范围为（1、2、3、5），5为最大，为什么没有4，以及估点原则后续日记中总结。
（5）对大于等于5点的story进行拆分。
然后，对story进行优先级划分。
最后，将上面的story纳入迭代计划。
Q3：需求沟通会需遵守的原则有哪些？
（1）会上讨论的story都是PM思考清楚的，RD、QA leader review过的。
（2）每个story讨论时间不超过10分钟，否则认为此需求为需求不明，不纳入迭代，会后再沟通。
（3）估点大于5的需求都需要拆分，等于5的实在不能拆，可不拆。
Q4：需求沟通会应该达到什么样的效果？
所有疑问都在沟通会上提出来，会上沟通确认的需求，直接进入待开发状态。
本次需求沟通会沟通迭代二的新需求，本该按上述流程和要求进行，但这次会前PM需求不太明确和细化，因此在会上没有过验收标准，会下进行的补充。
Q5：如何控制需求沟通会的时间？
目前暂定需求沟通会不得超过一小时，一小时之后没有拍板的需求将被视为需求不明，暂不放入此迭代，这样也能促使PM将story的质量尽量提高。
C。遇到流程问题。
1.关于task卡。（ps：个人总结，后续再找PMO讨教）
Q1：什么样的任务作为task卡？
不用交付给用户的任务，都可做为task卡，如：调研、性能优化、代码重构。
Q2：task卡的特点
（1）从敏捷团队的经验来看，只有个别的task卡才需要测试。
（2）如果不需要QA测试，task完成后直接会被挪到验收完区域，而不进入待测试区域，QA关注待测试的卡片就可以。
Q3：QA需要如何对待task卡？
作为QA，一张新卡上墙了，我们都要关注是不是对系统质量有影响，或者说，我们对所有task卡都应该有些了解。
Q4：如何区分task卡是否需要QA测试？
虽然每个task卡都需要QA关注，但仅有少量需要特别关注，因此，我和RD协商，目前尝试将需QA测试的task卡右下角标注为“T”字样。
D。遇到环境问题
1.环境解耦
（1）接口
问题描述：由于系统依赖很多上游，因此现在开发和测试都使用很多上游桩，但作为敏捷项目，希望尽可能接触对外部环境的依赖，以达到敏捷的目的。
解决办法：
第一步，列出所有上游桩依赖。（给出列表：接口名 上游 机器 上游接口人 能否部署到测试环境 ）
第二步，调研哪些桩能直接拿过来部署在测试环境中，自己维护。
第三步，部署并维护可用桩。
第四步，开发不可复用上游的已有桩，逐步解除依赖。
（2）数据库
问题描述：开发的过程中，RD不断修改数据库表结构，并且没有地方维护这些脚本，直到上线前才给出整体脚本，QA维护测试数据库成本很高。
解决办法：调研dbdeploy，自动维护修改表结构脚本。
E。测试进度
1.和PM细化需求。
2.和PM补充验收标准
3.需求沟通会
4.完成了story20（修复投放地域的前端显示）的测试
【2012年3月9日】
今天进度来看，进展很顺利，大大超出了预期，不过还得看上线效果才能下定论，质量第一。
A。早会
早会效率很高，已经达到预期的10余分钟，遇到的流程上的问题也较之前大大减少。
B。遇到流程问题
1. bug story的格式
bug story
2. slow build 、quick build解冲突（数据库）
由于目前的quick build 和slow build都会读写数据库，虽然slow依赖quick，但slow build的时候如果有人check in，就会触发quick build，因此同时读写数据库会造成单测case的失败，为解决此问题，已考虑解决办法如下：1. 使用不同的数据库，2.修改配置，使编译的war包放在不同的地方。
3。RD本地deploy
由于目前团队条件，先不增加local build，在过渡期先使用RD本地部署，自测通过后提交，以提高check in build成功率和代码质量。
c。测试进度
story6（在漏斗分析页的点击环节添加“账户结构”的相应建议）的测试
D。首周小结
用敏捷开发后，本次项目当前的进展情况和bug比例和之前比较，主要体现在以下两个方面：
1. 项目进度较之前快；
2. Bug比例较之前低。
现对以上情况做以下分析：
1. 收益（速度快，bug率低）
A． 采用story模式，将大需求拆为可独立交付的小story，需求清晰明了，节省了大量的需求评审时间。
B． story足够小，设计难度较低，并且改之前的书面详细设计及其评审为“口头沟通为主，文档为辅”，详设环节的时间也大量节省。
C． story足够小，验收标准更明确，测试设计环节简化，评审环节改为口头沟通，节约了大量设计时间。
D． story间并行，不是之前的所有需求评审完成，才开始详设，详设没问题之后才开始编码和测试，因此将需求阶段PM的瓶颈，开发阶段RD的瓶颈、测试阶段QA的瓶颈都降低了不少。
E． 将RD从文档和评审中解放出来，RD更有时间也更愿意去自测和写单测，bug量减少。如
F． 落地hudson check in build、一键部署，也节省了很多交流和环境的成本。
2. 风险（漏掉bug？）
最近几天，测试设计的编写被弱化，QA测试都是按照之前定验收标准来测试，可能简单的测试case不如之前深思熟虑的测试设计更完整，回归范围更准确，这可能也是bug较少的一个原因，正在摸索解决方案。
目前已和志浩约定，有固定的测试设计编写环境，以真正理清自己思路，规避测试模式变更带来的风险。
3. 其他因素
1. RD编码技术经过之前项目的历练，提高了不少，单测质量也有所提高。
2. 需求多为升级，较之前需求复杂度低。
【2012年3月8日】
今天除女同胞们过节休假外，节奏貌似都进入正轨了，测试进度正常。
A。早会
今天早会由于线上有点问题，部分人请假了，整体时间消耗还算比较合理，效率有进步。
B。遇到流程问题
1.关于红点绿点。
敏捷中，用绿点来代表story在“开发中”停留的时间，以标识估点和实际使用点之间的差别，如果差别太大就说明估点有问题。红点用来标识story在“待测试”和“测试中”停留的总时间，反应测试压力，可以反映出QA人力、以及测试压力方面的问题。
2.关于提测方式改变
之前的提测规则为：RD打tag，并标识此tag中哪些功能点提测，QA根据该tag号，从svn上检出代码，自己编译，然后部署到测试环境中。
现在的提测规则为：RD通知QA某个story已提测，QA去取hudson中最新的war包进行部署。
比较：后者直接测试的hudson编译的war包，部署时能节省掉export和编译的时间，并且前者有可能因为编译环境的不同造成一些问题。不过若使用后者，在编译中就不能部署。
改变后造成的影响：需要重新编写自动化部署脚本，在编译过程中不能部署。
3.关于上线开关
一个story，上线还是不上线，迭代初不能完全确定，就有可能如下问题：a.迭代完成时stroy不能交付，无法上线，回滚困难。b.需求变更，不上线，需回滚。如果不提前提供上线开关就会造成回滚困难的问题。
如何解决，还待确定。
4.slow和quick build冲突
hudson上slow build和quick build有可能冲突，如果设置为互相依赖，肯定不可能，如果设置为slow build依赖quick build，也不能完全避免冲突，现暂时设置为slow build在下班后到上班前执行，办法不是很好。
PM给出一种解决办法：把依赖=改成两个条件，每次quick完成，就去slow排队，slow跑完一遍，就在队列中选择最新的那次quick通过的提交版本进行slow test，队列的问题暂时不知道怎么设置，还待解决。
C。遇到业务问题
story9（关键词推荐页高级设置中PV修改）不上线
原因：PM觉得PV为0的关键词还是有一定价值，决定不上线。
造成影响：RD、QA之前的工作量浪费，且增加新工作量--回滚。今后应该尽量避免这种需求上的问题，以免造成人力浪费。
D。环境问题
1. 因为提测规则的改变，导致之前写好的web自动化部署需要做相应修改，已完成。
2.wbdp的自动化部署也已经解决。
E。测试进度
1.完成story7（在漏斗分析页“账户结构”建议增加入口，调用“变形金刚”）的测试。
2.完成story21（修改“新分配”tab内新账户的操作列）的测试。
【2012年3月7日】
今天大家貌似基本适应了敏捷的流程，按部就班地做着自己的任务。
A。早会
今天早会的时间还是相对较长，原因是昨天对stroy形式的敏捷中遇到问题的处理办法还是不太清楚。早会花了半个小时，以后还需提高效率。
B。遇到流程问题
1. build相关
问题1：目前仅有quick build，无slow build、check in build、local build。且quick build是按模块来划分优先级的，不标准。
目前解决方案：根据实际的团队情况，先增加check in build，将集成脚本和不太重要的部分划入slow build，慢慢的将quick build按重要程度提取。把之前的定时build改为check in build。
问题2：hudson build 失败，谁来跟进。
目前解决方案：PMO增加一台显示器，放在显眼的地方，专门显示hudson build情况，且RD 一旦check in，就得关注hudson 的build是否成功，一旦失败，最高优先级解决。至于发邮件提醒，暂时不考虑。
问题3：之前提测的时候，RD经常没有将前端的包打进提测包中去，导致提测后由QA发现，耽误测试时间。
解决办法：已让RD开发自动打包脚本，避免此类问题。
2.外界打扰
增加白板，记录被外界（团队外）打扰的事件，来观察整个团队被外界打扰的程度，如果问题较大，需要考虑解决方案。
3.提测质量
问题：目前将卡片从“开发中”移动到“待测试”没有一个明确的标准，如何来衡量这个标准（比如单测？自测程度？）需要慢慢摸索。
暂无解决办法，摸索中。
4.PM验收的环境
问题：现在PM需要显现验收，验收环境谁来提供？
目前解决办法：现由QA提供测试环境给PM验收，测试环境中的必须的数据也需要QA来提供。
5.“测试中”区域宽度
问题：“测试中”区域内，有几个卡片合适？
答案：“测试中”区域卡片数量由QA的数量来决定，一般QA的个数即为“测试中”区域卡片的最大数量，大于这个值就会有漏测风险。因为敏捷中希望QA一个时间只做一个story，即对于QA来说story之间串行，这样更利于QA思路的专注和测试效率。
6.已拍板的story需求变更
问题：测试过程中PM变更需求怎么办？
答案：既然story已形成，已经在开发或测试中，说明次需求是经过深思熟虑的（除非有特别严重的错误），因此，如果中途有需求变更，应该增加一个stroy放进需求池，而不是将之前的stroy做修改，目前stroy照常开发测试，至于上线与否，再根据具体情况而定。
7.发现线上bug，如何修复？
在需求池中增加bug修复的story，如果bug影响十分严重，特别紧急，则提高其优先级，插入此迭代中进行修复，如果很无关紧要，则将优先级放低，后期修复。
C。遇到业务问题
1.物料优化未设置投放地域的story，进度过慢，原因是FE对相应业务不熟。
2.FE发现一个物料优化的遗留显示问题，不紧急。
D。测试工作
1.完成story2（新分配-新户）的测试，发现一个bug，已修复验证。
2.完成story1(需搭建)的测试。
3.解决hudson自动部署影响build的问题。
【2012年3月6日】
今天是敏捷开发的第二天，也是第一次拿到RD实现的story进行测试。
A。测试环境自动部署。
敏捷开发和之前的迭代不同，之前RD几天提测一次，最频繁也就每天一次，现在有可能每天有几个stroy开发完成提测，并且在不同时间点，RD一天可能提测很多次，因此测试环境自动化部署就尤为重要，要不QA得累死。今天编写了基于hudson的自动化部署脚本，完成了web的一键部署，由于hudson的bug，server的自动化部署暂时还有点问题。
B。stroy设计交流
之前提过重沟通，轻文档，且目前的需求都被拆分得很小（stroy形式），因此RD的详细设计又被弱化了，那么QA如何知道RD怎么去实现没一个stroy？RD又怎么和QA达成对需求理解的一致呢？那就只有坐一块沟通。RD给QA详细讲解实现的具体过程，QA提出疑问，RD做出解答，QA再对RD漏掉的需求进行补充。这样效率比较高，不过也有某些问题QA可能暂时发现不了的风险。
C。关于需求
由于需求评审也被弱化了，之前需求评审阶段会发现的很多PM考虑不周的地方，可能会在RD实现，甚至QA测试的时候才真正被发现，这些bad case会相对比较多，这就需要QA更细心，思路更清晰，也更能体现QA的价值。
今天发现一个可能存在问题的需求，两个bad case。
（bad case1描述）
账户识别页面，新分配tab，新分配到客服下的老户，点击操作列的“优化”，显示的是：”此账户内没有物料，需先搭建账户，去搭建账户“，实际上老户可能有词。
（bad case1建议解决方案）
新分配老户隐藏掉“优化”（优），或者链接到昨日的优化建议（劣）。
（bad case2描述）
账户识别 点击今日，新分配的账户数据里仅有“账户状态”、“账户名”、“行业”、“今日方案”，因此，高级查询条件除“账户状态”和“行业”之外的条件查询均无意义。
（bad case2建议解决方案）
高级查询区分昨日和今日，点击今日的时候，高级查询条件只提供“账户状态”和“行业”。
D。关于bug
由于需求管理使用的是spark系统，PMO的意见是将bug提交到spark里面去，但spark的系统远不如icafe的trace，统计分析bug也是基于trace，因此现阶段先做如下解决：将bug提交到trace中，将对应的id粘贴到spark系统中。
E。关于测试
测试的时候，坐到RD旁边，有问题随时交流，RD的相应变快了不少，不过因为没有编写case，因此思路容易被打乱，建议以后还是自己根据需求先编写简单的case，理清自己思路，以避免漏测。
F。关于开发
今天测试一个RD已标记为“待测试”的stroy，发现RD仅完成了web的开发，数据导入的开发还没开始，因此打回该story，让RD高优先级开发该stroy。
G。关于敏捷白板
敏捷白板由以下几列组成：新建、待开发、开发中、待测试、测试中、QAsign off、已验证。如下图所示，详细信息请参见：智能账户优化敏捷白板，进去后点击：当前迭代。
【2012年3月5日】
今天是敏捷开发定期发布的第一个迭代的第一天。
A。早上例行站会，第一次站会了解了一下站会的大概流程：
从RD到QA，每个人发言，内容为：1. 昨天干了什么，2.遇到什么问题，3.今天准备干什么。
站会的时间尽量控制在十分钟左右，主要目的是大家周知下每个人的进度，以及遇到的问题。
最后负责人总结一下，然后根据实际遇到的问题，少数人进行线下沟通、跟进、解决。
B。工位调整
QA、PM都搬到了RD那，因为敏捷开发注重沟通、交流、信任，轻文档、个人责任，因此交流十分频繁，坐到一块就是必须的了。
C。stroy验收标准补充。
之前完成的story验收标准内容比较粗略，QA的test case的编写也弱化了，因此stroy验收标准的细化就十分必须。
QA、PM坐在一起细化每一个stroy的验收标准，一方面QA理清自己的思路，保证没有测试点被漏掉，另一方面帮助PM理清思路，发现一些考虑不周的地方，最后形成了几个待实现的story最终的验收标准。
D。task划分
RD分到story后，将每个story划分为一个个的task，task相对于stroy更接近具体实现，比如一个需求分为前台页面、service层逻辑、数据库设计、数据导入，那么就至少可以拆分为4个task，每个task还能划分成更小的task，作为svn的最小提交单元（当然这只是理想，RD并不一定这么干）。
E。测试准备
熟悉RD正在开发的stroy，并将测试环境搭建起来，在这就不多说了，和之前一样。
kick-off会议纪要
在智能账户定期发布的kick-off会议上，PMO给我们介绍了敏捷流程，会后PM/RD/QA进行了STORY的拆分工作，
主要成果记录如下：
² 目前的定期发布（迭代）周期是2周
² PMO路宁同学，给大家介绍了敏捷的主要流程，指导大家开展story拆分及后续开发测试工作，解答了大家的困惑。
² PMO吴瑶同学，将和智能账户同学坐在一起，全程指导智能账户同学展开敏捷实践，做到产品的高效定期发布。
² 根据路宁介绍，结合智能账户实际情况，和PMO吴瑶同学梳理了一个敏捷活动流程参考，请大家了解，后续根据会不断完善。请见邮件最后
本次会议TO DO及跟进情况：
- 依赖第三方接口的程序稳定性保证（QA/RD调研）。
- 持续集成中数据库的使用方式，dbploy使用（PMO吴瑶）---已经联系了PMO同学，周一会对智能账户敏捷情况摸底，进行针对性培训
- 敏捷过程中RD的详设要不要写，怎么写？（PMO/RD/QA）---RD和QA已经达成一致，只写测试考虑及必要信息，其他靠沟通完成
- 目前RD/QA的分工方式需要从“一人负责一个模块”向“所有人负责所有模块”转变。
- QA需要更早参与PM的Story编写，完成验收条件。
- 敏捷进度的管理工具，推荐使用burn-up图。
- 维护一个随时可以供PM查看story的环境，提高合作效率。
- RD/QA需要保证专人专用，RD4月份之后会做到这一点。
- 每个Story的大小，在1-3天内完成为佳。
敏捷活动流程参考
| 敏捷活动 | 产出 | 参与角色 | 备注 | |||
| PM | RD/FE | QA | ||||
| 项目启动会 | 全员参与 | 全员参与 | 全员参与 | PM讲解整体需求、确定参与人员、开发模式（迭代周期、上线周期等）、沟通机制、各种环境、依赖第三方、风险评估、review机制 | ||
| Story拆分、估点 | 需求整理 | 粗略需求产出 | 整理需求并排定优先级 | |||
| 需求挖掘、澄清 | 带有优先级及验收标准的详细需求，且需求的可实现性基本确定，大小合理 | PM | leader参与，重点从技术实现角度挖掘需求 | 全部参与，完成验收条件 | PM业务不熟悉情况下，RD/QA参与帮助挖掘需求；以减少迭代计划会上时间浪费 | |
| 迭代计划会 | 产出迭代计划 | 全员参与 | 全员参与 | 全员参与 | 计划包括：迭代包含的Story，每个Story的优先级和估点 | |
| 每日站会(10min)&可视化管理 | 项目现状 | 全员参与 | 全员参与 | 全员参与 | ||
| Story开发 | Story kick-off（3-5min） | 澄清即将开始story细节 | Story相关人 | Story相关人 | Story相关人 | |
| Story开发过程中随时沟通 | RD/FE为主 | |||||
| RD TDD, QA设计Test Case | RD 开发、单测 | QA测试 | ||||
| mini Show case（5min） | QA粗略检查Story完成质量 | -- | RD | QA | QA检查内容、通用检查、重要探索性测试，确保没有严重问题（重点在控制提测质量） | |
| 验收 | QA sign off Story | 高质量Story通过QA验收 | RD fix bugs | QA | sign off！ | |
| Show Case | 给PM展示Story | PM | RD | QA | bui！ | |
| Buffer | 敏捷初期留出最后buffer | Buffer减少需要依赖Story质量的提高 | ||||
| 上线 | Story可以直接上线 | |||||
| 回顾会议 | 总结经验教训、制定改进方案 | 全员参与 | 全员参与 | 全员参与 | ||
扫一扫
8922
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
