管理篇：敏捷开发

管理篇：敏捷开发

       声明：谨以此篇献给我的领路人王昊老师以及和我并肩作战的小伙伴! 该篇所列的观点不是原创，只是将自己十年敏捷实践进行了总结。

     

        什么是敏捷？是不是项目管理遵循Scrum就是敏捷，或者说团队没采用Scrum就不是敏捷？敏捷是一种工作方式，是一种思想，是小步快速前进。敏捷不是让你走得更快，而是让你走得更稳。敏捷不是保证你一定成功，而是在你失败时你的损失最小。敏捷增强了开发过程中的可视性，这种可视是及时、直观的。

任务管理

---

 

任务分解

        任务分解的方向是纵向不是横向，采用流水线的工作方式，任务要具有可验收的特性（即完成度可视）。任务必须估计完成时间，任务的粒度要尽可能的细，最大不能超过1-2天，最好是2个小时。太大了验证周期太长，大任务极有可能是需求理解不准确。当然过小的任务，会给管理添点麻烦。
        任务的管理采用看板和燃尽图，看板让任务状态可视，燃尽图是让任务的完成趋势可视。
        任务分配的方式是认领，认领后的任务不是个人的，而是团队的。认领任务是表示认领人对这个任务负责，并不要求认领人要独立完成这个任务。
法则1. 优先认领，优先级高的任务，必须最早完成；
法则2. 尽早集成，如果提交的代码让CI Build失败超过4个小时，要被惩罚（当时惩罚不是目的，是为了让你注意这个问题）。
既然这样，那有成员就会想，没做完我就不提交了；你想多了，我们还有一个法则。
法则3. 不留代码过夜，所有的代码收工前必须提交到CI，否则你只能删除代码。
法则4. 集中精力完成一个，一次只能领一个，即只能有一个正在进行的任务，一个人只有一个任务在进行中，甚至一个团队也只能有一个任务在进行中，当然没事可做的人除外。
法则5. 及时终止延期，当任务完成的时候超过了预估时间时，请及时中止你的任务。首先请重新确认你对任务的理解，将你的任务再次分解。然后可以试用以下两个方法：
        方法一，将你之前所写的代码全部删除，重新再来，不要害怕删除；
        方法二，在你的团队寻求技术帮助。
        很多人在任务延期时往往会给自己一个预期，也许再多15分钟就可以做完了，如果真的完成了，那皆大欢喜。但15分钟如果没有完成，请及时放弃。因为我们通常发现，这个延期可能会超出你的想象。
        说明：这里的任务是泛义的概念，没有严格对应敏捷的Task。

个人任务管理：四象限法则+番茄工作法

        我们通常要同时处理多项任务，很多人可以多线程处理，但并不是所有的任务都适合多线程运行（比如开发，开发时被中断将严重影响开发效率）。
神器一：多任务模式下，先用四象限法则（紧急、不紧急、重要、不重要）排列任务优先级，按优先级来完成，优先级要及时进行调整。如果你的任务都是按天计划的，那就没有意义了，所以我们还要结合神器二。
神器二：将任务按“番茄时间”进行分解并执行，用醒目的标志宣告你在闭关修炼，任何人不许打扰。
        番茄工作法：选择一个待完成的任务，将番茄时间设为25分钟，专注工作，中途不允许做任何与该任务无关的事，直到番茄时钟响起，然后在纸上画一个X短暂休息一下（5分钟就行），每4个番茄时段多休息一会儿。

会议

---

 

        会议有毒，世界上最可恨的打扰莫过于开会，而且会议会自我繁殖（一次会议总能引出下一次会议）。对于会议我们可以问几个问题，这个会议是否一定要开，这个会议是否一定要在这个时间开，这个会议的所有议程是否一定要，参会人员是否一定要这些？
法则1：给会议定个闹钟，闹钟响起时，散会！

法则2：终止讨论，讨论通常是无休止，先给出一个初步方案，有意见可以在会后再找时间交流。

法则3：不轻易说不，当你决定对别人的方案和意见说不，你得要提出一个新的解决方案，否则你没有说不的权利。

计划会议

        计划的目标是确定下一个阶段要演示的内容，计划的时长一般是1-2周。计划即瞎猜，计划的周期越长，偏差可能就越大。所以我们应该缩短计划的周期，明确要完成的任务，哪些人参与，每个人的参与度如何？计算每个人的有效工作时间，有效工作时间不等于8小时，请将事务性工作从有效工作时间中排除，如：填写报账单，学习等。计算团队兼职人员的投入工作时间，这些人往往有多项任务在进行。
法则1：及时调整计划，盲目遵循不切实际的计划比无计划更可怕。计划是为了让我们看见实际开发与计划发生了多少在偏差，不是要求我们一定要按计划执行。
法则2：不要计划加班，在你的计划中不要有加班，你的加班肯定会比计划多。

每日例会

       会议的主要任务是评估任务的昨天的任务是否有问题，今天的任务有什么建议。所在会议有如下特征：
       会议时间短，控制在15分钟之内；
       会议地点应设在任务墙前或看板前；
       每个人回答三句话：昨天做了什么，今天要做什么，有什么问题（是否需要协助）
       法则1：会议是站着开，哪怕是远程，当你想坐下的时候，就要考虑结束会议；
       法则2：昨天做的要和今天做的不一样，如果是同一个任务也要明确区分。

评审会

        演示可以工作的软件，尽量让客户和所有项目成员都参加。让客户尽早看到并使用软件，解答客户的问题，尽早发现需求偏差；让所有成员都看到自己成果，更好的激励团队。（当前如果你的任务没完成的话，可能就是鞭策了。）

回顾会议

        回顾会议以轮流发言方式进行，每个人都要发言，总结上一次sprint中遇到的问题、改进和大家分享讨论。同时对问题列优先级清单，讨论哪一些我们应该在下一个Sprint解决。这里的讨论主要是针对开发方式，对软件开发的效率产生影响，例如：可以是技术分享。这些问题和软件的Bug一样重要，甚至更重要。
法则1：拒绝“臣附议”，每个人都必须发言，而且后一个发言人不能重复前面发言人的内容。（你会发现开会的效率瞬间提高）。
法则2：验收上次回顾会议的改进清单，分析未完成原因，加入到当前问题清单中重新排优先级。

技术分享

技术分享特权，可以在团队内部申请10分钟的站立技术分享会，但最好将分享资料提前发给大家，会议可以选择在晨会后进行，因为大家已经在会场了。

......未完待续......