随笔分类 - 敏捷开发
摘要：敏捷外包工程系列的第四篇（栏目目录）。业界存在的问题CMMI最近没有以往火了，原因之一是SEI发现中国和印度的很多企业在级别评估上造假，尤其是高等级评估。为此SEI还在4级以上做了复审的规定。为什么那么多企业争先恐后地争抢高等级呢？因为想证明自己的质量高。在软件外包，或者说项目开发（而非产品研发）中，进度、质量、成本、需求这些因素虽然可能达到的最终效果有限，但各自的投入却可能是无限的，只是每个因素都以对数曲线规律运行，任凭你投入10倍的人力物力，它只增加一倍。所以，在投入之前，应该问自己：到底哪个是我的终极目标呢？在软件外包或者说项目开发领域，成本是终极目的。因为外包或项目的终极目的是交易，是
阅读全文
摘要：这是火星人预览系列的第七篇（之一，之二，之三，之四，之五问答，之六，之七）。之一：需求与故事结构之二：编辑故事，产品管理，组织结构之三：迭代，计划会，分配任务之四：故事板，燃尽图，我的工作项之五：常见问题问答之六：我的空间，我的通知之七：自定义字段正逢改变SVN后的第99次签入，签入Log如下：可用版本：故事树挪到/Agile/Stories/Index中；解决了故事树中的多产品问题；新增UDCDictsController，其中Index用于比较查看所有/What/Type的自定义字段，Create用于快速创建字段；同时废弃了原来的在UDCsController中的相应功能；菜单中Sprin
阅读全文
摘要：这是敏捷开发一千零一问系列的第十四篇。（之一，之二，之三，问题总目录）正逢周末，又是愚人节，群中有人正在加班，想起上次培训中间休息的时候，讨论起这个“敏捷开发加班吗”的问题，虽然后来没有作为课后投票入选，但这里也完整回答一下。问题敏捷开发加班吗？楼下有人问到“敏捷和加班有什么关系”，补充这两句。有些程序员认为，敏捷开发从制度上要求不加班（可持续的步调），因此会说“老板，现在你不是推敏捷开发吗，那我们就不能加班了，因为敏捷开发不能加班。”结果肯定是：“敏捷要敏捷，加班也要继续加班。”“存在的就是合理的”，既然加班，至少还是有目的或好处的，要想把加班废除掉，就必须找到比加班更合理的东西，让它取而代
阅读全文
摘要：这是火星人预览系列的第六篇（之一，之二，之三，之四，之五问答，之六，之七）。之一：需求与故事结构之二：编辑故事，产品管理，组织结构之三：迭代，计划会，分配任务之四：故事板，燃尽图，我的工作项之五：常见问题问答之六：我的空间，我的通知之七：自定义字段个人中心下面的两个界面都是兼容iphone屏幕尺寸的(960px)。我的空间这个略微复杂的界面是“我的空间”，设计风格很接近微博，基本上在一个界面即可看到与自己相关的所有事情。左侧是我的产品（被产品经理置顶了）、我的团队（项目经理、普通成员会选择将此项置顶）中间是所有与我有关的“通知”（一个很广义的代办事项概念），按时间顺序排列。右侧是我的日历（尚未
阅读全文
摘要：这是火星人预览系列的第五篇（之一，之二，之三，之四，之五问答，之六，之七）。之一：需求与故事结构之二：编辑故事，产品管理，组织结构之三：迭代，计划会，分配任务之四：故事板，燃尽图，我的工作项之五：常见问题问答之六：我的空间，我的通知之七：自定义字段常见问题火星人与以往的敏捷开发工具有何区别？1. 更关注需求管理与传统工具强调团队内部的管理（如故事板、任务管理、缺陷管理等）相比，火星人更加关注团队与外界的沟通；比如用户故事的生成、编辑、组织方式、跟进，是发生在团队与产品部门、团队与客户之间的事情，是火星人的主要议题。原因之一是一个团队由于内部坐在一起，其管理的最佳途径是现场沟通而非借助工具；但团
阅读全文
摘要：这是火星人预览系列的第四篇（之一，之二，之三，之四，之五问答，之六，之七）。之一：需求与故事结构之二：编辑故事，产品管理，组织结构之三：迭代，计划会，分配任务之四：故事板，燃尽图，我的工作项之五：常见问题问答之六：我的空间，我的通知之七：自定义字段日常跟进截图故事板：燃尽图（具备钻取功能）：跟进表：个人中心截图个人中心是3月迭代的重点，所以未来会多很多功能。我的通知：我的工作项（新建和当前负责，可以筛选类型）：
阅读全文
摘要：这是火星人预览系列的第三篇（之一，之二，之三，之四，之五问答，之六，之七）。之一：需求与故事结构之二：编辑故事，产品管理，组织结构之三：迭代，计划会，分配任务之四：故事板，燃尽图，我的工作项之五：常见问题问答之六：我的空间，我的通知之七：自定义字段迭代计划截图迭代计划：团队与迭代日历：意向表及预估（对于当前迭代、前一个及更久远迭代、之后迭代的综合安排）：计划会截图故事讲解+估算：分配页面（计划会后和平时都可使用）：
阅读全文
摘要：这是火星人预览系列的第二篇（之一，之二，之三，之四，之五问答，之六，之七）。之一：需求与故事结构之二：编辑故事，产品管理，组织结构之三：迭代，计划会，分配任务之四：故事板，燃尽图，我的工作项之五：常见问题问答之六：我的空间，我的通知之七：自定义字段产品与故事截图（二）产品版本树：编辑用户故事：团队截图组织结构图：团队操作导航：
阅读全文
摘要：这是火星人预览系列的第一篇（之一，之二，之三，之四，之五问答，之六，之七）。之一：需求与故事结构之二：编辑故事，产品管理，组织结构之三：迭代，计划会，分配任务之四：故事板，燃尽图，我的工作项之五：常见问题问答之六：我的空间，我的通知之七：自定义字段本人除了做培训、写博客、编手册之外，两年来用半业余半全职的时间一点一点开发了一个敏捷开发管理工具，最近接近发布内测版本，发一些预览资料，欢迎大家关注。名称：火星人方法论：Scrum（瀑布模型只可以使用“产品与故事”模块）部署平台：B/S，windows，IIS，SQL Server Express 2008开发平台：asp.net 4.0，C#，MV
阅读全文
摘要：这是敏捷开发日常跟进系列的第四篇。 （栏目目录）跟进表是大型敏捷团队的一种实践。在一个80多人的网络游戏团队中，他们为了清晰地显示整个团队的运作方式，使用了这种方法。跟进表以上面的网络游戏团队为例，说明一下跟进表上的信息：1. 哪些故事完成了在故事板中也能表达，但缺少结构性。故事板中的故事都是平等的，较难显示大小、父子包含关系等。2. 谁在跟进案例中这个人一般是策划人员，故事的创建者和验收者。3. 谁在开发案例中这个一般是若干个开发人员、脚本、美术的群体，也可能只有其中一个工种。4. 某个任务大概可能在何时开始、结束。在故事板、燃尽图上均无法表达。5. 哪些故事被搁置了可能遇到了困难，也可能有
阅读全文
摘要：这是敏捷开发一千零一问系列的第十三篇。（之一，之二，之三，问题总目录）问题这是课堂上提的一个问题，这是一家外企，PO在国外，研发在国内；PO希望大家用故事点估算，而团队习惯用人天估算，问用哪个好，或者两个都用好？分析先分析，后出方案。这个是一个典型的有关无我、无住的问题。所谓无我，就是先弄清楚为什么不同的人想要不同的东西，然后本着到底“谁应该要，应该优先满足谁”而非“我应该要，应该优先满足我”来分析问题。所谓无住，就是故事点和人天估算本无优劣之分，否则就不应该并存在另外一个了，何时使用、为什么使用才是问题的关键。人天估算。人天估算的目的，是为了团队进行沟通。在半年前写的松结对编程共同估算篇（h
阅读全文
摘要：这是敏捷开发日常跟进系列的第三篇。 （栏目目录）故事板和看板其实不是一个东西，前者是最初的敏捷开发里边的东西，受到了后者的启发产生的；而后者是制造业的东西，具体内容请参考末尾的百度百科。但是在敏捷开发里边提到这两样东西，可以认为大致相同。故事板简单说，故事板是展示迭代中的用户故事和任务的方法，在《硝烟中的Scrum和XP》的封面上就印着一个典型的故事板：一般故事板分为三列：To Do还没做的, Doing正在做的, Done做完的（有各种各样的中英文写法，大同小异）有些团队的分工比较多，会出现一些中间状态，比如“还没做的/正在开发的/等待测试的/正在测试的/等待评审的”是一种典型的开发与测试分
阅读全文
摘要：这是敏捷开发一千零一问系列的第十二篇。（之一，之二，之三，问题总目录）问题原问题：敏捷的具体实施是否按照一定的步骤？方案越前面的方案月容易实施，但是也越容易流于肤浅而失败。方案1：循序渐进这个可以说是所有事物推广的方法，不只是敏捷，而作为“敏捷”而言，崇尚迭代交付，自然更符合循序渐进的思想。方案2：面向问题常常听到这样一个问题：我是过程改进人员，以前CMMI过级的时候很忙碌，也很充实，最近公司今年没有过级的任务，大家都闲下来了，下一步该怎么办呢？既然是过程改进人员，就应该改进过程，和CMMI本来是无关的。CMMI的引入，是帮助我们解决问题的，而不是让我们忙碌和充实的。现实项目的问题和困难，才是
阅读全文
摘要：这是敏捷开发一千零一问系列的第十一篇。（之一，之二，之三，问题总目录）问题原来问题是这么写的：“每个人对美的认识不一样，在产品开发过程中，该怎样有效控制界面设计用时？”大致是说有些人觉得这样就得了，另外一些人觉得还不够漂亮，不知道评审的时候该听谁的。这个问题有点另类，所以泛化成“需求谁做主”。方案方案1：听产品经理PO的这个是简化的方案。一般而言，我们总会挑选出正确的人，或至少是最正确的人——他对市场清楚，客户明白，至少在业务方面比程序员经多见广——来形成对需求的雏形，日后验收的，也是他。这个人就是PO，Product Owner，产品的主人，产品经理。不过，常常不存在一个人这么厉害，能超越和
阅读全文
摘要：这是敏捷开发日常跟进系列的第二篇（栏目目录）。迭代及燃尽图的目标燃尽图的目标是完成迭代的目标，迭代的目标是什么呢？1. 按产品经理的要求，交付计划会中计划的用户故事2. 尽量完成1之后还会看到，这个定义还有狭隘之处，在系列后面的文章中会提到。为什么燃尽图不能直接地达成这个目标？潜在的问题包括：1. 如果燃尽图按时完成，有可能是为了按时完成，同时牺牲了所有故事（重要和不重要的）的质量，换取了进度。2. 如果燃尽图未按时完成，有可能不是一个故事没有完成，而是所有故事都剩下点活没做完，导致所有故事都无法交付。3. 如果燃尽图未按时完成，没有完成的故事中，有可能包括了极其重要的一些。只从燃尽图的形态看
阅读全文
摘要：这是敏捷开发日常跟进系列的第一篇（栏目目录）。这个系列将涉及燃尽图（Burndown Chart）、故事板（看板）、每日立会等内容，描述在计划会之后，评审会之前，敏捷开发团队内部产出与产品经理和项目经理的各种活动。日常跟进中的某些内容比如团队工作模型、预估会议、用户故事跟进等在之前的松结对编程、团队管理、用户故事、产品管理等系列中有所描述。在这个系列之前，还应该有一个敏捷计划系列，描述敏捷开发的从版本规划到计划会估算的详细内容，未来将会补上，当前可以参考2.29版的《火星人敏捷开发手册》，有5页与其相对应。燃尽图燃尽图Burdown Chart也叫燃烧图，是罕见的敏捷度量，以至于每当有人问起“
阅读全文
摘要：2012-02-24：新版本发布，新增敏捷计划5页由于原定发布时日期2012-02-29在外地培训，提前发布；本期内容由原定的产品管理改为较为基础的敏捷计划，建议下载。预告：下一更新日期：2012-04-30。本文仅做通知，下载链接及反馈请访问主贴：http://blog.csdn.net/cheny_com/article/details/6616794页面截图：
阅读全文
摘要：这是敏捷开发一千零一问系列的第十篇。（之一，之二，之三，问题总目录）问题总体架构设计在什么时机进行？是每个迭代做还是先做完再迭代？方案之前提到了在时间的角度上，从技术和商业层面上的架构设计，下面看看横向的架构设计。方案1：开发人员全体参与架构设计敏捷开发整体上是一个崇尚“跨职能”的管理方法，开发和测试融合（所以才有很多类似自动化测试、单元测试、持续集成这些需要开发人员强参与的测试活动），开发与产品融合（开发人员要参与客户价值分析）等等，所以在架构设计与编码这两块，也不会分得很开，不能有人专门做架构，另外一些人专门编写代码。一方面，“架构设计”一旦变成一个文档，就要被写，被读，效率不说，中间难保
阅读全文
摘要：这是敏捷开发一千零一问系列的第九篇。（之一，之二，之三，问题总目录）问题总体架构设计在什么时机进行？是每个迭代做还是先做完再迭代？这是少数几个被提到的技术问题。在两天的培训课程之后，最后剩下的纯的技术问题一般只占1/5都不到，多数都是管理问题，而管理问题中，又基本上是人的管理问题，这也说明了在“心法人事物”中，心总是第一位的。方案最早想写成方案1、方案2，但感觉有点像说是有不同的很多并行方法，之后又改成步骤1、步骤2，又有点把事线性化了。现在干脆写回成方案123吧，总之越往后的越终极一些，也越难以一步到位。方案1：Sprint0对于长期的项目，常常引入“Sprint0”的概念。Sprint0就
阅读全文
摘要：这是敏捷开发一千零一问系列的第八篇。（之一，之二，之三，问题总目录）问题在Team中，TeamLeader给人指定任务时，基本没有选择怎么办？（因为大家对别人的工作都不熟悉）方案步骤1：如果团队已经习惯了沉闷地自己开发自己的工作，办公室里边总是静悄悄的，那么一个可行的起点，是Leader可以先与大家进行松结对，就是不断地指导有难题的人。实际上当大家听到有人在交流的时候，就会侧耳听听，如果听到自己感兴趣的话题，也会积极参加。步骤2：下一步，可以主动喊某些人一起交流，比如“老张，过来帮忙看看小李这个问题”，这样交流的范围就逐渐扩大到3个人，而且老张-小李之间也建立了联系。一个宽敞点的办公环境还是很
阅读全文
浙公网安备 33010602011771号