牧心

关注敏捷、关注人

开始写BLOG

2009年05月03日

Amazon五星级项目管理图书《Manage It！》已发布试译章节索引

《Manage It！》已发布试译章节索引阅读全文>

发表于 @ 2009年05月03日 11:19:00|评论(loading...)|举报|收藏

2009年06月15日

分离需求与GUI设计——保持项目节奏实践之七

我们希望系统解决的问题通过需求得以体现。GUI设计是要体现出GUI如何引导用户使用系统以解决他们的问题。很多项目都将GUI设计混同于需求的假面之下，这很让人讶异。如果你的项目总是陷于无尽的需求工作之中，看看问题是不是出在GUI设计上。 GUI是设计，不是需求凯伦，程序经理我在一家新公司工作时，试图拯救一个陷入“需求地狱”的项目。需求文档已经达到300多页，而且远未完成。阅读这些文档后，我找到了原因。所有的GUI设计都被记录在需求文档中。GUI设计没有放在项目的设计阶段，业务分析人员和GUI设计人员试图将所有的GUI需求都放在需求文档中。他们使用了功能强大的图形设计工具，并在需求文档中定义GUI。我向他们询问原因，他们看着我，说道：“这些是GUI需求。”我建议他们认真看看GUI设计，并且考虑这些设计是否应该跟希望系统解决的问题放在一起。GUI设计不应放在需求文档中。最终，他们同意采纳我的建议，我们也可以逃离需求地狱了。而且，由于我按照逐个功能重新组织了项目，GUI设计也就跟各个功能结合在一起了。我们定期检查整个GUI的一致性，但是这与需求无关，这属于设计。人们很阅读全文>

发表于 @ 2009年06月15日 17:17:00|评论(loading...)|举报|收藏

2009年06月13日

通过用例、用户故事、角色和场景来定义需求——保持项目节奏实践之六

要减少不必要的代码，有一个好方法：想想谁会使用系统，又该如何开发用户需要的系统。有很多项目都试图通过定义功能性和非功能性需求来确定需求。可是这些需求没有说明一个人如何使用系统，以及一个功能在何种场景下必须运行。需求收集的方法应该为项目团队提供上下文，这样才能深入理解需求。谁需要那个支票账户？克拉丽莎，资深经理我的项目团队陷入困境。他们实现了一堆只开发完一部分的功能，可是没有哪个能够真正运行。我召开了一个会议，以决定接下来该做什么。在会议上，我想知道：为了完成项目，哪些用户是他们的首要服务对象。他们看着我，脸上毫无表情。“你们看，我们是一家银行。我们希望年满18岁、将要进入大学的人们首先使用我们的服务。还有住在郊外的妈妈们，她们还有其他资产，75岁的老奶奶，以及年方15已经靠做家务挣得零花钱的孩子们。我们可以为他们提供不同的理财服务。如果他们走进来，我们希望他们成为我们的客户。对于这些不同类型的客户，我们真地想过要给他们提供什么样的产品么？” 他们以前太过专注于系统的内部功能，忽视了系统真正要为之服务的用户。我们把期望捕获的用户重新进行了排序，项目团队因此得以完阅读全文>

发表于 @ 2009年06月13日 20:15:00|评论(loading...)|举报|收藏

2009年06月10日

Google Translation Toolkit初测——初具雏形的翻译IDE

Google Translation Toolkit 是google刚刚发布的在线翻译平台，初步评测结果如下：说明：在settings里面有两个选择：第一种：让目的文档中填充它翻译的结果；第二种：在目的文档窗口中直接放置原文以下测试方式，选择第一种设置：已尝试如下三种方式： 1、提供英文页面urll，直接让其翻译，结果：翻译质量不行，而且格式乱掉，它自己加了很多span 2、将英文web页面另存到本地，再上传文件让其翻译，结果：同上； 3、提取html标签内容，另存为word文件，再上传，让其翻译结果：格式同样乱掉，它自己很“智能”地处理了一些标签，结果更乱了。。..-_-|||||.. 当setting中选择显示原文时，上述第一和第二种方式生成的文件同样含有n多span，无法使用。第三种方案翻译起来相对比较方便，但是如果要调整html标签的位置相信比较麻烦（要调整，是因为语序上的变化）， =============== 如果在环境中选择show toolkit，屏幕下方会有工具箱出现，目前看来，字典比较方便，但是解释比较简单阅读全文>

