码迷,mamicode.com
首页 > 其他好文 > 详细

敏捷开发一千零一问:怎样处理重要但不明白的任务?

时间:2017-06-07 20:47:47      阅读:130      评论:0      收藏:0      [点我收藏+]

标签:情况   targe   不能   计划   line   height   重要   敏捷   日常   

本文是敏捷开发一千零一问的第三十九篇。(栏目总文件夹

也是敏捷开发日常跟进系列的第八篇。(栏目文件夹

问题:有一类任务非常重要(如果同一时候也非常紧急)。但却非常不明白,该怎么办?

答案分非常多种情况。大致例如以下:

客户早就提出的需求

一般而言,除非事出紧急(客户突然提出),否则不能让一个重要的内容处于重要+不明白的状态。

处理方法应该例如以下:

1. 尽早做原型,使之明白

由于重要+不明白的任务工作量肯定大于重要+明白的任务,所以早做才干保证同一时候完毕——如果截至点同样。

只是,早做仅仅是使之明白而已,并不须要真的做完,所以能够视同为原型。

每一个迭代把用来明白的原型展示给客户看,让其提出明白的意见。

客户突然提出的需求

如果仅仅有一个迭代周期就要上线,该怎么办呢?

这时候应该打破原来的评审会制度,由于本来就不明白。被评审通过的概率非常低。而是採用“渐进式评审”(參考这里:http://blog.csdn.net/cheny_com/article/details/7339173)。即任务完毕的同一时候就立即拉评审。如果不通过就接着改,甚至能够放弃一些同迭代的次要任务——谁让它重要呢。

技术预研

PO应该在计划会之外,更早、更长期地与团队有一个接触,内容是远景展望、近期2~3个迭代的内容等。參与人员是PO+技术骨干。

这样团队就能提前获知一些潜在的预言,提前做准备。

技术改造

这是一类相似“性能优化”的活动,经常难以在实施前确定目标,非常easy无始无终。这时的处理方法是划分为若干个可跟踪的点。分期达到。

比方我以前做过一次性能优化,我们大致分为四个步骤:

1. 确认性能基线,就是如今的内存、速度怎样。

2. 确认问题点,就是哪些内容占领了内存、时间。

3. 排序问题,从大到小逐个解决。

4. 每解决一些问题。就做一个推断是否停止。

当时大约2周后,性能达到了原来的1/6内存和1/7时间。且仅仅有SQL Server自带工具的两倍(由此推断优化空间已经不大了),于是作罢。

这个步骤,也能够变形一下用于技术预研。

敏捷开发一千零一问:怎样处理重要但不明白的任务?

标签:情况   targe   不能   计划   line   height   重要   敏捷   日常   

原文地址:http://www.cnblogs.com/yxysuanfa/p/6958748.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!