文章标签 ‘项目管理’
2012三月29

提高Sprint计划会议效率之一:Scrum团队如何进行充分的理解需求?

Scrum实施近3个月来,Sprint计划会议最大的问题就是计划会议时间过长,其中一个两周的Sprint开了近6个小时左右,占用时间的主要环节是:需求理解(讲解)。如何让Scrum团队更好的理解需求,我们采取过两种方式:

2011十一月28

Scrum敏捷实践之第一个Sprint(2011年11月21日-11月25日)回顾会议记录

第一个Sprint时间:2011年11月21日-11月25日

2011十一月9

《走出软件作坊》读书笔记,老生重谈

《走出软件作坊》的这本书最开始拜读还是2009年,转眼近两年过去了,回头看看那时候做的读书笔记,结合自身这两年的情况,感慨良多,很多事情又若隐若现的重现了。以下是那时候做的笔记

2011八月9

项目开发过程大杂烩2011年8月8日

  1. 协作边界、权限的问题
    有些想当然了,总以为别人明白了你的意思,其实真的不明白,很多理解甚至是大相径庭,这个跟之前看到的一个沟通理论是吻合的
  2. 项目变化
    1. 让程序员参与需求分析、沟通
    2. 灌输责任意识,你自己做的同时出问题让别人无法使用,你应该比热锅上的蚂蚁还急才行啊。
    3. 技术实现与业务要求的平衡:可以让业务先跑起来,再逐步优化技术,罗马不是一定建成的。
    4. 小团队贯彻小步快跑的项目思想,快递迭代,盘子小了,可控性才能增强。
    5. 需要明确目标,“不择手段”完成目标,但不能沉迷在自己的世界中,你不是一个人在战斗
    6. 先自己寻求解决,这个是不必须的,但控制好时间
    7. 主动寻求帮助,项目组内部,技术内部
    8. 忘掉过去,不要被过去的一些不合适的开发、思考方式所束缚
  3. 技术人员技术本身
    1. 让程序员参与需求分析、沟通
    2. 基础概念理解:如传值、传引用、线程、异步、资源释放、事务等的概念理解不透彻,从代码结果上看,有些可能根本没有这个意识。
    3. 综合运用能力有待提高
    4. 调试发现问题的能力
    5. 善于做简单Console Demo来验证自己的技术点,而不是仅仅估计、猜测
    6. 关于开发人员的测试:发现可能根本就没有测试,一个简单的信息维护模板,在发布前,连增删改这个最最基本的测试都不到位不行的。
  4. 其他
    1. OA项目组的启用项目本身的问题系统来管理Bug,自己用了才知道,才能更好的做好。
  5. PS:这篇文字只是记录自己的工作中的一些随笔,可能对也可能不对,请辩证的去看。