摘要：本文开始K君更名为kaka，Z君更名为国良。 周末，kaka在公司进行培训敏捷研发方面的知识，想到还有一名员工没有招聘到岗，内心开始焦躁起来，由因为要面试的相关技术不是很了解，必须依赖大牛唐博士，于是给唐博士发了一个短信，询问一下下周的行程，看看能不能抽出时间来一起面试。没过多久，唐博士电话就打过来了。一聊，唐博士下周都没有时间，在项目上面出差呢。ka... 阅读全文

摘要：为什么要开Sprint启动会，不开是否可以？它的作用是什么？为什么要PO，SM，TEAM都参加？带着这些问题，我们分析一下Sprint的启动会的内容。 大家也知道启动会重点做了以下的这几件事情： 进行需求讲解 挑选PBI（product backlog item），也就是由客户选出重要的PBI. 拆解PBI到SBI（sprint backlog... 阅读全文

摘要：Z君很快就整理好了需求模板，放到了Wiki上面，让大家进行参考，后续的每个功能点的需求都需要按照这个模板进行填写，这样后续需求人员进行整理需求的时候就可以方便的进行需求汇总了。SVN上的项目也由新波创建好了，一个M产品的Project，下面分了6个模块的子Project。整个研发过程还是依照之前裁剪的Scrum流程进行，每两周一次迭代，每日9点钟进行立会，在看板上进行挪动自己的任务... 阅读全文

摘要：Wiki新波（M产品的研发经理）的努力下搭建好了。虽然在搭建的过程中，破费周折，自己机子测试良好的Wiki在发布到服务器上，却巨慢无比，也不知道为什么，于是连忙换了台机子之后，方才有所改善。那么Wiki好了，该如何开始呢？工具都已经有了，就看你怎么干了。 K君还在思考着后续如何进行的时候，突然想到产品的大纲还没有写上呢，于是赶紧登陆Wiki准备研究一下大纲编... 阅读全文

摘要：M产品酝酿了那么长时间，终于大规模的研发了，实属不易，但是摆在K君面前的困难还是不少的。6大模块同时发力，需求欠缺，只有概要需求，时间期限很紧，人员缺失，研发人员，需求人员都存在着瓶颈，并且年底前需要出α版本。想到了这些脑袋就已经大了。 如何做？怎么做？那么多的需求，需求人员对应的过来吗？研发人员一起研发6大模块，还是像以前一样，等待着需求写出来，评审完毕在进行吗... 阅读全文

摘要：前一篇文章《Scrum迭代中的质量标准》提到Scrum迭代内的质量标准，关于质量标准，不同的人给与了不同的看法，在这里根据大家的一些反馈进行一些补充。 1.全能人才的Scrum团队实际上也需要一个质量标准进行把关，只是需要汇总前面的研发bug数和测试人员的bug作为一个质量标准进行验收。 2.不同人员的能力不同，导致的质量目标是不尽相同的，但如果把这个质量标... 阅读全文

摘要：在Scrum迭代过程中，比较看重的一点是最后的验收质量，迭代是滚动的，如果迭代的质量不达标，就会导致质量债一直存在，这样就会像滚雪球一样，逐步积累起来，越来越大，最终导致Scrum只有形而已，而不是真正的敏捷。因为不能在任意阶段拿出可以发布的产品。 而产品质量这个词汇，又是一个比较虚的词汇，谁也不能保证产品没有bug了，谁也不能说产品的质量到达一个什么地步了。另外一点就是在Scrum迭代过程中存在着三种角色，产品经理，研发，测试。在高质量的敏捷素质要求里面，要求后两者合二为一了，成为一个全能人才。但是很多公司里面，研发和测试还是割裂开的。那么这三个角色之间也会面临着质量诉求，研发要求... 阅读全文

摘要：最近一直在看《金矿》，一本讲精益的图书，里面讲到了各种看板和流程梳理的事情，看的时候总是不由自主的想到Scrum的一些流程，其中的很多知识给与我更多的思考。 精益里面的流程，是以看板为基础进行拉动前面的生产，同时控制前面的生产节拍和节奏，保证了在制品的减少，从而减少了在制库存，也减少了成本。那么如果把这个思想放到Scrum里面的话，那又会是怎么样呢？ 以前，在实施Scr... 阅读全文

摘要：每日看板是每日状态的表现，但是关于每日看板有些反模式存在，以某个部门内的每日看板为例。 这个看板主要体现了两个反模式 1.开发中版面过大 给与开发中预留的版面过大，这样给与大家的一个信号就是可以有多个同时在开发中的任务，从版面所占比例来说也是鼓励这样去做，这样就会造成一个现象就是开发人员同时开始多个任务，从现在的现象来看也是这样的，这样造成的后果就... 阅读全文

摘要：最早接触敏捷的时候，是从Kent的TDD开始，当时比较崇拜Kent，一是因为Junit的代码写的太棒了，里面的思想给与我很大的启发，第二个是我是用着Eclipse，其中也有kent的代码在里面，这样一个伟大的人物深刻的影响着我。于是我买了关于TDD的书，学习TDD的思想，但是因为各种原因，没有实行起来，后来XP的流行也继续冲击着毕业没有多久的我，极限的条件，极限的编程，冲击很大，思想也影... 阅读全文

