项目启动会议开始, 项目经理拿出自己的项目计划信心满满的想要告诉大家接下来的项目实施应该如何展开. 可是刚刚开始就被需求分析师和产品经理质疑:

模块划分不合理,应该按照业务场景制定发布计划.

这意味着项目经理原本按照功能和系统模块制定的计划被90%的推翻.

为什么会有这样的问题?

项目经理的技术出身导致其对项目的scope估计无可避免的过早考虑到设计(甚至是代码重用)

而产品经理和需求方更多关注的是产品提供的feature,或者说一个"完整的"功能点.在scrum里我们称为"用户故事".

而项目经理的项目计划又有两份,一份是给"上面"看的,也就是用户,产品经理,需求方;而另一份是给"下面"看的,也就是系统设计/开发人员.而这里显然是第一份.因为关注点不同.

这也是项目驱动(project-oriented)和产品驱动(product-oriented)的交付方式和内容的不同.

项目驱动更多的是在整个项目结束后交付完整的代码和所有的功能.因为项目(开发)的周期相对较短.

而产品驱动则是要在不同的阶段都要交付feature和功能(当然你觉得每个阶段都可以用项目驱动来做也没什么不妥),同时还要兼顾整体的系统设计和重用性/维护性等问题.因为产品(开发)的周期通常较长,夜长也就梦多了,开发周期可能同时伴随的维护任务和设计重构.在产品驱动模式中,项目经理需要更好的平衡能力和全局掌控能力.

敏捷宣言推崇:
1.个人与交互重于开发过程和工具
--敏捷开发小组认为: 一个由使用普通工具的优秀人员组成的/运行良好的小组,总是会比由使用优秀工具和过程的普通人组成的,紊乱的小组做的更好.
--我们花了太多的时间试图定义一个开发过程,以便把人当作机器上可被替换的齿轮,却没有取得成功
2.可用的软件重于复杂的文档
--每次迭代结束时获得一个稳定的,逐渐增强的版本,比便更频繁的收集对产品和开发过程的反馈
--将反馈回馈到开发过程,以保证开发小组始终在处理最有价值的功能
3.寻求客户的合作重于对合同的谈判
--这是一个希望,也许不是开发小组可以控制的 --我认为
4.对变化的响应重于始终遵循固定的计划
--最终的目标!!是向项目客户和用户交付更多的价值(或者更多的必要特性,更合理的时间,更小的成本)
--而切记计划是为目标服务的 --我认为

基于活动而不是基于功能进行规划 (是不好的!)
基于活动的规划分散了我们对功能的注意力,而功能才是衡量客户价值的担忧
忽视关于用户最终需要什么的不确定性,会导致虽然然按时完成了项目,却没有包含在制定计划以后发现的那些重要功能.

敏捷开发小组的主要工作方式:
1.作为一个整体工作
2.按短迭代周期工作
3.每次迭代交付一些成果
4.关注业务优先级
5.检查与调整

如何分割用户故事
1.按照数据边界分割
按照用户故事所支持数据的边界分割大型用户故事
2.按照操作边界分割
把大型用户故事分割成独立的建立/读取/更新/删除操作
3.去除横切考虑
为用户故事建立两个版本:一个具备对横切考虑的支持,另一个不具备这种支持.
4.不用满足性能限制
5.分割具有混合优先级的用户故事
6.不要把故事分割成任务
而是寻找一个方法来让曳光弹穿过整个故事
7.避免相关变化的诱惑
在一个适当规模的功能中增加相关变化会把事情弄糟,除非这些变化具有同样的优先级
8.组合用户故事
对按照2周一次的迭代周期工作的开发小组来说,合适的做法是3~5天做完

速度驱动的迭代规划步骤
调整优先级/确定目标速度->确定迭代目标->选择用户故事->分解任务->对任务估计

承诺驱动的迭代规划
调整优先级->确定迭代目标->选择要增加的用户故事/把故事扩展成任务/对任务估计->要求小组作出承诺<->移除一个用户故事(如果无法承诺)->迭代规划完成(可以承诺)

阅读和谈论scrum,与具体实施它是两码事.scrum必须先就位,才有机会被充分理解.
-scrum敏捷项目管理 c4

--也许这样翻译好一点，＂自我管理，自发机制，任务进度透明情况和自检＂
Powered by MoFire

