日志
- 分享 过程改进日记之学习Scrum2010-9-9：外部培训笔记
- 今天下午有个咨询公司给在我们公司范围做了个Scrum的培训试讲，我把主要的问题和解答记录下。（唉，都是我在问，兄弟部门的弟兄们仅问了一个还算有价值的问题。） 针对我们目前遇到的一些情况，在老师最后QA环节集中问了下，老师的一部分重要观点不是在回答我提问的时候说的，为了阐述方便，我也一并整合 ...
- 分享 过程改进日记之学习Scrum2010-9-6：对话Dev Leader
- 今天早上例会最后，我把上周五讨论到的重视质量，请大家明确验证方法说了一下，但从大家的反应看，应该是觉得对验证所需要的消耗是否值得还是心存疑问的。 而事实上，对这方面到底需要多大的投入，能产生多大的价值我也有疑问，毕竟，产品前期开发时间已经用了很多，市场打开后，已经有用户针对演示的版本提 ...
- 分享 过程改进日记之学习Scrum2010-9-3：关于质量和热情
- 散会后，PM、DPM、我、SQA MM习惯性留下来交换下意见（这已经成为惯例了，有时候老大也会凑着这个时候进来发表下他的疑问或者新的外部信息） DPM悠悠得说了一句话：“ 我觉得最近的任务完成情况看起来不太可靠 ” 我天 ，原来不是我一个人有这样怪怪的感觉，个别工程师表述任务完成情况潜意识的含糊了。 一 ...
- 分享 过程改进日记之学习Scrum2010-9-2：Sprint会议和关键任务
- 昨天没写，是因为昨天的故事在今天才有个结果 昨天的晨会中有个框架调试的任务没有搞定，而这个任务的成果恰恰是多个工程师任务验证的一个依赖条件，因此，导致昨天乃至前天的部分任务没有能够验证。 今天的晨会，大家心情都很愉快，因为这个阻塞任务可以移到Done区域了，很多相关任务也都可以验证完成了，按照 ...
- 分享 Scrum度量的一些想法
-
今天看《平衡敏捷与规范》，想到另外一些可以着手准备的度量，先记录下 Scrum上的需求和任务都是明确的，Sprint会议应该做一些基础的度量，比如Task，可以根据下面的表来识别是否太粗的容易更容易延期，或者相反。（如图，数据是我杜撰的） 如果把任务按照设计、研究、开发、UI、测试等来分，可以得到更多的任务估算 ...
- 分享 关于需求的想法点滴记录（续）－上中下三策
- 项目管理培训，其中关于需求的一些言论记录下。 这个我是从培训讲师那边听来的，但不知道他是不是版权所有者，等待更多信息。 B、上中下三策 上策：在第一时间发现变更的可能性 中策：做好优先级，不做无谓的浪费 下策：运用变更控制流程
- 分享 关于需求的想法点滴记录－want & need
- 项目管理培训，其中关于需求的一些言论记录下。 昨天在群里讨论到了需求管理，觉得有些信息可以分享下，于是先记录些。 a、want need want：基于自己的理解，随着理解加深，往往会有更多变化 need：基于能够解决什么业务问题来做评判，更多依赖专业背景来发现 我个人理解的： 所谓专业背景 ...
- 分享 过程改进日记之学习Scrum2010-8-30：新计划上墙
- 今天SQA MM忙着整理所有任务，准备Sprint2任务上墙，这次我们预期了两周的工作量，看起来任务数量较多。 我们目前还做不到测试驱动，所以基本上在每个需求的后面，都有一个测试任务（为便于查看，我们用蓝色的即时帖来登记测试任务。） autobuild方面，由于开发这边忙于跨Team的进度协调，以及新员工工程接入等 ...
- 分享 过程改进日记之学习Scrum2010-8-27：下一阶段任务分解
- 终于一周过去了，由于这周并没有按照Sprint的方法来安排计划，只是按照看板的形式来确认每天的任务，所以完成情况的确不怎么理想，额外增加的任务，工程师对需求了解不够导致的工作量评估不够、新员工学习时间成本等等，使得这周的趋势和老大预想的完全一致。 嗯，正如我们所有人所说，发现 ...
- 分享 过程改进日记之学习Scrum2010-8-26：考虑每日构建
- 每天，各工程师都有一些功能需要给测试验证，DPM都要知会大家准备，编译、制作安装包，如果没有通过验证，开发工程师修改后，需要能够马上编译，这样才能达到敏捷的要求。 目前我们的AutoBuild系统还只是DPM人工触发的，既然是敏捷开发，那就应该更快些，另外，老大和PM希望随时可以看到最新的版本，并且评估 ...
