IT博客-乐在其中-文章分类-管理知识

丰田汽车的14条管理原则

小胡子 — Wed, 25 Jun 2008 03:53:00 GMT

原则1：管理决策以长期理念为基础，即使因此牺牲短期

原则2：建立无间断的操作流程以使问题浮现

原则3：实施拉式生产制度以避免生产过剩

原则4：使工作负荷水稳准稳定(生产均衡化)

原则5：建立立即暂停以解决问题、从一开始就重视品质管理的文化

原则6：工作的标准化是持续改进与授权

原则7：运用视觉管理使问题无处隐藏

原则8：使用可靠的、已经过充分测试的技术以协助员工及生产流程

原则9：把彻底了解且拥护公司理念的员工培养成为领导者，使他们能教导其他员工

原则10：培养与发展信奉公司理念的杰出人才与团队

原则11：重视事业伙伴与供货商网络，激励并助其改进

原则12：亲临现场查看以彻底了解情况(现地现物)

原则13：不急于作决策，以共识为基础，彻底考虑所有可能的选择，并快速执行决策

原则14：通过不断省思与持续改进以变成一个学习型组织

小胡子 2008-06-25 11:53 发表评论

眩目的敏捷架构师[转载《程序员》200806期]

小胡子 — Wed, 25 Jun 2008 03:42:00 GMT

眩目的敏捷架构师
随着敏捷软件开发的概念和方法论逐渐被越来越多的人接受，敏捷架构师在团队中的地位也越来越重要，那怎么样才能成为一名优秀的敏捷架构师呢？
文/Vikas Hazrati 译/舒克
      一直以来，无论是在软件开发组织之内，或是行业广大人士之中，对于敏捷团队是否需要架构师一直存在着争论。大家的质疑集中在：既然软件的架构是随着每个迭代而演进的，那一个架构师还能给敏捷项目带来哪些价值呢？这让许多传统的架构师都感受到了威胁，并力图寻找掩护，也为一种心类型的架构师——敏捷架构师——打开了机会的大门。在敏捷项目中，传统架构师的象牙塔已经逐渐成为最薄弱的一环，而他们的许多工作职责也已经被整个敏捷团队所分解。敏捷架构师的出现，正符合了查尔斯.达尔文的“适者生存”理论。在一个团队中，敏捷架构师角色的重要性是毋庸置疑的而且许多敏捷团队都认为他是任何敏捷软件开发团队中最有价值的成员之一。
      那怎么样才算敏捷架构师呢？我们如何识别团队的架构师是否是敏捷架构师呢？嗯，答案其实并不简单；不过敏捷架构师确实具备与众不同的品质，而且这些品质会体现在他们每天的日常工作中。如果团队中的架构师能够体现出这些品质，那么他肯定就是一个很好的敏捷架构师。不过首先我要警告你：下面的描述听起来也许有些过于理想化了，但他们确实描绘出了敏捷架构师应该达到的境界。敏捷架构师的首要目标：以最优质量交付可用的解决方案。
      这里的两个重要的方面。首先：解决方案的质量应该是最优的。理想状态下，质量的需求（也被称为非功能性需求）在敏捷项目的每个迭代中都要有所体现。像安全性、性能、代码质量等等这些方面会隐式地包含在一个用户故事之中，或者作为一个单独的用户故事在迭代中出现。然而，在迭代中工作的团队经常会陷入到对业务功能的开发中，而质量方面的要求被抛在脑后了。敏捷架构师要保证团队在每次进行构建时，都能从持续集成环境中获得关于静态代码质量、性能统计数据的反馈。他还要注意监控这些统计数据和质量属性，并不断提醒团队对他们的注意。
      其次，解决方案必须是可以正常工作的。敏捷架构师要与团队评估众多不同的选择，并一起交付一个可以工作并且能够产生业务价值的解决方案。他必须要确保解决方案不只能够独立运行，而且可以与客户现有整个软件环境进行良好的集成。这个解决方案必须足够健壮，可以随着时间变化进行变更和扩展。他必须将注意力置于可工作的解决方案之上，而不是对业务价值没有多大贡献的文档和管理层要求提交的某些可交付物上。
