scrum实践.docx资源-CSDN文库

scrum

5星 · 超过95%的资源需积分: 5 27 浏览量 2011-12-05 20:51:30 上传评论收藏 950KB DOCX 举报

资源详情

资源评论

二、实践小记：

．目前的团队刚好  人，且项目背景提供了可实践  的良好土壤；

小版本迭代：从项目启动开始，采用最多不超过３周的阶段计划；各个阶段根据情况发布系

统内部版本；

注意与传统方法区别，没有按固定周期月之类定计划，而是按目前能预见的周期内定计划。事

实也是如此，根据几个月的实践经验，最多只能预测三周。

每次阶段计划的时候：功能要求、、缺陷、用户提出的改进、具竞争力的功能及技术

升级等，先从各成员处收集汇总成为项目任务，并以半天为单位，预估工作量；集体讨论确定

优先级，然后排工作量，优先级低的任务被去除；

可惜的是无法做到让客户来帮我们定优先级；

不过期间我们通过“现场开发”（与客户方常驻一起）的方式，尽量让客户每天能看到系统，提

出修改意见；实践证明，这种开发效率的确要高很多。

每次阶段计划末：统计上个阶段每个人任务完成情况、团队阶段任务完成情况、成员工作自

我评估满意度等，并在一个较大周期（一般是  月  日个小阶段）后绘制统计曲线；

注意这个曲线一方面可作为项目绩效参考，一方面也能够清楚反映项目计划、进度控制中的各

种问题；

每周都进行有 － 次进度沟通（每次２０－３０分钟）：互相了解开发进度、遇到什么

问题如何解决，需不需要调整细节计划、内部调整；其中一次是随机的，一次是固定的，每周

五例会。

注意，在周五例会的时候，除了正常的工作沟通，还会进行心情指数、压力指数调查，并安排

相应的娱乐活动，关注每个成员的情绪状态和满意度；

关于心情指数，压力指数，工作满意度等也会在一个大周期后绘制统计曲线，作为项目阶段总

结，以持续改进；

其实每周例会最忌讳的是“公事公办”，应该尽量随意点，成为大家坦诚沟通的平台，谈工作，

谈生活，发牢骚，情绪宣泄越畅快越好；有条件就到室外去开。

后来我们在周例会中还加入了３０分钟技术交流时间，轮流有人自发就本周工作中的体会或经

验进行简短技术交流，不用花太多时间准备，但对团队知识积累非常有益（交流完了，资料要

求进入知识库）

核心任务，或项目中的关键路径，采取更紧凑的日进度沟通：通常是对里程碑任务和新加入

成员，采取日进度沟通。形式上不是“站立式会议”，多以该面对面随意聊天、或即时消息、个

人或团队工作日志进行。

个人更推荐随意的面对面聊天，更符合我们的习惯，主导该关键任务的人，每天早上来了，跟

任务相关的人打打招呼：

ｈｉ，搞定了没？”

这么快啊，你家伙很厉害嘛。。。”

哦，请假了啊，没关系的，先让帮你看看。。。”

通过这种很随意的方式，即达到了进度沟通的目的，又让大家觉得亲切如朋友。如果太严肃，

反而会隐藏很多问题。

持续改进：一般在 － 个阶段过后，往往会进入项目下一“新进程”，这个时候把前面所有

的进度统计、成员满意度统计、问题跟踪统计、技术问题等资料统统收集起来，进行分析总结，

并确定下一阶段的改进措施和工作目标。

问题和改进措施非常重要。一般的做法是让每个人都提  个认为团队工作最需要改进的方面；

然后集体再去排优先级，讨论可行的改进措施，然后制定成问题改进跟踪表（有个软件平台最

好），到下个进程再循环；

以我们的实践经验，只要前面做好了，这份总结很容易，半天就可以整理好。

总结中一个非常重要的方面，就是对成员的管理。这个大阶段内，有人进步非常快，有人一直

承担核心任务，有人总是赶在进度之前（是不是下次应多分配点任务），有人进度延迟较多，

满意度也不高（是不是个人情绪问题，生活中有什么事情影响了工作？）

针对这些情况，私下里或正式或随意的面谈沟通非常重要。不解决好人员问题，后面就有很多

不可控的风险。

人员管理为核心：团队成员角色识别、个性搭配、技术能力搭配、团队成员技术发展目标

和能力发展目标，及时面谈沟通等。

授之以渔，非授之以鱼”：任何能够让成员提高的事情，都要绝对遵循这个原则，哪怕相对要

