构建之法——第五篇

上一周对于需求分析那一模块的内容还存留一点的疑问,经过一周的学习,弄清楚了以下几个方面。

对于软件需求的类型,以及利益相关者,我们根据不同的角度进行了以下的划分,对产品功能性的需求,对产品开发过程的需求,非功能性需求,综合需求;因此,对于软件产品的利益相关者而言,我们要弄清楚“他们想从软件中得到什么”。当获取用户需求以及进行用户调查的时候,我们可以采用焦点小组,深入面谈,卡片分类,用户调查问卷,用户日志研究,人类学调查,眼动跟踪研究,快速原型调研,A/B测试。

竞争性需求分析的框架,根据构建之法这本书里NABCD模型。我们可以根据此来进行功能的定位和优先级,N即Need,需求;A即Approach,做法;B即Benefit,好处;C即Competitors,竞争;D即Delivery,推广;对于功能分析的四个象限,杀手功能,外围功能,必要需求,辅助需求。

在我们开始进行估计之前,必须得分清楚几个概念,即目标,估计,决心。

在这一周的学习当中,不仅明白了需求分析模块,对于项目经理模块也有了简略的学习。

   对于项目经理我们可以简称为——PM;也有很多人会说,PM即Product Manager,Project Manager,Program Manager;针对于这一模块,我们主要介绍项目经理——Program Manager。由它的来历说明,我们有两个问题凸显出来:团队成员之间交流的成本急剧增长,有很多开发和测试之外的事情,需要专人负责。

那么它主要负责哪一些问题呢?对于交流成本,开发和测试搞不定的事情;那么对于PM而言,他对于一个团队最大,最独特的贡献是,带领团队达成最重要的目标,并保持团队的平衡。

  也有很多人就说了,作为一个PM,他的能力要求和任务是什么?我认为最重要的就是观察,理解和快速学习能力,其次就是分析管理能力,紧接着是具有一定的专业能力,自省能力我认为是每个职务中最重要的能力。

  以上就是我上一周学习的内容,在接下来的一周我会继续努力。

时间: 2024-08-25 11:01:11

构建之法——第五篇的相关文章

构建之法第五篇阅读笔记

今天将构建之法剩下的阅读完了,主要讲述如何组队一起设计一款软件软件设计与实现过程中,着实有这么一句话:在理论上,理论和实践是一回事:在实践上,理论与实践却是两回事.若是只是在理论阶段讨论着实践,就永远不知道想象中的目标实现难度与实际的目标实现难度差距有多么的大.这在课程结对编程中有所体现,也感触颇深,动手前将设计思路商量地基本完美,大多会遇到的问题也都通通解决,然而到了实现环节就出问题了,发现原来之前商量的方法并不可行,还有很多突发的问题没有考虑到……所以,有的程序可以“一拍”即得,有的不行.构

通读构建之法提出五个问题

我是通过`软件工程课`认识这本书的.老师要求读一遍构建之法.自己偷懒,其实没读完,大致翻了翻.翻看粗读后,初步有一下感受: 1. 这不是一本传统的教材,没那么多晦涩的概念. 2. 排版挺好看的,文章穿插图表,很精致. 3.语言幽默好懂. 在没读此书之前,只是觉得为什么软件工程里还会有这么多方法,软件工程不就是一些人合作做个项目就好了嘛?但现实远远没有想象的那么简单.<构建之法>一书一共有17章.每个章节讲述不同的重点.构建之法的每一章都是独立的子章节,并且涵盖了测试.项目经理.开发人员.用户体

构建之法第五章学习

