1. 关于项目
1.1. 概述
在任何组织中，项目其实就是一件需要大家共同努力配合完成的事情，且最后生产出的事物，是可以供他人长期使用的。
好比一个蚁群，有蚁后，也有默默无闻的蚁兵们。蚁后负责命令大家搬食物，先搬这块再搬那块，蚁兵负责搬，大家排成长队互相传递食物；最后，蚂蚁将大于自身体重几千甚至几万倍的食物分解搬运到了另一个地方。
1.2. 团队组成
在现在互联网企业内，一个项目也需要由多人组成，产品、项目管理、设计、程序等等。当然这里不能把产品或者项目管理比喻成蚁后，不然其他小伙伴们就要罢工了:)
来说说一个互联网项目从产生到结束的大部分组成人员：
- 需求方：一个产品的需求发起人；他需要做的就是找产品聊天，并把他的想法传递给产品
- 产品：整理需求方提过来的需求，进行加工，参考市面上的竞品，进行研究并创新调研，最后定义产品的各个方面并告诉团队的其他成员产品的样子是什么
- 项目管理：团队的大总管，负责项目的整体时间把控和人员使用分配，必要的时候，可能需要对团队成员进行评估考核
- 设计：包括UI设计和UX设计。UI负责静态(用户界面、设计风格)部分的设计，UX负责动态(功能交互、用户体验)部分的设计
- 程序：整个项目的功能实现。一般分为前端和后端，前端负责UI和UX部分的程序实现，后端负责产品所有数据操作及逻辑业务层的实现
- 测试：负责产品功能实现的测试，负责产品在特殊环境下的运行结果测试，负责产品安全防范方面的测试等
- 运维：产品的上线部署等工作，并对产品的运行环境进行监控等
以上团队成员的顺序基本是按照项目的先后流程排序的，可能有些人的职责不仅仅是上面所描述的，但是大体上可以参考。
1.3. 项目流程
1.3.1. 瀑布流程
在项目管理的初期，大家基本都是按照这种流程来进行项目开发的，类似于计算机的单线程计算，前面的工作完成了，后面的才继续，容易造成资源的浪费。
以下是一个简单的瀑布流程例子：
| 成员 | 时间1 | 时间2 | 时间3 | 时间4 |
|---|---|---|---|---|
| 产品 | doing | - | - | - |
| 设计 | waiting | doing | - | - |
| 程序 | waiting | waiting | doing | - |
| 测试 | waiting | waiting | waiting | doing |
- 产品：调研，写MRD、PRD、流程图、原型图等，完成所有的文档后转交给设计
- 设计：按照产品的文档做相应设计，完成所有设计转交给程序
- 程序：按照产品的文档和设计的文档，进行程序开发和集成，完成程序后交测试
- 测试：按照产品的功能说明文档进行功能测试，对程序进行边界、压力测试等
可见，每个成员的等待时间都很长，资源浪费严重；且如果某个环节出错，则整个流程就无法进行下去。
1.3.2. 迭代流程
迭代流程应该算是瀑布流程的升级版，唯一的区别在于，瀑布流程里每个人只在一个时间段干活，而迭代，是把一个项目分成很多个子过程，每个成员在每个子过程中都需要干活。
以下是一个简单的迭代流程例子：
| 成员 | 迭代1 | 迭代2 | 迭代3 | 迭代4 | ... | 迭代N |
|---|---|---|---|---|---|---|
| 产品 | doing sub1 | doing sub2 | doing sub3 | doing sub4 | ... | doing subN |
| 设计 | doing sub1 | doing sub2 | doing sub3 | doing sub4 | ... | doing subN |
| 程序 | doing sub1 | doing sub2 | doing sub3 | doing sub4 | ... | doing subN |
| 测试 | doing sub1 | doing sub2 | doing sub3 | doing sub4 | ... | doing subN |
项目管理把整个项目分成N个子过程，这里的子过程就是我们所说的一个迭代，每个迭代固定在1周或者2周内。当然，迭代的目标可以在项目初期制定好，也可以在开发的过程中不断产出。
迭代开发的优势在于，试错性强，如果某个迭代出现了问题，则可以在下一个迭代中解决它。
1.3.3. 敏捷流程
敏捷流程中，人们更注重的是功能的快速实现，而忽视文档的编写和流程的记录。当然，在敏捷开发的团队中，必须人人都是精英，人人都有产品的意识。
在敏捷过程中，已经不能用时间轴去记录项目的各个阶段。产品可能不能给出详尽的文档，项目管理可能不能给出具体的完成时间，系统架构师可能无法规划好整个系统等。
说到敏捷开发常用的管理工具，那就是看板。以下是对看板的介绍。
2. 看板介绍
看板管理，常作“Kanban管理”（来自日语“看板”，カンバン，日语罗马拼写：Kanban），是丰田生产模式中的重要概念，指为了达到及时生产（JIT）方式控制现场生产流程的工具。及时生产方式中的拉式（Pull）生产系统可以使信息的流程缩短，并配合定量、固定装货容器等方式，而使生产过程中的物料流动顺畅。
以上出自百度百科(http://baike.baidu.com/view/660386.htm)
2.1. 看板在项目流程中载体的分类
2.1.1. 实体白板/黑板
这是敏捷开发团队中用的最多，最直接的一种看板类型，且适合团队所有成员都在一个办公室工作的环境。
它的优点一目了然，方便工作成员展示自己的任务和进度，另一方面则可以提高成员间互相竞争的意识（谁干的多，谁解决的问题越难，成就感就越强）。当然，缺点也很明显，就是没有历史记录。虽然可以使用不定期的拍照来解决，但是还是不方便追溯。
白板适用在项目管理中所包含的元素有：
- 白板
- 列表(纵向列表、横向泳道)
- 便签纸
- 图钉、磁铁
2.1.2. 互联网式的看板
既然有实体工具，当然也有软件化的工具。国内外的项目管理工具非常多，但是能实现敏捷开发的工具却不多，而能像看板一样展示的工具更不多。以下介绍几款我接触到的看板工具：
Trello：有网页端也有移动端，网址是 https://trello.com/WeKan：参考Trello实现的开源版。与Trello最大的区别在于每个任务没有Deadline，且没有移动端。网址 https://wekan.io/leangoo：国人开发，没有使用过，有兴趣的小伙伴们可以访问网址 https://www.leangoo.com/ 试用
拿Trello操作举例来说，跟实体白板的操作基本一致，只是在某些元素名称上有些出入，名称对比如下：
| 实体白板/黑板 | Trello看板软件 | |
|---|---|---|
| 白板 | vs | 看板(Board) |
| 纵向列表 | vs | 列表(List) |
| 便签纸 | vs | 卡片(Card) |
| 图钉、磁铁 | vs | - |
在软件类的项目管理工具中，最大的优点就是有历史记录的追溯，方便查询快照，而且对于一个成员在异地工作的团体来说，互联网式的看板工具是一种最好的选择。
2.2. 项目管理在看板中的职责分类
2.2.1. 项目管理主导型
在之前的团队组成中说过，项目管理是整个团队的大总管，他非常清楚团队中各个成员的优缺点，所以他能够知道什么任务派给谁是最适合的。
下图最能体现出大总管的主导作用，项目管理把任务分配给Jone、Alex、Tom或者Marco，成员只要完成自己的任务就好。
2.2.2. 成员主导型
这里看到成员主导型，也许有人就觉得项目管理就没事了。错！项目管理依然要把项目拆分成各个小任务，然后，然后就让大家自己去“抢”任务了。
“抢”任务，为什么要抢？前提是成员自己认为能够胜任这个任务，二是要建立在多劳多得或者是绩效考核之上的，如果没有这些，就没有“抢”的意义了。
以下是成员主导型的看板展示：
2.3. 根据团队的规模增减看板
- 如果你是一个后端的开发主管，那你的手下肯定都是后端，则列表项就是最基本的
Todo、Doing、Done三列 - 如果你是一个技术部的老大，你管理者程序员、测试、运维，那你的列表项可以是
Todo、Dev-Doing、Dev-Done、Testing、Deploy五列 - 如果你是一个产品制作人/产品经理，你的团队成员包含了一个产品创建所需要的所有人员，那你可能需要2个看板，一个是需求池看板，一个是迭代流程的看板。
2.4. 看板实例
在正式的项目开发中，可能有很多始料未及的状况出现，这些状况可能会逼着产品经理对需求进行优先级改变，所以，需要有紧急的列表可以插入。
以下是我最喜欢的看板结构：
func 1~4，项目管理把项目拆分的模块名Ice Box，翻译过来是冷冻室，也就是冰箱，其实是项目管理已经拆分好的一个个任务，供成员获取- 这里
Emergency就是上面说的紧急需求，如果某个模块行中有紧急需求，必须先做紧急需求，再到Ice Box里拿东西 In Progress，说明这个任务已经有人接手了，必须将接手人的姓名写在任务标签上Testing，一般都是任务的开发者自己进行测试，或者是开发主管Complete，任务完成，等待进行持续集成
3. 结束语
以上是我在项目中尝试过的多种管理方法，有些也是脑子中成型的想法但是还未实现；如果大家有兴趣实践，请把遇到的问题共享出来共同探讨，谢谢。