第五章 团队和流程
5.2 软件团队的模式
主治医师模式、明星模式、社区模式、业余剧团模式、秘密团队、特工团队、交响乐团模式、爵士乐模式、功能团队模式、官僚模式
5.3 开发流程
①写了再改模式
②瀑布模型(Waterfall Model) 是一个项目开发架构,开发过程是通过设计一系列阶段顺序展开的,从系统需求分析开始直到产品发布和维护,每个阶段都会产生循环反馈,因此,如果有信息未被覆盖或者发现了问题,那么最好 “返回”上一个阶段并进行适当的修改,项目开发进程从一个阶段“流动”到下一个阶段,这也是瀑布模型名称的由来。
瀑布模型的适用范围:产品的定义非常稳定但正确性非常重要、产品模块之间的接口能很好地定性定义和验证、使用的技术很成熟、子团队不能做到频繁的交流。
③瀑布模型的变形:生鱼片模型(各个相邻模块像生鱼片那样部分重叠)以及大瀑布带着小瀑布(各个子系统统一到最后进行系统测试)
5.4 统一流程RUP
统一流程Rational Unified Process,团队的各种成员在一个复杂的软件项目中的不同阶段做不同的事。这些不同类型的工作在RUP中叫做规程或者工作流。简介:
业务建模、需求、分析和设计、实现、测试、部署、配置和变更管理、项目管理。
分为四个阶段:初始阶段(达到生命周期目标里程碑)、细化阶段(达到生命周期结构里程碑)、构造阶段(达到初始功能里程碑)、交付阶段(达到产品发布里程碑)
第六章 敏捷流程
6.1 敏捷的流程
①敏捷开发原则:
(1)尽早并持续地交付有价值的软件以满足顾客需求
(2)敏捷流程欢迎需求的变化,并利用这些变化来提高用户的竞争优势
(3)经常发布可用的软件,发布间隔可以从几周到几个月,能短则短
(4)业务人员和开发人员在项目开发过程中应该每天共同工作
(5)以有进取心的人为项目核心,充分支持信任他们
(6)无论团队内外,面对面的交流始终是最有效的沟通方式
(7)可用的软件是衡量项目进展的主要指标
(8)敏捷流程应能保持可持续的发展。领导、团队和用户应该能按照目前的步调持续合作下去
(9)只有不断关注技术和设计,才能越来越敏捷
(10)保持简明——尽可能简化工作量的技艺
(11)只有能自我管理的团队才能创造优秀的架构、需求和设计
(12)时时总结如何提高团队效率并付诸行动
②敏捷流程概述:找出完成产品需要做的事情→决定当前的冲刺(Sprint)需要解决的事情→冲刺(冲刺期间每天开每日例会)→得到软件的一个增量版本并发布
6.3 敏捷的团队
自主管理:自己挑选任务、自己提出改进并实施改进
自我组织:每个人联合起来对项目负责
多功能型:每个人都全面负责,自己搞定规格说明书,和别人沟通,自己搞定测试
6.4 敏捷总结
在迭代开始时,团队审视摆在他们面前的任务,选择他们认为可以在迭代期间完成的那些任务(Plan)。然后团队独立地尽最大努力完成这些任务(Do)。在迭代结束时,团队给利益关系人展示成果(Check),并对开发流程进行调整(Act/Adjust)。
这里有一些实践者的经验教训:
(1)敏捷宣言表明的是一些优先级,不必当作圣旨或者教条来争论。
(2)Scrum Master不是一个官,而是一个没有行政权力的沟通者,就像微软的PM那样。他/她同时还要在团队中做具体的工作。直接把原来的“经理”变成Scrum Master,大多行不通。
(3)一些项目需要很多暗箱操作和政治角力才能搞定,Scrum会把这些矛盾都摆到明处。这有好处,也有风险。
(4)在复杂的项目里,要让一线团队成员做决定。
(5)创业公司的团队其实经常是运行在Scrum 的模式中(只不过大家太忙,没工夫论证自己到底有多么Scrum)。
(6)在Scrum计划阶段的估计不是一个“合同”,领导们不要把它当成一个合同。估计总是不准的。坚持短期的Sprint,这样即使不准的估计也不会有大的损害。
(7)不要和管理层谈“流程”,他们只关心“结果”。
(8)在大型团队、跨地区的团队,或者复杂项目中,Scrum并没有非常完美的答案,Scrum的创始人也承认这一点.