日志
- 分享 缺陷管理，纠结在敏捷和规范间
- 关于缺陷系统的抱怨和自发的敏捷实践 随着各产品线新产品开发逐渐进入收尾阶段，反馈缺陷库使用不方便的声音越来越强烈，于是专门找各产品开发、测试负责人访谈。 对于缺陷系统的抱怨主要集中在三部分 1、 编辑和查询 ：新增bug的时候条款复杂、必选项多，检索速度慢，查询视图不方便 2、 工作流 ：流转环 ...
- 分享 老文档摘录－关于管理体系和企业文化的建立之建议
- 搜索资料总看见一些以前写的不错的东西，留在此处吧，也算分享。 以下是很久前写给HR的 关于管理体系体系 ① 组织架构的科学性 ：如何保证组织架构的稳定性，避免因人设岗、因事设岗，增强岗位设置的规划性，岗位设置要既要符合公司短期的业务需要，也要考虑一定的前瞻性和稳定性 ...
- 分享 过程改进日记之学习Scrum2010-11-16 迷你看板& 对缺陷管理的反思
- 机箱上的看板： 立会之后，想着燃尽图没有更新，去作战室数一下，发现感觉少了好些，某工程师名下寥寥几张，于是跑他座位上去问下，不过走进一看，不用问了，他把机箱放桌上的，侧面朝外，贴了好多即时帖，敢情这位老兄不看系统了，他把今天checkout的任务都拿来贴自己机箱上了。 这倒好，一个机箱迷你看板。 ...
- 分享 过程改进日记之学习Scrum2010-11-15 缺陷收敛和燃尽图
- 之前介绍过，N 产品Sprint6有新Backlog开发和稳定产品两个目标，因此我们设置了两条燃尽图，截止到上周末的趋势如下。 关于Bug看板，我们有个非典型的Sprint4做过一次实践，详 见《Sprint4最后一天，思考Bug看板的应用价值》 在Sprint6实践一周，有些和上次不同的实践可以描述下。 ...
- 分享 过程改进日记之学习Scrum2010-11-11 一个Team两块看板
- 背景：两个看板 C Team 的技改项目评估完成后，新建了一个看板，为便于叙述和阅读，我把这个技改项目取个好听易记的名字吧 ，（第一个蹦出脑海的词汇就是“雷神之锤”）， 就叫“ 雷神 ”吧。（ 以后实践中可以让Team自己为项目取名 ） 之前介绍过，C Team的工作特点是OEM任务多，通常客户有需求。Team就会随机 ...
- 分享 过程改进日记之学习Scrum2010-11-8 使用估算扑克
- C Team有个内部技术改进工作，为方便管理，单独立项了，预计在12月中旬结束，和Team沟通了一下，借这个机会我们尝试做了扑克估算。具体方法很容易找到图文并茂版的，不用赘述。单就我的观察写一下。 需求确定、并且已经分解到任务级别，我们就是对这些任务来进行估算。 前半场，前一天下午16：00～17：30，我们没 ...
- 分享 过程改进日记之学习Scrum2010-11-5 Sprint6 一个看板，两种算法
- Sprint6的目标有两项 1、产生可以对客户提供评估的for A平台版本 2、完成B平台的XX模块开发，能够交付QA测试 这样，Team开发人员分成两小组，甲小组集中修改缺陷以达到可交付评估的质量标准，乙小组完成B平台下XX模块的学习、研究、开发。 乙小组工程师名下的缺陷分派给甲小组的工程师。 分工完 ...
- 分享 过程改进日记之学习Scrum2010-11-4 Sprint5演示和反思
- 准备好了吗 基于自治原则，所有工程师轮流主持，这次轮到新员工小C，和上次新员工M不同，SQA MM特定和他一起商量着整理了DEMO List，并且准备好设备、在会议室的电脑上也装好了程序，确认连接没有问题。各模块界面都可以打开，需要验证的功能也跑了下，真正是万事就绪状。 会议时间到了，众人落座问候完毕，小C先介 ...
- 分享 过程改进日记之学习Scrum2010-11-3 看板的两个注意事项
- 看板≠Todo List C Team的工程师看来的确很喜欢即时帖的过程，我们领来的即时帖是多色的，昨天CPM美女贡献了一套彩色水笔，大家一抢而空，然后就再也不需要我们帮忙抄写了（想起 第一次沙龙中的问题 ，不禁莞尔） 这两天开会，都是这样的场景，工程师早早写了一些任务，等到9点就进来说昨天的，说完粘一 ...
