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