中小企业网站制作软件,那些做测评的网站好,广州版单一窗口,手机音乐制作软件[移山之道 14 章] 14.6 开发阶段的日常管理14.6.1 闭门造车#xff08;leave me alone#xff09;
荔荔#xff1a;我今天真失败#xff01;在办公室里坐了10个小时#xff0c;但是真正能花在开发工作上的可能只有3个小时#xff0c;然后我的工作进展大概只有两个小时… [移山之道 14 章] 14.6 开发阶段的日常管理14.6.1 闭门造车leave me alone
荔荔我今天真失败在办公室里坐了10个小时但是真正能花在开发工作上的可能只有3个小时然后我的工作进展大概只有两个小时
阿超那你的时间都花到哪里去了
荔荔就是我们以前说的 “我没看见你在写软件你到底在忙什么” 上面列出来的破事儿。每一件随机事情看起来都是挺重要的我就放下手里的开发工作。但是好不容易做完了刚想进入状态又一件随机事情来了……
阿超你要硬着心肠说 “不”。
当场景、功能都计划好的时候要给员工足够多的时间让他们投入到工作中去而不要经常打断他们。
要尽量减少非开发时间不要动不动就开“全体会议”。团队成员们自我时间管理也很重要。由于MSF鼓励沟通TFS也设置了不少提示Alert自动报告全体成员项目各方面的情况因此团队的E-mail会特别多。在这种情况下不要整天被E-mail牵着鼻子走。在Outlook上设置好邮件规则按下面的规则把邮件自动分类到不同的邮件夹中
1从直接老板来的发给你一个人的——马上处理。
2从团队成员来的、和项目有关的事情自动分配到一个叫“Team”的邮件夹中。
3从TFS来的状态信息如团队的check-in email自动分配到一个叫“Check-In”的邮件夹中。
4从公司其他同事来的与工作无关的消息如笑话大减价的消息等自动分配到一个叫“Other”的邮件夹中。
最好每隔两三小时集中阅读和回复一下E-mail。
荔荔河对岸的河曲数码经常把所有人都拉去做“封闭开发”这样是否就能避免干扰
阿超我们做开发软件并不是让团队像被关在监狱里一样。要有大家自由交流的时间团队成员们在无拘束的环境中会更乐意提问和分享这会比召开正式会议强迫每个人分享好得多。在“封闭开发”的情形下领导也更有可能每天、每小时来询问项目的进度这种团队内部的干扰源并不会因为团队搬到一个监狱里而消失。大家还记得MSF的“充分的授权和信任”
果冻我这里还有笔记。
小飞另外我经常去看测试人员又发现了什么Bug有时就花时间研究和修复它们。
阿超可以等第二天会诊之后再看看是否值得马上修复。
果冻这样新建的Bug要等到第二天门诊之后才能给开发人员处理是不是会影响进度
阿超不一定。
提示
1开发人员在开发阶段最重要的任务是把规定的功能完成
2在项目初期可以不用集体会诊开发/测试人员可以直接处理“缺陷”不必等待。
3在任何时候测试人员都可以把“缺陷”交给开发人员但是只有会诊的人员才能改变会诊决定。
14.6.2 每日构建
阿超我好像有几天没有收到每日构建Daily Build的报告了。
小飞已经有一阵子 Daily Build 没成功了。
阿超哦我们上课的时候不是说过“每日构建”的重要性么
小飞我同意在我们有时间的情况下要做每日构建但是当工作忙的时候我们的确实没有时间去管构建的问题。
阿超这么说还是应了那句话——在理论上理论和实践是一回事而在实践上理论和实践是两回事。
阿超指着窗外河对面的工地。
阿超他们在建楼房吧。
小飞对据说是软件学院的新大楼。
阿超那他们的脚手架自从搭好了之后就没有垮下来过吧。
小飞那当然不会俺爹是干这一行的所有的工人和材料都得运上运下脚手架要搭得特别结实。
阿超那你爹他们有没有因为工期紧就凑合着搭个架子就往上盖楼或者脚手架倒了也不管
小飞那哪成要倒下了就要出人命了哪还能盖楼
阿超对呀我们的软件构建就和脚手架一样每天都要立着倒下来就麻烦了。
小飞不过我们搞开发的都有点不屑搞构建没有写程序来劲。
阿超不会建脚手架的小工你爹会要么
小飞不会。
阿超不会做构建的程序员就像不会搭脚手架的小工运球不熟练的球员。这样的程序员我们也不要。
小飞我明白了。
下午阿超在喝水的时候碰到小飞来报告说Daily Build正在运行中。发现的几个错误都改正了。估计晚上就可以产生一个新的构建了。
阿超了不起这么快就做好了。
小飞超总我想提一个和我职业发展有关的问题。我们接受的可都是科班的软件工程教育我们当时的院领导说我们毕业后都是要朝CTO发展的至少是软件金领我当然知道这是遥远的将来的事但是我总觉得我至少可以做一个软件白领吧这些构建之类的事情嘿嘿是不是要由所谓的软件蓝领来做
阿超问题提得好……
他望着这位将来的CTO、软件金领突然想抄起身边的塑料水桶把水都从他的白领里灌进去。他喝了一大口水退到窗边勉强把这个念头压了下去。阿超看着窗外的操场——
阿超听说你篮球打得不错
小飞还行常和二柱几个玩。
阿超你提到大学的课程让我想起大学的篮球课。我们当时考试的科目之一是定点投篮。老师叫每个要考试的同学站在罚球线上别的同学负责捡球考生就站着不动一个一个地瞄准了投如果进了一个球老师就开始算分。平时玩球的同学都是十个进七八个连运动细胞不多的同学都是十个球中五个以上皆大欢喜好像大鲨鱼奥尼尔罚球也不过50%上下大家都有NBA球星的感觉。另一个考试科目是两人配合上篮当然这是在球场空荡荡的时候进行的大家接/传/投一气呵成颇有马龙和斯多克顿的风范觉得篮球“技止此耳”考试后我们意犹未尽和在一边玩球的同学打球赛尽管我们“定点投篮”和“二人配合”的分数都很高但是我们都输得很惨……
小飞为啥
阿超因为我们运球、传球都不熟。这都是我们平时不屑练习的东西即使勉强到了篮下投篮都是在踉跄之中完成当然没有考试时候的准星。
小飞超总您把我绕远了您的意思是
阿超我觉得大学的软件工程课本来要教全面的技术但是考试往往只考定点投篮和无防守情况下的配合。所以有些大学的高材生到了实际工作中很多“蓝领”的基本功比如实战中的运球、传球都不灵他们津津乐道的定点投篮十中八九的功夫也没有发挥的机会了。我还没有见过从天而降的白领或金领。所谓的大拿们都是从蓝领摸爬滚打出来的。换句话说我眼里没有白领或蓝领只有“汗领”——就是大家都得出汗干活。
小飞你是说构建就像运球、传球……好我明白了。超总下班后我们球场见
14.6.3 构建大师
头碰头会上大家发现最近连续几个构建都不成功测试组都拿不到新的版本没法进行测试。
阿超手里拿了小飞整理的“导致构建失败的失误列表”分送到每人手里表上列举了错误的类型和导致错误的签入以及牵涉的成员。
大栓看来拿不到新的构建版本的原因有这些——
1构建在开发人员本地机器上就不成功。
2构建在本地成功在服务器上失败。
3构建在本地及服务器上成功但是基本功能不能使用导致无法进行测试。
阿超试着对症下药很多事情我们在培训时都讲过了——
1强调基本开发流程注意编译要产生deBug | release两个版本。
2签入时必须从TFS同步下载所有最新的版本再编译而且个人的签入要做成一个Shelveset成为原子操作而不能把一次修改中的所有文件分成几次签入。
3这时我们以前做的单元测试和构建验证测试BVT就要发挥作用了每一个开发人员在签入前都要运行所有的单元测试和构建验证测试确保没有问题后才能签入。
我们要让团队中做事不仔细的人慢下来这样能减少他们的危害。将欲取之必先予之。阿超进而建议——
对于下一个导致构建失败的成员授予“构建大师”Build Master称号构建大师做下面的事
1负责管理构建服务器。
2调试构建负责找错并分析出错的原因。
3负责把“构建大师”称号和责任交给下一个导致构建失败的成员。
4“构建大师”同时向团队的“腐败基金”存入50元以供大家将来“腐败”之用此项可选。
14.6.4 宽严皆误
上次头碰头会议后各个小组都进一步强化了单元测试和BVT。
下午果冻发了一封E-mail标题是“我受不了啦”内容如下——
我的签入流程
1代码写好本地测试通过代码复审通过。可以签入了。
2同步TFS上最近更新编译deBug | release解决版本冲突半小时。
3安装最新版本运行本地单元测试BVT一个小时。
4提交到TFS上发现有版本合并冲突因为在第2、3步的时候有人签入了和我的代码有关的新修改。
5如果我简单地合并版本并且签入很有可能会导致TFS 上编译失败。但是如果我为了保证质量在合并后本地编译并运行各种测试这相当于重复了第2、3步。当我再次提交签入重复第4步时有可能碰到新的版本冲突。这样循环往复以至无穷……
二柱发了E-mail第一句话就是
在理论上理论和实践是一回事而在实践上理论和实践是两回事。
然后也抱怨了类似的问题似乎大部分时间都花在了没有价值的“同步/编译/验证/再同步……”的循环中。
荔荔似乎应该在签出一个文件的时候加上一个“防止别人签出”的锁这样就没有冲突了。
果冻但是如果你锁住了file1要签出file2与此同时我锁住了file2要签出file1这样我们都进入了死锁……
小飞我刚刚同步TFS然后编译就不成功了。我在一台全新的机器上重新试了一次也不行。这至少证明不是我引起的问题。现在我已经没法工作只好到“顶球”喝两杯去了。谁把错误修好了就给我发短信我就回来上班。
阿超除了构建大师所有开发人员都可以到“顶球”去玩。
构建大师我已经连续三天错过了午饭时间谁能帮我从顶球带两个烧饼回来另外能不能不要在午饭前安排构建要不然铁打的胃也受不了。
经过一个多小时的忙碌构建终于好了但是构建大师问阿超现在构建成功了明天呢
阿超让我想想……
阿超晚上把情况和同事们的意见报告了愚公阿超在E-mail最后写道
团队有两条路可以实行
1很严的规则和流程控制这样会保证很高的签入成功率如果一个人根据流程来做几乎肯定能成功。这样构建质量高但是团队的进展会受到限制。极端情况下整个团队的进展被序列化为一系列个人串行签入操作。
2宽松的规则和流程每个人随时可以签出签入签入时的成本很低但是签入成功率不高构建质量低极端情况下所有人都可以签入、同步但是没有人能正常工作。
哪一种是最好的呢
第二天一早阿超就看到了愚公的回复
不审势即宽严皆误从来治蜀要深思。
阿超心想那什么是我们这个团队目前的“势”呢他根据每一个步骤宽、严各是什么做法和当前团队的情况势列出了一个“宽”或“严”表如表14-7所示。
阿超认为当团队成员的行为只是影响到个人的时候就尽量放松让个人根据自己情况处理当其行为影响到整个团队的时候就尽量严格因为整个团队都有可能会受影响。同时我们要提高可预见性——明确构建大师的职责公开显示固定的构建时间。
表14-7 宽严表 步骤 宽 严 势 签出 自由签出 签出时候将文件上锁 很多人都会同时编辑同一文件 本地单元测试 不要求 要求 每个模块都要求写单元测试 本地check-in test签入测试 不要求 要求 BVT还没有完成 签入时间 任何时候 每天固定时间开放 目前签入情况很混乱 签入冲突处理 合并后即可签入 合并后再重新编译测试再提交 重新测试会花费比较多的时间 签入必须经过代码复审 随意 必须 开放人员有一半是新员工必须通过代码复审建立良好的规范 签入时必须运行代码分析工具 不要求 要求 代码分析工具尚未配置好 签入时单元测试必须同时签入 不要求 要求 每个模块都要求写单元测试 步骤 宽 严 势 签入必须是多个相关文件同时签入 不要求可以签入单个文件 要求 保证每一个签入都不会导致构建失败 签入必须和一个工作项关联 不要求 要求 所有的工作必须有工作项跟踪 设定专用网络服务自动处理提交的ShelveSet、构建、BVT、然后签入代码 不要求 设置 需要很多人力来设计并维护
续
表
综上所述移山团队目前的开发流程如表14-8所示。
表14-8 具体流程 时间 总体 管理/程序 经 理 开发 构建大师 测试 8am~10am 开发人员可以同步代码这时只有非常要紧的签入才能经过批准签入TFS 9am—— 头碰头会议Bug会诊分配Bug 同步代码构建根据自己的任务Bug情况决定今天的工作 测试新版本新建Bug 10am~12am 代码签入时间经过正常代码复审及其他流程后代码连同单元测试才能签入 程序经理组织必要的会议 单元测试代码复审同步/解决代码冲突签入代码 准备构建服务器 12am~1pm 午饭时间 1pm~3pm 构建/安装/基本测试/宣布版本质量见后 待命随时准备攻克问题 全程监督执行负责把导致构建失败的缺陷找人修复并签入 运行基本测试 3pm~6pm 开发/测试人员继续工作 运行BVT后宣布此次构建质量失败/可测/可用 聪明的测试人员此时就开始测试并报告缺陷 6pm 晚饭及机动时间 阿超我特地把紧张的构建及待命阶段安排在午饭之后这样大家至少可以安心吃饭了。 14.6.5 小强地狱Bug Hell
在这一次的头碰头会议上平时不主动发言的阿亨也说话了。
阿亨开发的同志们你们手里有那么多小强为什么都揣着掖着不舍得修复让测试人员有事情做测试人员反映因为现有的小强没有被修复有越来越多的小功能点不能进行测试我们都要没事做了。
大栓我们的开发任务很重必须先把新功能全部实现后再修复旧的小强。
阿亨这是不对的我们有些小强在你们手头很久了看似举手之劳为什么不尽快修复让我们测试组能继续完成测试
二柱我们都是按优先级来进行的开发新功能的优先级远大于修复小强。
阿亨但是有些开发人员手里头有二三十个小强难道数量不是一个考虑因素
阿超我同意随着项目的深入每个人同时要开发新的功能修复以前的缺陷。由于没有明确的优先次序一般人都愿意把时间花在开发新功能上。但是我们的确需要平衡进度和质量。有这样的一种方法
小强地狱Bug Hell
如果开发人员的小强Bug数量超过一规定值则此君被送入“小强地狱”在地狱中他能做的唯一一件事就是修复小强直到小强数量低于此阈值。
这一阈值由团队根据实际情况来确定要注意开发人员同时“入狱”的人数应在全体成员的5%~30%之间若比例太高则要考虑阈值或小强数量的计算方式是否合理是否只包括某一严重程度以上的Bug。
在项目过程中阈值不宜频繁调整最好事先宣布阈值。
大栓但是我们已经违反了“最好事先宣布阈值”这一规定。
阿超如果我们现在要让20% 的同志入狱需要马上运行一个TFS 查询看看这一个阈值是多少是15好那我们现在宣布给大家三天时间第三天后小强数量达到或超过15 的开发人员请入狱然后每天早上9点头碰头会议时统计并宣布入狱/出狱名单。
大牛 其实先把所有的功能写完也不错至少我可以告诉客户“功能写完了”让他们高兴高兴。
大栓大牛这不就是咱们以前项目的情况么你一直问“功能都写完了为什么还不能用”? 我们一直说“还有一些小问题”然后小问题总是不能解决因为要真正解决这些“小问题”的话我们还得重写一些功能。
阿超对很多问题甚至是大问题都隐藏在目前的小强后面如果一味赶所谓的“进度”到时候有些小强就变成了大怪物因为我们已经在错误的基础上搭建了很多新的逻辑和功能这时再来处理一些历久弥新的小强就有投鼠忌器的麻烦。
阿亨那怎么办
阿超我们要分析小强看看这是一个小问题解决了就万事大吉呢还是冰山的一角解决后也许会发现更多、更棘手的问题。或者看似不经意的一个小强会让很多人加班重新实现功能——这就成了设计变更需求——DCR。
14.6.6 DCR Tell mode v.s. Ask mode设计变更
在项目早期如果大家觉得要做一个设计变更可以用告知模式Tell-mode的形式就是说修改方必须通告所有关系人“我在这里修改了某某界面。”但是修改方不必取得其他关系人或者模块的事先同意就是说可以先行设计并编码。当然如果其他关系人不同意修改还是不能签入。
当项目进行到稳定阶段Tell-mode 要改为请求模式Ask-mode这时修改方必须先问“我是否可以在这里修改某某界面”当然还要有更详尽和充分的理由得到肯定的答复后才能进行修改。这时的默认回答是“不”。
14.6.7 每周进度报告——还有多少事没做完
头碰头会议。
大栓我有一点不太放心……
大牛哦为啥我们大家都干得很欢。完成任务应该没问题吧。
大栓我们每天都在签入新的代码每人都很忙但是我总觉得不太对劲。会不会越做事情越多呢
阿超这时我们可以看看各种报表首要推荐的是“Remaining Work”。
请看图14-2。
这个报表告诉我们究竟还剩下多少事情要做。我们要分析这么多签入到底是否解决Resolve了相应的问题如果是那么我们的任务数量应该逐渐下降但是从图14-2上我们看到深灰色的任务和缺陷还在缓慢增长。而浅灰色的“已完成任务”却一动不动这就要引起我们的注意了。
可以在报表设置控制板中进一步选择你要报告的内容如Iteration选择里程碑Area选择项目的不同部分也可以修改报告的起始和终止日期等。 [注: VS2010 还提供了 burndown chart 等, 参加中科大同学的博客, 例如
http://www.cnblogs.com/OMG-Team/archive/2011/09/30/2196150.html] 14.7 代码完成什么叫代码完成Code Complete[1]
就是我们认为所有应该写的代码都写了所有应该实现的功能都实现了。
那就是可以发布了
不代码都写了。但是代码中可能有很多小强各个模块之间的合作还有很多问题。Beta用户看到产品后说不定要提不少修改意见。但是我们毕竟是把“我们认为所有应该写的代码都写了功能都实现了”。这是一个了不起的事件。一个团队经过几个月的努力从无到有从简到繁把几个月前的远景变成了可以运行的软件也许我们还有许多问题但这无疑是很值得庆祝的
在TFS上就是所有的代码任务Task都完成了。也许我们现在还有许多缺陷Bug还有一些与测试相关的任务。这些事情要留到以后稳定阶段才能全部解决。 14.8 讨论问 每次里程碑结束后我们向客户汇报的时候客户总是会惊讶地说某某功能不是我们当初商量的那样啊而PM却也同样一脸诧异地说不对啊当时咱们就是这么说好的啊有文档为证。客户不干了威胁不加/不改xx功能就如何如何这时PM该怎么办?
大牛我们在合同里要写明到底我们要交付的是什么这就要看PM的分析和说明能力了。有时要对客户说“不”。同时我们在需求说明中也要从用户的角度去描述问题和解决方案这样用户才能了解他们最终会得到什么。
问 项目开发中后期Dev lead用工具一统计乖乖足足xx万行代码xx千个存储过程可是每到给客户演示时却不时出现程序的各个功能相互不配合不能自圆其说的尴尬场景Dev lead很郁闷想想自己可是没少加班啊代码量也够多可是问题究竟出在什么方面呢
阿超一个原因是每个人都沉浸在“我要写出最强大的某某类或某某模块”不停地优化一些没有人用的功能但是真正能够为其他模块使用的功能却未能实现。他们忘了他们写的代码是给别人用的而且是为了解决用户问题的。所以这个时候我们要想想“用场景驱动”的方法保证典型的用户场景能够实现。如果从“场景”出发各个模块的互相集成就能得到充分的测试按照场景演示起来就更有保障了。
问 在项目开始之前, 有很多队员还没有接触过编程语言例如C#导致PM在分配任务时很难用时间来衡量就拿写一个Web Service这一模块来说一个熟练的程序员可能只需要两个小时而对于C#的初学者来说就得先花两天来理解Web Service的实现机制和原理。在有限时间的催促下导致一些紧急的任务不断向高手集中而初学者的任务越来越少。这时应该怎么办
阿超对于这些队员可以考虑在他们自己的任务估计值之上再乘以4。另外如果你是写一个商业项目请不要让连开发语言都没有接触过的队员进行开发工作。并不是非得 “写” 程序才是对项目有贡献有时不写也有很好的贡献。如果他们有热情就从测试开始学习吧。请参看前面提到的“大马哈鱼洄游模型”。 [1] 有一本很著名的书叫《Code Complete》中文翻译为《代码大全》。事实上此书不是各类代码的汇编“大全”。Code Complete简称CC是“代码完成”的意思。
