按功能实现，而不是按架构――保持项目节奏实践之三
“夏东海夏”通过精心收集，向本站投稿了7篇按功能实现，而不是按架构――保持项目节奏实践之三，今天小编在这给大家整理后的按功能实现，而不是按架构――保持项目节奏实践之三，我们一起来看看吧！
篇1：按功能实现，而不是按架构――保持项目节奏实践之三
系列文章目录索引：《保持项目节奏实践：掌控项目节奏，做到了如指掌》
逐个功能进行实现和测试
哈威、维贾、道、兰迪、肯和梅布尔，负责提醒功能的团队
我是哈威，团队的头儿，我们的开发人员包括维贾、道、兰迪和肯，梅布尔是测试人员。我们在GUI、平台、硬件集成以及几个方面都有专家，而梅布尔无所不知。（背景中传来笑声。）
刚开始的时候，我们试图先把架构开发出来，再制订规范，告诉大家我们在做什么。我们每个人各自负责一块，最后再放到一起。可是一切都没有按计划进行。因为即使我们有规范，在开发各自的组件时，我们总会改变些什么。
梅布尔曾经听过有关按功能实现的说法，并告诉了我。我问大家是否愿意组建一个基于功能的团队。嗯，其实是基于功能集合的团队。我们开发所有的提醒功能，一次完成一个，从前端到后台。梅布尔会负责测试。
开始时有点儿困难，不过习惯之后，我们添加功能的速度让人惊喜不已。我们不再是每个人开发很多代码然后再集成到一起，而是只添加每个提醒功能需要的代码，再进行测试。梅布尔保证我们不要出现系统级别上的问题，我们保证每个提醒功能不要出问题。
我们的开发速度如此之快，不久就有新的功能需要开发了。现在，有些其他组也在尝试我们的做法。整个项目的进度都加快了，而且客户也能知道我们在开发哪些功能，反馈也由此而来。
很多项目团队都是按照架构进行组织的，比如基于Web的产品会分平台组、中间件组和GUI组。可是如果按架构进行实现，项目经理就很难知道开发完的功能是否可以正常运行，除非等到整个产品集成完毕。如果按架构实现，就很难进行持续集成了，因为无法构建和运行测试。在开发的开始阶段，没有哪个功能是完全实现的，都要等到快结束的时候才能做完。而且，项目经理也无法将任何功能视为完成。
所有已经完成的开发工作都是在创建“浪费”［MP06］，没有产生任何有价值的东西。一旦完成某些功能，就可以开始计算价值了。可是在此之前，这些价值无法衡量。
按架构实现会打乱项目的节奏，因为得到的都是部分完成的功能。不到开发完成，项目经理看不到完整的功能，而这时得到的反馈对开发人员来说就太晚了。如果按功能实现，开发团队只要针对某个功能的要求利用架构进行实现就好了。假如要开发Web应用，项目经理可以组织一个小型的基于功能的跨职能团队，其中包括一些了解平台的人员、一些了解中间件的人员和了解GUI的人员，他们各自负责自己擅长的工作，并且只针对团队负责的一个特定功能。要是团队人员拥有不同的兴趣和技术技能，比如擅长GUI和固件方面的技术，这些人就可以按照功能逐个应用他们的技能。（项目经理应该帮助他们组织好各自在项目中的工作时间。）
有些团队认为，应该在项目前期预先细化需求（Big Requirements Up Front，BRUF），并进行大量设计（Big Design Up Front，BDUF），
这样的团队要想切换到按功能实现的方式，就没那么顺利了。这时，可以跟他们说明一个功能应该是什么样子（它应该有多小），并让他们知道自己不应该做什么（参见5.3节），帮他们了解实现的功能要具备足够的架构完整性，从而在实现后续功能时也不会有问题。要提醒这些团队，他们在调试和测试的时候，都是按功能进行的，因此不会陌生。
有些人可能仍持反对态度，说他们在考虑一个功能之前，仍需要知道整体架构没有问题。这种情况下，架构草稿会有所帮助（参见3.5节）。不过不要坚守其中的架构，除非团队已经实现过不少功能了。
9.3.1. 首先实现具有最高价值的功能
在按功能实现时，要先实现最有价值的功能。把风险最高的功能先往后放一放。如果运气足够好，也许根本不用开发这些高风险的功能。这样一来，测试人员和开发人员就能对整个系统有足够的了解，他们就可以保持自己的节奏了。
有些团队不愿意按功能实现，因为他们不知道先开发哪个功能。团队中有些人会希望先开发风险最高的功能，有些人希望先开发最有价值的功能。如果没人愿意排定需求的优先级顺序，那就很难知道哪个功能最有价值了。
如果没有客户或是客户代理的参与，你作为项目经理，就要在团队的辅助下，担起制订和发布产品待办事项列表的责任（参见16.6.1节）。项目经理要判断出各个功能的实现顺序。
如果有人愿意判定各个功能的价值，那就按价值高低进行实现，即便会给架构带来风险也要这么做。
如果功能的价值和完成度越高，项目经理就能在当前项目中为自己和团队带来更多灵活性。你也许可以尽早发布（如果高风险的功能无法使用当前架构），这对很多客户都是很有价值的。推迟开发高风险、低价值的功能，可以保持项目的节奏，并降低当前版本的风险。
9.3.2. 按功能调试
有些团队坚持按架构实现。到了测试的时候，测试人员却是逐个功能进行的。这么一来，团队在调试的时候也得按功能进行了，即使他们构建产品的方式与此不同。
为了按功能调试，项目经理要构建跨架构团队（要么就得能够接触到所有团队成员）。如果从来没有组建过跨越架构的团队，项目的节奏会因此而扰乱。不过，要是没有跨越架构的团队，问题是无法解决的。
要是到了项目尾声，发现团队在按功能调试，那还是考虑在一开始就按功能实现吧。这会减少项目的干扰，同时项目节奏也更平稳。
9.3.3. 按功能测试
测试人员会按照功能测试系统，有时是因为需求的编写方式，有时是因为这就是测试人员访问系统的工作方式。当测试人员报告问题时，他们很少会单独报告各个小架构组件上的问题。实际上，他们会在测试用例中提出问题，比如，“当我试图打开一个银行账号时，我可以看到数据穿过中间件进入到数据库中，但是我看不到返回的确认。”测试人员在这里报告了一个中间件的问题，但是没有明确指出是在哪里。
开发人员已经习惯于看到这样的报告了（不管是与调试还是测试相关），也惯于回溯问题，以判断功能是如何与架构交互的，从而理解问题。按功能实现，开发人员就可以在设计和编写代码时看到潜在的问题，不至于到开发尾声才发现。
本文来自：blog.csdn.net/MagBryan/archive//05/15/4189639.aspx
篇2：持续集成――保持项目节奏实践之一
系列文章目录索引：《保持项目节奏实践：掌控项目节奏，做到了如指掌》
项目经理不但要用管理实践掌控项目，还可以欢迎团队改变自己的技术实践，从而获得更大收益，本章包含的一系列实践，能为项目带来很多好处。项目经理和团队要根据自身的实际情况，判断如何调整、使用这些实践，而不要强制推行。如果你认为它们有所裨益，不妨将其介绍给团队，并欢迎团队积极尝试。
9.1 在项目中使用持续集成
开发人员用一两个小时编写一段代码，对其进行编译，测试，复查，构建，运行冒烟测试，并验证做出的改变不会破坏现有系统代码，再将其签入到代码库中。持续集成就这么发生了。[1]
持续集成可以让开发人员马上得到所做工作的反馈。他们开始考虑将大任务拆分成更小的部分（这可以让他们以更快的步伐前进），还能尽早识别出项目的集成风险。持续集成让开发人员每天都能有所收获，帮助项目团队找到符合自己的节奏。
开发人员只有在完成了某个功能的代码后才将其签入，这就是按阶段集成的方式。有些开发人员一周签入一次代码。有些更糟糕的项目，开发人员一到两个月才签入一次代码。按阶段集成会打断项目的节奏。构建时出现的问题，会中断设计和编写新功能代码的人们的思路。他们不得不记住很多小细节，而这些小细节覆盖了从项目开始直到进行集成的各个阶段。如果忘记了这些细节，项目进度会放缓，因为团队发现了缺陷，而且必须想起可能是几个月前所写代码的细枝末节。这其实是一种同时处理多任务的方式，而且特别不容易发现。人们是在做同一个项目的工作，而且手上的任务可能也相关，但是思考问题时的抽象层次却有所不同（设计比调试的抽象层次更高），而且也不再是处理同一个功能的问题，思考问题的上下文由此发生了变化。所有切换上下文的代价都发生在这里（参见16.7.3节），在设计下一个功能时，开发人员可能会因此而丧失好的想法，还可能增加向设计中引入缺陷的潜在风险，
频繁构建是为开发人员和项目经理准备的
如果你提出使用每日构建，测试人员可能会抱怨：“我们做不到以如此快的速度构建，只能每周构建一次。”频繁构建，比如每小时甚或每天，不是为测试人员准备的。频繁构建可以为开发人员提供反馈，同时让项目经理了解项目状态。
如果测试人员可以利用每日构建来运行测试，那就太棒了。不过即使测试人员做不到这一点，通过每天构建可工作的代码，并维持这样的节奏，开发人员也可以从中获得有价值的反馈。
如果项目经理不能将变更后的代码集成到代码库中，你可以采取持续集成的变种。假设你管理一个项目团队，大家的任务是扩展一个已存在产品的设计。团队目前正在处理的部分产品代码是整个产品的基础。如果这部分代码无法运行，那整个产品都不能运行。你现在不想签入代码，因为这样会破坏现有的产品，而且会占用三个月的时间来添加和替换产品的现有功能。你该怎么做？
应该选择现有状况下的最佳方案。你可以将主代码库做一个分支版本，并让所有开发人员在这个分支版本上开发。他们每次签入一些代码，都会与主线代码进行同步，保证自己的分支代码是最新版本。这使得开发人员总是在最新和最全的代码版本库上进行开发，而且他们一直都在进行集成。当他们完成各自工作后，就会将所有代码都合并回主线。
这是持续集成的一个变种。如果必须重写已经存在的代码，而且在开发变更代码时不想破坏现有系统，可以采用这种方式。如果项目经理管理的项目所提供的服务要为一组产品使用，比如一个程序库或是一个平台，这种方式同样适用。
[1]见www.martinfowler.com/articles/continuousIntegration.html。
本文来自：blog.csdn.net/MagBryan/archive/2009/05/08/4160018.aspx
篇3：准备重构――保持项目节奏实践之五
系列文章目录索引：《保持项目节奏实践：掌控项目节奏，做到了如指掌》
重构是对代码的简化，无论是产品代码还是测试代码，重构不等于重新设计，只是简化而已。重构过的代码不会改变它的接口，只是更简单。
我的代码不见了
哈尔，初级开发人员
我现在参与的项目是离开学校后的第二个。在第一个项目中，经理听了我的代码工作估算后说：“好，既然你还是个新人，咱们就再多加点儿时间吧，这样你可以把学到的经验应用到写好的代码中。”我觉得他这么做纯属多余，不过没关系，我还是加倍努力，在截止日期来临之时完成了手上的工作。接下来，我了解了整个系统真正的运转方式，就得修改已完成的工作了，不只耗费了所有额外的时间，而且还多用了一点点。让我感到惊讶的是：为了解决问题，我没有编写更多代码，而是简化了现有做法并去掉一些代码。我的代码不见了。
现在这个项目，我使用了持续集成，而且一边开发一边重构。在开发时，简化并清洁代码，而不是改变设计，这让我对自己手上的工作和开发速度有了更清晰的认识。而且，我的代码仍然在继续消失。
如果你曾经随项目进展计算过代码行数，要是项目采取顺序式生命周期，或是将集成和测试放在项目临近结束时进行，那就会看到一个S形曲线（见图9.1）。可以注意到，开始集成和测试后，代码的数量就开始减少了，这是因为发生了重构，
（没错，也许是重新设计了某些东西，不过以我的经验，主要是重构造成的。）如果不准备在项目快结束时进行重构，或是不愿意在顺序式生命周期中偿还技术债务，代码量会居高不下。在项目快结束时，代码缩减就不会发生。
图9.1顺序式生命周期中代码量的典型变化
在使用敏捷生命周期的项目中，代码量的曲线很可能如图9.2所示。代码的增长要慢得多，因为开发人员仅仅编写当前功能需要的代码。他们还会一边开发一边重构，而不是等到项目快结束时再去修复一大堆bug。（对于很多bug来说，去掉某些代码就可以解决。）
图9.2敏捷生命周期中代码量的典型变化
项目经理可以让重构与开发同时进行，也可以最后再进行重构。如果希望发布的产品中缺陷越少越好，就必须要对代码进行重构。如果让重构与开发同时进行，重构的成本是非常小的。如果打算在项目结束时重构，那成本可就高了，而且你会发现总是没有时间去做重构。要么管理层就会指示你不要重构。高昂的成本来源于开发人员得到的反馈延迟过久，以及不知道应该重构哪些代码以及如何重构，因为开发人员很久没有思考过要重构的代码了。
来自：blog.csdn.net/MagBryan/archive//05/28/4222908.aspx
篇4：为构建创建自动化冒烟测试――保持项目节奏实践之二
系列文章目录索引：《保持项目节奏实践：掌控项目节奏，做到了如指掌》
不管使用持续集成与否，都应该为构建产品创建自动化冒烟测试，冒烟测试仅仅是为了验证要构建的版本没有问题。你想添加多少回归测试都可以，我不拦着，但是使用冒烟测试，是要知道当前的构建版本是否对大家有用。
有了自动化冒烟测试，项目团队就可以知道是不是有人破坏了当前构建版本。如果能尽早知道一个构建完成了，你就可以在其基础上做些自己想做的工作。要是必须依赖其他开发人员或是测试人员才能知道当前构建版本出了问题，那你就不能以最快的速度修复当前构建版本了。
别让烟跑出去！
梅瑞狄斯，资深测试人员
作为测试人员，寻找问题是我的职责所在。而且，我也很擅长这个。我有一句座右铭：“别让烟跑出去。”
有一次，我加入了公司的一个新项目。开发人员以前从没有与专业测试人员一起工作过。我拿着一张有15个缺陷的列表，走到他们中一个人的面前，然后说：“你得说说这是怎么回事，要不我把这些问题提交到缺陷跟踪系统里面如何？”他们都惊呆了。
我向他们说明，这些缺陷通过一个自动化冒烟测试都可以找出来。没有哪个缺陷需要靠我的专业知识和经验才能发现。我不想浪费时间找出这些易于发现的缺陷，而是要找出更捣蛋的缺陷——时而发生的问题、系统可伸缩性上的问题和可靠性问题，
管理资料
我想钻到代码之中，把高难度缺陷一个个都揪出来，直到它们全部显形。
那个开发人员脸色发白，屏住呼吸说道：“呃，好吧，我希望你也能那么做。需要我配合你什么？”
我解释了我的座右铭：“你的工作是尽量保证不出问题。我的职责是尽量让问题血淋淋地暴露出来。明白了么？”他表示同意。我想我听到他跟别人说我有点嗜血倾向。不过，管他的，我对此毫无意见。
我签入了我的测试代码，开始构建自动化冒烟测试框架。开发人员开始一点儿一点儿地加入冒烟测试。如果我找到了一个冒烟测试应该发现的问题，就会冲到加入这个缺陷的开发人员跟前，对他说“别让烟跑出去”。不久之后，大家只要一看到我走向开发人员的小隔间，就会有人大叫：“是谁把烟放出去的？”
我们现在合作得非常好。这些开发人员的工作表现非常好，而且他们也让我能很好地完成自己的工作。我们的产品NB极了！（这么说没事吧？）
让构建版本正常工作，这对建立并保持项目的节奏大有裨益。能够第一时间发现构建版本出现问题，也使得项目经理可以将项目带回正常的节奏，或者发现是什么使得团队无法保持节奏。
实际上，如果项目的产品要在多种型号的计算机、数据库或固件上运行，要确保团队每天都为所有的平台编译并构建产品。如果不这么做，到了项目结束的时候，项目经理就得忙着解决那时才能发现的问题了。在项目中越早发现兼容性方面的差池，就越容易应对，而且开发人员在后面的工作中也能将其牢记在心。
来自：blog.csdn.net/MagBryan/archive/2009/05/10/4166356.aspx
篇5：分离需求与GUI设计――保持项目节奏实践之七
系列文章目录索引：《保持项目节奏实践：掌控项目节奏，做到了如指掌》
我们希望系统解决的问题通过需求得以体现，GUI设计是要体现出GUI如何引导用户使用系统以解决他们的问题。很多项目都将GUI设计混同于需求的假面之下，这很让人讶异。如果你的项目总是陷于无尽的需求工作之中，看看问题是不是出在GUI设计上。
GUI是设计，不是需求
凯伦，程序经理
我在一家新公司工作时，试图拯救一个陷入“需求地狱”的项目。需求文档已经达到300多页，而且远未完成。
阅读这些文档后，我找到了原因。所有的GUI设计都被记录在需求文档中。GUI设计没有放在项目的设计阶段，业务分析人员和GUI设计人员试图将所有的GUI需求都放在需求文档中，
管理资料
他们使用了功能强大的图形设计工具，并在需求文档中定义GUI。
我向他们询问原因，他们看着我，说道：“这些是GUI需求。”我建议他们认真看看GUI设计，并且考虑这些设计是否应该跟希望系统解决的问题放在一起。GUI设计不应放在需求文档中。
最终，他们同意采纳我的建议，我们也可以逃离需求地狱了。而且，由于我按照逐个功能重新组织了项目，GUI设计也就跟各个功能结合在一起了。我们定期检查整个GUI的一致性，但是这与需求无关，这属于设计。
人们很容易在项目开始阶段设计GUI，并称其为需求。如果要这么做，项目就永远无法找到自己的节奏。它会一直陷于需求的泥沼之中，直到最后，无法完成任何客户需要的功能，虽然到时候能够得到精美无比的GUI。
来自：blog.csdn.net/MagBryan/archive//06/15/4271003.aspx
篇6：多几只眼睛盯着产品――保持项目节奏实践之四
系列文章目录索引：《保持项目节奏实践：掌控项目节奏，做到了如指掌》
邀请团队成员相互复查工作，复查的形式并不重要，结对编程（pair programming）、伙伴复查（buddy review）、同行复查（peer review）、走查（walk-through）、正式代码检查（formal code inspection）都可以。复查能够为项目方方面面带来好处。项目经理要为团队提供多种方法。这些方法以特定顺序介绍：从最不正式到最正式。以我的经验来看，这也可以从最有效和易于保持的，到最没有效果和难以维系的。
结对编程。先不要假定“这里没人愿意这么做”，要允许大家这么做。（而且可以提醒大家，他们已经完成过结对调试了。）我会问大家谁自愿进行结对。我建议他们在开始之前，先去阅读一些相关资源，比如［WK02］和［SH06b］，还有www.pairprogramming.com。
不出意外的话，会有人愿意尝试结对的。相对独自工作来说，他们可以学到如何通过结对编程使工作变得更有效率。
除了减少缺陷、加快开发速度外，结对编程还能带来很大的好处：有两个人完全熟悉并知道如何处理同一块代码。而且，如果人们经常切换不同的结对对象，他们就会深入了解目前团队正在开发的系统的各个部分。此外，对代码作者的反馈也没有延迟。
用哪种生命周期都没有关系。结对这种技术总是可以用来让更多人了解代码。
伙伴复查。伙伴复查无法达到与结对编程同样的学习效果。没错，每个人都可以了解产品某个功能的代码，但是不会像作者那样深入，
作者得到的反馈也会有一点点延迟——即完成复查所需的时间。
同行复查。同行复查与伙伴复查的意思差不多（把你的代码给别人看看），但是很多人倾向于一次复查一个完整的模块，不管是一个文件还是几个文件。复查大量代码要更难，很难找出需要进行复查的大块时间，而且很难记住脑子里面所有的想法。
同行复查很难达到与伙伴复查同样的学习效果。以我的经验来看，这样做经常只能复查代码风格，而不是内容。对于作者的反馈延迟可以长达一星期。
走查。用走查的方式，一些人会集中在一个房间之内，由代码作者说明产品，过一遍文档。这里几乎没有团队学习的过程，而作者得到反馈的延迟时间也相当长——也就是用来组织会议需要的时间。
正式检查。如果做得好，正式检查可以帮助团队通过讨论了解产品。不过我很少看到正式检查能够在组织内长久实施下去。即使是启动检查的人，也很难维持检查的动力。
维持检查很困难，因为检查别人的代码会打乱每个人的节奏，还有项目的节奏。要想进行一次费根式（Fagan-style）的检查，人们必须离开自己的工作任务上下文，详细阅读产品代码，准备评论自己看到的东西。我发现，为了一次两小时的检查会议，要花上几小时甚至一天的时间去准备。
费根式检查（Fagan inspection）是一种在开发文档中试图发现缺陷的结构化过程。这些文档可以包括代码、需求说明、设计文档以及其他软件开发过程涉及的文档。其命名来源于迈克尔·费根（Michael Fagan）——正式软件检查的发明人。详情可查看：en. .org/wiki/Fagan_inspection。——译者注。
篇7：通过用例、用户故事、角色和场景来定义需求――保持项目节奏实践之六
系列文章目录索引：《保持项目节奏实践：掌控项目节奏，做到了如指掌》
要减少不必要的代码，有一个好方法：想想谁会使用系统，又该如何开发用户需要的系统，
有很多项目都试图通过定义功能性和非功能性需求来确定需求。可是这些需求没有说明一个人如何使用系统，以及一个功能在何种场景下必须运行。需求收集的方法应该为项目团队提供上下文，这样才能深入理解需求。
谁需要那个支票账户？
克拉丽莎，资深经理
我的项目团队陷入困境。他们实现了一堆只开发完一部分的功能，可是没有哪个能够真正运行。我召开了一个会议，以决定接下来该做什么。
在会议上，我想知道：为了完成项目，哪些用户是他们的首要服务对象。他们看着我，脸上毫无表情，
管理资料
“你们看，我们是一家银行。我们希望年满18岁、将要进入大学的人们首先使用我们的服务。还有住在郊外的妈妈们，她们还有其他资产，75岁的老奶奶，以及年方15已经靠做家务挣得零花钱的孩子们。我们可以为他们提供不同的理财服务。如果他们走进来，我们希望他们成为我们的客户。对于这些不同类型的客户，我们真地想过要给他们提供什么样的产品么？”
他们以前太过专注于系统的内部功能，忽视了系统真正要为之服务的用户。我们把期望捕获的用户重新进行了排序，项目团队因此得以完成需求定义，并完成系统的功能。
人，总是人的因素，不是么？
只要大家了解需求的上下文，开发人员、测试人员和文案人员就能知道如何开发、测试、编写文案。如果他们不能了解，要是需求以功能性和非功能性需求的方式罗列，他们也可以问一些更好的问题，从而深入了解需求。
来自：blog.csdn.net/MagBryan/archive/2009/06/13/4266911.aspx
【按功能实现，而不是按架构――保持项目节奏实践之三】相关文章：
文档为doc格式