发表于 @ 2009年06月10日 00:38:00|评论(loading...)|举报|收藏

2009年05月28日

准备重构——保持项目节奏实践之五

重构是对代码的简化，无论是产品代码还是测试代码。重构不等于重新设计，只是简化而已。重构过的代码不会改变它的接口，只是更简单。我的代码不见了哈尔，初级开发人员我现在参与的项目是离开学校后的第二个。在第一个项目中，经理听了我的代码工作估算后说：“好，既然你还是个新人，咱们就再多加点儿时间吧，这样你可以把学到的经验应用到写好的代码中。”我觉得他这么做纯属多余，不过没关系，我还是加倍努力，在截止日期来临之时完成了手上的工作。接下来，我了解了整个系统真正的运转方式，就得修改已完成的工作了，不只耗费了所有额外的时间，而且还多用了一点点。让我感到惊讶的是：为了解决问题，我没有编写更多代码，而是简化了现有做法并去掉一些代码。我的代码不见了。现在这个项目，我使用了持续集成，而且一边开发一边重构。在开发时，简化并清洁代码，而不是改变设计，这让我对自己手上的工作和开发速度有了更清晰的认识。而且，我的代码仍然在继续消失。如果你曾经随项目进展计算过代码行数，要是项目采取顺序式生命周期，或是将集成和测试放在项目临近结束时进行，那就会看到一个S形曲线（见图9.1）。可以注意到，开始集成和测试后，阅读全文>

发表于 @ 2009年05月28日 20:51:00|评论(loading...)|举报|收藏

2009年05月19日

多几只眼睛盯着产品——保持项目节奏实践之四

邀请团队成员相互复查工作。复查的形式并不重要，结对编程（pair programming）、伙伴复查（buddy review）、同行复查（peer review）、走查（walk-through）、正式代码检查（formal code inspection）都可以。复查能够为项目方方面面带来好处。项目经理要为团队提供多种方法。这些方法以特定顺序介绍：从最不正式到最正式。以我的经验来看，这也可以从最有效和易于保持的，到最没有效果和难以维系的。结对编程。先不要假定“这里没人愿意这么做”，要允许大家这么做。（而且可以提醒大家，他们已经完成过结对调试了。）我会问大家谁自愿进行结对。我建议他们在开始之前，先去阅读一些相关资源，比如［WK02］和［SH06b］，还有http://www.pairprogramming.com。不出意外的话，会有人愿意尝试结对的。相对独自工作来说，他们可以学到如何通过结对编程使工作变得更有效率。除了减少缺陷、加快开发速度外，结对编程还能带来很大的好处：有两个人完全熟悉并知道如何处理同一块代码。而且，如果人们经常切换不同的结对对象，他们就会深阅读全文>

发表于 @ 2009年05月19日 17:52:00|评论(loading...)|举报|收藏

2009年05月15日

按功能实现，而不是按架构——保持项目节奏实践之三

逐个功能进行实现和测试哈威、维贾、道、兰迪、肯和梅布尔，负责提醒功能的团队我是哈威，团队的头儿。我们的开发人员包括维贾、道、兰迪和肯，梅布尔是测试人员。我们在GUI、平台、硬件集成以及几个方面都有专家，而梅布尔无所不知。（背景中传来笑声。）刚开始的时候，我们试图先把架构开发出来，再制订规范，告诉大家我们在做什么。我们每个人各自负责一块，最后再放到一起。可是一切都没有按计划进行。因为即使我们有规范，在开发各自的组件时，我们总会改变些什么。梅布尔曾经听过有关按功能实现的说法，并告诉了我。我问大家是否愿意组建一个基于功能的团队。嗯，其实是基于功能集合的团队。我们开发所有的提醒功能，一次完成一个，从前端到后台。梅布尔会负责测试。开始时有点儿困难，不过习惯之后，我们添加功能的速度让人惊喜不已。我们不再是每个人开发很多代码然后再集成到一起，而是只添加每个提醒功能需要的代码，再进行测试。梅布尔保证我们不要出现系统级别上的问题，我们保证每个提醒功能不要出问题。我们的开发速度如此之快，不久就有新的功能需要开发了。现在，有些其他组也在尝试我们阅读全文>

