每天积累一点，一年后你会发现，自己变化很大

负责软件项目管理有段时间了，偶然得到一本讲scrum的书，摘出了一些自己看得懂的文字。核心价值观个体和互动高于流程和工具；工作的软件优先于文档客户合作高于合同谈判变化优先于计划scrum的角色scrumMaster：scrum专家项目负责人：管理项目的开发开发团队：实际开发项目一些思想及早交付有价值的软件；随时面对需求变化，通过敏捷过程掌

SOW是对项目提供可交付成果的说明。一份概要，在很高层次上说明项目用途、范围和途径。是客户与供应商间的高层共识。SOW是项目的最初输入，由项目外的发起人或客户提供。项目范围说明书最主要的是说明项目的主要目标，由项目团队制定，干系人共同认可。包括六个方面的内容：……实例：http://wenku.baidu.com/view/50731e6fddccda38376baf5a.ht

4.     从系统实现角度进行优化4.1    在可移植性和性能之间进行权衡论文[16]主要针对HDFS进行了优化，它分析了HDFS性能低下的两个原因：调度延迟和可移植性假设。（1） 调度延迟Hadoop采用的是动态调度算法，即：当某个tasktracker上出现空slot时，它会通过HEARBEAT（默认时间间隔为3s，当集群变大时，会适当调大）告诉jo

开始聊mapreduce，mapreduce是hadoop的计算框架，我学hadoop是从hive开始入手，再到hdfs，当我学习hdfs时候，就感觉到hdfs和mapreduce关系的紧密。这个可能是我做技术研究的思路有关，我开始学习某一套技术总是想着这套技术到底能干什么，只有当我真正理解了这套技术解决了什么问题时候，我后续的学习就能逐步的加快，而学习hdfs时候我就发现，要理解hadoop框架

在Hadoop中，常用的TextInputFormat是以换行符作为Record分隔符的。在实际应用中，我们经常会出现一条Record中包含多行的情况，例如：123doc>..../doc>此时，需要拓展TextInputFormat以完成这个功能。先来看一下原始实现：Java

作为技术人员，我们以往更多的关注的是技术，但是在做个多年后，发现做正确的事比正确的做事更重要，而软件中需求的好坏就很大程度决定了你这个 软件是否正确，需求确定后不管你如何实现，功能给客户直接带来的价值远远比技术直接带来的价值要高。鉴于需求的重要性，所以后续我将陆续写一些需求相关的博文和大家一起学习探讨，扩充开发人员的需求知识，提高我们应用需求到开发的技能。本篇将从下图所示的软件需求的三个层

作为技术人员，我们以往更多的关注的是技术，但是在做个多年后，发现做正确的事比正确的做事更重要，而软件中需求的好坏就很大程度决定了你这个软件是否正确，需求确定后不管你如何实现，功能给客户直接带来的价值远远比技术直接带来的价值要高。但是需求带来的问题一直是各个软件公司项目失败的首要原因，因此需求是很复杂的，我们希望能在不断地学习和实践中不断地理清需求、提高需求分析能力。 软件需求包括3个不同的层次

曾经有项目组拿着用户编写的原始需求就开始开发，随后状况不断，一次令人崩溃的研发过程。拿着用户编写的原始需求，编写我们自己的需求规格说明书，之所以重要，就在于用户编写的原始需求，是脱离了技术实现，编写的一份十分理想的业务需求。理想与现实总是有差距，我们之所以要编写自己的需求规格说明书，就是要本着实事求是、切实可行的态度，去描述用户的业务需求。那些不可行的需求被摒弃，或者换成更加可行的解决方案。这就是

Requirements Level Classification（需求的分类）To deal with the diversity in requirements types, Sommerville (2005) suggestsorganizing them into three levels of abstraction: User requirements