摘要：敏捷有些时候，不仅仅是一个流程，很多时候，还要涉及到心态的变化，从产品研发的角度来说，就需要相关角色转变思想不能还是停留在瀑布的思想上。 1.需求的心态 A）我写完了，你们们慢慢做吧，有问题问我。 ====》需求，研发，测试是一体的，需求人员需要随时关注产品状态，进行确认。产品的质量是大家的责任。 B）这么多的东西，我哪能那么快的写完，你们再等等... 阅读全文

摘要：之前在任务看板上贴的任务便签全部都是拆分后的，每个小任务，基本上都是2~3个小时，或者是0.5天，1天的任务，这样造成的一个后果就是一个功能点是否完成了，或者是一个特性是否完成了，不是很直观的知道，同时统计的燃尽图也都是根据小的任务进行统计的，导致某个时间点想看都有哪些功能点或者哪些业务特性做完了，就很难进行统计和了解，只能从错综复杂的细节中进行抽丝剥茧进行分析，使用起来很是不方便。 ... 阅读全文

摘要：一直在实践着敏捷的思想和一些敏捷的流程，但是因为很多原因没有完全照搬敏捷流程进行实践，而是根据自身的一些限制进行了裁剪和探索。本周三的时候和公司的研发管理部进行了交流，发现了我们的实践和敏捷思想的一个本质的冲突就是关于演示会交付物的品质标准是有所区别的。（后面称呼第一种流程为山寨敏捷，第二种叫做正规敏捷） 我们的流程为中定义演示会交付的成果物为研发人员自测标准，而研发管理部明确的敏捷流程演示会交付的成果物为测试人员验证后的标准，两个标准相差较大，并且所体现的思想也是相差很大。第一个图是我们实践的流程，经过研发人员自测之后，就算完成状态。第二个图是研发管理部规定的敏捷流程，研发之后，必... 阅读全文

摘要：在研发过程中，为了保证代码质量，很多团队都会使用代码评审，或者叫做代码Review。一般情况下，代码Review都会采用集体Review的形式。 集体Review 形式： 一个团队，大家坐在一间会议室里面。一人进行讲解自己的业务和代码实现，团队的其他成员进行Review，提出问题，发现问题和补充不足。 这样可以达到以下的目的： 1.Linus定律 "只要有足够多的眼睛，就可让所有问题浮现"。每个人思考和理解事情的角度不同，这样发现问题也不尽相同，人数越多，发现问题也就越全面。 2.在进行补充和提出建议的过程中，可以达到组内的开发规范和标准的传播，使大家明白统一标准。 ... 阅读全文

摘要：每日立会本身是进行状态分享交流的会议，现在发现大多数的时候，立会上大家都是各说各话，互不关心，在一个人说自己的事情的时候，每个人都在想着自己的哪一点事。别人说的什么，做的什么，只有项目负责人关心，讲的人眼睛也只是在看着项目负责人再说。并且更没有人在项目上说一些大家共同关心的事情，或者需要大家进行关心的事情。 如果每日立会都只是这样的话，和走形式就很类似了，也没有大家聚在一起的重要性也打折了很多，这样也造成了一个效果就是需要项目负责人非常用心去关注每个人，关注每个细节，如果稍有遗漏，可能问题就会溜走了。Linus定律 "只要有足够多的眼睛，就可让所有问题浮现"，在这里也没办法 阅读全文

摘要：每日立会的时候，需要会议的组织者注意一些词汇和和现象，不可走形式，不然的话，立会就不会达到预期的目标。立会的一个主要目的是及时有效的发现问题和解决问题。如果在立会上没有能发现问题，或者忽视掉了问题，那么立会的效果就会大打折扣。 立会上大家所说的话中如果存在含糊的词汇，就需要引起组织者和大家的注意，含糊的地方，其实就是需要注意的地方。比如“比我想象的有些难”、“这个任务有些复杂”、“我理解错了”、“我的实现方式有了问题”、“我的还差一点就好了”，“昨天弄点别的耽误了”等等。乍一听，感觉有些合理，因为一些原因导致了延误，或者有些事情给延误了，但是这些地方其实就是问题的地方。 1.关键词汇... 阅读全文

摘要：一直在实验着敏捷的思想，记录在立会的过程中发现的一些小问题 1.各说各话，互不关心 现象：大家都在各自说着各自的事情，做的多少，准备做哪些。眼睛也是盯着开发经理，项目的主持人，而不是大家。一个人讲话的时候，其他人都在想着自己的那点事情。 对策：现在准备改成提问，随机抽取听的人，问问是否听明白上一个人讲的话，明白就好，不明白就问到明白为止。现在发现效果不错，大家的情绪一下子提升起来了，气氛也热闹起来了。 2.分享问题 现象：只是说了自己昨天做了什么，大块的，没有技术分享过程和心得分享。 对策：等待说完了之后，补充问一句，有没有什么想要分享的，和学习到的。或者知道他有... 阅读全文