摘要：可能在项目管理中，没有什么比半路接个项目更可怕了。幸好这次还有些底气，是因为自己以前和这个团队合作过，人头还比较熟悉，另外就是在公司也算老员工了，各方面人头比较熟，应该能调动的资源更全面一些。 如果放在传统项目中，可能进入项目之后的第一件事情就是翻阅文档。可是在敏捷这样的大环境中，这些都是奢侈。唯一留下的就是人。所以第一件事情就是尽快评估分析谁是key person。一般来讲，BA是整个off shore团队的的需求来源，通过与他的沟通可以了解整个release的范围以及目前已经完成的状况。同时也就了解了剩下待完成的内容。结合剩余的时间可以大致评估出来项目目前在进度上的风险等级。因为没有人会. 阅读全文

摘要：喜欢《犯罪心理》这部美剧很久了，从第四季一直到现在还在追的第六季，觉得集集精彩。简练而不失悬念。该片的一些情节上的特质让我总是与工作上的某些场景产生对比联想。管理模式。BAU是一个典型的家庭式的管理方式。Hotch作为大家长，不辞辛劳的来维护整个家庭以及团队中每个人的利益。每一个家庭成员都各有所长，紧密团结在以Hotch为核心的关系网上。这种家庭关系来源于长期的工作中的出生入死。对整个家庭的忠诚，对每个家庭成员的信任，对个人信仰的坚持都是一些必备的要素，种种这些会让后期进来的人产生不适应。我相信Hotch并不是刻意的去营造这样一个模式，而是自发形成的，就像家庭关系中无法取代的血缘关系一样，打断 阅读全文

摘要：在敏捷中，每个产品的开发都是以john smith doc开始的，每个sprint都是以故事开始的。在以前，我通常会要求每个sprint开始前可以把需求确定下来，在冲刺的过程中发生的变更通常是不被轻易接受的，所有重大的改变都需要提交到后续的sprint中进行，但是在仔细琢磨之后，我觉得我应该改变对故事的看法。那么故事在敏捷中的作用是什么呢？ 我觉得故事在敏捷中扮演的角色是剧本。编剧或者导演构思出一部好的电影剧本，再好的剧本也需要好的演员去演，每个演员在看到剧本的时候都会有不同的感受，会选择不同的演绎方式。而剧本就给大家提供了一个讨论的平台，他没有规定死演员该怎么演而是更加的鼓励演员去创作，整个 阅读全文

摘要：今天下午有幸借助面试的机会和一位青年才俊做了较为广泛和深入的探讨。在南京面试了不下几百个.net开发人员，能在这个年纪有如此追求和理解的人还是头一回见到，说实话，越聊我自己反而越激动，先在这里祝福一下后面的谈判进行的顺利吧。毕竟有个急缺的位置空了很久，难得碰到如此好的人才，希望不要错过。 在和他聊天的过程中，我感觉他是一个被外包项目运作模式“伤害”过的孩子。以下是几点我和他问答的摘录。问的是他，答的是我。 问：你们公司有bug管理工具吗，有没有什么千行代码bug率.... 答: 我们公司主要用的是QC。不存在bug率的说法。对于一个产品的质量来说，用bug率来衡量一个开发人员的绩效是不合理的. 阅读全文

摘要：为了今年的年会，我们组特地赶制了一个电影剪辑外加搞笑配音，大家忙碌了一周终于在晚会前2个小时完成。在导出的过程中也经历了无数艰辛，直到晚会前30分钟才成功的将作品最终完成。没想到，到了最后关头，确发现酒店的投影仪根本没法放视频，一放视频就黑屏了。彻底雷翻了。 其实在这之前，行政一直要求IT人员带自己公司的投影仪到现场，可是IT人员拍着胸脯说全部没问题，最后发现他啥也没做就做出了如此承诺，结果到了最后开始前，不仅投影不能用，连音箱都不想了。真是悲剧啊。还好大家兴致较高，没有继续计较。 这一点，再次再次的提醒我们，一个东西好不好用绝对是用了才知道。所以测试人员千万不要听开发人员整天捶胸顿足的发誓， 阅读全文

摘要：随着负责敏捷的VP来到中国，看板也成为了这次讨论的热点。很多团队都在使用看板从而取代了之前的Scrum。 看板源于丰田，是丰田生成模式的经典代表，几乎每个学习丰田TPS的企业都会不自觉的把看板当作第一个引入的模式，因为它直观有效。而敏捷将可视化作为很重要的一个要素，自然而然的会想到向看板要概念。那么看板有哪些特色呢？ 在传统的TPS中，看板有很多类型，比如工序间，工序内，信号，外协等等。以工序间为例，当后工具需要一些零件的时候，就将需求（包括规格、数量等等）写到看板上，然后交给前一道工序，那么前一道工序就需要按照看板的指示来生产，生产完后将零件以及看板提交到生产线旁的零件箱中，没有看板而生产出 阅读全文