发表于 @ 2009年05月15日 17:00:00|评论(loading...)|举报|收藏

2009年05月10日

为构建创建自动化冒烟测试——保持项目节奏实践之二

不管使用持续集成与否，都应该为构建产品创建自动化冒烟测试。冒烟测试仅仅是为了验证要构建的版本没有问题。你想添加多少回归测试都可以，我不拦着，但是使用冒烟测试，是要知道当前的构建版本是否对大家有用。有了自动化冒烟测试，项目团队就可以知道是不是有人破坏了当前构建版本。如果能尽早知道一个构建完成了，你就可以在其基础上做些自己想做的工作。要是必须依赖其他开发人员或是测试人员才能知道当前构建版本出了问题，那你就不能以最快的速度修复当前构建版本了。别让烟跑出去！梅瑞狄斯，资深测试人员作为测试人员，寻找问题是我的职责所在。而且，我也很擅长这个。我有一句座右铭：“别让烟跑出去。” 有一次，我加入了公司的一个新项目。开发人员以前从没有与专业测试人员一起工作过。我拿着一张有15个缺陷的列表，走到他们中一个人的面前，然后说：“你得说说这是怎么回事，要不我把这些问题提交到缺陷跟踪系统里面如何？”他们都惊呆了。我向他们说明，这些缺陷通过一个自动化冒烟测试都可以找出来。没有哪个缺陷需要靠我的专业知识和经验才能发现。我不想浪费时间找出这些易于发现的缺陷，而是要找出阅读全文>

发表于 @ 2009年05月10日 22:24:00|评论(loading...)|举报|收藏

2009年05月08日

持续集成——保持项目节奏实践之一

第9章保持项目节奏项目经理不但要用管理实践掌控项目，还可以欢迎团队改变自己的技术实践，从而获得更大收益。本章包含的一系列实践，能为项目带来很多好处。项目经理和团队要根据自身的实际情况，判断如何调整、使用这些实践，而不要强制推行。如果你认为它们有所裨益，不妨将其介绍给团队，并欢迎团队积极尝试。 9.1 在项目中使用持续集成开发人员用一两个小时编写一段代码，对其进行编译，测试，复查，构建，运行冒烟测试，并验证做出的改变不会破坏现有系统代码，再将其签入到代码库中。持续集成就这么发生了。[1] 持续集成可以让开发人员马上得到所做工作的反馈。他们开始考虑将大任务拆分成更小的部分（这可以让他们以更快的步伐前进），还能尽早识别出项目的集成风险。持续集成让开发人员每天都能有所收获，帮助项目团队找到符合自己的节奏。开发人员只有在完成了某个功能的代码后才将其签入，这就是按阶段集成的方式。有些开发人员一周签入一次代码。有些更糟糕的项目，开发人员一到两个月才签入一次代码。按阶段集成会打断项目的节奏。构建时出现的问题，会中断设计和编写新功能代码的人们的思路。他们不得不记住很多小细节，而这些小细阅读全文>

发表于 @ 2009年05月08日 10:49:00|评论(loading...)|举报|收藏

2009年05月07日

掌控项目节奏，做到了如指掌

