随笔分类 - 敏捷开发
摘要：本文是敏捷开发产品管理系列的第八篇。（专栏目录）在产品开发中，常常遇到产品性能问题，这些性能问题会很大程度上影响到产品的架构。但解决这些性能问题，切莫认为只是技术人员的事情，产品经理和产品总监也要参与其中，甚至是业务人员（销售、售前）。下面以12306的售票问题为例，来做一个完整的说明。本文的目的，不是说技术性优化不必要，而是说作为开发人员不要闷头只想技术，而作为产品经理不要把所有“技术”问题推给开发人员，这一点很重要。技术方案的局限性12306为什么崩溃了？原因众说纷纭，解决方案也众说纷纭。到网上一搜“12306 性能”http://www.baidu.com/s?wd=12306+%D0%
阅读全文
摘要：本文是敏捷外包工程系列的第四篇。（之一，之二，之三，之四） 本文是2012年05月初IIOM（国际外包管理学院）的专访。传统认为敏捷开发是面向产品研发的，在外包项目里边比较难用，因为需求由客户牵制，而“拥抱变化”极有可能导致项目延期超支，等等。本文提及了敏捷开发对外包项目的帮助，以及如何利用功能点估算和度量防止出现超支。原文位置：http://www.int-iom.cn/int/members-area/2011-11-23-02-00-48/item/328-cy-zf 欢迎报名参加2012-06-01的相关研讨会，联系方式在上述链接的末尾。原文拷贝：-------------------
阅读全文
摘要：这是敏捷开发一千零一问系列的第十七篇。（在这里提问，之一，之二，之三，问题总目录）方案3：培养产品经理，想到客户前面被客户牵着鼻子走本来不是坏事，还少了做需求分析的工作，但关键是客户一会牵着向东，一会牵着向西，好像自己也没有主张的样子，这就令开发团队郁闷了。这时候，无论是不是产品化了，都应该培养一个人，看到客户前面去，看他自己是不是都迷路了。客户“迷路”大体有两种情况，一种是有路但自己不知道。曾经去过一家银行的研发中心做咨询，开发人员访谈时抱怨业务部门每个月都只扔一点点需求过来，大家就像玩拼图游戏一样猜测业务的整体，经常中间变化猝不及防；而业务部门则抱怨研发中心只关心需求不关心业务，“对整个业
阅读全文
摘要：这是敏捷开发一千零一问系列的第十七篇。（在这里提问，之一，之二，之三，问题总目录）这个是在一次面向电信行业供应商的公开课上提出的问题，被评为本场最佳问题。对于这类“供应商”而言，一方面业务根深蒂固，一般固化在某些专有领域因此很有必要产品化；另一方面又受制于客户总是来回改动，很难有自己的自主权。两者的矛盾，可以通过逐步推广敏捷开发而解开，也需要大量的周边技术、管理、市场手段来辅助。甚至应该反过来说，敏捷开发知识辅助这些技术、管理、市场手段的执行。问题长期受制于强势客户怎么办？方案多数情况下，受制于客户会导致开发活动长期以“无法复用的项目”存在，而不是以“一本万利的产品”存在。所以本文会更多地说说
阅读全文
摘要：这是敏捷开发一千零一问系列的第十六篇。（在这里提问，之一，之二，之三，问题总目录）这个和上一篇“敏捷开发与CMMI谁为主”都是最近一次培训被大家选出来的最有价值问题。问题开发人员一般都只关注开发，如何让他们去关注产品呢？方案方案1简单但不彻底，方案3彻底但不简单。方案1：产品经理在计划会讲解产品背景计划会是一个产品经理宣贯产品的好地方，但是我们山东籍的程序员就会问：“你啰啰这些没用的黄子做么”，西川籍的程序员也会说：“瓜娃子，直接说要做啥子就得了么”一来二去，计划会很可能变成需求会，需求会又会变成功能会，功能会再变成设计会。当然会有人说：“产品经理定义好需求，让大家按照做，不也没问题吗？”这个
阅读全文
摘要：2012-04-30：新版本发布，新增敏捷日常跟进4页。由于不明原因部分页面包括目录变成黑白的了，但是不影响点击链接等操作。预告：下一更新日期：2012-06-30。 本文仅做通知，下载链接及反馈请访问主贴：http://blog.csdn.net/cheny_com/article/details/6616794 页面截图：
阅读全文
摘要：这是敏捷开发一千零一问系列的第十五篇。（在这里提问，之一，之二，之三，问题总目录）也是敏捷与CMMI系列的第三篇。（总目录）问题原来问题是这么写的：“一家企业既要过CMMI，又要过ISO，还要实施敏捷，应该怎样做？”之所以改成“哪个好”，是因为如果要多头并存，就要有主次关系。那么，到底哪个好，应该以哪个为主呢？分析每次说到这个问题，都会有不同的角度可以分析。一个常见的角度是说：CMMI比较完整“大气”，可以做整个公司的管理框架，而敏捷更适合团队级别的管理。另外一个角度是说：两个是可以共存的，可以用敏捷开发的实践来满足CMMI的要求。那么，到底哪个角度是优先考虑的呢？商业目标是优先考虑的角度。这
阅读全文
摘要：敏捷外包工程系列的第四篇（栏目目录）。业界存在的问题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希望大家用故事点估算，而团队习惯用人天估算，问用哪个好，或者两个都用好？分析先分析，后出方案。这个是一个典型的有关无我、无住的问题。所谓无我，就是先弄清楚为什么不同的人想要不同的东西，然后本着到底“谁应该要，应该优先满足谁”而非“我应该要，应该优先满足我”来分析问题。所谓无住，就是故事点和人天估算本无优劣之分，否则就不应该并存在另外一个了，何时使用、为什么使用才是问题的关键。人天估算。人天估算的目的，是为了团队进行沟通。在半年前写的松结对编程共
阅读全文
摘要：这是敏捷开发日常跟进系列的第三篇。 （栏目目录）故事板和看板其实不是一个东西，前者是最初的敏捷开发里边的东西，受到了后者的启发产生的；而后者是制造业的东西，具体内容请参考末尾的百度百科。但是在敏捷开发里边提到这两样东西，可以认为大致相同。故事板简单说，故事板是展示迭代中的用户故事和任务的方法，在《硝烟中的Scrum和XP》的封面上就印着一个典型的故事板：一般故事板分为三列：To Do还没做的, Doing正在做的, Done做完的（有各种各样的中英文写法，大同小异）有些团队的分工比较多，会出现一些中间状态，比如“还没做的/正在开发的/等待测试的/正在测试的/等待评审的”是一种典型的开发与测试分
阅读全文
浙公网安备 33010602011771号