`
rocket
  • 浏览: 92224 次
  • 性别: Icon_minigender_1
  • 来自: 金城
社区版块
存档分类
最新评论

功能还是任务--制定敏捷计划

阅读更多

前些天对需求讨论确定后开始制定计划安排。
根据最近对agile的一些体会我这次制定计划是这样的:

1、根据需求的功能点定义,把需求纵向切割成一个个较为独立的story,然后把这个story归入到计划中。
解释:对于一个story来说,所有的分析、设计、实现都是由一个开发者来完成的。当然在开始实现前对于一般的设计都是要一起讨论的
这时候story可以确立的基本属性有:title(标题)description(描述)

2、我把story收集好之后,根据需求的复杂度和优先级作了一个初步的分析,然后再和资深的developer做一次沟通,大概预估以下每个story需要花费的时间,然后根据老大给我的时间要求把story分成了两个iteration
这时候可以确定的story属性有:Iteration(迭代周期)  Priority(优先级) Release(发布版本) Status(状态) PlanSize(计划时间)

3、当我确定了在当前迭代周期需要完成的story之后,我就会在开发小组内部召开一个小讨论,罗列出这个迭代周期内有哪些功能需要完成,然后由大家自己选择感兴趣的story
在选择story的同时可以经过讨论确立的属性有:developer(开发者)

至此一个迭代发布版本的粗略计划,一个迭代周期的详细计划就已经出来了。

but,当我把这个计划提交给我老大的时候,他们提出了几个问题:
1、一个功能纵向开发,如何知道开发者每天的工作任务,如何知道他现在是在做设计和还是在做开发
2、以前的开发是有一个专门负责实现设计和后台接口实现,一个专门负责调用接口和前台实现,这样由一个人开发后,有些人可能会在模型和接口的实现上因为经验不足而造成失误
3、让一个人独立开发一块功能,是不是破坏了项目组内部的协作机制,是否会让开发者感觉到他是孤独的
4、如何考察一个开发者的工作是否饱和?

对于上面的问题,我经过思考和讨论后给出了这样的回答:
1、每天都会由我发起一个简短的状态了解,了解每个story的进度,是在分析,是在设计,设计还是在实现了我都会对story做一个记录
2、一个人纵向开发也许会经验不足造成接口不够全面,但是由于是他一个人开发,他可以方便的根据自己需求来修改接口。而且两个人在横向开发时会有一些沟通交流问题而造成成本增加。(实际上在完全的agile中是由两个人结队开发,而且通常的组合是一个经验丰富的带一个经验少的)
3、在功能开发时,无论是分析,设计,还是实现发现问题都可以立即举手进行讨论。可以说只要有问题就是团队一起解决的。
4、这其实是只如何对开发者进行工作量考核了,我觉得从敏捷的角度来看考核的问题比较简单,就是你最终实现的完整功能(因为只有完整的功能才能给产品带来价值)所花费的时间和预期时间的差值。比如说一个story预期是6点(两点为一天)完成,结果你用3点就做完了,那么你的考核点就是+3,但是这还没完,当测试后发现这个功能点出现一次bug,你的考核点就要扣除1点,这样最终的考核点就是2点。

经过和老大的讨论之后,他们觉得以功能story来分配的方法和以前已工作任务来分配的方法是有些难以控制的,但是还是同意我开始在项目组试行(这里要赞一下我老大的开明态度)

最后提一下我用于agile项目管理的工具,相信很多人都猜到了,就是mingle

下篇预告:mingle使用小记    时间:2007-9-11

分享到:
评论
7 楼 jenniferYin 2007-09-21  
想问几个问题:

1  目前项目进展到什么程度了? 有没有达到预期的效果?
2  你的Team member的资历大概是什么样的? 是否每个member都有相当的能力做有品质的分析和设计?
3  纵向切分任务,那横向的framework层面的部分谁来负责,你怎样确保设计中大家都follow统一的规则来处理?


6 楼 rocket 2007-09-20  
<p>
cnfree 写道
最好的方式当然还是Senior开始新的模块,如果很忙的话,由junior来维护这个模块,不忙的话,谁做的谁维护。Junior虽说有点像打杂的,但是review别人的代码对自己的水平提高也是显而易见的。人不管水平高低,都是可以培养出来的。
</p>
<p>这个方法是我以前没有想到的,我觉得很好。我原来的想法是,来新人之后开始结对,这样让新人在结对过程中学习,进步。但是我觉得做为一个coder来说,必须要有很强的view code能力。这个是一开始就要培养的。</p>
<p>对于考核的建议来说,我的出发点是完成的功能,不是工作的饱和度,可能各有优劣。我只是觉得做为pm来说主观的来考核别人很不负责的,至少我考核别人的时候觉得比较困难。</p>
<p> </p>
5 楼 cnfree 2007-09-19  
比如说一个story预期是6点(两点为一天)完成,结果你用3点就做完了,那么你的考核点就是+3,但是这还没完,当测试后发现这个功能点出现一次bug,你的考核点就要扣除1点,这样最终的考核点就是2点。

这个我不太赞成,就我所在的公司而言,很有可能进行一次Checkin的时候,我就已经知道了其中有很多Bug,但是仍然需要CheckIn,如果不及时CheckIn,就无法让QA进行测试,得到最终的版本。Bug并不能作为考核的主要手段。主要手段仍然是由项目经理来评估你的效绩的,不同的人由于水平不同相同时间的成绩肯定是不同的。如果我愿意的话,我可以一天做完整个星期的任务,事实上也确实如此。当然每个公司的管理手段都是不一样的,我们公司是以Bug进行驱动的,如果Bug改完了,只能等着PM assign 新的bug,feature 也是bug.

最好的方式当然还是Senior开始新的模块,如果很忙的话,由junior来维护这个模块,不忙的话,谁做的谁维护。Junior虽说有点像打杂的,但是review别人的代码对自己的水平提高也是显而易见的。人不管水平高低,都是可以培养出来的。


4 楼 rocket 2007-09-11  
哦,个人认为有两个角度来解决则合格问题<br/>
1、story的划分粒度有多大,就是一个人完成的story在给别人介绍需求的时候应该是可以很快并且较为详细的介绍清楚的。(一般来说我划分一个story的plan size不会超过4天)<br/>
2、一个story在以后开发中会不断地变更需求进行维护,这时候你不能指望维护的那个人还是当时的开发者,所以我觉得花费在这种沟通之间的代价是有必要的。
3 楼 fly_ever 2007-09-11  
当然在项目开始前,团队内部成员对整个需求都会去了解,每个成员都会了解要做的东西,并且每个成员对自己负责的部分会了解得更加细致,但是不可能对别人的部分也了解得很细致,很深刻。
其实我说的有些功能或者说遇到的有些问题是要深刻的理解这个story的需求才能给出一个合适的方案的,而不只是了解需求,所以这时候就会出现需求的沟通。

2 楼 rocket 2007-09-11  
fly_ever 写道
引用
在功能开发时,无论是分析,设计,还是实现发现问题都可以立即举手进行讨论。可以说只要有问题就是团队一起解决的
我一直有一个问题,就是每个人独立的完成各自的story的时候,遇到问题,如果这些问题是与story的具体需求联系在一起的,而其他人并不能深刻的理解这个story,所以要让别人帮忙来一起讨论解决问题的话,还需要跟他们沟通这个需求,而且既然是遇到的难题,所以也并不能指望别人一理解了需求之后就能拿出一个合适的解决方案,所以也会继续跟这个人讨论,一起解决,或者是再去寻求另一个人,沟通需求,然后解决。 其实这也是一个很浪费时间的过程,尤其是在寻求一个人无效而去寻求另外的人的时候。 也许有些人说,举手讨论时,全组的人都聚过来一起讨论,解决,但这样的话我觉得不太现实。
<br/>
<br/>
<br/>
从你的描述中可以看到一个问题就是,在讨论之前,参与讨论的人并不了解需求。这里才是导致你觉得沟通代价高的原因了。其实我们的做法是这样的,当需求收集的差不多时,会拉上所以团队内部的人员(开发,测试,市场),来召开一个需求讨论会,这个会议的目的一个是大家一起讨论来确认或者否决一些需求,另一个目的就是让所有人知道,我们要做的东西是什么。所以,当把story交给某一个开发者开发的时候,其实开发团队内别人对这个需求也是有所了解的。这样当开发者遇到问题来具体讨论的时候,只是讨论他所遇到的问题:这个需求点不明确啊,这个设计是否合理啊,这个实现有什么更好的方案啊等等。至于参与讨论的人,通常情况是自由自愿,就是你听到了问题,你自己可以随时参与到问题讨论中来。但是当有些story格外重要的时候,我会主动发起讨论,把同组的资深开发者邀请进来一起研究解决方案
1 楼 fly_ever 2007-09-11  
引用
在功能开发时,无论是分析,设计,还是实现发现问题都可以立即举手进行讨论。可以说只要有问题就是团队一起解决的

我一直有一个问题,就是每个人独立的完成各自的story的时候,遇到问题,如果这些问题是与story的具体需求联系在一起的,而其他人并不能深刻的理解这个story,所以要让别人帮忙来一起讨论解决问题的话,还需要跟他们沟通这个需求,而且既然是遇到的难题,所以也并不能指望别人一理解了需求之后就能拿出一个合适的解决方案,所以也会继续跟这个人讨论,一起解决,或者是再去寻求另一个人,沟通需求,然后解决。
其实这也是一个很浪费时间的过程,尤其是在寻求一个人无效而去寻求另外的人的时候。
也许有些人说,举手讨论时,全组的人都聚过来一起讨论,解决,但这样的话我觉得不太现实。

相关推荐

    软件测试之敏捷测试--从实例详解敏捷测试的最佳方案

    敏捷测试的核心理念之一是“持续测试”,即在整个项目周期内持续不断地执行测试任务,而非等到开发阶段结束后才进行。 #### 敏捷测试的关键原则 1. **早期参与**:测试人员应该尽早地参与到项目的规划和设计阶段,...

    参考资料-A-实施服务合同之《项目实施服务工作任务书》-敏捷实施专用.zip

    在《项目实施服务工作任务书》中,敏捷实施会体现为灵活的工作计划、频繁的交付和反馈循环,以及对变更的接纳和快速响应。 三、工作任务书的构成 1. **项目背景与目标**:介绍项目的背景信息,明确项目的目标和...

    火星人敏捷开发手册 2012-12-31(修正了页眉)

    - **迭代意向表**:记录每个迭代的计划,包括预期完成的任务、估计的时间等。 #### 敏捷日常跟进扩展阅读 - **故事板、看板**:使用可视化工具来跟踪团队的工作进度,帮助识别瓶颈。 - **燃尽图(Burndown Chart)**...

    Leangoo领歌永久免费的敏捷工具提供-敏捷开发指南- 搭建敏捷体系,快速启动敏捷

    它提供全面的敏捷研发管理解决方案,涵盖了敏捷需求管理、任务协同、进展跟踪以及统计度量等功能。该工具由拥有丰富敏捷实战经验的顾问团队打造,能够完美支持Scrum、SAFe(规模化敏捷框架)以及Scrum of Scrums等大...

    敏捷软件开发实践估算与计划 Mike Cohn

    《敏捷软件开发实践估算与计划》是Mike Cohn的一部著作,由清华大学出版社于2016年出版。这本书深入探讨了在敏捷开发环境中如何进行有效的估算和计划,旨在帮助团队提升开发效率和项目成功率。 1. **敏捷开发**:...

    Scrum 敏捷开发ppt 实用篇

    - **回顾会议 (Sprint Retrospective)**:团队反思上一个Sprint的表现,识别改进点,并制定行动计划以提升未来Sprint的效率。 #### 六、Scrum 的五个价值观 - **承诺 (Promise)**:团队和个人对完成既定目标的承诺...

    藏经阁-企业局数据库敏捷研发模式.pdf

    2. 数据备份与恢复:定期进行数据备份,制定应急恢复计划,以防数据丢失或损坏。 3. 安全防护:实施防火墙规则,防止恶意攻击,同时监控数据库的异常访问行为。 4. 扩展性规划:随着业务发展,需要预先规划数据库的...

    轻松搞定Scrum

    这些原则包括尽早和持续交付价值的能力、对衍变的需求做出计划、频繁地交付可工作的功能、业务人员、客户或其拥护者、以及实施者必须在整个项目中每天一起工作、激励的个体以及创造支持环境、内部沟通最高效的方式、...

    敏捷项目管理经验分享

    计划板包括版本规划、任务分解、估算和资源分配等功能,可以帮助项目团队更好地计划和管理项目。 (二)任务板 任务板是指在JIRA中,用于管理和协作项目任务的板块。任务板包括任务的分解、执行和追踪等功能,可以...

    火星人敏捷开发手册 2012-02-29

    与传统的线性计划不同,敏捷计划允许团队在过程中调整计划,以应对变化的需求和技术挑战。这种计划方式强调短期目标和快速反馈循环。 **可用时间计算** 可用时间计算是指团队在规划每个迭代的工作时所采用的一种...

    敏捷开发.docx

    - 将选定的功能分解为具体的任务,并创建Sprint待办事项列表(Sprint Backlog)。 3. **每日站会(Daily Scrum Meeting):** - 每日固定时间召开,会议时间不超过15分钟。 - 团队成员汇报昨日完成的工作、今日计划...

    火星人敏捷开发手册-免费的Scrum开发过程手册 2011-07-21

    就如同橄榄球比赛中,球员们既要根据事先制定的战术计划行动,也要根据场上的实际情况做出即时调整一样,在敏捷开发中,团队同样需要在遵循预定计划的同时,保持足够的灵活性来应对变化。 - **计划与灵活性**:Scrum...

    火星人敏捷开发手册

    - **敏捷计划流程**包括迭代计划、迭代意向表等步骤,目的是为了更好地管理项目的进度和资源。 - **迭代计划**:团队需要在每个迭代开始时明确目标和任务清单。 - **迭代意向表**:用于记录每个迭代的计划和结果,...

    火星人敏捷开发手册 2011-12-31

    - **迭代计划会 (Sprint Planning Meeting)**:在每次迭代的第一天,团队成员会与产品负责人一起召开迭代计划会议,讨论本次迭代的目标、任务划分和优先级排序。 - **每日立会 (Daily Stand-up Meeting)**:迭代期间...

    IT项目管理-计划-进度计划的关注点(1)

    在IT项目管理中,制定进度计划是一项至关重要的任务,它涉及到项目的成功与否。首先,我们要明确进度计划并不是追求理论上的最优,而是要确保其可行性和对项目目标的满足。在实际操作中,WBS(Work Breakdown ...

    火星人敏捷开发手册 2012-08-15

    迭代计划是在每个Sprint开始时制定的详细计划,它列出了将在该Sprint中实现的具体任务。这个计划是基于团队的能力和当前的产品待办事项列表。 **迭代意向表** 迭代意向表是一个工具,用于记录团队在当前Sprint中的...

    火星人敏捷开发手册 2012-05-06

    敏捷计划涉及制定短期和长期的目标,并通过迭代的方式逐步实现这些目标。 - **敏捷计划流程**:包括确定迭代周期、估算工作量、定义完成的标准等。 - **迭代计划**:每个迭代开始时,团队需要规划在这个迭代中要...

    某敏捷开发框架专业版7.0.rar

    - **计划会议**:团队一起确定迭代的目标,排列优先级,制定工作计划。 - **开发迭代**:开发人员根据计划进行编码,同时进行持续集成和自动化测试。 - **评审会议**:展示迭代成果,收集反馈,准备下一个迭代的...

Global site tag (gtag.js) - Google Analytics