花较长时间，但绝对是值得的；任何团队都会受制于很多现实条件，或许团队里面有  个猪八

戒，或许团队里面除了一个孙悟空，其他的都还不及沙僧，或是人员变更，这都是不可避免的，

所以要提前做好预测，识别团队角色上的缺陷，尽早进行培养，才不至于落得被动。

关于成员发展问题，以前的太简单了，好像成员就是发展为项目经理，这就叫职业规划了，其

实完全不对路。团队里面，当确定目标的时候，一定要从小处入手：如技术方面，某一方面的

技术能力获取突破成为公司专家；某一技术弱项快速提高，达到中等层次；知识面拓宽；

如工作能力方面：语言表达、沟通能力达到团队最好水平，文档能力达到团队最高水平；如角

色方面；发展为技术管理角色；发展为集成员和质量保证角色；发展为管理角色等。

这种发展目标实实在在，每个人都能很快看到自己的进步。当然，如果某位成员有成为项目经

理的机会，也要鼎力向上级推荐。

关于“结对”编程：在某些关键任务的设计、调试阶段，采用结对方法；

另外：新成员学习期间，每天有  小时的结对时间；项目进行单元测试期间，“变相结对”，

首先：交换测试（你实现的我测，我实现的你测），然后共同解决问题。

其他，针对项目经理：

你是否还在当“队长”，而不是当“教练”？你是否还在“管事”，而不是“管人”？你是否还在惧

怕你的成员能力超越了你？如果是，后面都不用看了，无法做到的。

要做到前面所说，前期铺垫是非常重要的，你的团队成员都接受了你？你是否已经初步

和他们建立了坦诚、同甘共苦的合作关系？

你是否真的花了 ％的时间在沟通和协调？

你的团队角色都选好了吗？你的工作是否得到了上级支持？

你是否总是主动向客户和上级汇报工作进展，书面的，面对面的？

）你是否持续用分解的小目标来鼓励士气？

是否经常在小目标达成之后通过各种方式激励大家（公布问题改进跟综表让大家随时看

到团队的进步？一起活动，上班期间半小时聊天休息，邀上公司领导一起聚餐）

）除了工作外，你是否了解每个成员的个人生活状况，并随时能灵敏感觉到部分成员的消

极情绪？你是否尽全力帮他们解决了工作上，甚至生活上的问题？

在去除某个资源障碍时，你是否真正做到了绝对客观和问心无愧？

大公司流程管的严，是难操作些。

高深”的理论向来都不能“武装”人，只能吓跑人，所以我从来没在我的上级，或是同事之间说过，我们要

“，或“ ，或“!"。

我说：“头儿，我有些内部管理的想法想在我们项目中尝试下。”

头儿说：“可以啊，没问题”。

我说：“上次项目总结大家提的问题不是都说‘计划赶不上变化’吗，那我们现在能不能尽量把周期缩短点，

能预见多长，就定多长的计划呢？”

大家点头：“对，是该试下”。

我说：“，你看看是不是我们俩在一起研究下这块的代码”？

然后结对开始了。

公司外部版本发布，要严格走流程，我们就不停采用内部发布，这样一点一点小版本就出来了。

项目管理遇到的问题总结

1. 问题描述：进度延迟较严重；阶段计划变更频繁

原因分析：

# 前期策划中，对工作量的估计不足，计划过于乐观；

# 项目计划的周期过长；

# 策划时对风险的预测不充分；未制定有效的应对策略；

# 项目组内部管理不是很有效，团队执行力不够；

# 项目人力资源配备不充分；结构不合理，新成员太多，梯队在较长一段时间内未形成。



改进措施：

# 为项目组制订目标规划$周期不超过半年；

# 作目标规划时，可根据预计风险制订分支计划；

# 计划尽量切合项目组资源配备实际；

# 工作量估计要多吸取已有经验，避免太乐观。

# 项目经理、骨干项目成员和文秘分工承担进度控制责任，避免因项目经理精力不足影

响进度控制



 问题描述：输出产品业务功能需求满足度低，输出产品可用性和易用性差；部分有效的时

间做了无用功。

原因分析：

# 需求开发不充分；

# 没有积极调研同行资料、进行深入分析；

# 设计工作做的不够，急于编码输出成果；

# 团队中只有较少成员具备业务知识，没有做到团队整体业务知识的提高

# 在进行详细设计和界面设计的时候，未做需求调研，闭门造车；详细设计时间短，不

够认真仔细，未做评审；

