SCRUM开发沙龙 - .NET开发环境下的敏捷实施技巧
演讲嘉宾及主题
嘉宾简介：邹欣
现任微软亚洲研究院首席研发主管 (Principal Development Manager)。 他和同事们一起把研究成果转化到商业软件产品和服务。 最近的两个项目是 微软学术搜索和 旅游指南。他从1996年起在微软Outlook 产品团队从事开发工作, 主要注重于产品国际化，邮件内部协议，和提高应用程序的效能。 从2003 年到2005 年, 他在微软Visual Studio Team System产品团队工作，负责软件质量管理工具的开发。 2005年至今, 他在微软亚洲研究院技术创新组工作。
演讲内容：通过两个实际的项目, 分享如何在实际项目中建立敏捷团队, 树立敏捷的流程。敏捷不是万灵药, 在软件创新的过程中, 我们遇到了很多挑战,，我会分享这其中的一些实例，例如通过不同工作件的结合，解决多人合作完成同一个场景的管理问题；通过对典型用户的分析，提出有创新性的新功能，引导团队为共同的目标而努力；通过及时的工作件跟踪和管理，及时暴露问题，确保团队按时完成任务等。
嘉宾简介：徐磊
现任SSW中国研发中心首席代表，资深软件架构师，他也是微软最有价值专家MVP（2007-2010）和微软的区域总监。此外他还在TechEd 2008/2009大会上担任讲师，并且是经过认证的ScrumMaster（CSM）。更多介绍参见徐磊在 澳洲视窗官方网站的介绍。
演讲主题：SCRUM模式项目管理在Visual Studio 2010上的最佳实践
主要内容：这次分享的主要内容就是向广大开发人员介绍微软Visual Studio 2010系统和官方Scrum流程模板，以及如何结束vs2010种的各种功能来开发出更高质量的产品并建设更加高效的软件开发团队，具体内容包括：
Scrum 模式基本概念和实施经验
了解如何使用Scrum流程模板
Scrum 团队建设，进度审核和分析，Scrum团队面临的挑战
Scrum Master遇到的典型问题分析，如何使用Scrum让您企业更为有效
Product Owner面临的挑战和典型问题分析，如何与Product Owner协作，如何与Stakeholder协作
嘉宾简介：邹欣
现任微软亚洲研究院首席研发主管 (Principal Development Manager)。 他和同事们一起把研究成果转化到商业软件产品和服务。 最近的两个项目是 微软学术搜索和 旅游指南。他从1996年起在微软Outlook 产品团队从事开发工作, 主要注重于产品国际化，邮件内部协议，和提高应用程序的效能。 从2003 年到2005 年, 他在微软Visual Studio Team System产品团队工作，负责软件质量管理工具的开发。 2005年至今, 他在微软亚洲研究院技术创新组工作。
邹欣于2007年出版了《移山之道 - VSTS软件开发指南》, 2008 年出版《编程之美 - 微软技术面试心得》
演讲内容：通过两个实际的项目, 分享如何在实际项目中建立敏捷团队, 树立敏捷的流程。敏捷不是万灵药, 在软件创新的过程中, 我们遇到了很多挑战,，我会分享这其中的一些实例，例如通过不同工作件的结合，解决多人合作完成同一个场景的管理问题；通过对典型用户的分析，提出有创新性的新功能，引导团队为共同的目标而努力；通过及时的工作件跟踪和管理，及时暴露问题，确保团队按时完成任务等。
嘉宾简介：徐磊
现任SSW中国研发中心首席代表，资深软件架构师，他也是微软最有价值专家MVP（2007-2010）和微软的区域总监。此外他还在TechEd 2008/2009大会上担任讲师，并且是经过认证的ScrumMaster（CSM）。更多介绍参见徐磊在 澳洲视窗官方网站的介绍。
演讲主题：SCRUM模式项目管理在Visual Studio 2010上的最佳实践
主要内容：这次分享的主要内容就是向广大开发人员介绍微软Visual Studio 2010系统和官方Scrum流程模板，以及如何结束vs2010种的各种功能来开发出更高质量的产品并建设更加高效的软件开发团队，具体内容包括：
Scrum 模式基本概念和实施经验
了解如何使用Scrum流程模板
Scrum 团队建设，进度审核和分析，Scrum团队面临的挑战
Scrum Master遇到的典型问题分析，如何使用Scrum让您企业更为有效
Product Owner面临的挑战和典型问题分析，如何与Product Owner协作，如何与Stakeholder协作
如何扩展Scrum，使用Scrum管理大型开发团队
参会感悟
Scram VS VS2010
传统瀑布模式：流程可控 质量不可控
scram角色划分：product owner,scrum master, Team 综合能力
探索：在没完成以前永远不知道什么时候完成。
迭代周期：２周 每天８小时，高效为６个小时
质量要求：９０%测试覆盖率
自动化，模拟人测试
以业务为导向实现需要纵向开发
可以完成多少由ＰＬ开发决定时间
正向需求：客户需求
反向需求：客户如何测试 客户反馈
举例：发者在处理项目或产品发布时，如何能够避免程序Bug暴露的问题。“try{}catch{弹出异常、干脆不写或避免异常弹出}finally{}”像这样的语句是不行的。如何搜集已上马的Bug信息，又可以避免用户看到程序异常呢？“try{}catch{将异常信息通过服务接口发送至Bug管理系统}finally{}”这样的处理方式，可以避免上述尴尬的情况。如果项目或产品着急上马，那么测试员可以不用过多的测试，可以让典型的用户在实际的场景中测试，那么一旦异常爆发也不会暴露在用户面前，还可以将Bug信息悄悄的发送至Bug管理系统，由程序员根据异常不断改进程序，进而推出新的修正版本发布。虽然这种方法有点嫌疑，但毕竟是很好的管理方式。
如果没有在需求阶段投资，就要有人在维护中花钱。
在工作中推行新的工作方法注意二点
一是工具会带来文化的冲击 二是要循序渐进的推进，从上向下，注意赢得第一批鼓掌的人
要注意所有东西都一样好，都是为了公司利益。
估算时间 Ｍ/ n-1