下面是7月18日周四下午的免费敏捷沙龙活动介绍，我会出席并做敏捷开发早期估算的演讲。演讲内容可参考：http://www.scrumgathering.cn/topic/agile-estimating-and-planning如果CSDN能有一个开放会议室就好了，解决了场地问题，每周都可以组织一次！2013年度敏捷大讲堂主题沙龙活动敏捷与项目管理沙龙主办：北京软件行业协会中国敏捷开发联盟  合作

面对一张白纸的时候，如何才能迅速理清头绪写出一个结构相对完整、颗粒度适中的功能清单，而且程序员就知道了要写哪些类和函数？下面是简单的八步走法。

这是敏捷开发绩效管理的第八篇。（栏目总目录）每次敏捷开发培训课上，最备受关注的问题可以说是团队管理和绩效管理。“敏捷开发注重团队合作”“敏捷开发不考核个人”“敏捷开发放权”“敏捷开发对人的主动性要求高”……这些新话题可以说对一般程序员而言是非常陌生的，因为一般的程序员，基本上是距离客户最远的人。前面有市场、销售、售前，后面有测试、技术支持，因此最有理由远离“尘世纷扰”，只需遵循指令照章办事。一旦程

本文是敏捷开发产品管理系列的第八篇。（专栏目录）在产品开发中，常常遇到产品性能问题，这些性能问题会很大程度上影响到产品的架构。但解决这些性能问题，切莫认为只是技术人员的事情，产品经理和产品总监也要参与其中，甚至是业务人员（销售、售前）。下面以12306的售票问题为例，来做一个完整的说明。本文的目的，不是说技术性优化不必要，而是说作为开发人员不要闷头只想技术，而作为产品经理不要把所有“技术”问题推给

本文是敏捷外包工程系列的第二篇。（之一，之二，之三，之四）敏捷开发整体上适合小团队、产品研发（所以才有product owner一称）的环境，而外包软件开发中常常存在的则相反，因此在创建团队的时候要充分认识到这一点。Product Owner产品负责人的人选听到无数次有人说“我们的Product Owner就是客户，因为所有需求都是客户提的”，其实这样做极度危险。Scrum开发理念提出前的环境大致

这是敏捷开发绩效管理的第七篇。（之一，之二，之三，之四，之五，之六，之七） 续前文…… 功能点估算第一级简化上次说到只用数据+操作就能准确计算规模，听起来够简单了，但其实还不够。谁能在刚拿出2页纸的需求文档时（假设昨天老板在酒桌上刚从客户那记下来的），就猜出有多少个操作？而且还不遗漏？增删改查好猜，“加入角色”就不好猜了。NESMA早就遇到过这个问题了，他们这么解决：通过统计发现每个数据差不多有7

这是敏捷开发绩效管理的第二篇。（之一，之二，之三，之四，之五，之六，之七）团队管理是个由来已久的话题，各式各样的管理理论和方法层出不穷。笔者因为工作原因在过去16年里与100多家企业的团队或团队领导者有较为深入的交流，看到了听到了想到了很多相关的内容，下面做一个总结。不过受个人经历所限，这不是一个客观的全面的总结，而是带有本人的角度和主张，仅供参考。 中医治病的原理中医和西医看待疾病的角度差别很大

作者：陈勇出处：blog.csdn.net/cheny_com     有没有遇到某个重要的条目每次都被漏下完不成的情况？    有没有遇到冲刺结束的时候发现一大堆条目都已经开工了但都没有完成的情况？    有没有遇到Product Owner想用一个重要的变更来替代原来Spri

作者：陈勇       出处：blog.csdn.net/cheny_com       自相似性是指一个事物的局部与其更大的局部乃至整体具有相似性。从大的方面看，敏捷开发具有重视客户价值，提倡持续交付等思想。但一般而言，Product Owner常常具备相当好的客户价值意识，而

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