维护概念完整性
      他要确保在硝烟四起的战场上，任务能够得以顺利完成。在实施时间表和技术障碍的双重压力下工作，开发人员有些时候做出的决策会让项目偏离原有的业务目标。架构师必须注意这种情况，确保任务在整个开发过程中不会受到负面影响。
      当系统展现出这样的一致性——所有的东西看起来都可以缝合，这样的系统就具备了概念上的完整性。它是通过不同部分的一致性的展现和非理性设计的缺失来体现的。在大多数操作系统中的拖放操作就是一个很好的例子。如果系统在设计时遵循了概念上的完整性，那么拖放操作在任何时候、任何地方都应该是可以运作的。例如，要打开一个文件，可以通过将该文件拖放到合适的应用程序中实现；删除文件可以通过将其拖放到垃圾桶中完成。简单来说，应用概念完整性可以创造一个易于使用、易于维护、而且在使用中不会给用户带来过多压抑和不便的系统。
与团队一起工作
      他会参与项目整个过程。会像其他程序员一样领取开发任务、实现用户故事。类似工作不会占用他一整天的时间，缺是每天的固定工作。
      他会在整个项目中运用自己的经验，并指导架构完成演化。在最初的几次迭代中，架构是不会完成的，它会随着每个迭代的进行逐渐演进。这就意味着：敏捷架构师与传统的架构师不同，当所谓的架构设计阶段完成后，他也不会转向全新的项目。
编写系统级别的测试
      他会撰写底层的测试来检查系统地架构。如果架构上存在漏洞，失败的测试就会将其暴露出来。由于敏捷主张测试优先，它会编写使系统在质量特性方面失败的测试，并修改架构的某些相关部分来通过测试。少数情况下，用代码进行测试也许无法起到作用，它会想出其他的方式来“测试”架构。这可以确保不会在未经证实的设计上耗费精力。任何设计上的决策，无论大小，必须经过测试用例的检验。
      例如，如果要求系统达到同时为一万个用户提供服务的质量要求，敏捷架构师会使用JMeter或类似的压力测试脚本，以模拟足够的负载，确保系统可以承担这样的压力。如果测试失败，它会重构架构以通过测试。
参与紧密的协作
      他不会单独完成设计和技术上的决策：这些决策是与团队共同协作完成的。他拥有开放的心态，并且坚定认为自己不是全知全能的万事通，而且不会对自己的主意保有盲目的保守心态。当团队坐在一起进行头脑风暴时，就会产生最好的主意：任何人都可能提供好的想法和有价值的知识。开发和诚实的沟通可以帮助人们基于更好的信息做出更好的决策。敏捷架构师是一个善于与人打交道的人，他对任何人都充满敬意，并且利用每一个机会向别人学习。他会促进共识的形成，并欢迎团队中每一个人为解决方案做出贡献。
      如果业务发起者在解释完项目的目标之后，架构师马上就可以提出一个解决方案，那么这个架构师也许不是一个真正的架构师。
做鉴定的指导者
      他经常与团队一起工作，来提升团队的决策制定能力。根本上，这可以帮助架构师更好地利用大家的智慧，而不是成为项目中单一的决策制定者。通过指导团队使用新的技术、为技术架构构建并提供支持，他与团队可以更好地形成协作与互利关系。他可以确保团队不会因为缺少某些经验或是对某些技术感到不适而简单的拒绝一种设计方案。如果真的发生了类似情况，他会为团队弥补中间的隔阂，从而让大家可以做出更明智的决策。
      正如Martin Fowler指出：“这指出了如下这条基本原则：一个架构师的价值与其作出的决策数据成反比”
做熟练的协调者
      敏捷团队中包括技能熟练、富有激情的团队成员。对于设计决策、实现功能的最佳方式、开发流程的改进措施，团队中经常会出现不同意见。还会带来激烈的争吵，如果不能迅速妥善处理，会影响成员之间彼此的感情。这些场合下，团队成员需要一个拥有丰富经验、足够成熟、并且见多识广的调解人，来帮助团队打破僵局，重新和谐。而敏捷架构师由于其成熟的水平和经验就成为了不二之选。
