tag:gigix.thoughtworkers.org,2010:mephisto/ Mephisto Noh-Varr 2010-03-12T16:02:32Z gigix tag:gigix.thoughtworkers.org,2010-03-12:1029 2010-03-12T15:49:00Z 2010-03-12T16:02:32Z <p>首先，不要恐慌。这不是《重构》第二版。只是由于某种愚蠢的原因，从前的那个中文版已经买不到了。现在，它换了个书皮，让需要的人能买到。仅此而已。</p> <p>刘江兄写了一个 <a href="http://blog.csdn.net/turingbook/archive/2010/03/11/5366962.aspx">煽情的宣传</a> 。“从一个光荣的大学辍学少年（步乔布斯、盖茨后尘？）成长为ThoughtWorks的资深咨询师，Martin Fowler的同事。”嗯，很好的阶段性总结。</p> <p>（有时候我很怀疑自己做的一切是否真的有意义。如果“大家”真的会学习的话，为什么《重构》出版那么多年以后还有那么多烂代码存在──当然，如果“大家”真的会学习的话，为什么还有战争？）</p> <p>时间，才是最神奇的重构工具。这句话，也很好，很隽永。</p> <p><a href="http://www.china-pub.com/196374"><img src="http://www.turingbook.com/Data/Book/f38697a7-538c-4e1a-9a82-919433275d82/Cover/CoverBig.jpg" height="251px" width="200px" /></a></p> gigix tag:gigix.thoughtworkers.org,2010-03-12:1028 2010-03-12T11:55:00Z 2010-03-12T12:04:26Z <p><span class="caps">QWS</span>是一款电信交换机产品，其软件部分用C语言开发。经过长期的发展演化，当本文所述的咨询项目开始时，QWS的总体代码量已经超过2000万行，代码库体积超过4GB。本咨询项目所涉及的版本需要新开发的代码量约90万行。</p> <p><span class="caps">QWS</span>的版本交付团队大致由90名左右开发人员和30名左右测试人员组成。这支交付团队又按特性和模块划分为6个特性团队和2个任务团队，共计8个子项目组。每个项目组分别有一个SVN工作分支，项目组成员将代码提交到分支，项目经理再负责将分支代码合并到主干。</p> <p>在ThoughtWorks顾问组进入该团队之时，这支多年沿用CMM方法的团队正在自行尝试敏捷方法，刚刚开始第一个为期3周的迭代。但这第一个迭代远非一帆风顺。一方面，由于团队从来没有迭代交付的习惯，开发人员在编码阶段忽视质量，导致提交到SVN的代码有时甚至不能编译，即使编译出软件大包也存在严重功能缺陷，无法进行测试；另一方面，由于团队成员对SVN缺乏了解，多个分支的配置管理遇到了极大的困难。</p> <p>就在这样一种混乱的状态中，由3名ThoughtWorks咨询师组成的顾问组进驻了这支交付团队，开始对其进行为期4个月的敏捷改造。在项目进展中，我们大量借鉴了源自丰田的精益思想，最终取得了显著的成效。</p> <p>（ <a href="http://blog.csdn.net/gigix/archive/2010/03/11/5371464.aspx">阅读全文</a> ）</p> gigix tag:gigix.thoughtworkers.org,2010-03-09:1026 2010-03-09T01:20:00Z 2010-03-09T01:32:21Z <p>Buzz是个好东西。一边玩Buzz，一边抓紧时间看了几本书。</p> <p><a href="http://www.douban.com/subject/2138463/">Organizational Patterns</a> 操作性缺缺，看完仍然不知道该怎么实施──甚至不知道能不能实施</p> <p><a href="http://www.douban.com/subject/1924212/">说话的魅力</a> 废话超过文化</p> <p><a href="http://www.douban.com/subject/3313363/">演说之禅</a> “胶片”这个词真的很不好，因为它杂糅了幻灯片和讲义</p> <p><a href="http://www.douban.com/subject/3137158/">让你的声音更有魅力</a> 系统性和可操作性都太差了，国人写书的通病</p> <p>还在读 <a href="http://www.douban.com/subject/2776967/">Fearless Change</a> 。原来Linda Rising就是模式年鉴的作者，难怪我听着那么耳熟呢。</p> <p>Evangelist =&gt; Test the Waters =&gt; Time for Reflection =&gt; Small Successes =&gt; Step by Step</p> <p>Ask for Help, Connector, Guru on Your Side, Innovator, and Just Say Thanks</p> <p>You’ve had a meeting using the pattern Piggyback or Brown Bag. Perhaps you were able to Do Food and you scheduled the meeting at The Right Time. You brought some interesting books or articles, hoping to Plant the Seeds and point to External Validation for your new idea. You talked about the Next Steps for your fledgling effort and maybe you used e-Forum to help Stay in Touch with people who are getting interested in your work. If you were really lucky, your collection of like-minded folks has started to form a Group Identity.</p> <p>昨天收到 <a href="http://www.douban.com/subject/2075510/">Strength Finder 2.0</a> 。</p> <p>You might be especially adept at legal work, crafting sound business deals, or ensuring compliance to regulations.</p> <p>郭晓说：I am surprised by Harmony!</p> <p>伤了。</p> gigix tag:gigix.thoughtworkers.org,2010-03-04:1025 2010-03-04T23:37:00Z 2010-03-05T07:58:57Z <p><img src="http://gigix.agilechina.net/assets/2010/3/5/leadership_over_management.png" height="200px" width="400px" /></p> <p>灰色区域是普通员工，蓝色区域是被尊敬的员工，绿色区域是优秀的管理者，红色区域是危险的。</p> <p>所以，得不到管理职位没什么好着急的，领导力更要紧。</p> gigix tag:gigix.thoughtworkers.org,2010-02-26:1023 2010-02-26T02:44:00Z 2010-02-26T02:47:04Z <p>(From <a href="http://www.douban.com/subject/2138463/">Organizational Patterns of Agile Software Development</a> )</p> <p><strong>In a project, not all roles hear everything. But much of the information communicated has important implications for the product.</strong></p> <p>Within any software project, there are many activities, roles, and individuals competing for attention. Of course, there are the developers. But project managers have a need to be at the center of everything. They need to have their finger on the pulse of the project; to know everything that is going on. That’s their job. In a similar manner, perhaps to a lesser degree, other roles also need to be involved in the project.</p> <p>But all roles are not equal. Certain roles (developer and a few others) contribute directly to the product; they create it. Most other roles contribute indirectly to the product; they (should) exist only to help the producers do their job. The producer roles need information in order to do their job.</p> <p>Therefore,</p> <p><strong>The producer role(s) must be at the center or very near the center of the hive of communication. Make sure the producers are party to all, or nearly all communication about the project.</strong></p> gigix tag:gigix.thoughtworkers.org,2010-02-25:1022 2010-02-25T03:59:00Z 2010-02-25T04:01:46Z <p>(From <a href="http://www.douban.com/subject/2138463/">Organizational Patterns of Agile Software Development</a> )</p> <p><strong>It’s important to balance a desire that <span class="caps">SOMEONE ALWAYS MAKES PROGRESS</span> (4.1.20) with the thrashing that can accompany short-term priority calls.</strong> One worker will inevitably be blocked on you—you can’t do both things at once. Complete, omniscient foresight and scheduling are unreasonable to expect.</p> <p>Therefore:</p> <p><strong>If a developer is already working in “interrupt mode” on a critical issue, don’t put that work aside until it is complete or until that issue itself becomes hopelessly tangled.</strong></p> gigix tag:gigix.thoughtworkers.org,2010-02-25:1021 2010-02-25T03:39:00Z 2010-02-25T03:44:00Z <p>(From <a href="http://www.douban.com/subject/2138463/">Organizational Patterns of Agile Software Development</a> )</p> <p><strong>Your experts are spending all their time mentoring novices.</strong></p> <p>You begin to hear things like “We are wasting our experts,” or “A few experts could do the whole project faster.” Indeed, the experts are not proceeding at the rate you or they would expect, because training the new people is draining their energy, time and concentration. But the new people must be trained, by experts, of course.</p> <p>At the same time, you must make progress on the project itself.</p> <p>Therefore:</p> <p><strong>Put one expert in charge of all the novices, let the others develop the system.</strong></p> <p>Separate an experts-only “progress” team from a training team under the tutelage of one or more mentors. Select the mentors for their ability to teach design and programming (object-oriented design and programming, for example) to novices. Let the progress team design 85-95% of the system, let the training team focus on quality training, delivering only 5-15% part of the system. Transfer people to the progress team as they become able to contribute meaningfully.</p> <p>Make sure that the training team does not simply do training exercises, but actually contributes to the final system in an ever-increasing way.</p> <p>If you have many people to train (more than, say, six), you will have to design a series of tasks for them to attempt. Otherwise you may give them a small, real part of the main system to design.</p> <p>If the people in the training team are the ones who know the domain, you will have to make some further adjustment, or else the division may cause conflict.</p> gigix tag:gigix.thoughtworkers.org,2010-02-08:1019 2010-02-08T10:22:00Z 2010-02-08T10:22:58Z <div><a href="http://www.slideshare.net/alimenkou/agile-metrics-2725666" title="Agile Metrics">Agile Metrics</a>&lt;object height="355" width="425" style="margin:0px">&lt;param name="movie" value="http://static.slidesharecdn.com/swf/ssplayer2.swf?doc=agilemetrics-091215150548-phpapp01&stripped_title=agile-metrics-2725666" />&lt;param name="allowFullScreen" value="true" />&lt;param name="allowScriptAccess" value="always" />&lt;embed allowfullscreen="true" type="application/x-shockwave-flash" src="http://static.slidesharecdn.com/swf/ssplayer2.swf?doc=agilemetrics-091215150548-phpapp01&stripped_title=agile-metrics-2725666" allowscriptaccess="always" height="355" width="425">&lt;/embed>&lt;/object><div>View more <a href="http://www.slideshare.net/">presentations</a> from <a href="http://www.slideshare.net/alimenkou">Mikalai Alimenkou</a>.</div></div> gigix tag:gigix.thoughtworkers.org,2010-01-18:735 2010-01-18T13:29:00Z 2010-01-18T13:39:24Z <p>本文以某大型电信设备提供商与<strong>Thought</strong>Works合作的案例为基础，介绍如何采用丰田倡导的精益生产方法对大型软件组织进行敏捷改造。在这个咨询项目中，<strong>Thought</strong>Works咨询师引入的精益理念包括：</p> <ul> <li>5S</li> <li>自働化</li> <li>现场管理</li> <li>湖水和岩石</li> <li>造物先造人</li> </ul> <p>以这些精益理念结合敏捷实践，贯彻PDCA/SDCA实施策略，在四个月的时间里，成功地对一支超过百人的交付团队完成了初步敏捷改造。</p> gigix tag:gigix.thoughtworkers.org,2009-12-31:732 2009-12-31T14:31:00Z 2009-12-31T14:41:17Z <p>转过年，就三十岁了。</p> <p>（感叹的话全都不说了。三十岁的男人要沉稳内敛，嗯嗯。）</p> <p>我想亲身经历一家重要企业的精益变迁，并且在其中扮演重要的角色。</p> <p>我想把已有的技术磨练得更精熟，又学会新的技术做出新的东西。</p> <p>我想变得更可靠更教人安心，同时更自信而不恐慌。</p> <p>就是这样了。很简单的愿望。很大的愿望。</p> gigix tag:gigix.thoughtworkers.org,2009-12-20:716 2009-12-20T13:12:00Z 2009-12-20T13:31:42Z <p>…只要“被改进”的不是我。</p> <p>到底有多少人怀着这样的念头呢？</p> <p>给某知名互联网企业做了一个草草的价值流分析。这家企业和同集团的几家姊妹企业最近都在热火朝天地搞敏捷。培训，项目试点，经验分享，宣讲推广，还打算要制定流程规范。一级一级把成果和经验报上去，领导都很支持。业务线的领导说，交付线的同学们多搞搞敏捷，交付能力强了，咱们公司就能更好地应对顾客们的需求了…</p> <p>等等。这话为什么让我胃里一抽呢？</p> <p>十分钟画出的价值流图告诉我们，一个用户需求从被客户服务部门收集到，直到成为一个新特性上线供用户使用，lead time总计2个月又20天（约合58个工作日），process time约20个工作日。Muda在这个流程中占65%。</p> <p>那么交付线到底浪费了多少呢？嗯，交付线的lead time共计17个工作日，process time共计10个工作日。</p> <p>换句话说，就算这家公司得到了一根魔杖，只要魔杖一挥就能把用户需求变成可用的特性，<strong>他们也不可能在两个月内响应用户需求</strong>，如果业务线没有“被改进”的觉悟的话。</p> <p>所有人都在讲流程改进。所有人都在讲敏捷讲精益。你真的准备好了吗？流程改进的结果，真的是你想要的吗？得到一个精益流程所需的决心和勇气，你已经有了吗？</p> gigix tag:gigix.thoughtworkers.org,2009-12-11:714 2009-12-11T10:12:00Z 2009-12-11T18:25:25Z <p><img src="http://gigix.agilechina.net/assets/2009/12/11/archetype.png" alt="" /></p> <p>这是一个“舍本逐末”的系统基模。</p> <blockquote>上面的环路代表快速见效的症状解，它迅速解决问题症状，但只是暂时的。下面的环路包含了时间延滞，它代表较根本的解决方案，但其效果要较长的时间才会显现出来。然而它可能是惟一持久见效的方式。有时候舍本逐末的结构中，会多出一个由症状解所带来的副作用所形成的增强环路。发生这样的情形时，副作用常使问题更难以解决。 <p>想要扭转舍本逐末的情势，需要增强治本的反应与减弱治标的反应。组织的特性常显示在如何处理舍本逐末情势的能力上。</p> <p>增强治本的反应总是需要一个长期与共有的“愿景”。企业如果不能建立长期不断创新的愿景，那么暂时解决短期问题的策略将取得主控地位。</p> <p>减弱治标的反应，需要诚实地说出那些“症状解”的真相。有时采用症状解有其必要性，但必须认清那只是为了纾缓痛苦症状的权宜之计，此时最容易忽略的是，一旦压力纾缓，就停止寻找根本的努力。</blockquote></p> gigix tag:gigix.thoughtworkers.org,2009-12-10:690 2009-12-10T12:28:00Z 2009-12-10T12:56:00Z <ul> <li>Face-to-Face Team <ul> <li>团队成员对开发状态（进度、问题等）缺乏了解</li> <li>低效沟通导致的步调不一致和延迟</li> <li>个人工作不聚焦</li> </ul></li> </ul> <ul> <li>Standups <ul> <li>个人工作与团队目标偏离</li> <li>因任务受阻而浪费时间</li> <li>隐藏的、有可能影响项目交付的风险或问题</li> </ul></li> </ul> <ul> <li>Retrospectives <ul> <li>可以避免的、由于流程低效或缺乏支持造成的浪费和延迟</li> </ul></li> </ul> <ul> <li>Sustainable Pace <ul> <li>几种缺乏效率的团队工作方式： <ul> <li>任务跟踪不聚焦</li> <li>任务量不饱满</li> <li>“冲刺”编码（降低质量要求）</li> <li>任务分配过量</li> </ul></li> </ul></li> </ul> <ul> <li>User Story Lifecycle <ul> <li>在各个阶段不同角色的工作不饱满</li> <li>不灵活的计划</li> <li>时间或工作量严重超出预期</li> </ul></li> </ul> <ul> <li>Collective Ownership <ul> <li>由于任务需求集中在某人“拥有”的区域而造成的开发延迟（“瓶颈”）</li> <li>由于关键区域的“拥有者”缺勤而造成的交付风险（“ <a href="http://en.wikipedia.org/wiki/Bus_factor">巴士因素</a> ”）</li> </ul></li> </ul> gigix tag:gigix.thoughtworkers.org,2009-12-06:667 2009-12-06T14:07:00Z 2009-12-06T14:19:43Z <ul> <li>Common Vision <ul> <li>各方涉众迭代地汇总观点，就项目的目标、约束和优先级达成共同认识</li> <li>减少因对问题、方案和优先级的理解冲突而浪费的时间和开发资源</li> </ul> </li> <li>Short Releases <ul> <li>在项目进行中频繁交付可工作的软件</li> <li>减少在制品库存的浪费</li> <li>降低在制软件不适合生产环境需要的风险</li> </ul> </li> <li>Iterative Planning <ul> <li>项目计划根据进展中获得的信息迭代式制定</li> <li>避免最后关头获知进度或预算超标</li> <li>减少在低优先级功能上浪费投资</li> </ul> </li> <li>Simplicity <ul> <li>尽量消除软件中的浪费、重复和复杂性</li> <li>降低使用中软件的变化成本和风险（脆弱性）</li> </ul></li> </ul> gigix tag:gigix.thoughtworkers.org,2009-11-29:653 2009-11-29T10:09:00Z 2009-11-29T11:08:21Z <ul> <li>状态：有缺陷的代码持续产出，软件最基本的功能无法保证</li> <ol> <li>建立“缺陷发生时自动停线”的自働化机制</li> <li>实施可视化管理：停线立即告警，作为最高优先级处理</li> <li>解决基础质量问题：消除环境不稳定性，消除伪随机质量问题</li> <li>提升团队基础能力： <ol> <li>采用令牌制提交，明确责任人，谁破坏谁修复</li> <li>设立专人负责监控持续集成状态</li> <li>对于不能快速解决的问题，预备有效的修改撤销机制，快速恢复生产，减少破坏的影响范围</li> </ul></li> </ol></li> </ol> <ul> <li>状态：能得到可用基线，提交失败频率高</li> <ol> <li>分层分级的配置管理和验证体系</li> <li>验证提前：提交代码之前的准入构建</li> <li>更严格的令牌制：以成功的准入构建报告申请令牌</li> </ul></li> </ol> <ul> <li>状态：主线稳定可用，分支合入主线困难</li> <ol> <li>标准化的分支持续集成环境</li> <li>分支持续集成状态巡检，及时发现问题提供支持</li> <li>帮助分支组培养持续集成专门人才</li> </ul></li> </ol> <ul> <li>状态：持续集成稳定可用，需要持续提升</li> <ol> <li>配置管理下的持续集成，解决了改进措施在大团队中复制的难题</li> <li>迭代式改善的持续集成</li> <li>从“贪多求快”、“一步到位”的建设思路转变，确立“小步走稳”的持续改进路线，将PDCA方法应用于大团队持续集成建设</li> </ul></li> </ol>