一、优秀实践分享：
代表一：重复、复杂的工作任务如何拆分
根据工作的频次划分：日次、周次、月次；根据工作的内容划分：事务类、专项类、领导交办类、外部门协办类；根据工作的重要性划分：重要/不紧急、重要/紧急、不紧急
日次+无产出物：例如流程处理工作，不建卡片
周次、月次+事务类+有产出物：每件事务建立一个业务需求-系统任务为产出物-个人任务为成员分别产出物
领导交办+重要/紧急：统一建立一个业务需求-系统任务为具体交办事务-个人任务为具体工作安排
专项类：例如敏捷专项项目，按项目内容建立多个业务需求-系统任务为工作各阶段目标-个人任务为具体工作活动
TIPS：通过拆分使”杂乱“的工作有条不紊
代表二：需求量较多或需求较大时如何拆分
报表类需求数量多、颗粒度比较小，开发周期较短，系统任务基本都小于10人天，所以并行任务多、交付量大，通过看板有利于管理透明，及时跟踪多个并行任务进度
对于双降类需求，工作量较大，采取第一轮/第二轮的方式拆分系统任务（分批次），每轮安排3-4张表
TIPS：通过看板解决“乱忙”的状态，能捕捉到众多任务及时的状态与阻塞点
代表三：如何拆分与管理系统任务
需求按阶段性拆细，若达不到可监控粒度，再拆分到功能点
带上需求编号在标题上，通过导出表格方便统计系统任务与IT平台的任务核对，保证系统任务拆分完成、对比任务估算与工作量评估情况，有利于分析实际与计划工作情况
建议系统任务可以分两级，一级对应于IT综合管理平台的任务，在此基础上再拆一级：需求-平台系统-我的系统任务
TIPS：需求拆分原则-保证每个任务是可以交付的
代表四：已完成3轮迭代并享受其中的敏捷试点小队是如何玩的
为什么要拆：拆任务与迭代绑定
何时拆：迭代的第二周开始拆下一个迭代的任务计划；到了下一个迭代就主要是让任务流动，不是当下建任务
何时拆：如果需求还在澄清不建议拆，要拆明确要做的需求
什么样可以拆：需求要不要拆，不是项目组能决定的，要小队长与业务沟通确认，拆优先级高的需求，拆个人任务时项目经理要与开发人员或测试人员沟通好，达成一致
紧急需求如何处理？通过沟通尽可能得出该需求是否紧要、业务是否要求本迭代一定完成，多沟通看能否放在下个迭代进行，尽量不要影响当前迭代内容
TIPS：1.注重总结，通过回顾会中讨论梳理受阻，剖析根因，提出改进点，保证每次迭代越来越好;2不要把看板当成工具，也不要视其为负担，让我们一起拥抱看板
代表五：通过迭代与需求拆分我们获得的收获
看板能得到及时反馈，团队成员在站会中对齐后，能聚焦问题加快受阻点解决
安排任务不要太饱和，在迭代计划会时就评估紧急事项的开发容量，规划容量中就应该预留
引入看板后重在计划明确，以前琢磨要干4个月的工作现下预计一个半月就能完成
TIPS：通过拆分使计划更准确，使风险在迭代中暴露
代表六：规划任务的要点
一定要留buffer，保证项目组的弹性
要根据实际发生内容全面分析，及时做出调整
二、共性问题答疑：
Q1：看板拆分工作任务，增加了可视化同时也加大了工作量，相当于把工作内容记录到看板上
除了可视化，看板也是可以完善项目管理，对于看板上的任务是要提前建计划，然后让任务状态流动起来；忌任务来了才当下建任务，一定不是你做什么记录到看板，而是按照层层规划去优先推动价值最高的工作。
Q2：系统任务限于10人天有难度，个人任务是不是要强拆到1人天而枉顾计划
系统任务拆分并不是局限于10人日，看管理者自己管理粒度或需求大小，和对风险的把控拆分符合自己的管理粒度；分清指哪打哪还是打哪指哪的问题。
Q3：需求和系统任务、个人任务谁来拆
都可以拆，不限定权限，谁有空谁更懂就去拆；秉着职责清晰边界模糊的原则。
Q4：空降任务如何更好的处理
一种方式是事先预估该类任务开发容量，排计划时就预留出来；第二种是把优先级高的任务分派给其中几个人，把不紧急优先级不高的分派给几个人，等空降任务来，可以把任务交给手头上优先级不高的成员来处理。
三、总结
1.后续会进行需求优先级排序，版本规划（版本火车），规范发版窗口（不是想上线就上线，而是遵循发布日历）；业务也将参与到敏捷中来与团队一起进行迭代开发。
2.我们科技要反思能否在产品业务上提出有价值的建议，把握敏捷核心：总是做当下价值最高的事，持续交付有价值的产品，团队不断自我提升改进。
网友评论