采用敏捷开发感觉时间总是过的很快，三个星期一转眼又过去了，日历从2012转到了2013，我们的项目在新的一轮迭代之后，也变的更加丰富多彩。
之所以用“丰富多彩”这个词完全是为了体现在这个sprint中我们出来了IOS版本：背后的各种磕磕绊绊。IOS上依赖的一些lib文件是另一个城市的site维护的，很不幸拥抱变化的scrum模式遇上了跨site的交流不畅，具体过程实在是不想回顾了，总之这个sprint结束那天，我从电话里分明听出了另一个site的女程序员略带火气的建议：“有什么改变要让我们及时知道”。可问题是我们这边变了又变，到了demo展示前一天晚上才定下来workflow，再及时告知也晚了。我认为这种现象勉强算是敏捷开发的弊端吧，交流成本过高的体现。不可能避免跨site的交流，也就是很难做到大家随时的交流，这种情况下，没有严谨的完善的设计的缺陷就体现出来了，大家都喊着事先定好接口，划分清楚责任，可是真正实施起来，做着做着以前定好的东西就变了，而且大多改变是在两三个人的临时讨论之下完成的，讨论达成一致，回去改改代码完事，没有记录，没有总结，看起来简洁灵活，可是许多这样定下来的东西，过不两天，又会提出修改，甚至几天以后都不知道为什么要这么设计了，改了它更无所谓，相当令人郁闷的现象。或许每次讨论需要强制做些会议记录，可这并不是解决问题的根本办法，我从来不认为设计是可以轻率的定下来的，传统的开发模式的优势就是做好充分的设计，这一点在敏捷开发模式下略显薄弱，我想相对近期的设计还是要做的，比如一个完整sprint的设计要先做掉，而且要详细做，做完要出正式的不可轻易变更的文档。
当然了，并不是只有问题，也有不少的收获。出来了具体的架构，至少现在看是没有问题的，结合第一个component也证实了这种模式的适用性；各种平台下的编译也进入了正常轨道；unit test 也带来了积极的作用，大家更热情的进行ut；跨平台的第三方动用库也通过修改适用了起来。总之，这个feature算是把整个项目的底子打正了吧，其中也存遗留了一些问题需要解决，不过应该不会造成太大的block了。
明天又是新的一个sprint , 坚持最后三个周，迎接春节假期~
分类:
scrum
摘要: 采用敏捷开发感觉时间总是过的很快，三个星期一转眼又过去了，日历从2012转到了2013，我们的项目在新的一轮迭代之后，也变的更加丰富多彩。之所以用“丰富多彩”这个词完全是为了体现在这个sprint中我们出来了IOS版本：背后的各种磕磕绊绊。IOS上依赖的一些lib文件是另一个城市的site维护的，很不幸拥抱变化的scrum模式遇上了跨site的交流不畅，具体过程实在是不想回顾了，总之这个sprint结束那天，我从电话里分明听出了另一个site的女程序员略带火气的建议：“有什么改变要让我们及时知道”。可问题是我们这边变了又变，到了demo展示前一天晚上才定下来workflow，再及时告知也晚了。
阅读全文
posted @
2013-01-13 21:24 软件心理学工程师 阅读(499) |
评论 (0) 编辑
摘要: 三个星期飞快的过去了，第一个sprint就这么结束了。周五上午开了个总结会，大家对这个sprint的成绩做出了肯定，也坦诚的指出了很多不足之处。成功的deliver出来了预期的东西，完成了既定的目标，给继续采用scrum增添了信心；在这个过程了，大家更加积极主动的交流，问题得到更快的反馈和解决，体现出了敏捷开发的优势；引入了unit test之后，确实发现了代码中的一些潜在的问题，尝到了ut 带来的好处，大家更有热情的投入到 ut 中；每日的 stand up meeting 使大家越来越默契，增进了团队氛围。总之，scrum带来了很多积极的因素，随着第一个sprint的磨合，大家会更加得心应
阅读全文
posted @
2012-12-23 20:06 软件心理学工程师 阅读(612) |
评论 (0) 编辑
摘要: 今天下午的 weekly meeting 上大家尝试着进行了 poker Plan EST ，首先大家讨论认为1个 point 对应 1MD , 然后 scrum master 选择了一个 user story 让大家进行出牌。这是问题就出现了，大家对 user story 的逻辑流程的理解是不一样的，各人的能力也参差不齐，再加上性格上的原因，出牌的结果，大家差别很大。估计时间最多的人使我们team中的一个老员工了，但她没做个这个部分，她阐述了自己的想法，发现她的 workflow 过程附带很多我们新员工都不知道的环节，又因为是女生，她给交流成本和不确定因素分配了较多的时间，估计时间最短的是一
阅读全文
posted @
2012-12-05 18:25 软件心理学工程师 阅读(42) |
评论 (0) 编辑
摘要: 早晨的 stand up meeting 还是很成功的，15min 控制的相当好，每个人都说了上个工作日做了什么，遇到什么问题，今天准备做什么 。 虽然中间有人插话，不过大家都选择简洁的提问，简短的回答。大家都汇报了一轮之后，竟然还剩3分钟，scrum master 抛出了一个问题：如何定义 point ？这个本应该在 planning meeting 上对 task 估计 point 的工作当时没有做，因为当时大家觉得以时间做为 task 的衡量单位就足够了，可惜美国那边都是以 point 作为衡量标准，我们也不得不这么做。大家对 point 的单位设定没有什么概念，好像就是知道 point
阅读全文
posted @
2012-12-03 18:17 软件心理学工程师 阅读(38) |
评论 (0) 编辑
摘要: 博主背景：某985学校研二，软工专业，现在某500强IT外企实习，进入公司5个月余。项目背景：把公司现有产品的某些功能做成SDK提供服务，本项目大概持续5个月左右。因为整个team初次采用敏捷方式进行团队管理和开发流程控制，摸着石头过河，难免遇到各种问题，打算记录这个过程中的点点滴滴，希望能和有兴趣的朋友共同探讨学习。Planning Meeting For Sprint 1上周2开了一个长达2.5h的 planning meeting ,在开会之前一周已经通过 brainstorm 搞定了 back log 和 user story , 故这个会主要任务就是提取出 sprint 1 要实现的
阅读全文
posted @
2012-12-02 22:17 软件心理学工程师 阅读(59) |
评论 (0) 编辑
