1.软件开发流程：
在保证功能完成之后，首要的一件事就是，确保软件不会给客户带来破坏。因此除了敏捷开发以外，我们主要做了三件事情来让码农不要在开发的时候太分心搞别的。
第一件事就是你做了一个关键的设计之后，会有一个负责security review的小组来看你的文档，问你问题，根据他们的专业经验指出软件哪里可能是会被攻击的薄弱环节。举个例子，你用了XML做配置文件，如果用户偷偷给你换了一个破坏过的XML，你的程序就会挂。一旦程序进入挂了的状态的时候，是很危险的。如果你试图恢复它然后继续运行，你就得考虑大量的细节，来把你的软件从错误的状态恢复到正确的状态。中间稍有不慎就容易被攻击。所以我们都鼓励说，一旦发生了这些不可逆转的破坏，就让程序自己出dump然后自杀。当然具体到XML这个例子，我们还有xsd文件，用Windows自带的MSXML组件来实现验证一下，所以还算是个小事。JSON就没这个福利了。
第二件事情就是，我们的环境搭得特别科学。譬如说你开发SQLServer2014，那你还要给SQLServer2008打补丁。2008打补丁的时候用的SDK和开发环境可能跟2014有巨大的区别。所以我们有一个Build Team，写了几万行的perl和bat脚本，来使得我们可以做到说，我们只要从2014的branch切换到2008的branch，这些工具就自动变了，譬如说cl.exe就从新的版本指向了旧的版本，库啊什么其他的乱七八糟的也是。如果你刚好用不上Visual Studio的话，只要你把代码从Source Control上搞下来，运行他帮你建立在桌面上的一个快捷方式，就可以打开一个cmd，里面的环境都配置好了，而且不会污染别的cmd。那我们就再也不怕手忙脚乱用错工具来开发导致出现更多问题了。一个人有可能要同时在不同的版本上干不同的事情，因此这是很重要的。因此我们也会把大量的二进制文件checkin进去，因此很多组尝试使用git最后都失败了（啊哈哈哈
Visual Studio组跟SQLServer做法也差不多。但是因为VS要用上一个版本来开发下一个版本（譬如说2010就是用2008写出来的），因此Source Control里面的脚本还要负责编译一个干净的、临时使用的、不在注册表里面捣乱的、热拔插的Visual Studio。你们想，如果我给2010写的代码出了翔，把2008的注册表阉割了，还是把几个文件删了，我再也打开不了2008来改2010，这种事情能被允许发生吗？不能！但是程序总是会出bug的怎么办？所以我们要有特殊的手段来解决这些问题，就是随时编译、checkin一个绿色的、但是功能丝毫不少的Visual Studio。当然这个东西只有Visual Studio组的人才有，而且长得跟正常的VS还是有显著的区别的。不过这样Source Control里面的东西就更大了，但是微软有的是硬盘，而且Perforce和TFS天生就对二进制文件支持的好，没关系，跟git什么的不一样。
第三件事情就是制度的问题了。产品狗在我们这里，责任很大，权力很小。原则上产品狗是管不了我们的，我们之所以听产品狗的话，是因为我们跟产品狗都有相同的目标——把软件做好。所以每当产品狗做了一些奇怪的决定的时候，我们可以很容易的拒绝他。他为了完成他们自己的工作指标，要么就要来说服我们，要么就只能改自己的决定了。因为产品狗和码农之间没有达成一致从而导致软件没按时完成的，产品狗具有很大的责任。我们还有专业的测试团队。测试团队的权力不小。譬如说产品狗提了一个需求，测试可以跳出来说这个功能会给测试带来无比的困难，从而拒绝产品狗的决定。因此产品狗的每一个决定，首先要保证可以被科学的实现出来。当然产品狗自己通常可能不知道什么是科学，所以我们要通过不断的打他的脸来让他明白，什么是科学。
2.最喜欢的团队类型：
特工团队：软件团队由一些有特殊技能的专业人士组成，负责解决一些棘手而有紧迫性的问题。
社区模式：由很多志愿者参与，每个人参与自己感兴趣的项目，贡献力量，大部分人不拿报酬。
3.在这门课程中最应该采取哪种类型
我认为应该采取社区模式
优点：能够每个人参与进来，并且如果有的成员有做不到，其他成员可以互帮互助。
缺点：如果每个人都有一个不会的地方那么难题就无法解决，效率就会低下。
原文地址：https://www.cnblogs.com/wisdomzero/p/11631223.html