今天我学习了<构建之法>第五章 团队和流程.首先我了解了写了再改模式(Code-and-Fix) 史蒂夫·迈克康奈尔(Steve McConnell)在这里提到了不少开发流程.第一个提到的开发流程.这个流程也有好处,不需要太多其他准备或相关知识,大家上来就写代码,也许就能写出来,写不出来就改,也许能改好.当面临下面的任务时,也许这个方法是有用的.但是,要写一个有实际用户.解决实际需求的软件,这个方法的缺点就太大了. 然后我学习了瀑布模型 当软件行业还在年幼的时期,它从别的成熟行业(硬件设计,建

构建之法 第五次心得

构建之法9.10.11章 第九章 学习了第九章之后,了解到了在一个项目中项目经理的重要性.生活中,无论什么团队工作,都需要一个领队,来掌控团队项目的发展,以及各个成员工作的分配.PM指Product Manager.Project Manager.Program Manager.这个章节主要讲了Project Manager即项目经理,PM要凭自己的能力,把用户的需求展现成其他成员能够理解和执行的语言.项目经理需要正确地协调团队内部外部,调配各部门资源和时间,有效进行风险管理,保证一个项目顺利按

构建之法——第六篇

经过一段时间的学习,我已学习到<构建之法>的第八章需求分析.本周我将继续学习第九章项目经理.第十章典型用户和场景.第十一章软件设计与实现. 第九章项目经理主要给我们介绍的是在企业里占据重要位置的项目经理.项目经理的作用就表现于他在企业中充当了中间人的角色.对外,项目经理需要与客户交流,发现用户需求,了解和比较竞争对手的产品,改进团队流程等.对内,需要把市场/销售人员那一套MBA的套路语言翻译成程序员能懂的规格说明书,这样可以大大节省开发人员的麻烦.而一个合格的项目经理,必须要具备观察.理解和快

构建之法第五六章读后感

邹欣老师的这本书,写得形象生动,第五章用体育运动等团队例子引出软件开发团队的形式.软件团队形式多样,适用于不同的人员与需求.团队可能会演变的模式有:主治医师模式.明星模式.社区模式.业余剧团模式.秘密团队.特工团队.交响乐团模式.爵士乐模式.功能团队模式.官僚模式等.开发流程模式有:瀑布模式.瀑布模型的各种变形.统一流程.老板驱动的流程.渐进交付的流程等.在过去的学习生活很少有团队合作的时候,看了本章很期待后续与大家团队合作,肯定会遇到很多困难,但只有把学到的运用到实际,知识才会学得更牢靠. 看

构建之法第四篇读后感

只有先清楚自己的用户是怎样的,才能编出一个好软件,而其中,典型用户和典型场景的分析非常重要. 用例也是很常用的需求分析工具,包括以下四个基本要素:标题,角色,主要成功场景,扩展场景等.而使用用例的原则主要有以下几点:1.通过讲简单的故事来传递信息  2.保持对全系统的理解  3.关注用户的价值  4.逐步构建整个系统  5.增量开发,逐步构建整个系统  6.适应团队不断变化的需求 一个好的软件,光实现用户要使用的功能是不够的,还要考虑用户的体验,所以用户界面(UI)就很重要.

重新回答构建之法的五个问题

问题一:这本书一直在强调合作,我不是很理解这个合作的具体含义,我认为的编程是项目经理安排任务然后每个人只要完成自己的任务就好.所谓的合作我认为的不外乎就是沟通.各种接口对接等等.可能会有会议讨论等等.但是合作是不是就是沟通确实不是很清楚. 答:沟通是信息传递的重要方式,只有通过沟通,信息才能在部门与部门之间.员工与员工之间得以传播.工作的开展在很大程度上来讲,就是通过从上到下的层层沟通采得以进行的.沟通是一个双向的行为,沟通双方一个要善于表达,一个要善于倾听,通过双方沟通.倾听.反馈再沟通.倾听

构建之法的五个问题

问题一:这本书一直在强调合作,我不是很理解这个合作的具体含义,我认为的编程是项目经理安排任务然后每个人只要完成自己的任务就好.所谓的合作我认为的不外乎就是沟通.各种接口对接等等.可能会有会议讨论等等.但是合作是不是就是沟通确实不是很清楚. 问题二:我承认文档的重要性.但是我认为更重要的还是代码的实现程度,也就是代码的复用性.可能这就是菜鸟级选手和软件工程师的区别吧. 问题三:对于一般的程序而言,只要客户要求的,或者客户的需求做到就可以了,那为什么还要做各种各样的测试.在我的主观印象里只要做好基于