敏捷开发 - 随笔分类 - 阳光VIP1

敏捷开发免费管理工具——火星人预览（问答）

摘要：这是火星人预览系列的第五篇（之一，之二，之三，之四，之五问答）。常见问题火星人与以往的敏捷开发工具有何区别？1. 更关注需求管理与传统工具强调团队内部的管理（如故事板、任务管理、缺陷管理等）相比，火星人更加关注团队与外界的沟通；比如用户故事的生成、编辑、组织方式、跟进，是发生在团队与产品部门、团队与客户之间的事情，是火星人的主要议题。原因之一是一个团队由于内部坐在一起，其管理的最佳途径是现场沟通而非借助工具；但团队内外的沟通则很需要沟通。原因之二是故事板、任务管理的记录一般在一两个月后就可以扔掉了，完全可以用纸片；而需求管理的记录则需要长期保存，必须用工具。2. 全新的展示界面“界面”常常被认阅读全文

posted @ 2012-03-15 19:42 阳光VIP1 阅读(2877) 评论(0) 推荐(0)

敏捷开发免费管理工具——火星人预览（四）

摘要：这是火星人预览系列的第四篇（之一，之二，之三，之四，之五问答）。日常跟进截图故事板：燃尽图（具备钻取功能）：跟进表：个人中心截图个人中心是3月迭代的重点，所以未来会多很多功能。我的通知：我的工作项（新建和当前负责，可以筛选类型）：阅读全文

posted @ 2012-03-15 14:43 阳光VIP1 阅读(253) 评论(0) 推荐(0)

敏捷开发免费管理工具——火星人预览（三）

摘要：这是火星人预览系列的第三篇（之一，之二，之三，之四，之五问答）。迭代计划截图迭代计划：团队与迭代日历：意向表及预估（对于当前迭代、前一个及更久远迭代、之后迭代的综合安排）：计划会截图故事讲解+估算：分配页面（计划会后和平时都可使用）：阅读全文

posted @ 2012-03-15 13:01 阳光VIP1 阅读(253) 评论(0) 推荐(0)

敏捷开发免费管理工具——火星人预览（二）

摘要：这是火星人预览系列的第二篇（之一，之二）。产品与故事截图（二）产品版本树：编辑用户故事：团队截图组织结构图：团队操作导航：阅读全文

posted @ 2012-03-15 11:48 阳光VIP1 阅读(326) 评论(0) 推荐(0)

敏捷开发免费管理工具——火星人预览（一）

摘要：这是火星人预览系列的第一篇（之一，之二，之三，之四，之五问答）。本人除了做培训、写博客、编手册之外，两年来用半业余半全职的时间一点一点开发了一个敏捷开发管理工具，最近接近发布内测版本，发一些预览资料，欢迎大家关注。名称：火星人方法论：Scrum（瀑布模型只可以使用“产品与故事”模块）部署平台：B/S，windows，IIS，SQL Server Express 2008开发平台：asp.net 4.0，C#，MVC3，SQL Server Express 2008免费版核心功能（不限人数，永久免费）：产品与故事产品线-产品-版本Edition-版本Version-发布管理用户故事管理团队与迭代阅读全文

posted @ 2012-03-15 11:08 阳光VIP1 阅读(1671) 评论(0) 推荐(0)

敏捷开发日常跟进系列之四：跟进表

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

posted @ 2012-03-10 12:08 阳光VIP1 阅读(205) 评论(0) 推荐(0)

敏捷开发一千零一问系列之十三：故事点好还是人天好？

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

posted @ 2012-03-06 11:51 阳光VIP1 阅读(323) 评论(0) 推荐(0)

敏捷开发日常跟进系列之三：故事板，看板

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

posted @ 2012-03-05 20:15 阳光VIP1 阅读(310) 评论(0) 推荐(0)

敏捷开发一千零一问系列之十二：敏捷实施的步骤？

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

posted @ 2012-02-29 23:32 阳光VIP1 阅读(177) 评论(0) 推荐(0)

敏捷开发一千零一问系列之十一：需求谁做主？

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

posted @ 2012-02-29 23:31 阳光VIP1 阅读(108) 评论(0) 推荐(0)

敏捷开发日常跟进系列之二：燃尽图（中）

