有消息称ScottGu从原来的VS组（尤其是新兴的MVC、Razor）调任到云计算部门（Azure），这件事情也在一定程度上表明了MS的战略：借助开发工具（VS）与运营工具（各种版本的Windows/SQL）的联合优势，在未来云计算中占有一席之地。VS2010 SP1对SQL CE的支持正是其中一种表现。

这是火星人预览系列的第一篇（之一，之二，之三，之四，之五问答，之六，之七）。之一：需求与故事结构之二：编辑故事，产品管理，组织结构之三：迭代，计划会，分配任务之四：故事板，燃尽图，我的工作项之五：常见问题问答之六：我的空间，我的通知之七：自定义字段   本人除了做培训、写博客、编手册之外，两年来用半业余半全职的时间一点一点开发了一个敏捷开发管理工具，最近接近发布内测版本，发一些预览资料，欢迎大家关

本文是“松结对编程”系列的第二篇。（之一，之二，之三，之四，之五，之六，之七，之八，此系列之九及之后文章请见栏目总目录。）新人其实很少偷懒，因为一方面正处于入门学习的高峰期，另一方面工作时间不长需要得到企业和团队的认可。可为何他们工作总是不得力呢？新人的真正问题在于无心办错事和好心办错事。无心办错事包括没学过某种好的方法、不知道企业已经有某些可用代码或库、不懂业务等种种问题。好心办错事包括想做一个

这是敏捷开发团队管理系列的第八篇（团队管理栏目目录）。还是敏捷开发一千零一问的第二十八篇（在这里提问，之一，之二，之三，问题总目录）。还是敏捷开发松结对编程系列的第十三篇（松结对编程栏目目录），与之前系列第六篇139团队、第九篇微软TechED上的讲座有密切关系。问题大致问题：若人数在30人左右开发一个产品，里边的子系统数量比较多，每个子系统都有各自的发布计划，而又要协调。如果作为一个团队管理，人

这是敏捷开发一千零一问系列的第五篇。（在这里提问，之一，之二，之三，问题总目录）本问题被评为某次课程最佳问题之一（每场2～4个）。问题怎样让团队成员完成从派活到主动要活？方案步骤0：在一个传统团队中，多半是由一个人（一般是项目经理）估算、分配、监督任务完成。由于这个人处于鸡的角色（请参考百度“猪与鸡”），所以真正承担任务的人要冒任务被错误估算和分配导致绩效低下的风险，引起大家的不满。按时完成了经理

本文是敏捷开发产品管理系列的第七篇。（序言及设立迭代目标，产品版本规划，产品用户群规划，新产品研发，预估会议，Product Servant，Product Owner团队，产品线管理），也是敏捷开发团队管理系列（拟）中的一篇。目的在之前的《Product Servant》一篇中曾经提到，作为产品经理或产品总监，都应该有自己的方式来根据市场和用户情况来管理产品的走向，其中前者更倾向于具体的功能，而

本文是“松结对编程”系列的第一篇。（之一，之二，之三，之四，之五，之六，之七，之八，此系列之九及之后文章请见栏目总目录。）传说中的结对编程，大致结构是两个人共用一台电脑，一个开发，一个测试，以随时评审来抵消返工时间损失。传说归传说，谁也没有见过。问题出在哪里？有两种主要原因。一是来自高层的，高层感觉两个人只有一个人干活，实在是有点浪费。“评审抵消返工时间”虚无缥缈，但每天只有一个人干活却是现实情况

本文是“松结对编程”系列的第三篇。（之一，之二，之三，之四，之五，之六，之七，之八，此系列之九及之后文章请见栏目总目录。）估算是经久不衰的管理话题，大致分为两种流派。第一种是领导指派，领导说这是10天的活，就必须当是10天的活来干，如果干不完，可以用加班、损失质量、功能缩水等各种方法曲线救场。另一个变种是大家自己估算，但是交给领导审批；领导审批其实就是砍一半的过程，还好大家之前就已经加了一倍，所以

这是敏捷开发日常跟进系列的第三篇。 （栏目目录）故事板和看板其实不是一个东西，前者是最初的敏捷开发里边的东西，受到了后者的启发产生的；而后者是制造业的东西，具体内容请参考末尾的百度百科。但是在敏捷开发里边提到这两样东西，可以认为大致相同。故事板简单说，故事板是展示迭代中的用户故事和任务的方法，在《硝烟中的Scrum和XP》的封面上就印着一个典型的故事板：一般故事板分为三列：To Do还没做的, D

这是火星人预览系列的第四篇（之一，之二，之三，之四，之五问答，之六，之七）。之一：需求与故事结构之二：编辑故事，产品管理，组织结构之三：迭代，计划会，分配任务之四：故事板，燃尽图，我的工作项之五：常见问题问答之六：我的空间，我的通知之七：自定义字段  日常跟进截图故事板：燃尽图（具备钻取功能）：跟进表：个人中心截图个人中心是3月迭代的重点，所以未来会多很多功能。我的通知：我的工作项（新建和当前负责