我的一天

摘要： 这是火星人预览系列的第二篇（之一，之二，之三，之四，之五问答，之六，之七）。之一：需求与故事结构之二：编辑故事，产品管理，组织结构之三：迭代，计划会，分配任务之四：故事板，燃尽图，我的工作项之五：常见问题问答之六：我的空间，我的通知之七：自定义字段产品与故事截图（二）产品版本树：编辑用户故事：团队截图组织结构图：团队操作导航： 阅读全文

摘要： 这是火星人预览系列的第一篇（之一，之二，之三，之四，之五问答，之六，之七）。之一：需求与故事结构之二：编辑故事，产品管理，组织结构之三：迭代，计划会，分配任务之四：故事板，燃尽图，我的工作项之五：常见问题问答之六：我的空间，我的通知之七：自定义字段本人除了做培训、写博客、编手册之外，两年来用半业余半全职的时间一点一点开发了一个敏捷开发管理工具，最近接近发布内测版本，发一些预览资料，欢迎大家关注。名称：火星人方法论：Scrum（瀑布模型只可以使用“产品与故事”模块）部署平台：B/S，windows，IIS，SQL Server Express 2008开发平台：asp.net 4.0，C#，MV 阅读全文

摘要： 给自己留一条进可攻，退可守的后路，确实不是一件容易的事。段伏枥翻来覆去碾转反复，还是一无所获，只搞得自己心烦意乱，直到半夜三更才入眠。其实如果能想出来，早就想到了，哪里还用等到今天。只不过是干姐的一番话，突然勾起自己的思绪而已。 因为徐雅思和刘思敏所住的地方空空荡荡的，没有电视，没有宽带，就连做饭也不方便。所以到周末的时候，如果没有出去逛街或是户外活动的话，都会来段伏枥这边来玩。没办法啊，谁让这边有电视，有宽带，就连做饭所需要的用具也一应俱全呢？不过自从上次狗不理事件之后，段伏枥就基本不敢显摆了，以免浪费粮食；即使偶尔到厨房转转，也只是帮两个女生打打下手，洗洗菜之类的。 一觉醒来，差不多也到. 阅读全文

摘要： 这是敏捷开发日常跟进系列的第四篇。 （栏目目录）跟进表是大型敏捷团队的一种实践。在一个80多人的网络游戏团队中，他们为了清晰地显示整个团队的运作方式，使用了这种方法。跟进表以上面的网络游戏团队为例，说明一下跟进表上的信息：1. 哪些故事完成了在故事板中也能表达，但缺少结构性。故事板中的故事都是平等的，较难显示大小、父子包含关系等。2. 谁在跟进案例中这个人一般是策划人员，故事的创建者和验收者。3. 谁在开发案例中这个一般是若干个开发人员、脚本、美术的群体，也可能只有其中一个工种。4. 某个任务大概可能在何时开始、结束。在故事板、燃尽图上均无法表达。5. 哪些故事被搁置了可能遇到了困难，也可能有 阅读全文

摘要： 招人风波之后，就很少见武总往17楼跑了，大部分时间都是坐在20楼的隔间。而武总对段伏枥的抱怨，也仅仅只有那次，后来就再也没有提过。对于段伏枥而言，还要不要招新人，后续如何去招新人，已经不是自己所关心的事情；自己现在最重要的任务，则是如何捣鼓这GPS主板。 其实在两天前，段伏枥他们已经将这主板的每个功能模块都调通。当然并不是打回来的十片板子都能够正常工作，毕竟开发过程中还是有损耗的，能正常使用的也就六片，不良率接近40%。但这对于段伏枥他们而言，这相当于自己的第一个作品，也算是成功了。只不过，接下来的问题才是最最关键的，这调好的主板能做什么呢？ 在规划这块GPS主板的时候，结构是随意而为的... 阅读全文

