小型团队的软件开发过程
我在这里可能是个例外，但我从未与超过三个开发人员和/或者五个人的团队合作过。我们仍然可以设法完成工作(以某种方式)。
是否有适合这种"极端"情况的软件开发过程？而且，如果我们是独立程序员，是否有什么可以适应日常生活的，从而使其更易处理，更连贯，更有据可查，并且仍然可以完成工作？
解决方案
敏捷方法是一个很好的起点，因为恕我直言，它们更适合小团体。
至于保持个人工作节奏，我建议我们使用一种基于TODO列表和Task2Gather之类的工具的方法。我们可能也想看看GTD。
即使对于我自己的团队，我也不会放弃的事情：
- 源代码版本控制
- 备份
- 去做
- 单元测试/ TDD
- 代码文档
- 重构/代码审查
大多数敏捷方法适合个人资料。
当前最受欢迎的是SCRUM。它是专为小型团队的生产力而设计的，它的支持者声称开发时间比传统的瀑布方法要快5-10倍。
如果我们想开始阅读，我推荐一本Headfirst软件开发书。
我建议使用Crystal Clear方法
七个属性
- 使用带时间限制的迭代进行频繁的交付/集成
- 反思和改善，批评和解决
- 通过办公室组织和开放渠道进行渗透(被动)知识获取和交流
- 人身安全，诚实待人，对法庭批评有信心
- 保持专注，明确任务，工作重点，限制工作量
- 接触专家用户，提供快速，高质量的反馈
- 通常敏捷的东西：自动化测试，CM，持续集成
让强大的SecretGeeek教我们如何成为一名独立的程序员。享受 ：)
intellisense
||
\/
code >>> compile >>>>> run >>>> success >>>> profit ;-)
/\ || ||
^^ \/ \/
^^ errors errors
^^ \ //
^^ \ //
^^ google
^^ ||
\ \/
\<<<<<<< copy N paste
SecretGeek的一个严肃建议。
设置开发环境或者编辑器以自动列出带有TODO标记的所有行，Visual Studio默认情况下会这样做。
步骤1
- 编写类或者方法的大纲(即" Public Class ..."或者" Public Sub ..."，其中没有任何代码。)
- 包含粗略逻辑
- 添加前缀为" TODO"的伪代码：
- 只写非常简单的代码-其他任何事情都只需添加一个TODO
第2步
- 重复步骤1，直到整个应用程序被粗化为止
- 现在，我们有大量的"待办事项"任务
- 检查完整性(宽度)
- 查看可以删除的内容。
- 看看可以简化什么(例如，两个类似的待办事项注释：可以使它们相同吗？
第三步
- 用对不存在的类，方法等的调用替换TODO(对于测试驱动的开发，请为这些方法/类中的每一个创建详尽的测试)
第4步
- 随便添加TODO：伪代码到每个伪代码。
- (如果需要，还可以在适当的地方添加" HACK："注释和解释)
- 在适当的地方，用所需的普通代码替换TODO
第5步
- 重复步骤4，直到没有编译错误为止。
- 如果还有待办事项，请返回步骤3.
(还有很多事先计划，纸张原型设计，客户会议，讨论，拖延，数据库设计，喝咖啡，用于存储和临时存储调用的代码生成，可重复使用的DAL的导入，PAG块使用，PAG ！，文件签核之前的来回辩论，论据，深夜，沮丧，与朋友聊天，通过电子邮件筛选，刮擦visio，打印内容并将其留在堆中，钉书钉，抓巴士，背部和颈部伸展运动等，但为简单起见，所有这些都被省去了……)
(再次是MarkJ)有点像Code Complete中的伪代码编程过程。我们都同意，每个人都应该阅读《代码完整》，对吗？
基本上是为大型团队创建开发流程，以避免可能出现的混乱情况。如果我们尝试自己做大型项目，则无论使用哪种开发过程，都将失败，因为我们需要大量才能及时完成所需的工作。
如果我们从事小型项目，那么任何敏捷方法都可以。 GTD不是方法，它只是一种方法。就像我为我的大脑程序申请了专利。
这不是我们问题的直接答案，但史蒂夫·麦康奈尔(Steve McConnell)十多年前写了一篇名为《少即是多》的文章，内容涉及小型团队为何更有生产力。
持续集成是我一直努力建立的团队的第一件事，因为我认为这是良好开发实践的基础，即经常集成，自动构建/发布，自测试构建，任何人都可以轻松获取最新信息。
在这里阅读更多关于它的信息：
http://martinfowler.com/articles/continuousIntegration.html