摘要：这是敏捷开发日常跟进系列的第二篇（栏目目录）。迭代及燃尽图的目标燃尽图的目标是完成迭代的目标，迭代的目标是什么呢？1. 按产品经理的要求，交付计划会中计划的用户故事2. 尽量完成1之后还会看到，这个定义还有狭隘之处，在系列后面的文章中会提到。为什么燃尽图不能直接地达成这个目标？潜在的问题包括：1. 如果燃尽图按时完成，有可能是为了按时完成，同时牺牲了所有故事（重要和不重要的）的质量，换取了进度。2. 如果燃尽图未按时完成，有可能不是一个故事没有完成，而是所有故事都剩下点活没做完，导致所有故事都无法交付。3. 如果燃尽图未按时完成，没有完成的故事中，有可能包括了极其重要的一些。只从燃尽图的形态看阅读全文

posted @ 2012-02-29 10:46 阳光VIP1 阅读(616) 评论(0) 推荐(0)

敏捷开发日常跟进系列之一：燃尽图（上）

摘要：这是敏捷开发日常跟进系列的第一篇（栏目目录）。这个系列将涉及燃尽图（Burndown Chart）、故事板（看板）、每日立会等内容，描述在计划会之后，评审会之前，敏捷开发团队内部产出与产品经理和项目经理的各种活动。日常跟进中的某些内容比如团队工作模型、预估会议、用户故事跟进等在之前的松结对编程、团队管理、用户故事、产品管理等系列中有所描述。在这个系列之前，还应该有一个敏捷计划系列，描述敏捷开发的从版本规划到计划会估算的详细内容，未来将会补上，当前可以参考2.29版的《火星人敏捷开发手册》，有5页与其相对应。燃尽图燃尽图Burdown Chart也叫燃烧图，是罕见的敏捷度量，以至于每当有人问起“ 阅读全文

posted @ 2012-02-29 09:04 阳光VIP1 阅读(643) 评论(0) 推荐(0)

【更新】火星人敏捷开发手册2012-02-24新增敏捷计划内容

摘要：2012-02-24：新版本发布，新增敏捷计划5页由于原定发布时日期2012-02-29在外地培训，提前发布；本期内容由原定的产品管理改为较为基础的敏捷计划，建议下载。预告：下一更新日期：2012-04-30。本文仅做通知，下载链接及反馈请访问主贴：http://blog.csdn.net/cheny_com/article/details/6616794页面截图：阅读全文

posted @ 2012-02-24 11:17 阳光VIP1 阅读(116) 评论(0) 推荐(0)

敏捷开发一千零一问系列之十：总体架构什么时机进行？（下）

摘要：这是敏捷开发一千零一问系列的第十篇。（之一，之二，之三，问题总目录）问题总体架构设计在什么时机进行？是每个迭代做还是先做完再迭代？方案之前提到了在时间的角度上，从技术和商业层面上的架构设计，下面看看横向的架构设计。方案1：开发人员全体参与架构设计敏捷开发整体上是一个崇尚“跨职能”的管理方法，开发和测试融合（所以才有很多类似自动化测试、单元测试、持续集成这些需要开发人员强参与的测试活动），开发与产品融合（开发人员要参与客户价值分析）等等，所以在架构设计与编码这两块，也不会分得很开，不能有人专门做架构，另外一些人专门编写代码。一方面，“架构设计”一旦变成一个文档，就要被写，被读，效率不说，中间难保阅读全文

posted @ 2012-01-30 18:09 阳光VIP1 阅读(121) 评论(0) 推荐(0)

敏捷开发一千零一问系列之九：总体架构什么时机进行？（上）

摘要：这是敏捷开发一千零一问系列的第九篇。（之一，之二，之三，问题总目录）问题总体架构设计在什么时机进行？是每个迭代做还是先做完再迭代？这是少数几个被提到的技术问题。在两天的培训课程之后，最后剩下的纯的技术问题一般只占1/5都不到，多数都是管理问题，而管理问题中，又基本上是人的管理问题，这也说明了在“心法人事物”中，心总是第一位的。方案最早想写成方案1、方案2，但感觉有点像说是有不同的很多并行方法，之后又改成步骤1、步骤2，又有点把事线性化了。现在干脆写回成方案123吧，总之越往后的越终极一些，也越难以一步到位。方案1：Sprint0对于长期的项目，常常引入“Sprint0”的概念。Sprint0就阅读全文

posted @ 2012-01-20 10:48 阳光VIP1 阅读(121) 评论(0) 推荐(0)

敏捷开发一千零一问系列之八：团队习惯了分工怎么办？