（图片来自：http://www.flickr.com/photos/cuppini/）节奏，无所不在。春夏秋冬，日升月落，这是大自然的节奏；日出而作日入而息，朝九晚五，这是人类社会的节奏。生活有了节奏，人体的各个构成部分、乃至各个细胞才能正常运作，以保证整体的健康。社会中有节奏，而不是朝令夕改，大家才能安居乐业。项目管理同样如此。《Manage It！》第8章“掌控项目”第1节就名为“掌控项目的节奏”。其中说到：节奏，每个项目生而有之。有些项目节奏混乱，进展缓慢。有些项目就像坐上了火箭，倏忽间，团队就完成了更多工作。所有的项目都有节奏，不过它会随时间而变。观察节奏是项目经理的职责，你还要看出来哪些实践是否能够帮助项目建立并维持合理的节奏，保证项目取得成功。项目的生命周期越接近于顺序式生命周期，项目的节奏就越有可能随阶段发生变化［Rot04a］。在早期阶段，项目看起来就像遭受了很多痛苦，项目经理也不知道需求何时冻结、设计何时稳定。有些项目会“神奇地”找到出口，在进入实施阶段后，节奏逐渐显现出来，而且日趋稳定，因为该做的决策已经做了，而且得到了实行。假定没阅读全文>

发表于 @ 2009年05月07日 10:59:00|评论(loading...)|举报|收藏

2009年05月06日

令人恍惚的日程——项目经理应该小心的游戏之十六

下星期二，来自总部的大人物就要来视察了。或者你可能要在十个星期后做上市演示。不管怎么样，你要面对一个不可改变的日期、一系列充满野心或是不可能实现的功能集合，而且这些功能必须要在那个日期之前完成。无论是否已经测量过团队的开发速度，你知道团队是无法在截止日期来临之时完成所有的功能了。看起来团队面对着日程，都已经处于恍惚的状态了。有时，这就是团队对于“幸福日期”的回应。图6.16 令人恍惚的日程首先，要创建项目的仪表板（dashboard，见第11章），再测量进度，从测量开发速度开始。然后考虑采取如下行动。如果还没有用迭代式开发，赶紧把剩下的项目分解成迭代吧，迭代时间越短越好。如果在不可改变的截止日期前有10个星期的时间，项目最少要分解成5个迭代，最好是10个。每周一个迭代，这可以帮你不断调整工作的优先级。迭代的目标是要完成某个功能或一组功能，这包括功能的开发、文档、测试，以及其他产品对于“完成”的要求。如果上市演示需要在线帮助，除非一个功能具备了在线帮助，否则它就不算完成。在一个迭代中要集中精力，每日站立会议对此会有所帮助。项目团队的目标必须放在要完成的工作阅读全文>

发表于 @ 2009年05月06日 11:24:00|评论(loading...)|举报|收藏

2009年05月05日

互联网时代，咖啡和茶不再重要

这两天在上班路上听了Linda Rising这个有关personal agility视频的录音，虽然不是直接与软件开发相关，但还是有一些收获，记录如下：当人类社会进入到工业时代之后，有饮用咖啡和茶的习惯的人可以及时起床，赶去上班，以满足严格的时间要求。从而超越习惯于日出而作日入而息的人们，获得更多机会。引申问题：现在，如果懂得很多敏捷的原则和实践，能够身体力行Clean Code的人，是不是同样会获得更多机会？我想是的。工业时代Command and Control的管理方式，也打乱了人们以往日出而作日入而息的生活方式，我们不得不依靠咖啡因来提神。古代的一个有趣谚语： In wine there is wisdom In bear there is freedom In water there is bacteria(guess this is just a joke :) 时钟的发明和咖啡因的广泛使用改变了人们的生活。对成年人来说，只需要1个小时，咖啡因就可以从血液进入到大脑中，阅读全文>

发表于 @ 2009年05月05日 15:54:00|评论(loading...)|举报|收藏

2009年05月04日

2009.5.4 阅读笔记——语义网与Web 3.0

