春天的气息-spring3.1例子

摘要： 本文长期更新，请常来看看。• 序言– 从代码行到故事点敏捷估算：故事点与直接估算天数的差异– 下一步？• 敏捷团队绩效管理– 谁来管理团队中的个体？同行压力（兼谈敏捷团队，绩效管理，自组织团队）目标管理（百度百科）– 敏捷团队的目标– 从团队外部认识团队目标 敏捷团队绩效管理与目标管理：关于如何为团队设立外部目标– 敏捷开发中的目标管理意识 – 执行与实施层面的敏捷实践 敏捷生态系统：2009敏捷中国大会上的演讲稿139团队（大型研发团队，大型敏捷开发团队，大型团队结构，敏捷绩效管理）绩效管理：软件开发团队的非物质激励机制• 敏捷产品版本管理– 当我们成为“产品的主人”“迭代期间内变更”与敏捷 阅读全文

摘要： 作者：陈勇出处：blog.csdn.net/cheny_com迭代期间无变更？支持派说：对，如果经常变，我们怎么开发啊。反对派说：不对，敏捷开发不能上来就确认了需求，要的就是在开发中逐步了解需求，怎么可能不变呢。只在开发层面，这个问题无解。让我们站在研发心理学的高度来看这个问题。先看看如果变更了，团队会有哪些不利的心理变化。1. 咱们不要在开始承诺能完成，一旦变化承诺就落空了2. 既然总是在变，每次我们都预留点估算余地吧3. 别着急，你忙也完不成的，到最后一天还给你变4. ……再看看Product Owner，这个变更发起人居然也发生了变化：1. 反正日后可以变，这次计划会我就不出席了，让他们 阅读全文

摘要： 作者：陈勇出处：blog.csdn.net/cheny_com迭代期间无变更？支持派说：对，如果经常变，我们怎么开发啊。反对派说：不对，敏捷开发不能上来就确认了需求，要的就是在开发中逐步了解需求，怎么可能不变呢。只在开发层面，这个问题无解。让我们站在产品版本规划的高度来看这个问题。下个产品版本（或下个迭代）中到底应该有什么功能？最重要的功能？最基础的功能？当前可能实现的功能？已经弄清楚的功能？这些角度都是基于技术活动而非市场目标来制定的，都有其局限性。其实，每个产品的版本都是企业的一步棋：在某个时间，推出某些功能，满足某些需求，获取某些客户，打败某些对手，取代某些产品。若认同了这一点，则早在产 阅读全文

摘要： 作者：陈勇出处：blog.csdn.net/cheny_comIT人士要想被激励起来，除了可以用薪酬之外，其实还有很多办法。比如笔者刚刚毕业的时候，曾经彻夜编制一个软件长达5个月，原因是自己居然有一台专属的486电脑；而数年后我一个同事会在中午一边吃饭一边编程，是因为他独自负责一个至关重要的模块……很多人身边都因为各种不同的原因发现神奇的被激励的人，这些激励机制有哪些可遵循的规律呢？我02年左右曾经读过一本麦克康奈尔（当时人称美国几大GURU之一，《完美编程Code Complete》也是其作品）的《快速软件开发》，里边曾有一章节提及软件团队的激励问题，其大致将人分为两种：团队领导和团队队员， 阅读全文

摘要： 作者：陈勇出处：blog.csdn.net/cheny_com很多人都知道甚至感觉到敏捷开发的生产率比传统开发高，但到底敏捷开发是怎样提升生产率的呢？以及当前自己正在实施的敏捷开发还有多大的生产率潜力？当然“受激励的个体”会产生生产率，但只是这样解释恐怕难以服众，更难说服老板。让我们换一个角度吧。下面几个问题揭示了一些隐性的生产率潜力：10万/100万/1000万代码行的项目有20%/48%/65%被取消（Jones, 1998）成功交付的产品中，约2/3延期交付（The Standish Group, 1992~2004）所有软件平均60%左右的功能从未或很少被使用（个人是PPT和Excel 阅读全文

摘要： 作者：陈勇出处：blog.csdn.net/cheny_com在敏捷中直接估算天数最大的好处是直观，坏处是很难衡量是否有故意的高估和低估，也不能比较生产力是否在提升，于是基于故事点的估算应运而生。基本使用方式故事点的基本做法是：把一些常见的“标准任务”给出一个“标准点数”，形成比较基线，估算的时候只要是同一类型的任务，直接写上故事点数而非天数。比如：1. 对单个表进行增删改查2. 为一个已经存在的数据表增加一个复杂报表3. 修改一个中等难度的BUG……在刚开始的时候，“点数”可以就是以往完成任务的平均天数。比如曾经有4次对单个表进行增删改查，查看历史记录发现天数大约是15天，则可以定为15点。 阅读全文

摘要： 在敏捷测试中也有测试活动乃至专职的测试人员，但其活动内容和目标是有显著差异的。一般在传统开发团队中，产品经理（或销售）为范围或称之为需求负责，项目经理和开发组为进度负责，测试组为质量负责，部门经理为成本负责，结果就是当四者发生矛盾时，会有四个部门各自站在自己的立场上，从而导致沟通不畅或或博弈成分超过合作。在敏捷开发中需求与进度的冲突由计划会和自组织团队机制解决，成本由BDC和故事点开发率的提升来解决（解决的不好），而进度与质量间的矛盾，则由新型的测试理念来解决。在传统测试中，测试团队被认为是找BUG的人，比如如果BUG众多，则测试人员和开发人员会一起加班，后者修改BUG，前者验证是否修改好。而 阅读全文

摘要： 作者：陈勇出处：blog.csdn.net/cheny_com 定义简单看，139团队就是1个项目经理，3个小组长，9个开发人员，小组长管理各自管理3个左右开发人员。139团队从管理上缩减了团队规模，可以被视同只有1个项目经理和3个小组长，细节交由小组长处理。这样就方便在大型团队中进行敏捷开发了。角色在Scrum敏捷团队中，队员们是平等的，只有Scrum Master是个个例。但由于在国内很难找到Scrum Master（一则知识缺少，二则一般PM不愿意放弃管理权和技术而转而做“协调”工作），且团队往往超过7～9人，139团队会是一个替代方案。项目经理主要工作与原来的项目经理无异，如果在做敏捷 阅读全文

摘要： （原文载于教堂墓地的一块墓碑上，但主人不详）When I was young and free and my imagination had no limits, I dreamed of changing the world. As i grew older and wiser, I discovered the world would not change,so I shortened my sights somewhat and decided to change only my country.But it, too, seemed immovable.As I grew into m 阅读全文

摘要： 如果你以前编写的HtmlHelper喜欢返回string而非MvcHtmlString，那么在使用Razor后要改改了。假设原来有一个Helper调用： <%= Html.ProgressBar(tree, progress) %>而函数声明是： public static string ProgressBar(this HtmlHelper htmlHelper, SFCProgressTree progressTree, SFCProgress progress, bool show = false){...return ImgTag.ToString()}则在新的Razor中 阅读全文