- 博客(40)
- 资源 (1)
- 收藏
- 关注
RSS订阅
原创 过程改进日记之学习Scrum2010-10-14：内部沙龙
原计划沙龙15：00开始，我到了14：50还在十万火急地修改，希望把最新Sprint5计划的情况写上去。（我还以为是15：30开始的呢）赶紧保存了赶过去，有点迟到了，不过迟到的参与者更多，于是等了一阵子。<br />之所以以沙龙的形式，希望参与人员能够以放松的心情来观察别人实践，探寻项目管理中的疑问。<br />沙龙方面，准备也不够细。很多工程师之前对Scrum了解不够，带着问题来的人不多，不过不乏一些有代表性的问题，我把一些典型观点和问题以及我的理解分别描述下。<br />所幸做为典型客户代表的N产品PM
2010-10-18 08:49:00
377
原创 过程改进日记之学习Scrum2010-10-12：很好的实践-换位置
<br />今天晨会，刚进门：DPM就意有所图状看着我，“我昨天仔细看下，貌似泥泥占了两个座位，你们把位置腾出来的话，我们可以搬过来。” 我汗，真没白Scrum，这帮家伙行动力真强了，最开始的时候我和SQA MM都说到座位的问题，那时候谁都觉得“犯不着”、“别人不愿意的”。现在果然不同了。 SQA MM坦然牺牲靠窗的好位置，我当然没有问题了：“行，你们给我指点一个位置就可以了，我中午行动吧”。 SQA MM很热心，看到另外一个PM位置，觉得N产品的测试工程师坐这儿太合适不过了，然后主动去游说：“你和W测试工
2010-10-15 13:19:00
307
原创 过程改进日记之学习Scrum2010-10-11：不好的实践-来自测试工程师
<br />测试工程师不好的实践好多，围绕在质量、协调方面，给出了很多他觉得不好的地方，除了一些和集体反思一致的，比如UI更新、项目目标，其它方面主要是递交管理和缺陷管理。表面上的原因，是我们放弃了原来非常严谨的递交系统和缺陷管理工具，转而使用了禅道来管理缺陷，递交和缺陷管理要求降低，导致质量下降。按照DPM的说法：“系统自动编译，完了自动把安装包路径发给测试，然后工程师就觉得没事了，这个系统太爽了……，尤其是对于没有经历过完整的递交环节的新员工来说，完全不关心点击Autobuild按钮之后还有什么事情
2010-10-15 13:18:00
383
原创 过程改进日记之学习Scrum2010-10-08：尝试需求的头脑风暴
<br />需求的头脑风暴是PM先提出来的，我也很想做这样的尝试，自从参加了产品创新培训后（搜索《产品与服务开发》，L.LBean公司案例），很希望能够有机会尝试一些行动。<br />在演示会和反思会之后，展开需求讨论的头脑风暴。考虑到大家未必真的理解头脑风暴的真正含义，于是简单的说了几点规则<br />步骤<br />1、 明确主持人和记录者<br />2、 发散思维，获得尽可能多的线索<br />3、明确主题，约定时间（一个主题在40分钟左右）<br />注意事项<br />1、 鼓励自由畅谈、禁止
2010-10-15 13:15:00
684
原创 过程改进日记之学习Scrum2010-10-08：Sprint3演示会和反思会
<br />今天晨会人不多（大家都养成习惯了，即使现在Sprint之间，也习惯性的按时到作战室），有些人请假了。先说下，Sprint4结果没有完成，一个兼容性问题……，PM、Tester、DPM早就知道需要改，但最后几天，集体无意识的忘了……“算了，等下午反思会再好好说说”，大家都有此打算，也好，起码我们已经能分清楚晨会和反思会各自侧重不同了，这已经很棒了。 按预先计划，下午应该依次是演示会、反思会、以及需求头脑风暴会。上午，PM修订了下Sprint区间计划，把具体的会议记录、主持都分了下工，本着鼓励工程师
2010-10-15 13:14:00
500
原创 过程改进日记之学习Scrum2010-9-27：避免测试阶段的黑洞
<br /><br />直到今天的立会后，我才反应过来今天是Sprint3最后一天，燃尽图上最后的8Day全是测试任务，Unplanne倒是很多，那开发人员都在修改bug。<br /><br />昨天的立会中，某工程师是这样介绍他的工作的：“昨天修改了一些bug，今天还要修改些bug”，集体厥倒<br /> <br />在传统模式中，系统测试阶段，大量的工作就是围绕Bug讨论、修改、验证，中间会插入一些调整UI的活动，从我们目前的情况看，这个并没有多大改善，这应该是前期测试还不是充分的，当然我们现有的能力和
2010-10-15 13:13:00
262
原创 过程改进日记之学习Scrum2010-9-30：Sprint4最后一天，思考Bug看板的应用价值
<br />今天的“Sprint4”最后一天，先说下这几天晨会的情况 第一天：严重程度为1、2级的Bug做为任务上看板，我们觉得效果很不错，工程师讨论bug有明确的针对性。<br /> 第二天：UI方面的Bug、优先级在3级以上的Bug更新到看板上，虽然抄写量并不大，但是下班前抄一次，晚上工程师加班又增加了一些，加上状态变更，次日晨会看板上就不是最近信息了。 第三天：UI这边的问题没有变更，另外一主要工程师请假。看板逐渐失去作用。 今天，又一主要工程师请假，PM家里有事请假，Test生病了要
2010-10-15 13:13:00
426
原创 过程改进日记之学习Scrum2010-9-25：重新整理产品需求&代码走读安排
<br />一、重新整理产品需求PM的思考：经过3个Sprint，从目前看来，觉得我们在禅道上输入的产品－模块－需求树形结构比较散乱，当时一方面对系统不够熟悉，另一方面希望能够兼顾产品视图和工程视图，但这样做难度太大。 如果全部按照产品的角度来分解需求，那么有些底层的需求如何分解，比如各模块都需要的外部通讯等等，这需要我们从实践中寻找答案。 另外，配合中秋节前讨论的看板调整方案，我们将在新的需求上增加“How To Demo”的信息。 二、代码走读的安排今天我和DPM讨论代码评审如何安排，我们先总结了需要改
2010-10-15 13:12:00
297
原创 过程改进日记之学习Scrum2010-9-21：调整看板，准备Sprint区间计划
每个Sprint都要寻找改进的尝试，Team每一个成员都能够感受到快速的变化，在和PM的沟通中，她对于新员工的成长的反馈是“有别于以往的经验，新员工的速度成长让人惊讶，尤其是最新的新员工，他们使用我们UI殷勤的能力居然要超过几个月前到来的次新员工。这的确是Scrum的成效，这种方式大大缩短了问题的周期。 马上Sprint3快要结束了，虽然Sprint反思会要过N天才需要执行，不过我们这边早些总结过程方面的得失，并给出一些改进方案有助于提高效率。（我姑且这么说吧，其实是否真的这样我不也不确定） 这次Sprin
2010-09-25 15:52:00
400
原创 过程改进日记之学习Scrum2010-9-21：被吃掉的任务、Fix Bug算不算任务
<br />今天因故晚1小时上班，到公司先问SQA MM今天情况如何，答：“你自己去看吧，会吓你一跳”，看表情一定不是坏事，赶紧去看下。<br />!@#$%，今天的看板格外干净啊，不对吧。全体工程师打了鸡血了？还是我一觉睡了三天，居然把所有的任务都干掉了？<br />回到座位上，一片狐疑，问SQA MM“他们把任务条吃了？怎么我感觉和昨天的对不上啊。”<br />SQA MM：“你看出什么没有问题了吗？”，嗯，不至于考洒家吧，洒家看不出，不过俺每天拍照可不是为了耍宝，查下。<br /><br />我晕，还
2010-09-25 15:51:00
315
原创 过程改进日记之学习Scrum2010-9-20：准备沙龙
连续几天没写日志了，需要惩罚一下懒虫了，监督的人上哪去了啊曾经有过一个想法，给TeamLeader发邮件，请他们参观我们的Scrum方式，不过效果不理想，除了揪住一个TL和他对话外，再没有其它感兴趣者主动来问，一来他们太忙，二来他们太没有好奇心了，第三就是我们太没吸引力了。某日，老大问起，我就给了以上三个答案，老大的判断，主要是没有好奇心，这是个问题，好奇心是成长的基础，没有好奇心，当然也就没有尝试的动力，当然，还有一个可能是他们都不看好这样的模式:(没关系，这个方法失灵，还有更多的方法，我想在整个事业部内
2010-09-25 15:49:00
306
原创 过程改进日记之学习Scrum2010-9-15：你了解自己的任务吗？
今天早上，往公司赶的时候，收到PM的短信。说有事要晚点来。<br />立会的时候，看看貌似DPM还没到，老大在门口说了下，DPM临时有事请假了，一群人都有点发愣。“好吧，那我们就开始吧，谁先上？”既然Scrum倡导自治，向大家汇报，PM和DPM都不到，刚好让大家适应下。<br />每个人挨个回答三个问题，PM、DPM不在，感觉疑问也少了些，大家听过算数。节奏比平常快些。轮到某工程师MM，拿起一个任务：“今天做这个，‘切换设备，调整当前UI’”，<br />按照惯例，为了方便把任务信息登记到禅道中，一旦任务开
2010-09-25 15:48:00
276
原创 过程改进日记之学习Scrum2010-9-13：Sprint3计划会&Sprint2反思会
<br />Sprint3计划会<br />反思是痛苦的，但实践是飞快的<br />我们没有再找PM讨论需求是否太多的问题了，但我在会议上惊奇的发现几个现象<br />1、一个外围模块没有被安排在Sprint3中（PM会后告知，原本这些模块拿到Sprint2做就是为了让新员工尽快熟悉软件的，现在看情况来不及了，这些并没有答应客户，所以就先不做了）<br />2、一个模块用最简单的功能代替了之前较复杂的逻辑（同样事后得知，这是最初的产品设计，后来丰富出来的延到后期）<br />3、个别工程师的任务很少，看起来
2010-09-25 15:47:00
727
转载 普遍适用只是一个神话－摘自《平衡敏捷和规范》
<br />当我们发现某样东西有效时，就很容易认为它普遍适用。这正是银弹的特性，软件生产力联盟的Sarah Sheard对银弹的生存周期进行过令人愉快的描述。银弹的生存周期是这样一个过程：发现→成功应用→对成功的宣传→要素的建立和公布→首次（轻微的修改）重复运用→早期采用者的证实→无知的中层管理者在迥然不同的环境中对其进行过程化和实施→资金不足以及误用→由于最初思想的退化导致回报逐步变少→最终被丢弃并开始新的发现<br />引自：Sheard.S.July 2003,"The Life Cycle of a
2010-09-15 09:36:00
338
原创 过程改进日记之学习Scrum2010-9-10：Sprint3之前的讨论－再谈分工
下午，PM和DPM一边商量一边把需求分解成任务，我和SQA MM都没有参与，我在座位上看着禅道上一条条任务新增者，心理还在想着如何才能让Team的效率更高些，减少需求是一方面，日常沟通、行动上还是有诸多问题，有必要寻找相对容易解决、成本较低的方法。培训老师讲的Team成员的强分工和弱分工一直在我脑子里转，之前看《轻松Scrum之旅－敏捷开发故事》中那些主人公，随便什么时候工作都可以置换，虽然质量有高低，但都可以上手。实际情况可以这样么？我从头到尾思考自己从业来看到过的项目，但好像没有一个象书上讲得这样真正实
2010-09-15 09:09:00
420
原创 过程改进日记之学习Scrum2010-9-10：Sprint3之前的讨论－对话老大
上回写到为了我和SQA MM试图游说PM减少需求，但PM觉得这些都是向市场做出的承诺，已经不能再减少了，游说没有成功，我们俩继续讨论对策的时候，老大来参观了，得知我们的期望和努力后，慢悠悠的说“这是方法问题，我觉得你们应该提高你们问问题的能力了。” 这样也行，我略有不服，我已经问的很清楚了，但是PM说这些都是客户要的，我还能咋办，总不至于给她测谎吧。基于彼此的信任，我认为PM不会凭空杜撰的。<br />老大看我的样子，习惯性的卖关子：“我先问你一个问题，你写的博客是在浏览器里写的，还是在本地写好再粘贴到浏览
2010-09-14 13:12:00
290
原创 过程改进日记之学习Scrum2010-9-10：Sprint3之前的讨论－对话PM
<br />到9.10是Sprint2最后一天，燃尽图看起来完成了差不多一半而已，不知道工程师怎么理解，我还是感到比较彷徨的，虽然书上、培训老师都说不要过于关注燃尽图，但是这正如关心孩子学习，但不要关注成绩一样。要做到泾渭分明，太难了。<br /><br />下一个Sprint，我们能够改进能够哪些呢，已经有客户提出了新的需求。<br />在我们的商业文化中，如果一个产品有客户明确的需求，那产品战略就要向客户倾斜，因为客户愿意投入的起码是有市场需要的，而我们自己讨论的灵感能不能获得市场认可只是我们自己的沙盘
2010-09-14 13:11:00
379
原创 过程改进日记之学习Scrum2010-9-9：外部培训笔记
今天下午有个咨询公司给在我们公司范围做了个Scrum的培训试讲，我把主要的问题和解答记录下。（唉，都是我在问，兄弟部门的弟兄们仅问了一个还算有价值的问题。） 针对我们目前遇到的一些情况，在老师最后Q&A环节集中问了下，老师的一部分重要观点不是在回答我提问的时候说的，为了阐述方便，我也一并整合到问题的答案中，所以，老师的答案中也有我自己加进去的内容。大部分是老师原话我改得更顺畅些，极少一部分是根据老师零碎的提示改编，题目我自己取的。<br />㈠、过度承诺和分工模式<br />我：“我们尝试Scrum的方法有
2010-09-10 19:16:00
363
原创 过程改进日记之学习Scrum2010-9-6：对话Dev Leader
今天早上例会最后，我把上周五讨论到的重视质量，请大家明确验证方法说了一下，但从大家的反应看，应该是觉得对验证所需要的消耗是否值得还是心存疑问的。 而事实上，对这方面到底需要多大的投入，能产生多大的价值我也有疑问，毕竟，产品前期开发时间已经用了很多，市场打开后，已经有用户针对演示的版本提出了一些需求，我们的底线是不能比原来的开发模式消耗更多的人力和时间资源。 上周末，和老大商量后，我向几个开发Leader发出了邀请，告诉他们我们再做一个实践，有兴趣的话他们抽空来作战室观摩，也可以参加每日站会，但我们最近不打算
2010-09-07 18:44:00
599
原创 过程改进日记之学习Scrum2010-9-3：关于质量和热情
散会后，PM、DPM、我、SQA MM习惯性留下来交换下意见（这已经成为惯例了，有时候老大也会凑着这个时候进来发表下他的疑问或者新的外部信息）<br />DPM悠悠得说了一句话：“我觉得最近的任务完成情况看起来不太可靠”<br />我天，原来不是我一个人有这样怪怪的感觉，个别工程师表述任务完成情况潜意识的含糊了。 一、任务完成情况不可靠<br />看板的好处是透明，谁没有完成谁完成了一目了然，大家都希望晨会上自己的任务能够按时挪到Done区间内，有些任务暂时不能通过集成到软件中来验证，这时候，标准就变成自我
2010-09-07 18:43:00
349
原创 Scrum度量的一些想法
今天看《平衡敏捷与规范》，想到另外一些可以着手准备的度量，先记录下Scrum上的需求和任务都是明确的，Sprint会议应该做一些基础的度量，比如Task，可以根据下面的表来识别是否太粗的容易更容易延期，或者相反。（如图，数据是我杜撰的）如果把任务按照设计、研究、开发、UI、测试等来分，可以得到更多的任务估算准确度数据。<br /><br />另外，从需求方面来考虑，每个需求都会要分解成若干个任务，也可以从这里着手，来分析需求的变迁曲线，比如A需求，Sprint会议中确定的Task是否足够，最终完成时消耗的总
2010-09-07 18:42:00
421
原创 过程改进日记之学习Scrum2010-9-2：Sprint会议和关键任务
昨天没写，是因为昨天的故事在今天才有个结果昨天的晨会中有个框架调试的任务没有搞定，而这个任务的成果恰恰是多个工程师任务验证的一个依赖条件，因此，导致昨天乃至前天的部分任务没有能够验证。今天的晨会，大家心情都很愉快，因为这个阻塞任务可以移到Done区域了，很多相关任务也都可以验证完成了，按照平均每天搞定6Day的任务计算，昨天阻塞任务Done后，今天晨会一下子转移了11Day的任务后。燃尽图的趋势向理想趋势靠拢，这无疑是让大家都比较开心的。 这里有两个反思一：Sprint计划一定要共同做正如我在8.27的日志
2010-09-07 18:42:00
279
原创 关于需求的想法点滴记录－want & need
项目管理培训，其中关于需求的一些言论记录下。昨天在群里讨论到了需求管理，觉得有些信息可以分享下，于是先记录些。a、want & needwant：基于自己的理解，随着理解加深，往往会有更多变化need：基于能够解决什么业务问题来做评判，更多依赖专业背景来发现我个人理解的：所谓专业背景，应该避免“我觉得、我认为”等主观词汇，而是凸显用证据来证明需求的过程，举个例子，在讨论是否需要在办公系统的任务管理功能上增加周月年形式的日历视图的需求。可能的说法1：用户有了这个功能以后，会更方便的查看他所有的任务2、某同类软
2010-09-07 18:41:00
548
原创 关于需求的想法点滴记录（续）－上中下三策
项目管理培训，其中关于需求的一些言论记录下。这个我是从培训讲师那边听来的，但不知道他是不是版权所有者，等待更多信息。B、上中下三策上策：在第一时间发现变更的可能性中策：做好优先级，不做无谓的浪费下策：运用变更控制流程
2010-09-07 18:41:00
297
原创 过程改进日记之学习Scrum2010-8-30：新计划上墙
今天SQA MM忙着整理所有任务，准备Sprint2任务上墙，这次我们预期了两周的工作量，看起来任务数量较多。<br />我们目前还做不到测试驱动，所以基本上在每个需求的后面，都有一个测试任务（为便于查看，我们用蓝色的即时帖来登记测试任务。）<br />autobuild方面，由于开发这边忙于跨Team的进度协调，以及新员工工程接入等活动，还来不及把所有各工程师负责的DSW文件枚举出来，比预期进度要慢些。<br />今天在帖任务的时候，老大进来参观，刚好一个负责市场的同学进来，老大问他从墙上能看出点什么来么
2010-09-07 18:40:00
331
原创 过程改进日记之学习Scrum2010-8-26：考虑每日构建
每天，各工程师都有一些功能需要给测试验证，DPM都要知会大家准备，编译、制作安装包，如果没有通过验证，开发工程师修改后，需要能够马上编译，这样才能达到敏捷的要求。 目前我们的AutoBuild系统还只是DPM人工触发的，既然是敏捷开发，那就应该更快些，另外，老大和PM希望随时可以看到最新的版本，并且评估后给关键客户做评估。 基于这些需求，我们讨论，决定采用日构建＋工程师自主构建＋递交构建的组合方式。 1、日构建还是需要从用户培养开始，在Team中达成规则，每天下午16:30（暂定）前，工程师确保只有通过验证
2010-09-07 18:39:00
247
原创 过程改进日记之学习Scrum2010-8-27：下一阶段任务分解
终于一周过去了，由于这周并没有按照Sprint的方法来安排计划，只是按照看板的形式来确认每天的任务，所以完成情况的确不怎么理想，额外增加的任务，工程师对需求了解不够导致的工作量评估不够、新员工学习时间成本等等，使得这周的趋势和老大预想的完全一致。 嗯，正如我们所有人所说，发现问题是个好现象，我们有可以改进了，我建议应该花两天时间一个个需求细分，帮助工程师了解需求、分解逻辑，细化任务。PM：“在就马上行动吧”于是，就在作战室，PM和DPM把工程师一个个请进来，针对每个需求请工程师画出大致的功能分解图、解说开
2010-09-07 18:39:00
374
原创 过程改进日记之学习Scrum2010-8-25：Backlog也上墙了
今天晨会一看，我的天，SQA MM昨天把N产品的module和Feature都整到墙上去了，果然是工作麻利的能人啊，执行力超预期噢，真好！ 今天例会有个很可喜的片段 一新毕业的帅弟工程师（简称XD吧）简述他昨天的工作：“我在做某底层优化，我把A接口性能调优了，然后我发现B接口原来没有做容错机制，我加上了，今天我打算看看A和B同时处理的时候会不会影响C模块的效率”SQA MM：“那你看看具体那张任务帖可以移到Done栏目去”XD在看板前徘徊2分钟，嘴里念念有词：“我的Feature应该是这条，嗯……，好像这条
2010-09-07 18:38:00
252
原创 过程改进日记之学习Scrum2010-8-24：看板第二天以及过程改进工作规划
今天上午因故不能参加晨会了，9：40，赶紧跑到作战室看一眼，奇怪，怎么有些任务在Next中。问了下SQA MM，原来是今天的晨会再次评估所有任务，觉得有些人的任务看起来怎么也没法在一周内都完成，既然不能保证完成，不如明确工作目标，选择最重要最可行的做，于是，将一些已经明确的目标移到Next。美中不足的是Checked Out的任务占大多数，针对这个疑问，SQA MM对我的疑惑嗤之以鼻，有板有眼的教导我：1、如果没有召集正式的Sprint会议，而仅仅是评估一周的工作量，这样的计划实际上不符合Scrum的教义2
2010-09-07 18:37:00
296
原创 过程改进日记之学习Scrum2010-8-23：第一次使用看板
一大早上班，先去作战室瞄了一眼，空白！我以为上周末大家会把任务帖上去来着。今天的晨会按时开，周一早高峰难免有迟到的常规现象居然没有发生，真是令人欢欣鼓舞（我今天直接打车上班，小小的昂贵下了）晨会，PM手上攒了一把写好的即时帖，每个人说下计划在本周完成的任务，PM就一个个帖上去，有些同仁的任务没有细分的，也当场确定了。 第一天的形状被老大的乌鸦嘴不幸言中 太棒了，我喜欢这样的实践，一下子发现了很多可以改进之处。我看到的问题问题一：Not Check Out的不多，相映成趣的是被Checked Out的任务数量
2010-09-07 18:36:00
311
原创 过程改进日记之学习Scrum2010-8-20：下周任务细分和老大的乌鸦嘴
今日晨会，从部门会议室移到老大办公室隔壁的小房间了（以后用我就称之为作战室了），里面有几张沙发，座位有限，所以剩下的人只能站着了，我没等来他们自己主动觉悟，倒是座位不够了，他们也就站着了。原来他们已经做到臀下有座位，心中无座位了，哈哈。 晨会中对这墙上的空白模版，PM讲了下大概的要求，后面我们的SQA MM（她上周休假，第一次参加Team晨会）补充了一些关于Sprint看板以及燃尽图方面的知识。PM希望今天能够把下周所有任务都讨论、明确，更新到禅道系统中，考虑到第一次使用看板管理，本应由所有工程师自己整理任
2010-09-07 18:35:00
790
原创 过程改进日记之学习Scrum2010-8-19：预备看板管理
热度 1已有 79 次阅读2010-8-20 11:53|个人分类:过程改进|关键词:看板 日记 预备 改进 管理这个日志晚了一天，自我批评下昨天例会，会后和PM商量了一周来的实践成果。觉得例会中反馈出一些现象1、一些任务比预计的多花费了时间，这些应该是任务外延不清，导致额外增加了一些活动2、个别任务遇到障碍，需要其他Team支持的，有可能到忙碌到周五，被大家遗忘了3、和产品工作无关的活动，或者工程师请假，会降低工作节奏。这些问题的档案应该是很确切的，用看板管理就可以了，我们只花了不到五分钟就达成一致了。每
2010-09-07 18:34:00
324
原创 过程改进日记之学习Scrum2010-8-18 backlog or Feature list？（二）
例会，除了PM和我，终于那个新员工MM记得站着，其他人坐着，就例会本身的描述，明天没有变化我就不写了。省得搞得和天气预报一样。 今天尝试写一个Wifi相机的Bcaklog，诸如以下形式（节选）作为相机用户，我希望把相机上连上热点后，立即把缩略图发送到我指定网络图片库中，这样我的朋友可以随时看到我在哪里happy作为相机用户，我希望把相机连上热点后，可以将我的GPS信息翻译成地址发送到我指定的手机号码上，这样我最重要的人可以随时知道我的方位作为相机用户，我希望相机连上热点后，能够随时检查相机的固件信息，但我不
2010-09-07 18:33:00
846
原创 过程改进日记之学习Scrum2010-8-17 Backlog or Feature list（一）
今天例会照例只有我和PM站着，不过居然除了我之外没迟到的，可喜可贺。 今天是最近一个月要做的需求review，涉及三个模块，分成三次，参加者包括PM、DPM、UI Design、QAPM（产品测试负责人）主创开发工程师分别进场，轮流参加。这样可以避免浪费时间。（不过，我觉得有机会需要大家一起简单过一下，这样大家可以互相知道各自在做什么） 我们的需求包括了低保真界面和一些相对细致的逻辑，因此，大家很容易形成讨论的基础，虽然PM写的还是比较详细，但还是有些应用场景没有覆盖到。 需求评审实际上是传统模式的一个重要
2010-09-07 18:31:00
682
原创 过程改进日记之学习Scrum2010-8-16 每日晨会（二）
培训9：00开始，例会8：30，我手头要处理些东西，所以迟到了4分钟。今天是周一，习惯并没有养成其一：工程师们还是以周为口径来叙述，开口就是“我上周做了ABC、这周我会做DEF”，PM也会说上周发给大家的某文件请研究下。不是说这样不可以，但最好说上周五发给大家的文件，主要是思维惯性需要刻意的扭转过来，把以周为单位的叙述风格转化为以日为单位。 其二：包括周五我简单询问的MM，没有一个人意识到应该站着，我只好继续站着看他们坐着了，呵呵，这个我真不着急了，等待挖掘第一个有好悟性的同学。 上周五计划中开始编写Bac
2010-09-07 18:30:00
431
原创 过程改进日记之学习Scrum2010-8-13 每日晨会（一）
昨天第一次会议，约在九点，Outlook会议邀请中明确说明之后每天八点半，今天还是有迟到的，但情况好了很多，坚持下去，起码第一个效果出来了，上班迟到会减少。今天我和PM按时到，一个新员工其次到，然后是老大，后面陆续到，老大、PM、我其实都是站着的呢，我们不断走动，或者靠在椅子上（的确不太习惯，尤其要记点什么的情况下），但是其他人没有感觉到。 为了写这个，我问了下第三个到会的新员工MM。（我把她昵称改成MM后全部粘贴上来） 泥泥: 问你下，今天晨会，你注意到和昨天有啥细节不一样<br />MM: 报告的内容变
2010-09-07 18:29:00
506
原创 过程改进日记之学习Scrum2010-8-12 改变，从身边开始
前言：我们的软件开发流程已经有了比较明确的规则，也经过很久的实践考验，通过不断改进内部系统，总体上是传统模式＋FDD快速开发的结合。但考虑到目前软件基于互联网开发快速开发的主流特点，我们也需要与时俱进，提高我们的工程效率。重要的是行动，因此，在理论上没有更深入了解的情况下，我们还是考虑采用有些Scrum的实践，来帮助我们提高开发效率。为了帮助思考和改进，在老大的启发下，我想把每天的进展和思考都更新在思步的个人日志上。以便能够及时获得更多同行的帮助和指点。愿我们共同提高。－－－－－－－－－－－－－－－－－－－
2010-09-07 18:28:00
242
原创 培训管理，剃头担子还是豆腐脑担子
培训管理要做好，流程是最简单的环节，无非培训需求、计划、度量，但现在互联网信息丰富，各种论坛、沙龙、博客、乃至群，用得好的话自成一体，比单位里安排的内训目的性，效果都好很多。组织层面的培训，如果没有把准脉搏，极有可能变成一个剃头担子式的服务，一头热，即管理上重视，而工程师淡然。当然，最好是豆腐脑摊子，两头热。 培训按内容分，对于工程师而言，无外乎倾向流程或倾向技术：一是倾向流程
2009-09-22 14:13:00
376
原创 关于研发哲学：项目紧急，先把功能完成还是先修改缺陷
我不知道这个选择题是不是很容易说明白，所以我在群里问了下，谢谢China Tracy给的答案：“作为项目经理就是要考虑干系人的关注点， 他们在结项时的要求是什么，是要高质量的项目成果，还是要个大而全的系统范例”。和我前几天思考的差不多。这个答案非常正确，正确到了分不出初级和高级的区别，所以我很郁闷，我有一个貌似很高级的发现，但是我提问的能力太弱，高级的发现被掩盖了，就像我儿子问我，为什么小
2009-09-22 14:04:00
521
2
Directory Lister Pro
2010-03-25
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人