黄智生博士谈语义网与Web 3.0 文章对语义网的一些概念进行了分析和澄清。我看重其中提到的这样三点Web3.0的基本特征：新颖性：它应不同于已有的Web 1.0和Web 2.0的技术，它能提供全新的一代网络服务模式（即解释为什么它不属于Web 1.0或Web 2.0）。可行性：它在现有的网络环境下，经过努力是可能实现的，它并不存在不可逾越的技术障碍（即解释为什么它不属于Web 4.0或更高）。迫切性：它提供的网络服务应是当前社会迫切需要的，它引入的技术是能够对社会产生重大影响的。（即解释它为什么应只属于Web 3.0）。新颖性、可行性、迫切性，其实也可以用作评价任何新技术的标准。另外，黄博士在其中提到的几个观点也很有意思：本来有希望发挥语义网潜力的价格比较网站，在使用语义网技术方面却发展得很慢，其原因是商家不喜欢价格比较网站把自己逼到价格被动的境地，故不积极配合采用语义网技术。他还提到两个有趣的案例，不由得让我联想到何时这样的案例可以在国内出现。在语义网领域出现了一些令人瞩目的应用系统，如D阅读全文>

发表于 @ 2009年05月04日 17:40:00|评论(loading...)|举报|收藏

我们马上会变得更快——项目经理应该小心的游戏之十五

假定项目经理正在管理一个敏捷项目，或是按阶段交付的项目，或是其他生命周期类型的项目，总之这个项目可以用增量式的方式来构建系统。项目经理一直在测量团队的开发速度（或是实现的功能），可是进展速度没有达到预期效果。由于某些原因，团队成员对于如期交付很乐观（见图6.15）。图6.15 我们马上会变得更快讲求实效的项目经理不愿意发出悲观论调或是冷嘲热讽，他希望让大家认识到现实，帮助团队成员看清真正的进度。说到底，也许他们还是可以赶上进度的。可以采取下面这些措施来管理信马由缰的乐观情绪。与项目团队成员讨论进展速度。收集数据：是什么样的所见所闻，让他们觉得接下来可以比之前工作效率更高？测量估算质量因子（见11.2.4节）。有些因素会让人们觉得自己一直在按进度计划开发，甚至超越了进度计划。要特别注意这些因素。测量团队所做的每一件事情。确定每个人都全力投入到项目中，而且都为了按规定日期交付而开发必要的任务。如果有人在为其他项目工作，或是开发某个后续版本需要的任务，要马上中止这种状况。如果项目中涉及硬件组件，要测量其挣值（参见11.2.3节），看看它是否阅读全文>

发表于 @ 2009年05月04日 14:52:00|评论(loading...)|举报|收藏

2009年05月03日

90%完成状态——项目经理应该小心的游戏之十四

非常非常多的知识工作者，特别是技术人员，都从未学习过如何估算。就算是尝试过估算的人，他们也过于乐观了，总是会过低估计一项任务需要的工作量。要么得不到任何对估算的反馈，所以他们不会知道自己的估算是不准确的；要么他们预测不到一个任务中会牵涉多少子任务，比如准备测试环境或是签入代码这样的任务。在任何情况下，当有团队成员以为自己完成了90%的任务，而实际上还有90%工作尚未完成的时候，“90%完成状态”就发生了（见图6.14）。图6.14 90%完成状态我在职业生涯的早期，曾是“90%完成状态”的受害者。当时我在写一个数据库对话工具，要把一种数据库格式转换成另一种。我认为其中的数据是干净的，可事实恰恰相反。我以为我很清楚每个字段的格式，其实我不知道。我以为我对需求了解得很清楚，可随着工作的进行，每次处理数据库中的一条记录，我遇到了越来越多的特殊情况，每一种都对需求有所变更。最后我还是振作起来了。我开发了一系列测试用例，改变代码后我就会运行这些测试用例，慢慢地，整个开发工作开始取得进展。（要想知道更为现代的方式，可以阅读有关行为驱动开发的资料。[1]）上司问为什么进度这么慢，我向阅读全文>

发表于 @ 2009年05月03日 21:59:00|评论(loading...)|举报|收藏

第1页，共5页

第一页上一页 下一页 最后一页

用户操作

[即时聊天] [发私信] [加为好友]

郑柯