摘要：丰田人眼中什么是浪费呢？ 1.不为客户创造价值的活动，如检验、物流等 2.尽管创造价值，但所消耗的资源远远超过了“绝对最少”的界限。 这两点简直就是太精辟了，而且是我们大多数人都没有意识不到的问题。也完全的体现了日本人的BT精神。 我们每天都在辛勤的工作，很多人都在忙忙碌碌，却始终得不到认可，因为没有看到东西。我们经常将两个词放到一起比较，效率和效果。我们应该更重视哪个呢？显然是后者。前者在大多数时候总是看上去很美，比如有些人很能说，开会就说个没完没了，动不动就把话题发散，结果什么问题都没解决，除了自己嘴巴痛快外，就剩下浪费别人的时间了。这种浪费是很可怕的，但是也常常被忽略。经常的审查自己每 阅读全文

摘要：软件业发展数十年，开发过程也一代接一代的往前变革着，估计不久就会出现敏捷的下一代。从接触敏捷开发开始，我的脑海里就有一个疑问，敏捷开发与传统制造业有关系吗？它的理论依据是不是来源于传统行业呢？直到最近看了一系列关于丰田模式的文章，才算是找到答案。 丰田的生产模式的核心就是精益生产，可以把它看作去除浪费，降低成本，提高效率的精神。时时刻刻以企业的系统性思考为理论基础。 1.从工厂的组织看。组装线以外的专职人员都不创造价值，把清理现场、工具小修、质量检查的任务都下放到生产小组，允许这些小组定期讨论改进工艺。这明显的可以映射到敏捷开发中破除silo，取而代之的是团队开发模式。团队中的开发、测试、BA 阅读全文

摘要：PO就是我们的客户，客户就是上帝，上帝的旨意就是天大的事情，我们人类一思考，上帝就忍不住想笑。但是，如果你的上帝会技术，那么他就不那么可爱了。 因为，懂技术的人在碰到问题的时候，就会抑制不住的暴露出他的技术情节。这不，当下的这个冲刺，我们的PO在面对界面上出现重复数据的时候，忍不住的要我们解释SQL的逻辑。。。 也许，通过检查我们的SQL，很多问题会被更容易的定位，但是一个问题的出现不仅仅是Po和开发人员被卷进来，而是所有的人都需要被关联到，BA,QA，我们不能因为他们不谙技术就被无情的抛在一边，隔岸观火一般。这种面对问题的思路绝非正确，而且一旦开始便容易上瘾，因为这样的做法看似快捷高效，其实 阅读全文

摘要：Scrum Master身上背负的一个很重要的职责就是让回顾会议开的成功，不然就有虎头蛇尾之嫌，更何谈good to great呢？ 长期以来我们的回顾会议都是这样进行的，到点了，大家拿着笔记本进入会议室，一番闲聊之后，主持人开始打开文档模板，简单的介绍一下会议的流程，然后简要的回顾一下这个冲刺我们都承诺了，实际作了什么，期间发生了什么。接下来顺着座位顺序，各自发感想。感想一般都是可以拿之前的拷贝。然后逼不得已的选一个root cause。结束。整个会议充斥着应付，所以更大程度上是一种休闲。 问题在哪？没有惊喜。什么是惊喜？惊喜就是你浑浑噩噩的进入会议，你心中在背诵主持人的发言稿时，发现他早已 阅读全文

摘要：事件的起因是每个冲刺最后需要作的回顾。考虑到整个团队彼此之间实在是太熟悉，经常会出现所谓的集体无意识，我将回顾会议改为每个人事先发给我他的个人意见，我加以整理合并，然后在回顾会议上提出供大家讨论补充解释。这样就避免了在会上都重复一句话，前面的都说过了，我同意。可是这次，印度那边的文档MM却怒了，因为我们这有人说她前几故事的文档稍微延误，而且都是再说开发和测试高效，从来没人说过文档高效，她一个人写两个产品线的文档辛辛苦苦确不被人认可。。。 说实话，对于远在印度的文档团队，我一向的态度就是认真按时文档不要阻碍我接受故事就行，并没有从内心里太在意他们的感受，也许正是这样的心态多多少少反映在工作中，让 阅读全文