摘要：这是敏捷开发一千零一问系列的第八篇。（之一，之二，之三，问题总目录）问题在Team中，TeamLeader给人指定任务时，基本没有选择怎么办？（因为大家对别人的工作都不熟悉）方案步骤1：如果团队已经习惯了沉闷地自己开发自己的工作，办公室里边总是静悄悄的，那么一个可行的起点，是Leader可以先与大家进行松结对，就是不断地指导有难题的人。实际上当大家听到有人在交流的时候，就会侧耳听听，如果听到自己感兴趣的话题，也会积极参加。步骤2：下一步，可以主动喊某些人一起交流，比如“老张，过来帮忙看看小李这个问题”，这样交流的范围就逐渐扩大到3个人，而且老张-小李之间也建立了联系。一个宽敞点的办公环境还是很阅读全文

posted @ 2012-01-19 11:58 阳光VIP1 阅读(155) 评论(0) 推荐(0)

敏捷开发一千零一问系列之七：怎样对待有看法的徒弟？

摘要：这是敏捷开发一千零一问系列的第七篇。（之一，之二，之三，问题总目录）问题松结对编程中，师傅对徒弟安排任务时，对于有想法的徒弟提出的意见怎样解决？方案步骤0：正心，诚意。人们到底是在管理一个人（控制，监督，指令）还是领导一个人（帮助，引导，培养），被管理者和被领导者其实心里是一清二楚的。因此在师徒关系中，不能为了师徒而师徒，而是要找到师+徒这个体系的目的，把心态放在把事情做好而非维护师徒结构上，从这个角度看问题才能做好下面的事情。步骤1：师傅日常要多在收尾的时候检查徒弟的代码，指出其中的问题，以让徒弟正确认识自己的水平。软件开发有一个好处是比较理性：好的就是好的，没有什么可争辩的；但也有一个坏. 阅读全文

posted @ 2012-01-17 10:18 阳光VIP1 阅读(115) 评论(0) 推荐(0)

敏捷开发一千零一问系列之六：业务人员怎样参与开发？

摘要：这是敏捷开发一千零一问系列的第四篇。（之一，之二，之三，问题总目录）有一次课程上居然来了一个非开发人员，他是个网站的业务人员，提出了这个问题，并被评为课堂最佳问题之一。问题一线业务部门应该怎样具体参与到敏捷开发中来？答案方案1：敏捷开发中有很多活动是需要业务部门参与的，如果没有时间，第一个要参与的事情是“评审会”，就是阶段性验收产品的会议。在会上应该思考产品在实际应用中是否可用，并提出改进意见。但是要注意改进意见不要急于实现，而是应该询问下一步原来的计划，或许原来的计划更加重要。如果能在评审会上对产品未来的应用做出一点预测，对之后的迭代会有帮助。方案2：如果能选出一个代表，参与到计划会中，对于阅读全文

posted @ 2012-01-12 12:04 阳光VIP1 阅读(145) 评论(0) 推荐(0)

敏捷开发一千零一问系列之五：怎样让队员主动要活？

摘要：这是敏捷开发一千零一问系列的第五篇。（之一，之二，之三，问题总目录）本问题被评为某次课程最佳问题之一（每场2～4个）。问题怎样让团队成员完成从派活到主动要活？方案步骤0：在一个传统团队中，多半是由一个人（一般是项目经理）估算、分配、监督任务完成。由于这个人处于鸡的角色（请参考百度“猪与鸡”），所以真正承担任务的人要冒任务被错误估算和分配导致绩效低下的风险，引起大家的不满。按时完成了经理领导有方，延期了则总能找到一个临时工来顶缸，事情永远做不好。步骤1：“领导”和“管理”的区别在于后者利用权力行事，而前者亲自带领队员。比如如果项目经理仍然估算和分配任务，但是会主动帮助认为估算不对、任务过难的人。阅读全文

posted @ 2012-01-11 11:42 阳光VIP1 阅读(122) 评论(0) 推荐(0)

敏捷开发一千零一问系列之四：优先级排错怎么办？

摘要：这是敏捷开发一千零一问系列的第四篇。（之一，之二，之三，问题总目录）这个系列的文章太多，除了用于总结性篇章外，请访问“问题总目录”查找感兴趣的具体问题。初始问题对于不断更新的需求，导致需求优先级的判断出现了错误，知道项目周期后期才发现，怎么办？答案1. （临时方案）确保所有排序均是由PO完成的常常出现所谓现场客户、由客户出PO、由一个销售当PO的情况，都是应该避免的。PO一方面要熟悉具体的需求和原始目的（广度与细度的要求），另一方面则应该对产品的商业目标、终极目的了然于胸（高度与深度），才能站在企业立场而非简单的客户价值立场。从这一方面看，“有无限时间陪着我们的现场客户”和“一个销售”，其细度阅读全文

posted @ 2012-01-10 11:26 阳光VIP1 阅读(153) 评论(0) 推荐(0)

随笔分类 - 敏捷开发