没有合适的资源?快使用搜索试试~ 我知道了~
首页scrum实践.docx
scrum实践.docx
5星 · 超过95%的资源 需积分: 5 13 下载量 165 浏览量
更新于2023-03-03
评论
收藏 950KB DOCX 举报
实践小记 项目管理遇到的问题总结 几个项目管理问题及讨论 项目经理应该具备的能力和自我评估 客户沟通的一些体会 Agile与人生哲学 关于两个需求故事
资源详情
资源评论
资源推荐
二、实践小记:
.目前的团队刚好 人,且项目背景提供了可实践 的良好土壤;
小版本迭代:从项目启动开始,采用最多不超过3周的阶段计划;各个阶段根据情况发布系
统内部版本;
注意与传统方法区别,没有按固定周期月之类定计划,而是按目前能预见的周期内定计划。事
实也是如此,根据几个月的实践经验,最多只能预测三周。
每次阶段计划的时候:功能要求、、缺陷、用户提出的改进、具竞争力的功能及技术
升级等,先从各成员处收集汇总成为项目任务,并以半天为单位,预估工作量;集体讨论确定
优先级,然后排工作量,优先级低的任务被去除;
可惜的是无法做到让客户来帮我们定优先级;
不过期间我们通过“现场开发”(与客户方常驻一起)的方式,尽量让客户每天能看到系统,提
出修改意见;实践证明,这种开发效率的确要高很多。
每次阶段计划末:统计上个阶段每个人任务完成情况、团队阶段任务完成情况、成员工作自
我评估满意度等,并在一个较大周期(一般是 月 日个小阶段)后绘制统计曲线;
注意这个曲线一方面可作为项目绩效参考,一方面也能够清楚反映项目计划、进度控制中的各
种问题;
每周都进行有 - 次进度沟通(每次20-30分钟):互相了解开发进度、遇到什么
问题如何解决,需不需要调整细节计划、内部调整;其中一次是随机的,一次是固定的,每周
五例会。
注意,在周五例会的时候,除了正常的工作沟通,还会进行心情指数、压力指数调查,并安排
相应的娱乐活动,关注每个成员的情绪状态和满意度;
关于心情指数,压力指数,工作满意度等也会在一个大周期后绘制统计曲线,作为项目阶段总
结,以持续改进;
其实每周例会最忌讳的是“公事公办”,应该尽量随意点,成为大家坦诚沟通的平台,谈工作,
谈生活,发牢骚,情绪宣泄越畅快越好;有条件就到室外去开。
后来我们在周例会中还加入了30分钟技术交流时间,轮流有人自发就本周工作中的体会或经
验进行简短技术交流,不用花太多时间准备,但对团队知识积累非常有益(交流完了,资料要
求进入知识库)
核心任务,或项目中的关键路径,采取更紧凑的日进度沟通:通常是对里程碑任务和新加入
成员,采取日进度沟通。形式上不是“站立式会议”,多以该面对面随意聊天、或即时消息、个
人或团队工作日志进行。
个人更推荐随意的面对面聊天,更符合我们的习惯,主导该关键任务的人,每天 早上来了,跟
任务相关的人打打招呼:
hi,搞定了没?”
这么快啊,你家伙很厉害嘛。。。”
哦,请假了啊,没关系的,先让帮你看看。。。”
通过这种很随意的方式,即达到了进度沟通的目的,又让大家觉得亲切如朋友。如果太严肃,
反而会隐藏很多问题。
持续改进:一般在 - 个阶段过后,往往会进入项目下一“新进程”,这个时候把前面所有
的进度统计、成员满意度统计、问题跟踪统计、技术问题等资料统统收集起来,进行分析总结,
并确定下一阶段的改进措施和工作目标。
问题和改进措施非常重要。一般的做法是让每个人都提 个认为团队工作最需要改进的方面;
然后集体再去排优先级,讨论可行的改进措施,然后制定成问题改进跟踪表(有个软件平台最
好),到下个进程再循环;
以我们的实践经验,只要前面做好了,这份总结很容易,半天就可以整理好。
总结中一个非常重要的方面,就是对成员的管理。这个大阶段内,有人进步非常快,有人一直
承担核心任务,有人总是赶在进度之前(是不是下次应多分配点任务),有人进度延迟较多,
满意度也不高(是不是个人情绪问题,生活中有什么事情影响了工作?)
针对这些情况,私下里或正式或随意的面谈沟通非常重要。不解决好人员问题,后面就有很多
不可控的风险。
人员管理为核心:团队成员角色识别、个性搭配、技术能力搭配、团队成员技术发展目标
和能力发展目标,及时面谈沟通等。
授之以渔,非授之以鱼”:任何能够让成员提高的事情,都要绝对遵循这个原则,哪怕相对要
花较长时间,但绝对是值得的;任何团队都会受制于很多现实条件,或许团队里面有 个猪八
戒,或许团队里面除了一个孙悟空,其他的都还不及沙僧,或是人员变更,这都是不可避免的,
所以要提前做好预测,识别团队角色上的缺陷,尽早进行培养,才不至于落得被动。
关于成员发展问题,以前的太简单了,好像成员就是发展为项目经理,这就叫职业规划了,其
实完全不对路。团队里面,当确定目标的时候,一定要从小处入手:如技术方面,某一方面的
技术能力获取突破成为公司专家;某一技术弱项快速提高,达到中等层次;知识面拓宽;
如工作能力方面:语言表达、沟通能力达到团队最好水平,文档能力达到团队最高水平;如角
色方面;发展为技术管理角色;发展为集成员和质量保证角色;发展为管理角色等。
这种发展目标实实在在,每个人都能很快看到自己的进步。当然,如果某位成员有成为项目经
理的机会,也要鼎力向上级推荐。
关于“结对”编程:在某些关键任务的设计、调试阶段,采用结对方法;
另外:新成员学习期间,每天有 小时的结对时间;项目进行单元测试期间,“变相结对”,
首先:交换测试(你实现的我测,我实现的你测),然后共同解决问题。
其他,针对项目经理:
你是否还在当“队长”,而不是当“教练”?你是否还在“管事”,而不是“管人”?你是否还在惧
怕你的成员能力超越了你?如果是,后面都不用看了,无法做到的。
要做到前面所说,前期铺垫是非常重要的,你的团队成员都接受了你?你是否已经初步
和他们建立了坦诚、同甘共苦的合作关系?
你是否真的花了 %的时间在沟通和协调?
你的团队角色都选好了吗?你的工作是否得到了上级支持?
你是否总是主动向客户和上级汇报工作进展,书面的,面对面的?
)你是否持续用分解的小目标来鼓励士气?
是否经常在小目标达成之后通过各种方式激励大家(公布问题改进跟综表让大家随时看
到团队的进步?一起活动,上班期间半小时聊天休息,邀上公司领导一起聚餐)
)除了工作外,你是否了解每个成员的个人生活状况,并随时能灵敏感觉到部分成员的消
极情绪?你是否尽全力帮他们解决了工作上,甚至生活上的问题?
在去除某个资源障碍时,你是否真正做到了绝对客观和问心无愧?
大公司流程管的严,是难操作些。
高深”的理论向来都不能“武装”人,只能吓跑人,所以我从来没在我的上级,或是同事之间说过,我们要
“,或“ ,或“!"。
我说:“头儿,我有些内部管理的想法想在我们项目中尝试下。”
头儿说:“可以啊,没问题”。
我说:“上次项目总结大家提的问题不是都说‘计划赶不上变化’吗,那我们现在能不能尽量把周期缩短点,
能预见多长,就定多长的计划呢?”
大家点头:“对,是该试下”。
我说:“,你看看是不是我们俩在一起研究下这块的代码”?
然后结对开始了。
公司外部版本发布,要严格走流程,我们就不停采用内部发布,这样一点一点小版本就出来了。
项目管理遇到的问题总结
1. 问题描述:进度延迟较严重;阶段计划变更频繁
原因分析:
# 前期策划中,对工作量的估计不足,计划过于乐观;
# 项目计划的周期过长;
# 策划时对风险的预测不充分;未制定有效的应对策略;
# 项目组内部管理不是很有效,团队执行力不够;
# 项目人力资源配备不充分;结构不合理,新成员太多,梯队在较长一段时间内未形成。
改进措施:
# 为项目组制订目标规划$周期不超过半年;
# 作目标规划时,可根据预计风险制订分支计划;
# 计划尽量切合项目组资源配备实际;
# 工作量估计要多吸取已有经验,避免太乐观。
# 项目经理、骨干项目成员和文秘分工承担进度控制责任,避免因项目经理精力不足影
响进度控制
问题描述:输出产品业务功能需求满足度低,输出产品可用性和易用性差;部分有效的时
间做了无用功。
原因分析:
# 需求开发不充分;
# 没有积极调研同行资料、进行深入分析;
# 设计工作做的不够,急于编码输出成果;
# 团队中只有较少成员具备业务知识,没有做到团队整体业务知识的提高
# 在进行详细设计和界面设计的时候,未做需求调研,闭门造车;详细设计时间短,不
够认真仔细,未做评审;
# 在业务经验不够充分的时候,没有认识到借鉴同类产品设计的重要性;
# 功能模块很多的情况下,规划不合理,开始阶段开发过于求快求多;对模块的优先级
和重要性排不够准确
改进措施:
# 出差调研,与客户深入交流和访谈,尽量获取较全面的用户需求;
# 积极调研同行资料、进行深入分析,并出分析报告,确认可吸收借鉴的地方,以及如
何吸收;
# 在整体设计、%& 设计和详细设计上专人负责,并尽早动手,做到重要文档都通过讨论
评审;重视业务知识汇总、业务知识库的归类;
# 在任何时候一定要先排定任务的优先级,永远做最当前最重要的事;
# 定期进行业务培训交流,重要部分组织考核;
问题描述:跨部门协作和沟通不畅。
原因分析:
# 未意识到沟通管理的重要性;未制订沟通计划,建立定期沟通制度;
改进措施:
# 制订沟通计划,建立定期沟通制度;
问题描述:项目测试组和开发组目标不一致,测试本身的质量无法衡量,导致版本改了一
轮又一轮,迟迟无法发布。
原因分析:
# 项目组与测试组没有建立共同的工作目标,测试组和开发组没有形成合力;
# 对测试的策划不充分,应该划分阶段测试目标和责任方;
# 测试方案未经评审、测试过程未进行有效跟踪和管理;
# 对测试重视程度不够;
# 测试人员配备和项目组测试工作量失衡;
改进措施:
# 测试组参与项目目标制订,建立双方认同的工作目标:很多情况测试的目标不是测到
一个 都没有,而是保证当前用户最需要、最常用的功能可用;
# 一定进行测试方案评审,在评审的时候对功能点测试优先级、测试通过的标准可进一
步审核,保证测试组的工作有效性;
# 若有不同类的测试任务,制订计划时分工明确,对项目组和测试组共同承担的测试任
务要有协调计划;
# 重视测试作用,测试与开发不要小于 ' 的比例
问题描述:项目组内部长期较高负荷工作,计划永远完不成,热情和积极性逐渐消失。
原因分析:
# 计划不切合实际,只是让“领导和客户满意”的计划;
# 任务分配未经充分的讨论,或是讨论时对目标、任务、工作的认识层次不齐,无法真
正做到集体决定;
# 缺乏有效激励;
# 没有真正考虑到项目团队成员的“满意度”;
改进措施:
# 在周例会的时候,除了项目,一定调查下项目成员的满意度(如“心情指数”和“压力指
数”);
# 建立有效激励的制度,物质上和精神上的;
# 管理分化,骨干成员承担管理责任;
# 管理一定要张弛有度,工作越紧张,越要给大家安排出适当的时间放松、调节;
剩余40页未读,继续阅读
海豚的翅膀
- 粉丝: 0
- 资源: 159
上传资源 快速赚钱
- 我的内容管理 收起
- 我的资源 快来上传第一个资源
- 我的收益 登录查看自己的收益
- 我的积分 登录查看自己的积分
- 我的C币 登录后查看C币余额
- 我的收藏
- 我的下载
- 下载帮助
会员权益专享
最新资源
- 2022年中国足球球迷营销价值报告.pdf
- 房地产培训 -营销总每天在干嘛.pptx
- 黄色简约实用介绍_汇报PPT模板.pptx
- 嵌入式系统原理及应用:第三章 ARM编程简介_3.pdf
- 多媒体应用系统.pptx
- 黄灰配色简约设计精美大气商务汇报PPT模板.pptx
- 用matlab绘制差分方程Z变换-反变换-zplane-residuez-tf2zp-zp2tf-tf2sos-sos2tf-幅相频谱等等.docx
- 网络营销策略-网络营销团队的建立.docx
- 电子商务示范企业申请报告.doc
- 淡雅灰低面风背景完整框架创业商业计划书PPT模板.pptx
- 计算模型与算法技术:10-Iterative Improvement.ppt
- 计算模型与算法技术:9-Greedy Technique.ppt
- 计算模型与算法技术:6-Transform-and-Conquer.ppt
- 云服务安全风险分析研究.pdf
- 软件工程笔记(完整版).doc
- 电子商务网项目实例规划书.doc
资源上传下载、课程学习等过程中有任何疑问或建议,欢迎提出宝贵意见哦~我们会及时处理!
点击此处反馈
安全验证
文档复制为VIP权益,开通VIP直接复制
信息提交成功
评论1