不做大型的预先建模
      通常他不会使用重型的CASE工具来做大型的建模设计和决策。一般来说，所有的建模都是“足够”的建模，并且是在白板上完成的。简单的建模会随着每个迭代慢慢成长、逐步改进。他会跟随敏捷建模的概念，对他来说“代码就是模型”。如果需要为了文档生成模型，那么这些模型也是通过一种合适的逆向工程工具从代码中生成的。
      模型、文档、沟通的方式会以尽可能简洁扼要的方式保存。关键是要将注意力放在内容上，而不是展现或其他为了看起来好看而作的事情，这些东西并不能添加多少业务价值。
寻找大规模重建的机会
      他总是在注意观察可能成为严重的技术障碍、损害项目架构的问题。随着系统的成长，他确保架构可以跟上发展的脚步。他总是在注意观察可以取得更大收效的变革。举例来说，如果应用程序没有利用足够的CPU，并导致性能低下，那么他可能会试图引入多线程，以使得空闲的资源可以被利用起来提供更好的性能表现。他会首先选择最简单的可用解决方案，接下来会经常对其进行重构，以满足变化的质量和功能需求的要求。
      敏捷架构师同样会帮助切分系统。他会推荐采用“先征服再切分（conqure and divide）”而不是“先切分再征服（divide and conqure）”的方式。最开始时，一个小系统是通过小团队实现。最终，随着架构师经验的不断丰富，团队会将系统按照自然形成的界线进行切分，并且始终在心中包含有系统的整体概念，而且为系统每个不同的部分增加团队成员。
敏捷架构师是万能胶
      他会在团队成员之间、不同的厂商之间以及利益相关者之间逐步沟通架构、设计决策、任何技术障碍之类的东西，来充当万能胶的角色。他是业务世界和技术世界之间的媒介。它能够在业务上下文中通过技术的角度和问题发现潜藏的业务问题。它能够以业务价值的角度解释当前的采纳技术，让利益相关者明白这些技术的价值所在。例如，他可以使用人员利用率、更快的周转率、节省的资金等业务价值用语，来说明为什么在两种技术中选择其中一种。针对某个项目时，他会同时思考如何回答“为什么”和“怎么做”这两个问题，以回答业务和技术上的疑问。大多数传统的架构师会关注如何实现一个解决方案，而不是思考为什么这个解决方案是最佳的。敏捷架构师会试图与业务人员一起，并找出为什么需要某种特别的解决方案，是否会有比业务人员提出的建议更简单的方法解决手上的问题？
最后但并不是最重要的，敏捷架构师拥抱变化
      他拥抱架构和角色上的变化。真正架构上的敏捷度，是指快速应变而不损害架构的能力，同时对其他部分的影响尽可能小。要确保这一点，他要从好的设计开始，并让其随着项目的进展而演进。他常常会抽象出通用的元素，并将其封装在稳定的接口之后，因此将变化带来的影响最小化。
      真正的角色敏捷度是可以扮演多个角色。在一天的工作中，他可能从事程序员、系统测试员、指导者、协调者、团队成员、万能胶，甚至可能是管理层等多种角色的工作。
结语
      架构师象牙塔的根基已经被动摇了。新一类的“敏捷架构师”正在逐步涌现出来，并于团队一起工作，为团队做贡献。他们的确是在按照丰田原则[注]的第十三条在生活：“亲临现场查看，通过一手资料来彻底了解情况”。他们是开发团队的第一等公民，而且不只为团队工作，还在团队之中工作。因此，要想成为能够与开发团队共进退的敏捷架构师，成熟、经验以及上述的能力不可或缺。

小胡子 2008-06-25 11:42 发表评论

协调和沟通

小胡子 — Thu, 24 Apr 2008 02:37:00 GMT