上图是需求工程的组成部分，从图中可以看出，需求工程划分为两个部分：需求开发和需求管理。需求开发又分为需求获取（Elicitation）、需求分析（Analysis）、编写规约（Specification）和需求验证（Validation）。需求管理又分为基线管理、变更管理、需求跟踪。下面我将分别介绍一下上面各个主要组成部分主要的工作内容，以便那些不熟悉需求的人员读后能够从总体上把握需求所涉

企业架构、业务分析、软件产品线、产品管理，这些内容如何组织在一起发挥更大的作用，这是我2011年在中国软件技术大会上做的一个分享。PDF限期提供下载：http://down.51cto.com/data/941446

这个计划看看吧 以后也许用得着

软件需求是(1)用户解决问题或达到目标所需条件或权能(Capability)。 (2)系统或系统部件要满足合同、标准、规范或其它正式规定文档所需具有的条件或权能。 (3)一种反映上面(1)或(2)所述条件或权能的文档说明。80年代中期，形成了软件工程子领域——需求工程(requirement engineering, RE)。从1993年起每两年举办一次需求工程国际研讨会(ISRE)，自1994年

看后面两字的区别，应该能够感受出来吧，一个是分析，一个是说明。举个例：对于一个用户建议的需求，它说它希望添加某个功能。那么该做的第一件事情就是去‘分析’，为什么用户需要这个功能，这个功能的意义在什么地方，我们该不该添加功能，用户需要添加这个功能的真实目的是什么，这就是需求分析。需求分析做完后，那么就要筛选需求，然后针对需求优先级排序，决定做什么功能，这个时候，就该写需求说明，说清楚这个

软件需求包括3个不同的层次――业务需求、用户需求和功能需求。除此之外，每个系统还有各种非功能需求。 业务需求（Business requirement）表示组织或客户高层次的目标。业务需求通常来自项目投资人、购买产品的客户、实际用户的管理者、市场营销部门或产品策划部门。业务需求描述了组织为什么要开发一个系统，即组织希望达到的目标。使用前景和范围（vision and scope）文档来记录业务

篇博文属于对软件测试领域的科普篇，关于软件测试领域，名词颇多，发现有许多测试新手混淆概念，甚至有不少招聘要求中对各种软件测试相关的名词乱用，所以，这里汇总测试相关的名词，也许能理清你对各种名词的概念。 根据项目流程阶段划分测试                                                                         

需求管理是软件开发全生命周期重要的一个环节，我们每个人都知道它的重要性，但是要真做做好并不简单，我也写了一本在线电子书业务分析与需求.pdf来讲解需求相关内容。对于每种技术和方法，就像以前我写过的企业架构成熟度模型（EAMM）的一样，我们都不可能一下子就精通，而是按照一种学习的曲线进展，本篇本篇主要介绍一下需求管理成熟度的六个级别。级别0：没有需求（no requirements）

项目范围管理，包括为成功完成项目所需要的一系列过程，以确保项目包含且仅仅只包含项目所必须完成的工作。范围管理首先要定义和控制在项目内包括什么、不包括什么。通常包括制定一个项目范围管理计划，以规定如何被定义、检验、控制范围、创建与定义工作分解结构（WBS）；创建工作分解结构（WBS），编制一个详细的项目范围说明书作为将来项目决策的基础；将项目的主要可交付成果和项目工作细分为更小、更易于管理的部分；其

范围说明书理论http://blog.sina.com.cn/s/blog_6fe5e1c30100nk3i.html声像档案业务信息化项目初步设计范围说明书http://dag.mca.gov.cn/article/xxhjs/200802/20080200011743.shtmlXX公司ERP管理系统项目实施范围,目标和方法http://wenku.

保管利用室声像档案业务信息化项目　　初步设计范围（项目需求）建议书　　版本 　　文档编号： SXXT-2008　　当前版本： 1.0　　修改日期： 2008年2月15日　　拟稿人： 李航航　　　　一、项目背景　　随着我馆档案资料信息化工作的逐步展开，民政数字档案文献馆已初具雏形，各项信息

