读书笔记——《构建之法》

谢谢大家能来看我的博客,这是我第一次写博客,大概也会石沉大海吧。但我会逐渐成长,写出更优秀的博客。

那么下面开启正文吧。

  《构建之法》一书面向初级程序开发者,讲述个人开发、小组开发、团队开发中所要注意到的问题。有助于本学期软工课程的机会,我第一次能够担任一个较大小组(8人)的组长,并带领大家完成自己的小项目。但我深知自身的管理知识是非常贫乏的,又因本书章节很多,所以我特别挑选了几个章节借鉴经验,并且遴选了最有意义的两个章节将精华部分记录下来与大家分享。

5团队和流程

团队模式问题是由人数渐增而产生的,2、3人的团队大多不需要多少事前规划就可以没有多少冲突地将事情解决,而人数渐增所带来的角色、任务分配问题几乎无法避免。然而各种团队模式和开发流程都是优劣并存的,如何选择取决了我们所要处理的问题以及队员们的水平

1、团队模式:软件团队有各种形式,适用于不同的人员和需求,有几种较为流行的模式及其优劣如下:

1)主治医生模式:首席程序员负责处理主要的设计和编码,其他人从各个方面协助其工作。

优:最大限度发挥首席程序员的能力。

劣:“明星”也是人,也会受伤、犯错误。

评:如何让团队的利益最大化,而不是“明星”的利益最大化?(IBM SYSTEM 360)

2)社区模式:由许多志愿者参与,每个人参与自己感兴趣的项目,大部分人不拿报酬。

优:众人拾柴火焰高。

劣:如果大家不愿拾柴或柴火质量差,最后火就灭了。

评:成功的社区项目需要很严格的代码复审和质量控制。(Linux操作系统)

3)秘密团队模式:一些软件项目在秘密状态下进行,别人不知道他们具体在做什么。

优:团队内部有极大自由、较高热情、较少外界干扰。

劣:士气会随着时间推移而下降。

评:若发挥得好,很大的驱动力能让团队发挥超高的效率。(苹果研发Macintosh之后的系统)

4)交响乐模式:某个软件领域处于稳定成长阶段的时候,许多大型开发团队会采取。

优:门类齐全、各司其职。

劣:进行的都是很有经验的项目。

评:适合大规模的,有明确任务细分的软件工程。(Office97~2013…)

5)功能团队模式:具备不同能力的同事们平等写作,共同完成一个功能(Dev、UX、AQ、PM)。在一个功能完成后,这些人又重新组织,共同完成下一个功能。

优:每个小组都是一个有自主权的单元,自由度高而带来了开发时的高效。

劣:零散的小团队就要求团队间需要频繁的交流,从而一定程度上降低效率。较高的自由度不适用于一些等级制度森严的公司。

评:很多公司最后都会演变为这一模式,能充分利用每一个人的能力,整体团队分工又不死板。(FORTRAN语言项目)

2、开发流程:一群人一起开发软件,必定需要有一定的流程,否则一窝蜂地毫无章法地干,最后有可能做成,但也是一堆没有意义的程序。开发流程的选择关乎到软件开发的效率容错程度开发周期对风险的规避能力

1)瀑布模型:将硬件开发领域的分析->设计->实现->销售->维护运用到了软件工程中,先有一个模拟版本,在此基础上收集反馈,再走一次流程,最后交付最终版本。

优:1)各个阶段非常明晰,更容易把握项目的进展。

2)不需要频繁的交流。

劣:1)最终产品出现过晚,各个阶段相互独立,难以应对客户变化的需求。

2)各个过程难以回溯,但软件生产过程中需要时时回溯。

评:适用于客户要求非常稳定、技术人员较为分散、团队成员对所用的技术非常熟悉的情况。

2)统一流程:在系统的主要需求和架构明确之后,软件团队进入了一个不断演进的循环中:【开发->发布->听取反馈->根据反馈做改进】。为了早日听取客户的意见,把产品最核心的功能用最小的成本实现出来,然后快速征求用户意见。

优:1)能尽快地听取客户的意见,及时纠正软件开发的走向,规避风险。

劣:1)不适用于创造性、颠覆性的技术开发。

2)过早地发布可能带来更激烈的商业竞争。

评:这是很实用的流程,尤其适用于高校内尚不成熟的学生在规定时间内开发代码,不断地更新换代保证了时刻有可以交付的版本。当然这不是说就不适用于大企业的开发,微软的MSF模型正是来源于这一构想。