# 在业务经验不够充分的时候，没有认识到借鉴同类产品设计的重要性；

# 功能模块很多的情况下，规划不合理，开始阶段开发过于求快求多；对模块的优先级

和重要性排不够准确

改进措施：

# 出差调研，与客户深入交流和访谈，尽量获取较全面的用户需求；

# 积极调研同行资料、进行深入分析，并出分析报告，确认可吸收借鉴的地方，以及如

何吸收；

# 在整体设计、%& 设计和详细设计上专人负责，并尽早动手，做到重要文档都通过讨论

评审；重视业务知识汇总、业务知识库的归类；

# 在任何时候一定要先排定任务的优先级，永远做最当前最重要的事；

# 定期进行业务培训交流，重要部分组织考核；



 问题描述：跨部门协作和沟通不畅。

原因分析：

# 未意识到沟通管理的重要性；未制订沟通计划，建立定期沟通制度；

改进措施：

# 制订沟通计划，建立定期沟通制度；



 问题描述：项目测试组和开发组目标不一致，测试本身的质量无法衡量，导致版本改了一

轮又一轮，迟迟无法发布。

原因分析：

# 项目组与测试组没有建立共同的工作目标，测试组和开发组没有形成合力；

# 对测试的策划不充分，应该划分阶段测试目标和责任方；

# 测试方案未经评审、测试过程未进行有效跟踪和管理；

# 对测试重视程度不够；

# 测试人员配备和项目组测试工作量失衡；

改进措施：

# 测试组参与项目目标制订，建立双方认同的工作目标：很多情况测试的目标不是测到

一个  都没有，而是保证当前用户最需要、最常用的功能可用；

# 一定进行测试方案评审，在评审的时候对功能点测试优先级、测试通过的标准可进一

步审核，保证测试组的工作有效性；

# 若有不同类的测试任务，制订计划时分工明确，对项目组和测试组共同承担的测试任

务要有协调计划；

# 重视测试作用，测试与开发不要小于 ' 的比例



 问题描述：项目组内部长期较高负荷工作，计划永远完不成，热情和积极性逐渐消失。

原因分析：

# 计划不切合实际，只是让“领导和客户满意”的计划；

# 任务分配未经充分的讨论，或是讨论时对目标、任务、工作的认识层次不齐，无法真

正做到集体决定；

# 缺乏有效激励；

# 没有真正考虑到项目团队成员的“满意度”；

改进措施：

# 在周例会的时候，除了项目，一定调查下项目成员的满意度（如“心情指数”和“压力指

数”）；

# 建立有效激励的制度，物质上和精神上的；

# 管理分化，骨干成员承担管理责任；

# 管理一定要张弛有度，工作越紧张，越要给大家安排出适当的时间放松、调节；

剩余40页未读，继续阅读

评论收藏

内容反馈

lovepc1

2013-03-16

很好的资源，有些有意思的故事

scrum实践.docx

评论1

最新资源

scrum实践.docx

评论1

最新资源

相关推荐

Scrum开发流程最佳实践.docx

最新scrum执行文档.docx

scrum敏捷实践小抄本

敏捷流程scrum中的最佳实践之一每日站立会议

scrum实践-敏捷开发实践(转)

看板与scrum的实践（KanbanVsScrumAPracticalGuide）

敏捷开发中高质量Java代码开发实践.docx

敏捷开发指导书.docx

DevOps落地实践合集.zip

scrum_敏捷开发入门培训.docx

scrum敏捷开发方法和scrum的优势以及敏捷开发管理工具实践

scrum敏捷开发全景视图，流程，方法和最佳实践

敏捷(scrum)实践心得分享(1)

如何用leangoo看板工具完美实施单团队scrum敏捷开发(1).docx

CSDN_敏捷开发相关文档全收集_5

CSDN_敏捷开发相关文档全收集_2

CSDN_敏捷开发相关文档全收集_3

CSDN_敏捷开发相关文档全收集_1

CSDN_敏捷开发相关文档全收集_6

scrum:django rest 框架的轻量级 Django 书籍实践

CSDN_敏捷开发相关文档全收集_4

Qt 5实现串口调试助手 （源工程文件、0积分下载）

【SystemVerilog】路科验证V2学习笔记（全600页）.pdf

AutoSAR标准协议4.2.2

光伏-储能并网系统仿真.rar

NPPJSONViewer.zip

GD32替换STM32注意事项.pdf

XCP协议的规范文档

Qt 5实现串口调试助手（源工程文件、0积分下载）