陈勇的博客 - Scrum 敏捷开发培训咨询，绩效管理，团队管理，《火星人敏捷开发手册》

敏捷开发培训咨询敏捷开发免费工具免费培训教材《火星人敏捷开发手册》 IIOM咨询总监火星人首席架构师兼主程序员

12月 11月 10月 09月 08月 07月 06月 05月 04月 03月 02月 01月

原创敏捷开发“松结对编程”系列之十五：L型代码结构（编程篇之一）

本文是“松结对编程”系列的第十五篇。（松结对编程栏目目录）之前的L型代码结构的前三篇提到过，L型代码结构的微观计划和估算过程会与一般的编程方法不同，今天正好要编写一些新代码，边写边记录整个过程。如果中间卡壳了，我也会尽量记录下来。业务需求这是《火星人》中的一个功能，以往用户故事是使用故事树来展示的（就是有父子关系的用户故事），故事树隶属于一个产品Product。但是最近要发版了，感觉一个以前认为暂

2013-01-27 16:09:10 9548 1

原创 asp.net mvc3：自己编写的一些垃圾代码，删前分享（2013-01-18）

不小心发现自己编写的一些垃圾代码，删前留念。可以作为面试题使用。有时候一个程序员会或者不会什么具体的技术差别不大，因为看看书几分钟就能学会；但编写垃圾代码一旦养成习惯，不是一天两天能改好的。1. 这段代码等同于？ return vc.RequestContext.HttpContext.Request.Params["view"] != null

2013-01-18 09:57:46 4212 3

原创简单干净的C#方法设计案例：MFCUI.CheckBoxLink(三)

接上篇。第七步：需求变更外加挪地方新函数叫这个名字：位于class MFCUI之下。[csharp] view plaincopypublic static MvcHtmlString CheckBoxLink(WebViewPage page, string title, string parameter, string value) { var span = new TagBuil

2013-01-06 12:59:49 4261

原创简单干净的C#方法设计案例：MFCUI.CheckBoxLink(二)

方案2第一步：写一个新的函数名在原来的代码下面第二步：把原来的代码拷贝到下面两步下来，如图： @this.MergeParameter( @MFCUI.ImageLink("突出显示故事板上的状态", this.MergeParameter("highlight", "OnBoard"), displayAxTextUseCheckIcon: true, displayAsText:

2013-01-06 12:59:12 4448

原创简单干净的C#方法设计案例：MFCUI.CheckBoxLink(一)

说明：本人不是.net/Html/Ajax/Jquery....高手，所以经常用C#做一些这些技术能做的事情！本文仅用来说明如何简化设计之用。如果出现具体技术问题，请大家按自己的实际情况理解。问题假设想在屏幕上做这样一个功能（而且有很多这样的需要）：在当前页面http://localhost:53979/Agile/StoryBoard/TeamStoryBoard?teamID=103中有一个链

2013-01-06 12:58:35 11644 13

功能点需求模板

注意如果使用工具，Jira和TFS都有三层需求结构，分别对应Word目录中的：一级目录：项目名称二级目录：Jira-Theme，TFS-Epic 三级目录：Jira-Epic，TFS-Feature 四级目录：Jira-Story，TFS-Story。注意Jira和TFS都不约而同地采用了三级目录，但是都没有提到如何划分和获取三级目录，以及三级目录的实际物理含义（比如在软件中到底是个页面，还是个表，还是个Controller……）。而本方法可以让需求直接与软件对应起来。

2015-11-26

产品研发敏捷统一过程 AUP2.0

产品研发敏捷统一过程 AUP2.0的课件，另附有一个Word模板用来演示以这种方式形成的需求文档结构，可作为Scrum中的Product Backlog。请参考：http://blog.csdn.net/cheny_com/article/details/50020243

2015-11-26

火星人敏捷开发早期估算

“响应变化胜过遵循计划”，所以敏捷开发中的估算过程主要指在每个迭代计划会中，由开发人员自主估算本次迭代的工作内容。可是，随着一个个迭代结束，开发人员可能才逐渐感觉到整个项目需要一年，而实际上，高层领导早就签订合同或立项要求整个项目在半年内完成……而这个项目如果真的超期了一倍，那么到底是高层领导的决策失误，还是团队的生产率只有别人的一半？这就让我们不禁想问：有没有一种方法，在签署合同或立项前，仅仅凭借几页Word和有限交互，就能把十几人年的项目推算到±20%的精度内？有没有一种方法，不仅能在早期做估算，还能把估算结果直接演进为敏捷开发中的史诗故事和用户故事？有没有一种方法，不仅能让开发者意识到代码的不断增长，也能让客户和领导同步地理解并认可需求的蔓延？有没有一种方法，能在项目结束时，简单数数史诗故事和用户故事，就能将项目的完成情况与此团队的历史做纵向比较，甚至还能与其他团队、乃至业界的数据做横向比较，并让客户和老板信服？

2013-07-14