作者只是以一个虚拟项目 - FUBAR.罗列出问题,实例和风险,而并没有提出他的解决方法.似乎FUBAR项目的这些问题并不是像常见的软件问题一样 - 用工具就可以解决. 很多情况下都是掺杂了一些政治因素.比如经理的升职,表面文章,以及一些人情因素,比如情绪化,leader缺少个人魅力...有几条比较"伪",过于政治了.

QUALITY OF WORK AND EFFORT(工作质量和投入)
问题:太多的东西要搞(算法设计,源代码,系统配置,设计架构文档,测试,缺陷跟踪,计划任务),太多而无法确保其符合标准和保证质量.
--其实这些问题可以通过流程化来避免,当然流程化还是需要很多文档.这个一直都是让人很头疼的问题.AUP似乎是一个方向 - 通过快速迭代,直接反馈,TDD来控制,同时减少不必要的artifacts.使用正确的工具和最佳实践,避免搞一些自己独有的东西.

PROJECT PLANNING AND EXECUTION(计划和执行)
问题:项目的计划和执行完全是建立在不现实/不可能的"政治考量"或美好愿望,而缺乏确凿依据(bottom-up grounding).必要和有用的事情反倒因为"没有时间"而被推迟或取消. -- 结果往往并没有因为取消这些事情而节约时间.
--这个应该是认知的问题,知识决定了是否可以在决定之前可以知道做这件事是否有价值.如果没有知识和经验,自然不会去冒险,"没有时间"是最好的搪塞.

QUALITY ASSURANCE AND PROCESS(质量控制和过程)
问题:质量控制(QA)的优先级总是很低.有过程却不遵守.缺少专门的人来评判软件是否是可接受的和管理产品发布.
--也是认知的问题,只看到表面的东西,而看不到潜在的可能.软件的复杂性导致软件很难被检验.而这个时候更应该重视QA而不是回避.觉得QA老是跟自己过不去.当然也有可能是QA太烂,让别人不得不忽略它们. 得!又是人和人的问题.

ARCHITECTURE(架构)
问题:缺少一个合理稳定的架构设计
--这个是老生常谈了.看架构师了.

APPLICATION PERFORMANCE(系统性能)
问题:架构设计时没有考虑到性能需求
--也看架构师的经验和能力

STAFFING(团队)
问题:大多数的人员不是很胜任,经验不足
--这个不是什么问题,有点像是借口.

PRINCIPLES(信念)
问题:开发者都被灌输:好心情,真诚,付出可以战胜一切.但真诚往往最终被用来评判缺乏责任感和承担后果.
--后面那句确实有点意思,有时候真诚反倒成为被别人利用.还是人和人之间的问题.难道真的无法避免囚徒困境吗?为什么会造就出这样的博弈??

INTELLECTUAL HONESTY(不明智)
问题:项目经理不愿意听到坏消息和问题,只愿意听好消息.
--也是人的问题.没什么意思,看人了.

查了一下wikipedia,FUBAR: fxxked up beyond all repair(recognition....)
"FUBAR has sometimes been used in software development in the almost opposite sense: "Fucked Up But All Right," meaning that the system design is fatally flawed, but works anyway."

有一句话记得比较清楚:对于一个项目,个体和交互胜过过程与规范
这应该是敏捷的粉丝说的,但是这句看似简单的话却包含很复杂的背景.
项目:什么规模的项目?
个体:什么样的个体?对个体有什么样的期望?
交互:什么类型的交互,怎样有效交互?
过程:那到底有还是没有?
规范:那到底是要还是不要?

简单的表示: 项目=ax个体+bx交互+cx过程+dx规范
而a,b,c,d就是每个人对上面那些问题的经验和理解.所以有的人是:

成功项目=超人个体+无交互+无过程+无规范

有的人是:
失败项目=超人个体+无效交互+cmmi+iso2000
或者
失败项目=普通个体+有效交互+agile+无规范

那失败到底是因为agile呢?还是cmmi?还是团队?总不能说,agile的时候就一定捆绑了超人程序员和有效交互吧,那还要agile干什么,我自己发明个process怕也照样成功.

敏捷本来就是从传统制造业的精益(lean)衍生到软件工程的概念.可能只是一个过程创新,可是却又很多人把它当成救命稻草,期望"以后敏捷了,就可以天天吃饺子了"...

关于敏捷开发我的经验是0.

Powered by ScribeFire.