刚和外包公司谈好需求，还未开始开发。
目前正在选平台，dotnetnuke还是sharepoint? 如果没有平台，是无法整合的，如果选择dotnetnuke,我可以让外包公司开发模块，外包公司按照dnn的规范开发就可以了，可以安装到dnn上就好了。
并且还要加入work flow，不知道现在如何选择.
请各位指点
13 个解决方案
#1
通过VSS或SVN进行版本控制，
#2
我们是开发不在一起的，不是一个Team.
我在本公司开发项目(开发机不可以联外网的)，外包公司在他们的公司开发(外包公司不可以来我公司开发）。
所以不用VSS,或者SVN.
不知道wuyq11，用过dnn没有？可以让外包公司开发module,打包给我，我用dnn的安装包功能，直接装到DNN上就可以了。
谢谢：）
我在本公司开发项目(开发机不可以联外网的)，外包公司在他们的公司开发(外包公司不可以来我公司开发）。
所以不用VSS,或者SVN.
不知道wuyq11，用过dnn没有？可以让外包公司开发module,打包给我，我用dnn的安装包功能，直接装到DNN上就可以了。
谢谢：）
#3
我们退一步说可能更可以海阔天空。你可以每三天进行一次代码集成和内部的发布，如果外包的软件无法集成到你的项目中并且编译，那么根本不要再去开发后边的东西了，解决手头的集成发布问题就够了。只要能够满足这个基本的管理要求，什么办法和手段都尽管使出来，你和外包公司共同来想办法吧。你只要守住这个原则，外包公司每三天就要把最新完成的代码部分给你进行集成，绝对不能一段时间（从你的角度看）无所事事而之后另一段时间又忙的要死，必须保持这个敏捷开发的“节奏”，你只要坚持住着一个要求，其它的都可以商量解决。
看似困难，其实很简单。当然，也许会将“三天”推迟为“两周”，但是这时候就要高度警惕如临大敌了。
不必动不动就把问题归咎于使用的软件或者所写的文档，那些都不能代替实战经验。
看似困难，其实很简单。当然，也许会将“三天”推迟为“两周”，但是这时候就要高度警惕如临大敌了。
不必动不动就把问题归咎于使用的软件或者所写的文档，那些都不能代替实战经验。
#4
利用只是最少原则
根据需求，写出需要客户实现的接口
这样就可以分开开发了
之后只要根据接口调用实现，你们可以完全不去管外包项目
是如何实现的，只管最后实现了没有
根据需求，写出需要客户实现的接口
这样就可以分开开发了
之后只要根据接口调用实现，你们可以完全不去管外包项目
是如何实现的，只管最后实现了没有
#5
能够保持一种内部“发布节奏”是需要及其高超的系统设计技巧的。常见的情况是，pm可能空谈该使用什么样的管理软件、写出多么格式上看很完善的文档、前期分析多么神奇地覆盖了需求使得后期很少改变系统设计，然而他实际上很可能是在用漂亮的口号来拖延时间。我们先不管这个，只是说一下，如果你看到有些人：前期用大部分时间在那里清谈文档准备功夫，然后后期忙的要死地去加班编写代码，最后甚至整个系统没有测试几遍就匆匆上马漏洞百出，这时候就要引以为戒，考虑是不是缺乏敏捷开发的关键技术因而无法保证真正的敏捷（而只会添乱）。
#6
当你“让外包公司开发module,打包给我，我用dnn的安装包功能，直接装到DNN上就可以了”的时候，你要有一个外包公司跟你共同工作的“需求、设计、评估、测试、安装”平台，你要自己设计接口并且自己做测试。并且，上面我说了，想办法让你们的工作节奏保持比较敏捷（小步快跑），不要迈大步子。
#7
多谢各位！
especially sp1234!
我再补充一下：
所有外包的项目，需求都是我与外包公司谈的，所以需求我全都明白。并且我还要外包公司的源码，并读懂，如果代码不规范或者有BUG，会退给外包公司修改。
我用dnn的目的，就是相省事儿，外包公司开发项目只要符合DNN的规范（内部有定义好的接口）就可以了。我在我的平台上安装外包公司的项目（编译后的项目，只有aspx文件，没有.cs或者vb文件）就可以了，另外我保存一份该项目的源码就可以了。
especially sp1234!
我再补充一下：
所有外包的项目，需求都是我与外包公司谈的，所以需求我全都明白。并且我还要外包公司的源码，并读懂，如果代码不规范或者有BUG，会退给外包公司修改。
我用dnn的目的，就是相省事儿，外包公司开发项目只要符合DNN的规范（内部有定义好的接口）就可以了。我在我的平台上安装外包公司的项目（编译后的项目，只有aspx文件，没有.cs或者vb文件）就可以了，另外我保存一份该项目的源码就可以了。
#8
看看你们的文档怎么写的了。接口是否对应。既然可以分块外包。证明他们之间是松耦合的。那他们之间的接口怎么定义的，。
#9
用webservice
#10
我想所谓的需求以及接口设计需要足够的细节支持的。有时候，一个界面很复杂的界面，我会在需求定义中指出某个操作流程必须使用某一类控件（可以使用子类实例），以及这个控件必须具有的ID或者某个关键的属性，因为我需要自动化地编写一段代码来测试这段程序。当我休息的时候，我运行我的测试程序，回来时我有时看到我的几百个测试程序已经累计执行了上千次，没有发现bug，我才继续考虑当天以及未来2、3天新的工作。
其实管理的原则谁都知道，关键就是到该细节的时候许多人已经很明白的原则就变得不得不推倒重来了。知道该做什么和知道具体如何做是天壤之别的两个层次。
#11
我们要把我们的技术“插入”产品中，而不是高高在上。所以我经常说一个产品开发中，程序员未完成产品功能而写的代码其实只有此项目的代码含金量的一半，另一半就是我们为了方便管理、测试质量而自行开发的代码，这些东西往往对程序员是保密的，但是他们可以用到，例如一个适合你的项目的bug追踪软件可以让你就直接节省特别多时间。
#12
我们要把我们的技术“插入”产品中，而不是高高在上。所以我经常说一个产品开发中，程序员为了完成产品功能而写的代码其实只有此项目的代码含金量的一半，另一半就是我们为了方便管理、测试质量而自行开发的代码，这些源代码往往对程序员是保密的，但是他们可以用到，例如一个适合你的项目的bug追踪软件可以让你就直接节省特别多时间。
#13
例如从一个列表界面中选择一列中的某个LinkButton就在旁边出现此内容的明细内容，我会写程序随机地去模拟点击操作，并且之后在旁边的明细内容中查找一两个点来判断，然后再在明细内容中输入几个值，并且点击提交操作，再回来看看列表界面中是否刷新了新的值。这一切都是自动化的。
我这里是借鉴我的自动化测试要点来明确需求描述的细节。如果你做不到自动化，我也希望你不要用那种特别稀里糊涂无所谓的描述方式，应该描述关键、足够的细节。实在不行，学学在TD等软件上“如何写测试用例”的技术，借鉴他们的要点，也可以让你对需求描述细节起来。
例如我们看到有人说如何如何测试程序，结果你跟踪他一下，发现他仅仅对登录界面等少数界面的个别操作测试一下而并不集中在最经典和最复杂的交互界面，也就是所他的所谓测试的覆盖程度是低到根本就是空洞的程度。不但知道做什么而且精通如何做的人，反而可能不善于讲大道理，因为真正的道理其实都是那么简单、朴实。
#1
通过VSS或SVN进行版本控制，
#2
我们是开发不在一起的，不是一个Team.
我在本公司开发项目(开发机不可以联外网的)，外包公司在他们的公司开发(外包公司不可以来我公司开发）。
所以不用VSS,或者SVN.
不知道wuyq11，用过dnn没有？可以让外包公司开发module,打包给我，我用dnn的安装包功能，直接装到DNN上就可以了。
谢谢：）
我在本公司开发项目(开发机不可以联外网的)，外包公司在他们的公司开发(外包公司不可以来我公司开发）。
所以不用VSS,或者SVN.
不知道wuyq11，用过dnn没有？可以让外包公司开发module,打包给我，我用dnn的安装包功能，直接装到DNN上就可以了。
谢谢：）
#3
我们退一步说可能更可以海阔天空。你可以每三天进行一次代码集成和内部的发布，如果外包的软件无法集成到你的项目中并且编译，那么根本不要再去开发后边的东西了，解决手头的集成发布问题就够了。只要能够满足这个基本的管理要求，什么办法和手段都尽管使出来，你和外包公司共同来想办法吧。你只要守住这个原则，外包公司每三天就要把最新完成的代码部分给你进行集成，绝对不能一段时间（从你的角度看）无所事事而之后另一段时间又忙的要死，必须保持这个敏捷开发的“节奏”，你只要坚持住着一个要求，其它的都可以商量解决。
看似困难，其实很简单。当然，也许会将“三天”推迟为“两周”，但是这时候就要高度警惕如临大敌了。
不必动不动就把问题归咎于使用的软件或者所写的文档，那些都不能代替实战经验。
看似困难，其实很简单。当然，也许会将“三天”推迟为“两周”，但是这时候就要高度警惕如临大敌了。
不必动不动就把问题归咎于使用的软件或者所写的文档，那些都不能代替实战经验。
#4
利用只是最少原则
根据需求，写出需要客户实现的接口
这样就可以分开开发了
之后只要根据接口调用实现，你们可以完全不去管外包项目
是如何实现的，只管最后实现了没有
根据需求，写出需要客户实现的接口
这样就可以分开开发了
之后只要根据接口调用实现，你们可以完全不去管外包项目
是如何实现的，只管最后实现了没有
#5
能够保持一种内部“发布节奏”是需要及其高超的系统设计技巧的。常见的情况是，pm可能空谈该使用什么样的管理软件、写出多么格式上看很完善的文档、前期分析多么神奇地覆盖了需求使得后期很少改变系统设计，然而他实际上很可能是在用漂亮的口号来拖延时间。我们先不管这个，只是说一下，如果你看到有些人：前期用大部分时间在那里清谈文档准备功夫，然后后期忙的要死地去加班编写代码，最后甚至整个系统没有测试几遍就匆匆上马漏洞百出，这时候就要引以为戒，考虑是不是缺乏敏捷开发的关键技术因而无法保证真正的敏捷（而只会添乱）。
#6
当你“让外包公司开发module,打包给我，我用dnn的安装包功能，直接装到DNN上就可以了”的时候，你要有一个外包公司跟你共同工作的“需求、设计、评估、测试、安装”平台，你要自己设计接口并且自己做测试。并且，上面我说了，想办法让你们的工作节奏保持比较敏捷（小步快跑），不要迈大步子。
#7
多谢各位！
especially sp1234!
我再补充一下：
所有外包的项目，需求都是我与外包公司谈的，所以需求我全都明白。并且我还要外包公司的源码，并读懂，如果代码不规范或者有BUG，会退给外包公司修改。
我用dnn的目的，就是相省事儿，外包公司开发项目只要符合DNN的规范（内部有定义好的接口）就可以了。我在我的平台上安装外包公司的项目（编译后的项目，只有aspx文件，没有.cs或者vb文件）就可以了，另外我保存一份该项目的源码就可以了。
especially sp1234!
我再补充一下：
所有外包的项目，需求都是我与外包公司谈的，所以需求我全都明白。并且我还要外包公司的源码，并读懂，如果代码不规范或者有BUG，会退给外包公司修改。
我用dnn的目的，就是相省事儿，外包公司开发项目只要符合DNN的规范（内部有定义好的接口）就可以了。我在我的平台上安装外包公司的项目（编译后的项目，只有aspx文件，没有.cs或者vb文件）就可以了，另外我保存一份该项目的源码就可以了。
#8
看看你们的文档怎么写的了。接口是否对应。既然可以分块外包。证明他们之间是松耦合的。那他们之间的接口怎么定义的，。
#9
用webservice
#10
我想所谓的需求以及接口设计需要足够的细节支持的。有时候，一个界面很复杂的界面，我会在需求定义中指出某个操作流程必须使用某一类控件（可以使用子类实例），以及这个控件必须具有的ID或者某个关键的属性，因为我需要自动化地编写一段代码来测试这段程序。当我休息的时候，我运行我的测试程序，回来时我有时看到我的几百个测试程序已经累计执行了上千次，没有发现bug，我才继续考虑当天以及未来2、3天新的工作。
其实管理的原则谁都知道，关键就是到该细节的时候许多人已经很明白的原则就变得不得不推倒重来了。知道该做什么和知道具体如何做是天壤之别的两个层次。
#11
我们要把我们的技术“插入”产品中，而不是高高在上。所以我经常说一个产品开发中，程序员未完成产品功能而写的代码其实只有此项目的代码含金量的一半，另一半就是我们为了方便管理、测试质量而自行开发的代码，这些东西往往对程序员是保密的，但是他们可以用到，例如一个适合你的项目的bug追踪软件可以让你就直接节省特别多时间。
#12
我们要把我们的技术“插入”产品中，而不是高高在上。所以我经常说一个产品开发中，程序员为了完成产品功能而写的代码其实只有此项目的代码含金量的一半，另一半就是我们为了方便管理、测试质量而自行开发的代码，这些源代码往往对程序员是保密的，但是他们可以用到，例如一个适合你的项目的bug追踪软件可以让你就直接节省特别多时间。
#13
例如从一个列表界面中选择一列中的某个LinkButton就在旁边出现此内容的明细内容，我会写程序随机地去模拟点击操作，并且之后在旁边的明细内容中查找一两个点来判断，然后再在明细内容中输入几个值，并且点击提交操作，再回来看看列表界面中是否刷新了新的值。这一切都是自动化的。
我这里是借鉴我的自动化测试要点来明确需求描述的细节。如果你做不到自动化，我也希望你不要用那种特别稀里糊涂无所谓的描述方式，应该描述关键、足够的细节。实在不行，学学在TD等软件上“如何写测试用例”的技术，借鉴他们的要点，也可以让你对需求描述细节起来。
例如我们看到有人说如何如何测试程序，结果你跟踪他一下，发现他仅仅对登录界面等少数界面的个别操作测试一下而并不集中在最经典和最复杂的交互界面，也就是所他的所谓测试的覆盖程度是低到根本就是空洞的程度。不但知道做什么而且精通如何做的人，反而可能不善于讲大道理，因为真正的道理其实都是那么简单、朴实。