7实战中的软件工程

分析实战中的软件工程,莫过于分析最成熟的大公司的开发过程。本章选取了经典的微软公司的MSF模型进行分析,从它的基本原则、团队模型、过程模型入手,描述了微软开发团队内的开发精神、开发方式、开发过程

基本原则

一、推动信息共享与沟通

1、  在整个软件生命周期中使用团队协作服务器(GitHub或TFS),推动信息共享。

2、  借助于以上平台,团队成员之间的交流简明扼要即可。

3、保留并公开所有的信息,以便让项目进度和项目中存在的问题及时为所有人知道。

二、为共同的远景而工作

1、  在设定项目时,所有成员需要明确项目的预期目标,统一思想,否则团队内的分歧会随时间而累加,对项目的发展是很有害的。

三、充分授权和信任

1、  微软的MSF团队模型就是建立在两个原则之上:1)平等协作2)充分授权给团队和成员。

优:每个人都有权利估计并决定自己的任务需要的时间,所以人人都会支持计划和时间表。

劣:充分的授权可能会导致倦怠的滋生,不停地追踪会加重主管的负担。

评:在团队工具VSTS的帮助下,所有工作的进展都记录在案(这也是要推动信息共享的原因),任何延迟都会被及时发现。当然授权的管理理念又和一些集权类企业格格不入。

四、重视商业价值,提供渐进的价值

1、  首先,团队需要明确1)产品解决的问题2)为谁解决问题3)为什么你的产品能解决这些问题4)客户怎样付钱让你解决问题。因为项目需要重视市场和客户,技术是处于第三位的。

五、重视商业价值需要保持敏捷,预期和适应变化

1、项目需求的生存期是有限的,一旦开发过久,需求可能已经发生了很大的变化,而一个经验值是18个月。

2、客户的需求也是会变化的,我们需要预期变化而不是期望变化,这对开发流程和团队模式也带来了挑战。

六、在变化中需要抓住投资价值

1、投资讲究效率。我们并没有提质量第一,而是解决用户的问题第一,不惜一切代价达到最高质量往往错过了最佳的发布时机,而大型项目发布后追踪式的修补也是允许的。

2、投资讲究时机。为了尽量在产品中减少上述中的bug,1)在构想时充分讨论各种可能缺陷2)发展与测试应该并行发展。3)为迎合客户的时间需求,可以有针对性地取舍功能。

七、投资是长期的

1、团队的成长、成熟需要时间,生搬硬套大公司的开发模型与团队构成大多是南橘北枳。

团队模型:

在MSF团队模型中,每一个部分都是非常重要的,任何一个角色无法实现其目标都会危及整个项目。这也和微软内部的理念相契合,即:每个成员之间都是平等的。

这样的团队中,需要的是直言不讳,例如为了团队方案的争吵、因为产品质量而不赞同增加功能,每个人都参与设计规划、具体执行是指导思想,在对立中寻找共同利益,在冲突中达到平衡是团队的目标。

MSF过程模型

每一个项目都要经过一个生命周期,图示是MSF过程模型的生命周期简图,它吸收了瀑布模型基于里程碑的规划优势和渐进式交付的不断完善的长处。

优势:里程碑式的规划:团队里用里程碑来检查工作和同步各个角色的进度。

渐进式交付的不断完善:利于尽快交付产品,获得内外反馈。

劣势:各个阶段并不是理想化的,但可以通过设置缓冲区,不需要强求一律,但可以通过统一整体步骤,从而调节好团队间的依赖关系。

评:这是一个内外兼顾的模型,既考虑了外部的客户因素,又考虑了内部的成员间相互依赖的关系。

原文地址:https://www.cnblogs.com/Trinidad/p/8525959.html

时间: 2024-11-10 12:30:29

读书笔记——《构建之法》的相关文章

码农的产品思维培养第一节(人人都是产品经理读书笔记)

在前段时间,密集的推出Android学习记录之后,我觉得接下来的Android开发进入了一个精进演变的过程,革命性的东西略缺.每日更新特别新的东西也违背认知规律.所以以后关于Android方面的知识,碰到什么,然后记录什么. 而今天,在前一篇日志里面,我描述了我为什么要去理解"产品经理",从这一节开始,我要实施我的计划.所以,和Android记录一样,我要记录这个过程.对自己是一个回归总结吸收的过程,同时也希望能够帮助到更多的朋友,如果你也心存学习进取之心,如果你也如我一般疑惑未解心不