如实际工作中耳熟能详的集成产品开发IPD流程包括：售前开发流程MM：了解市场 - 细分市场 - 产品组合分析产品开发流程：概念 - 计划 - 开发及测试 - 验证 - 发布端到端交付流程：立项 - 投标 - 合同签订 - 工程准备 - 工程施工 - 合同关闭软件开发分为：需求 – 概要设计– 详细设计 – 编码 – 验证– 发布

《人月神话》这本书几年前就听别人说是本很经典的软件开发方面的书，这本书的成功之处在于他思想的前卫性，以至于不只是软件行业的人在读。现在终于找到读他的理由了，可以感受一下大师的杰作。在读之前我已经读过了《软件工艺》和《极限编程》，为什么留到最后读人月神话呢？主要是因为我觉得一本能够流传30年还被人们津津乐道的书，肯定是本学要好好细读的书，所以留到了最后。按照前两篇读书笔记的惯例，前面几段是一些我读书

1、产品（尤其是耗时较长，投入较多的产品）需要面向市场，面向未来，而不是只面向目前的客户需求。2、产品需要把“概念完整性”作为设计中最重要的因素来考虑，各个部分应该拥有一致的概念3、产品应该更多的考虑生命力和可扩展性，保证将来在其基础上生长出新的功能（枝叶），保证在一个较长的时间内，依托现有架构上稍作修补，即能应对各种变化的需求4、产品从需求到设计、代码、测试，包括产品包和

下面的文章是第一章和第二章的主要观点，后续章节的我回头再发。看这篇文章能够迅速了解Brooks的思想。 另外一个需要大家仔细考虑的就是，Brooks的《人月神话》是在几十年前写的，在软件行业发展这么多年后，各方面的情况都发生了翻天覆地的变化，那么，Brooks的哪些观点已经不符合当前的情况了呢？我们又能提出哪些新问题，作为对《人月神话》的一个与时俱进的补充呢？  

Brooks的观点拿到现在，不一定都是金科玉律，但是我们得分析，哪些还是客观规律，必须遵循；哪些需要与时俱进；我们应当对Brooks的观点有所增益。 第4章 贵族专制、民主政治和系统设计 4.1 “概念完整性是系统设计中最重要的考虑因素”。       我的理解：概念完整性是系统的一个最重要的问题，但是好像在身边做开发这个领域，对此予以充分关注的很少。4.2

此文章转贴自原著,因为高度概括了《人月神话》这本软件工程学的巨著所以作为读书笔记在此收藏。 

项目管理与软件开发的质量、效率、最终成果息息相关，本文主要讲述软件项目的风险评估、成本预算、客户沟通、需要分析、开发管理、成品交付等多个流程。在现今国内的项目的管理形式十分零乱，对管理欠缺重视，以致很多项目因为失去管理而最终折腰。很多的实战形人才只重视于开发环节，而对其他的流程欠缺认识（包括本人），因而导致项目欠缺有条理的、阶段化的管理。本人是一个典型的只重视开发的管理者，在多次的教训

项目管理十大知识领域和47个过程

岗位职责： 1、负责系统架构工作，负责运营支撑系统和交易服务系统的架构设计； 2、负责沟通，并形成技术解决方案和应用架构； 3、从事部分核心代码的编写，带领软件工程师攻克技术难关，指导和培训技术工程师； 4、参与系统的需求调研和需求分析，准确地将业务需求转化为设计需求。 5、 编写技术文档，制定技术规范，对设计系统的最终性能和稳定性负责岗位需求：

版本号　1.3.4-beta-2　该怎么理解？ 1 - 代表“主版本”，表示项目的重大架构变更 3 - 代表“次版本”，表示较大范围的功能增加和变化，但总体架构未变 4.- 代表“增量版本”，一般表示重大Bug的修复或功能的增强 beta-2 -  代表“里程碑版本”，表示当前的开发已经完成了某个里程牌，但还未稳定 抄自《Maven实战》

