叁 消除浪费

当我们追根溯源敏捷最先被发明的初期,可以发现,敏捷所消除的便是因为频繁业务需求改变带来的潜在浪费,而一切关于杜绝浪费话题到最后,都变成为对价值的纯粹追求。 任何商业模式都基于创造新用户和挽留老用户,最终也被细化为为新用户提供不可替代的新价值和为老用户提供持续改进的旧价值(当然同样可为新价值)那么两件事情被认为是杜绝浪费最重要的两个方面: 只给客户想要的; 让客户简单地用到他们想要的; 简而言之,做了没用的和没用已经做了的是最普遍的两种浪费。二者间的关系是:做了没用的往往的结果是未使用,但未使用往往不止是因为没有用(也许你不够好)。 一个简单的对话可能会揭示这个道理。gigix在贴卡片的时候使用了没有ThoughtWorks logo那一面,我问:用反面的价值是什么?gigix说:我顺手写在了反面。我说:那你就把 »

贰 沟通问题

强调沟通和杜绝浪费是敏捷最核心的东西,这两项基本是贯穿我这次咨询活动的主线-任何细微的活动都需要用心审视两个问题:我做这件事情的前提是传递价值给团队另一个人,那么价值的传递过程中有没有沟通的阻碍?价值的传递过程有没有什么东西导致了传递损耗既是浪费? 从一对一沟通谈起,逻辑是你不可能消除所有的沟通壁垒,譬如你的口齿不够清楚,那么至少发现那些你可以消除的壁垒,消除它,并告知和提醒你的听众那些你不能消除的。往往人们犯的错误是: 察觉不到那些可能成为沟通壁垒的微小细节; 对自己不能消除的壁垒过分乐观; 对自己的听众过分乐观; 很多微不足道的东西都可能称为沟通壁垒。传统上,邮件和文档理所当然称为阻隔沟通的最大障碍。文字的修辞不如口头表达直白有效;文字很难达到及时的确认反馈;超过一定数量的文字考验被交流者的耐心;绝大部分的文档撰稿人无法理解文档是一种用户界面的思想,我所看到的情况,大部分的文档达不到可读(readable) »

壹 从广州开始

今天已经是第四天,昨天无意中看到LL每天都在记录敏捷实践也颇感自己应该给自己和后面的人留下点什么,是为纪录。 咨询的对象是国际领先的一家大型电信供应商A,同时也是另外一家国际领先的电信运营商B的服务提供商,相当拗口。目的在于如何将敏捷方法论影响到内部团队端和客户端,以达到提高交付能力和交付质量的目的。逻辑上这个是很说得通的,提高交付能力就是做得快,通过对客户的引导实现需求划分和快速确定,发现隐含需求降低风险,减少因需求不明引起的返工,自然就会做得快;提高交付质量就是做得好,通过对团队内部引入敏捷实践实现信息透明共享,持续集成,自动化测试策略,需求故事化,提高代码质量,自然就会做得好。 项目内容也是BOSS级这种相当核心的系统,我个人也十分兴奋,之前的敏捷咨询大多数围绕在开发端譬如持续集成和本地构建此类技术层面展开,对于前端需求获取的参与较少,此次也是一次好机会展示敏捷方法论在需求阶段的可行性。 »