人人都是产品经理读书笔记(四)

补充:

《启示录:打造用户喜爱的产品》—— 读书笔记

这是一本非常不错的书,即使你可能只是一名开发工程师,也会有意想不到的收获! 如果你是一名产品经理,那就更不能错过了!不要留下遗憾! 这真的是一本很好的书,读每一遍都会有不同的收获,绝对让你震撼!我是会再读一遍或者N多遍的, 而能把这些内容转应用到实际中的人才是真正的高手,细细体会,在工作中好像已经有人在用了!惊讶!得抓紧时间了! 通过这本书,你将会知道一个合格的产品经理应该做什么,怎么做 本书主要讲解三个方面:人员.流程.产品 人员:产品从开始到完成过程中所有的参与者 流程:产品在开发过程中的所

产品经理学习笔记(二)------产品经理的工作职责(下)

二.产品经理的工作职责(下) 4.产品宣讲 ---宣讲对象:客服.市场.销售.运营.其他(开发进度到50%) ---宣讲目的:内部培训.获得认可 ---宣讲方式:内部推荐会(预测.演示.试用).注意控制(氛围.引导) ---宣讲目标:获得认可.帮助其他团队更好理解产品.协助其他团队更好开展工作 5.市场推广 ---对产品资料进行内容把关:网站.移动应用.印刷品等 ---主要针对:市场.公关.运营.销售 6.产品推出后的管理与迭代 ---运营数据的整理分析 ---深入一线体验产品 ---关注用户需

产品经理--读书静心的日子

入行教育,做教育产品工作,需要不断的进步. 一.了解产品开发.项目管理经验. 二.教育基础理论及相关知识. 小学阶段 (2016.2017不断的翻阅,有新的体会) 中学阶段(2018主攻方向)

谷歌和亚马逊如何做产品(读书笔记)

《产品经理》读书笔记

自从鼠标手犯病后,就刻意减少使用电脑的时间并且加强运动,目前已经完全康复,但是还是需要注意.因此更新博客的频率大大降低,但是也有时间多看看书,学习学习了! 最近看了<yes,产品经理>上下册,作者 汤圆 老马,文笔诙谐,把管理知识融入工作日常内容,浅显易懂,对于非管理专业的门外汉,还是不错的读物! 下面是摘抄的部分主要内容,个人认为比较有用的就记录下来. ------------------------------------------------ 制定产品价格策略的6步: 确定企业目标 冲

产品经理的那些事第一章读书笔记

1.一个产品经理的信仰:好产品能改变世界. 2.为什么要做产品经理:因为热爱,改变世界的方法有很多,技术可以改变世界,好的产品也可以,当然还有其他,但我热爱产品,一件事只有热爱了,才能持续不断的去做好,所以我选择了产品经理这条路. 3.产品是什么:产品是用来解决某个问题的东西. 4.产品经理为何而设:想要更了解产品与它面临的竞争情况,最终目的是要满足顾客的需求. 5.产品经理概念的进化: 分析: 1)行业形态不同:成熟行业vs.新兴行业 ①传统行业 概况:经过几十年乃至上百年的摸爬滚打,市场已经

【读书笔记】产品经理要做的事

文章链接:http://www.chanpin100.com/archives/44223 作为一个产品经理,不能只画图:产品经理更像是一个纽带,连接着各个环节,保持项目的正常运行. 在开始要做一个产品的时候,不能上来就画图,也不能告诉你需求就开始画图.应该先对需求进行筛选和挖掘:把伪需求去掉,挖掘出潜在需求. 1.分析产品的步骤:目标人群.使用场景.业务核心. 2.在团队中担任掌舵人,有目的的引导团队:激发团队灵感可以使用商业画布:客户分布.价值主张.渠道通路.客户关系.收入来源.核心资源.关

【读书笔记】神一样的产品经理(一)

 第一篇 产品经理 1.产品经理诞生的背景和价值 *很多入门级书里都会提到这一部分,本书讲了保洁诞生的第一个产品经理的故事. 2.很牛的产品经理(例子是乔布斯.郭靖) 1)几个重要特性:*影响力 *核心需求把控力 *创新力 *痴情力 2)产品经理的职责: *明确产品的目标用户群及其特征*获取.评估和管理用户需求*完成产品需求文档.产品原型和流程图*精通用户体验.交互设计和信息架构技能*项目管理.需求变更管理和需求验收*产品运营数据的分析和总结*提供运营.市场和销售等支撑 3)产品经理常犯的错误