4、和看板并非是对立的，它们是可以结合起来使用的。使用看板来管理每一次迭代的任务是一种可取也是很常见的精益实践。依赖于任务管理方法论，市面上很多软件都做了相应的支撑，自己曾经使用过的任务管理软件如下：Redmine：这个是自己最开始接触的任务管理软件，使用也比较广泛。比较遗憾的是，redmine安装有点繁琐，而且基于ROR，如果需要二次开发，需要重新学习ROR。Tower.im：这是一个任务管理云服务，界面设计的简单优雅，一目了然。很多小的私有项目，我都会用这个进行任务管理。类似的还有teambeation等。Jira：这款软件是商业版的任务管理软件，对于这一块做的是非常专业的，很多大公司都在使用
5、。但是，它是收费的。所以，如果你要用，要么付钱，要么去破解。禅道：这款软件最早是叫做bugfree,是开源且主要针对Bug管理的，后面慢慢发展成现在的集任务管理、bug管理、团队管理等的项目管理软件，并开启了收费策略。总体来说，功能很全，也比较专业，但是ui上有种传统it系统的感觉，流程上也不具有现在敏捷开发的一些优势。Kanboard：是实现了Kanban方法论的任务管理软件。对于个人的项目，其实依赖于tower.im这种第三方云服务完全足够了。如果担心数据安全的话，那么推荐在内网搭建Kanboard进行看板任务管理。文档协作研发中首当其冲的就是文档撰写，这个很多情况下都决定了项目的可维护
8、接手。当然，这些并不是死板要求的，应该根据实际的业务选择，不一定所有的文档都是必须的，也不一定要分开这几个文档写(可以将这些内容集成在一个文档中，这也是目前我经常采用的方式)。这些文档的范例可以见：/superhj1987/awesome-tech-collections/tree/master/document。而对于文档撰写协作的方式，我自己经历过的有以下几种：使用word撰写各种文档，提交到svn等版本管理工具上使用googledoc进行协作使用word撰写文档，然后提交到项目管理软件中进行管理使用markdown撰写文档，提交到版本管理工具上我自己比较推崇的是使用markdown撰写
10、档。在使用SpringMVC开发的后端应用中，个人推荐SpringFox，使用此项目能够通过在Controller中加入相应的注解信息从而自动生成API接口文档，同时也提供了在线调试的功能，极大减少了API文档的工作量。代码协作对于一个技术团队，最最关键的肯定是写代码。一个人单打独斗那倒好说，但是这就像篮球场上，一对一靠个人硬实力，但是5对5，那就不仅仅是一个人实力强就赢得了的了。因此对于技术团队来说，代码协作是至关重要的一个部分。代码版本管理：Git+SVN几年前最流行的代码版本管理工具是svn（当然此前，更加古老的还有cvs之流），的确为程序员们的代码管理带来了很多便捷。但到了现在，
11、相比起这种集中式代码管理，目前最为火热的当属git这种分布式代码管理工具，在Linux上直接搭建git服务器来构建项目的git系统的。而这几年随着Github以及类似系统的涌现，对于很多私人项目我都是采用oschina或者gitcafe提供的git私有代码管理来做代码版本管理的。当然，对于公司来说，有很多开源类github系统可以搭建在企业内网。详细的可以参见：搭建自己的github。当然，对比svn，git也是有缺点的。无法天然的支持对于目录级别的权限管理和基于目录的版本管理操作是目前不得不结合svn和git一起使用的重要原因。通常情况下，可以使用git做版本管理，辅以svn做基于目录级别的
12、发布包管理。代码分支/Tag管理：GitFlow其实分支/Tag管理是代码版本管理包含的内容，之所以单独出来，是因为对于分支的使用其实还是有一定的原则和技巧的。并非如很多人一样，所有项目就一个master分支，所有修改都往这里塞。目前，最为流行的一种基于分支的工作方式就是:Gitflow。介绍可以见:基于git的源代码管理模型gitflow。简单概括就是：master和develop作为主分支。主分支是所有开发活动的核心分支。所有的开发活动产生的输出物最终都会反映到主分支的代码中。master是可以随时发布的分支，而develop则时刻保持最新的开发代码。辅助分支是用于组织解决特定问
16、量保证当代码开发完成之后，需要质量保证机制的介入来保证功能的正常运行，从而保证代码是可发布的。一般来说，质量保证的手段就是测试，分为：代码质量测试功能测试性能测试代码质量测试一般是在编译打包代码之前进行，通常是自动化进行的。针对Java项目，自动化代码质量测试可以分为以下几步：源代码规范检查：对于Java来说，代码规范的检查一般使用checkstyle来检查。默认的规范非常严格，这里大家可以根据需要放宽一些规范。源代码静态质量检查:常用的工具是pmd,可以检查Java源文件中的潜在问题,比如空try/catch/finally/switch语句块等。字节码bug检查：常用工具是findb
17、ugs,基于BugPatterns概念，查找javabytecode（.class文件）中的潜在bug。如NullPoint空指针检查、没有合理关闭资源、字符串相同判断错（=，而不是equals）。单元测试：使用junit即可，当然在这里当使用mvn时，其testphrase会默认生成测试报告到$project.build.directory/surefile-reports文件夹中。这里建议使用coverage生成单元测试报告，其中一个关键的单元测试覆盖率指标达到98%以上才为合格(根据需要自己调整即可)。以上提到的工具，都是有maven插件的。通常情况下，也推荐使用这些工具的maven
18、插件来调用。目前流行的自动化ci工具jenkins、QuickBuild等结合各种丰富的插件可以提供这些功能，将他们集成到一个测试流程并形成最终的测试结果报表。在代码发布到线上环境之前，一个关键的步骤就是功能测试，通常都是工程师来进行的。需要测试工程师根据产品需求，形成测试用例，然后根据这些用例做相应的测试。测试用例的一个模板如下：用例ID功能名称用例名称测试数据前置条件操作步骤预期结果测试结果备注review说明-需要测试工程师根据需求创建并经过研发人员reivew确定测试用例，待到发布前进行测试以及反馈，直到所有测试用例都通过。对于移动app功能的测试，目前市场上有类似bugtags这种所
19、见即所得提交测试工具，可以很方便的提交bug。功能测试通过之后，对于一些对性能有要求的项目，还需要进行性能测试。对于这种测试来说，通常有以下几种方式：测试工程师写性能测试代码来进行测试使用性能测试工具测试，如LoadRunner、ab等当然，所有这些测试都是在项目发布上线之前进行的，通常是在项目的测试、预发布环境中进行的。此外，对于测试任务的管理工作一般在任务管理软件中都做了集成。也有类似Mantis这种事专门做缺陷管理的。自动化部署对于Java项目的发布流程，如下图所示：使用ci软件可将以上步骤自动化的。如上图所示，对于一个项目，我们是划分为三种或者四种环境的。测试环境:这个环境是一个相对
21、环境是比较严格的一个环境。在发布前，一般来说会进行发布确认等一系列上线评审工作后，由项目负责人或者运维人员部署发布。功能列表vs实现情况：检查是否已经实现所有计划的功能？如果有某些功能没有实现需要说明原因。软件演示测试结果和遗留问题列表：测试用例的情况，遗留的Bug以及情况说明上线确认后续任务计划其中，上线确认书的一个例子如下：xx项目上线确认书需求方验证结果意见：确认人：由各个负责人签字开发确认意见：确认人：测试确认意见：确认人：服务器是否需要重启是否需要自动更新那些App确认人：服务器配置影响是否需要增加新的服务器ip,是否需要修改nginx/tomcat，是否新装软件，是否新建域名
24、由用户发现的。但是由于客户端发布流程的繁琐，很难及时修复一次发布版本的故障，只能等到下次解决。但是，目前一些客户端使用混合开发，其中的h5页面是可以在线修复的，另外，很多安卓app热更新方案也都能在线修复一些代码故障，如Nuwa、HotFix、dexposed。故障解决完并非最终的结果，之后的故障总结也是故障管理尤为关键的一点。大公司会根据故障产生的影响不同定义不同的故障级别，从而追责到个人，再进一步影响个人的职级评定或者绩效考核、奖金之类的。但这一套却并不适用于小公司，毕竟大多数小公司没有那么完善或者说根本就没有职级和绩效这么一说。其实，追责并不是主要目的，最主要的是如何避免再次出现问题。因