上篇敏捷开发之 4句敏捷宣言中讲了敏捷开发的价值观, 从这些价值观中可以引出下面的12条原则，它们是敏捷实践区别于重型过程的特征所在。在Agile Software Development － Principles,Patterns,and Practices（中文书名： 敏捷软件开发－原则、模式与实践）中对这12条原则分别进行了阐述，这里我就不重复解释书本的内容了，将从我个人的理解去讲解这些

1.范围管理：定义和控制哪些工作应包括在项目内，哪些不应包括在项目内。 具体过程有：    a. 收集需求。主要输出有“需求文档”和“需求管理计划”（规定如何分析、记录和管理需求）    b. 定义范围。主要输出有“项目范围说明书”    c. 创建WBS（工作分解结构）    d. 核实范围（Verify Scope)，即验收。    e. 控制范围：监督范围状态、管理范

在刚开博客时就想开这么一个随笔分类, 但是一直拖延到今天才开, 一个很重要的原因就是我怕我不能够坚持下来。    一、为什么要开这个分类    作为编程狂热爱好者中的一份子, 笔者深切感受到了英语不好在学习道路上的阻碍, 因此十分羡慕那些英语好的朋友, 古语云:"临渊慕鱼，不如退而结网。", 有了阻碍不能停止不进, 而要想尽一切办法铲平学习道路上的一切"拦路石"。       

http://chenjianjx.iteye.com/category/34214

简介 本文的目的是为应聘项目经理提供帮助。项目管理是升迁的途径，需要运用你过去的开发经验，而且薪水通常高于程序员。应聘项目经理的准备工作包括：复习一些常用的概念、术语，问自己一些在面试中经常问到的问题。学会运用一个或多个项目管理计划编制工具。通过以上的准备，将为你应聘这个职位增加信心。想好你要说的内容并准备回答涉及面广泛的问题是成功应聘的重要方面。与应聘技术职位不同的是，项目管理问题的

有国外开发者在 Quora 提了这个问题：“为什么软件开发周期通常是预期的两三倍？” 并补充问：“这是开发人员的错误？ 是管理失误？ 是因为做事方法不对， 或者说缺乏好的方法？还是说这就是软件开发流程的特点？” Michael Wolfe 在2012年1月28日给的回复，非常经典，截至我们发布时已有8016个赞。以下是译文。让我们先沿着海岸线，从旧金山（SF）走路去洛杉矶（LA），去拜访我

需求调研------------------------------------------------系统需求分析说明书:本文档主要描述项目包含的软件需求，明确项目的开发范围，并对系统的功能、输入输出数据和性能要求进行了说明，力求准确、清晰、完整的反映系统的软件需求，使任务提出者与开发者双方对项目的需求有一个共同的理解，使之成为整个开发工作的前提，并作为《概要设计说明书》的编写基础。

这里把流程图用PS重新绘制了一下：程序员的基本技能包括了以下几个方面：      1、项目实践   　 软件工程理论 　　 质量体系：ISO9001和CMM体系 　　 UML基本理论 　　 测试理论和测试工具使用 　　 加密理论和加密方法 　　 源代码控制工具使用 　　 说明书编写 　　 程序的安装和部署       2、专业技能 

项目管理五招四十二式　　要把大象装进冰箱，分成九块还是太大了，还得切小一点。因此在PMBok第四版中，又将九大知识领域细分为42个过程，这些过程可以分为5个组，启动过程组、规划过程组、执行过程组、监控过程组和收尾过程组。这五大过程组42个过程，就是武术中的招式，可以直接用来实战中了，因此不妨称之为“五招四十二式”。　　1. 五大过程组　　五大过程组与九大领域一样

除了维护，整个软件生命周期都是围绕项目来展开的，从立项到产品发布与实施，在这个过程当中，项目管理的范围主要集中在三个P上：人员（people）、问题（problem）、过程（process）。 以下是项目管理者，通常是项目经理，在整个软件生命周期中所要做的事：一、项目立项1、项目建议根据招标书或合同、市场调研、项目组建议等提出《项目建议书》； 2、可行性分析项目建议