摘要： 这是敏捷开发一千零一问系列的第十三篇。（之一，之二，之三，问题总目录）问题这是课堂上提的一个问题，这是一家外企，PO在国外，研发在国内；PO希望大家用故事点估算，而团队习惯用人天估算，问用哪个好，或者两个都用好？分析先分析，后出方案。这个是一个典型的有关无我、无住的问题。所谓无我，就是先弄清楚为什么不同的人想要不同的东西，然后本着到底“谁应该要，应该优先满足谁”而非“我应该要，应该优先满足我”来分析问题。所谓无住，就是故事点和人天估算本无优劣之分，否则就不应该并存在另外一个了，何时使用、为什么使用才是问题的关键。人天估算。人天估算的目的，是为了团队进行沟通。在半年前写的松结对编程共同估算篇（h 阅读全文

摘要： 这是敏捷开发日常跟进系列的第三篇。 （栏目目录）故事板和看板其实不是一个东西，前者是最初的敏捷开发里边的东西，受到了后者的启发产生的；而后者是制造业的东西，具体内容请参考末尾的百度百科。但是在敏捷开发里边提到这两样东西，可以认为大致相同。故事板简单说，故事板是展示迭代中的用户故事和任务的方法，在《硝烟中的Scrum和XP》的封面上就印着一个典型的故事板：一般故事板分为三列：To Do还没做的, Doing正在做的, Done做完的（有各种各样的中英文写法，大同小异）有些团队的分工比较多，会出现一些中间状态，比如“还没做的/正在开发的/等待测试的/正在测试的/等待评审的”是一种典型的开发与测试分 阅读全文

摘要： 这是敏捷开发一千零一问系列的第十二篇。（之一，之二，之三，问题总目录）问题原问题：敏捷的具体实施是否按照一定的步骤？方案越前面的方案月容易实施，但是也越容易流于肤浅而失败。方案1：循序渐进这个可以说是所有事物推广的方法，不只是敏捷，而作为“敏捷”而言，崇尚迭代交付，自然更符合循序渐进的思想。方案2：面向问题常常听到这样一个问题：我是过程改进人员，以前CMMI过级的时候很忙碌，也很充实，最近公司今年没有过级的任务，大家都闲下来了，下一步该怎么办呢？既然是过程改进人员，就应该改进过程，和CMMI本来是无关的。CMMI的引入，是帮助我们解决问题的，而不是让我们忙碌和充实的。现实项目的问题和困难，才是 阅读全文

摘要： 这是敏捷开发一千零一问系列的第十一篇。（之一，之二，之三，问题总目录）问题原来问题是这么写的：“每个人对美的认识不一样，在产品开发过程中，该怎样有效控制界面设计用时？”大致是说有些人觉得这样就得了，另外一些人觉得还不够漂亮，不知道评审的时候该听谁的。这个问题有点另类，所以泛化成“需求谁做主”。方案方案1：听产品经理PO的这个是简化的方案。一般而言，我们总会挑选出正确的人，或至少是最正确的人——他对市场清楚，客户明白，至少在业务方面比程序员经多见广——来形成对需求的雏形，日后验收的，也是他。这个人就是PO，Product Owner，产品的主人，产品经理。不过，常常不存在一个人这么厉害，能超越和 阅读全文

摘要： 关于招个人来开发蓝牙程序的事情，难得武总这次没有忽悠——在提出建议后的第三天，武总就找来个新人。本以为自己已经够貌不惊人了，没想到还有人比自己更貌不惊人。不过呢，做技术这行又不是靠外貌吃饭，只要技术过硬，有什么害怕的？这看的是内涵！ 段伏枥一见新同事，自然是热情地打招呼:“你好！” 有老员工主动打招呼，自然同事也不会置之不理，回应到:“你好！我叫戴超群！” 从相貌上看，戴超群应该在三十来岁左右，当然不能”小戴、小戴”地叫，所以只能换个通用叫法:“戴工，你是来做蓝牙的吧？” 戴超群笑了笑，点了点头，算是段伏枥说对了。 段伏枥继续问到:“你做WinCE应该很多年了吧？” 没想到戴超群居然回答说:. 阅读全文