摘要：最近一段时间，因为PO的挑事，我和公司负责Agile推广的VP做了一次深入的讨论。我向她提出了几个在实践中遇到的问题，她也耐心的作了回复，而且回复的详细程度已经到了让我感动的地步。我本身对流程很感兴趣，也曾想过作一个职业的流程推广者，不过每每想到这位VP，我都不由的感慨，作这行得有巨大的耐心和无比坚定的信心。对旧思想的破除是一项非常吃力而且不容易讨好的，短期内很难看到效果的事情。而且，就从我们这边... 阅读全文

摘要：事情是这样开始的。。。 这个sprint，我们挑选了4个story，并且每个story的point都是一样。PO看了很奇怪，因为在她看来有些story明显大于别的。我就给她把这些story不同的难点分析了一下，她大约理解了。不过在解释的时候，我特地提到一点就是有一个技术上的考虑，主要是考虑到比较后的一个story的需求，所以现在在架构上作了调整，确实比单纯完成这个story要复杂一些。这个话题我们... 阅读全文

摘要：这是一篇我最不想写的博客了。不过，随着部门里面一个可爱的小姑娘为了爱情不得不去上海工作同时也成功的拿到了SAP的offer，我不得不思考如何作好工作上的交接，毕竟法律规定的期限只有一个月的时间。 先说下背景。我们这个团队是公司最早的.net团队，也成为了很多.net路线产品的孵化基地。也就是说我们从国外接了很多.net产品的开发任务，然后再转给别人。这就意味着，我们团队里的人涉及到的产品很多，目前... 阅读全文

摘要：在公司做敏捷快三年，每每在关键时候遇到高风险影响出货的危急关头，都无一例外的会把矛头指向质量。按照业界的常用规范，以及我们公司的标准，看似每个冲刺都执行的很漂亮，但是你放眼整个release，把冲刺当作一个点，而非一个时间段，不难发现整个过程是扭曲的，有很多坑没法填的。一个公司在导入流程的时候会有大量的培训予以洗脑。这一点和行销类似。一个销售在卖产品的时候，她只会宣称自己产品的好而不会强调自己产品... 阅读全文

摘要：虽然敏捷这个咚咚反复强调它唯一强调的只有一个，那就是客户价值导向，以提供高质量的软件为己任。但是，作为一个部门级的领导，依然需要考虑在冲刺进行的同时，如何有计划的引入更多更新的东西，以提高团队的活力。这是来源于最近的几次回顾会议上，大家都觉得没什么好说的，初期暴露出来的问题都逐渐解决。大家普遍感觉剩下来的事情就是在做一个一个的故事。所以，我考虑基于目前现状可以考虑引入一些新活，比如更加专业的单元测... 阅读全文

摘要：做了这么长时间的敏捷开发，第一次对一个冲刺有这么刻骨铭心的印象。我想主要有以下几点造成的。第一，是有一个全新的团队，非常年轻几乎没有经历过任何正规化流程的人员构成的团队。第二，是被迫把很多基础性的工作拉进来还不得显性的列在backlog中。第三是，从需求到技术再到部署，都没有在一开始就定好准备好，都是随着时间在迭代。团队。和任何一个经验丰富的scrum master聊天，我想都会感觉到不是每个人都... 阅读全文

摘要：敏捷也实践了不少时间，做过的项目从新的feature的开发，到SP,维护，各种类型的项目都用敏捷运作过。每一类型的故事划分都有其特色。最近新搞了一个团队，对于敏捷所谓只闻其声，为见其行。在一次plan meeting上，新的团队对故事划分的concern充分反映了是否敏捷化的人对流程的认识的差异。故事很简单，做一个报表。这个报表比较复杂，很难在一个sprint中完成，所以很自然的需要去分解成一个个... 阅读全文

摘要：理论上讲，做开发的时候我们永远无法知道什么时候是真正的稳定的状态，需求稳定，人员稳定，框架稳定。感觉就像生活在真空环境中，美好的如同化境。所以敏捷要告诉你的是，无需等待，从现在开始，让我们用自己的双手去发掘未来，探索世界。没有做过敏捷的人确实很难适应，他们总是希望自己对要做的这个任务完全熟悉，了解所有的业务逻辑，了解每一个入参，想清楚各个字段哪里来的。如果可以做到自然更好，可是如果现实是我们没有人... 阅读全文

摘要：昨天下午，是我个人第一次给别人讲敏捷agile。实话说，对敏捷的认识还是自打来到目前的公司后逐步形成的，一是公司主推这个；二是自己也确实想领略一下这个时下非常流行的咚咚，看看与自己研究蛮久的UP有什么异同，有什么可以互相借鉴的。昨天的这次培训，针对的是一个全新成立的团队进行的，有些人来自己不正规的公司，也很大部分来自做CMMI很久的公司。他们在培训中提出的问题其实还是很有代表性的。我先说两个。 第... 阅读全文