我们项目组目前包括我共7个人，沟通和协调是我每天的工作之一，也是目前工作重点！
1）早会
每日安排早会，这样的安排是考虑将上日工作最迟也是以天为单位了解进度完成情况，可以及时调整
2）工作中的协调和沟通
目前和他们花费的协调和沟通时间很多，这主要是感觉他们平时私底下沟通并不够。很多时候他们并不清楚彼此在做什么，是怎么做的。希望早会制度和协调能对他们沟通有所帮助，将当天问题当天都消化掉，从而不会造成进度的延迟。

目前接手项目已有两周，初步了解项目组成员，这两周还算顺利，与原设定计划没有什么大的出入。现在每天和他们沟通时间可能要占用我工作时间的一半，有些工作我不得不用下班时间来弥补，有时我都不好意思打扰他们的工作，不过他们看来还是能理解我的！

我想再过两周他们应该可以适应这样的工作节奏和我的管理风格。

小胡子 2008-04-24 10:37 发表评论

功能测试计划和任务分配

小胡子 — Fri, 11 Apr 2008 09:22:00 GMT

我按照功能列表中的功能模块与项目组人员沟通后，将所有模块安排测试顺序，再从其中挑出那些是要先完成的功能（核心功能）。这样考虑是因为这个项目功能比较多，让所有人都投入到核心功能的测试上，测试过程中必定会出现Bug，这时就需要安排人去修改这些bug。那剩下那些次要的功能就可以安排没有修订Bug任务的人去继续进行！这样可以尽快完成核心功能的测试，也可保证整个测试的进度停止！
再来讲讲任务的分配，将进度计划排出来以后，我就召开任务分配会议，要求他们必须将我表有核心功能符号的模块进行分配，分配形式以认领为主，如果没有人认领，再有我来进行指派，大家还是比较配合，基本上由谁负责的模块，都由谁主动认领了，只有少数模块没人要有我指派，这个过程非常顺利。然后就是要求他们按照已有测试用例设计文档，和现有功能进行比对，然后给出各自认领测试用例设计的工时，以便计划具体的时间安排！

小胡子 2008-04-11 17:22 发表评论

项目接手

小胡子 — Fri, 11 Apr 2008 09:04:00 GMT

接手项目有几天了，谈一下感受：
1、首先是人员。我和这个项目组在一个办公区域，和项目经理坐在一起，并且对这个项目经理比较熟悉，对项目也有所了解，对这个项目的人员也并不陌生，但是也谈不上太熟悉（毕竟没有带过）。整个项目人员项目开发初期（07年初）变动比较大，但是到了项目中后期相对稳定，目前项目组各人员技术相对稳定，不需要太多培训，只要考虑他们是否能适应新的管理模式就ok了！
2、其次是系统。目前系统处于开发后期，目前开发完成的功能经过功能测试，不过这之后又有功能调整，目前系统并没有什么大的问题，但是小问题还有一堆，所以我入手的第一步就是扫清这些问题！以便通过这次测试来完善系统，有一个像样的版本。（要面临客户的使用）
3、第一个工作安排
      我接手的第一步就是查看Bug追踪系统上的Bug情况，竟然有68个Bug解决没有验收，有48个Bug还处于待解决状态，有的竟然停留了1年多没人理会，Bug追踪系统形同虚设！我安排他们先要整理自己有那些Bug需要处理，那些Bug需要验收，那些Bug可以关闭，并且将目前还未解决但未登记的Bug由自己登记到系统上（已解决的就不需要了！）并评估一下处理这些事情的时间，这个优先级最高，因为我考虑只有先把未处理的Bug处理掉才可以往下进行！
4、功能测试
      得到他们的评估时间和Bug处理列表后，我就开始安排下一步功能测试工作计划了，因为目前系统基本功能已开发完毕，所以需要一次系统性的测试，来扫清目前系统中的Bug，让系统变得更加干净，这样面对客户可以更有信心！
5、系统测试
      不过功能测试并不能测试各模块之间的关联接口，所以还要安排系统测试来验证他们之间的关联性。
经过上面的步骤，系统应该可以得到一个相对稳定的版本，我会考虑建立一个分支，再这之上再进行需求变更和新增功能的开发！

小胡子 2008-04-11 17:04 发表评论