软件项目与过程管理
15道烧糊大脑的苹果面试题
以下15道题是从求职论坛GlassDoor摘选出的真实的苹果面试题目：
1.桌子上放着一部老款iPhone。你所了解的iPhone使用的材料有哪些？
面试职位：产品设计工程师
苹果产品设计工程师的重要任务之一就是控制供应成本，以降低手机的价格。
苹果的手机定价非常具有竞争力，因此面试者必须懂得如何在特定成本区间内设计产品。懂得材料及其性质能够帮助设计师在维持低成本的同时设计出更好的产品。
2.形容一下你平时使用苹果产品的情况。
面试职位：销售
如果你想销售苹果的产品，你最好已经是苹果产品的用户。
不用说，苹果当然不会雇佣一个从来没有使用过iPhone的人做销售。
3.如果有500台洗衣机被测试实验室认定为不合格，你如何找出不合格的原因以及解决办法？
面试职位：产品质量工程师
如果制造过程中出现任何故障，你可能会失去价值数相当于百台iPhone的收入–这个数字也有可能是数万台或数十万台。
如果你想担任产品质量工程师，那么请首先确认，不管出现什么问题，你都能发现故障并找出原因所在。尤其是当问题出现在供应链早期的时候，这一点更加重要。
4.在极其有限的资源环境下，如何在user-space框架下实现处理网络、文件系统、UI系统等的线程模型？
面试职位：软件工程师
编写一组代码并使之运行非常容易，但要让它高效率运行却很难。
尤其是如果你在为一款手机设计软件。你必须使用低功耗的芯片，以维持较长的续航时间。
5.你如何计算出中国供应给美国的苹果的数量？
面试职位：材料项目经理
面试官所指的是苹果。你懂的，一种水果。
但这仍然是一道相当基础的供应链题目。如果你要担任供应链管理职位，你需要清楚地知道供应商有哪些，他们能提供的材料有哪些。
苹果优势的一个重要来源就是，他们买断了制造智能手机所需的所有最好的零部件。如果你对整个供应链都了如指掌，你就能降低成本。
6.使用运算放大器设计一个LED驱动电路。
面试职位：硬件工程师
许多情况下，你设计的产品不会工作在最适宜的环境下。有时会太热，有时会太冷，甚至会掉进水里。
你必须保证你的硬件在这些非最佳环境下仍然能够运行。
7.你如何诊断缓冲区溢出？
面试职位：软件工程师
许多时候，判定一个工程师是否属于最优秀的行列，最好办法就是问他们如何解决一个问题。
如果出现缓冲区溢出，结果可能是灾难性的。因此，如果你想测试手下的工程师面临极端问题时将会如何反应，这个问题很适合。
8.现在有100个标记过的电灯泡。第一个人经过这些灯时，点亮所有的灯，第二个人经过时每隔一盏灯就切换开关一次，第三个人经过时每隔两盏灯切换开关一次。请问，当第100个人经过时，还剩多少盏亮着的灯？
面试职位：高级软件工程师
苹果面试官们并非全部使用原创的面试题，他们有时也会使用可汗学院（Khan[...]
Read More »
软件开发四大过程
一、 需求分析阶段
任务：建立用户需求和功能模块，确定系统中的角色和使用案例。利用ROSE，生成角色，使用案例和生成用例图
所用到的框图：
1. Use-Case[...]
Read More »
如何做好需求收集[来自《程序员》第2期]
项目前期需求收集过程的效果好坏，会对软件产品的最终质量产生直接的影响。如何收集好需求，本文作者给出了一条行之有效的实际操作途径。
什么是需求收集？
需求收集，是确定和理解不同类别用户的需要和限制的过程，是需要高度协作的活动，是在问题及其最终解决方案之间架设桥梁的第一步，因此其重要性不言而喻。据调查显示50%以上产品在市场上失败的原因，是由于忽视了用户需求。
需求收集在需求开发活动中的示意图如图1：
如图1
需求收集为什么会困难？
困扰项目组需求收集活动的原因可能如下：
v 需求收集人员往往只关注用户反映的表面问题，而不能主动深入挖掘用户的真实需求；
v 需求收集人员考虑的问题时习惯干“以产品为中心”，而不是“以客户为中心”；
v 用户往往不清楚自己的真实需求是什么，或者不知道如何准确地描述出自己的需求—“我心里很清楚，但就是说不出来”；
v 没有从所有可能的渠道去收集需求，需求信息来源不完整；
v 收集的需求没有规范记录下来，造成原始信息丢失或失真，且无法回溯；等等。
怎么做好需求收集活动？
首先，需要建立需求收集机制。其次，使用统一的需求收集系统。最后，在需求收集时，采取一定的技术和方法。
建立需求收集机制
(1). 明确每个需求收集活动参与者的岗位职责
根据项目组可能的需求来源（需求来源可能包括：市场调研，竞争对手信息分析，标准和协议等等，视项目组的实际情况而定），指定每个需求来源的收集负责人。同时，对通过各个渠道收集的需求信息，指定专门的接口人进行汇总和审核。
(2). 建立需求预处理流程
对收集到的需求，除了指定专门的接口人进行汇总和审核以外，还要建立相应的预处理流程，在对需求进行预处理时，相关的讨论，决策可以通过“需求CCB会议”完成（需求CCB是指：专门用于需求讨论和决策的Change[...]
Read More »
软件需求分析文档
软件需求分析就是把软件计划期间建立的软件可行性分析求精和细化，分析各种可能的解法，并且分配给各个软件元素。需求分析是软件定义阶段中的最后一步，是确定系统必须完成哪些工作，也就是对目标系统提出完整、准确、清晰、具体的要求。
软件需求分析的任务是：深入描述软件的功能和性能，确定软件设计的约束和软件同其他系统元素的接口细节，定义软件的其他有效性需求，借助于当前系统的逻辑模型导出目标系统逻辑模型，解决目标系统“做什么”的问题。
需求分析可分为需求提出、需求描述及需求评审三个阶段。
需求提出主要集中于描述系统目的。需求提出和分析仅仅集中在使用者对系统的观点上。用户、开发人员和用户确定一个问题领域，并定义一个描述该问题的系统。这样的定义称作系统规格说明，并且它在用户和开发人员之间充当合同。
在问题分析阶段分析人员的主要任务是：对用户的需求进行鉴别、综合和建模，清除用户需求的模糊性、歧义性和不一致性，分析系统的数据要求，为原始问题及目标软件建立逻辑模型。分析人员要将对原始问题的理解与软件开发经验结合起来，以便发现哪些要求是由于用户的片面性或短期行为所导致的不合理要求，哪些是用户尚未提出但具有真正价值的潜在需求。
在需求评审阶段，分析人员要在用户和软件设计人员的配合下对自己生成的需求规格说明和初步的用户手册进行复核，以确保软件需求的完整、准确、清晰、具体，并使用户和软件设计人员对需求规格说明和初步的用户手册的理解达成一致。一旦发现遗漏或模糊点，必须尽快更正，再行检查。
软件需求说明书的编制是为了使用户和软件开发者双方对该软件的初始规定有一个共同的理解，[...]
Read More »
讨论一下怎么写需求文档
作者：iFire
先谈谈我的想法。
一、要讨论怎么写需求文档，首先就的搞清楚需求的构成，我是这么分的：
1、功能需求；
2、非功能需求或技术需求；
我一般把功能需求划分为几个部分：
a、业务过程；
b、业务规则；
c、业务数据；
非功能需求（技术需求）我就不多说了，大致就是可用性，可靠性，性能，可支持性等等。
二、弄清楚需求的构成后，我们就得考虑以什么样的文档结构来描述这些需求了，UP的做法是这样的：
1、用例规格说明描述业务过程；
2、业务规则文档描述业务规则；
3、术语表描述业务数据；
4、补充规格说明描述非功能需求（技术需求）；
UP的做法还是很有道理的。这体现了两个原则：
1、分离关注点（每个文档描述相对独立的领域）；
2、减少重复（很多用例都会引用相同的业务规则及业务数据）；
这样便能够尽可能的使文档结构清晰，易阅读，易理解。也便于跟踪和维护。
但另一方面由于将不同的领域分离到不同文件的做法也使得可阅读性有所降低。比如用例规格说明中的业务过程描述时常需要引用业务规则文档中的业务规则及术语表中的业务数据。由于不是很方便在各个文档之间导航，你可能需要打开多个文档进行交叉阅读。这是比较麻烦的，特别是对于用户来说。
而且UP中每个用例都单独作为一个文件存在，这可能是为了便于跟踪及管理的缘故吧。但正如上所述，文件多了看着就觉得不爽了。我觉得完全可以将用例合并到一个文档中。或者几个相对独立的文档中（比如根据子系统划分）。
至于交叉阅读，导航困难的问题是否有什么别的方法解决呢？html文档似乎不错。不过写起来似乎没word方便啊。
三、总结：
无论怎么写需求文档，最终的目的无外乎易阅读，易理解，易沟通，易确认，易跟踪，易测试，易验收。我想我们都应该以这个为目标来进行思考。
[...]
Read More »
如何编写优质的需求文档
作者: Job Vranish 来源: 伯乐在线 发布时间: 2012-03-21
英文原文：How to write good requirements
编写需求文档，在嵌入式开发领域是非常普遍的。需求文档被用来定义开发任务，协调大规模的研发计划。对于最终的产品，需求文档扮演着开发者行为和消费者行为之间沟通纽带的角色。当需求文档书写正确的时候，便可以发挥巨大的作用。然而，如果你在嵌入式开发领域工作的时间足够长，你就会很快发现，这个领域里不合格的需求文档实在是太多了。当你尝试对这些不合格的文档进行修复时，你又会很快发现，书写正确的需求文档绝非易事。在这里，我们提出一些建议，希望能将书写正确需求文档这件事情变得清晰一些。
从较高的层次来看，书写需求文档的目的就是要提供对所需行为的有效描述。该所需行为可用一个黑盒系统描述，并需要注意以下细节：
工程师可以根据系统所说进行实现
测试人员，在不与开发人员沟通的前提下，可以利用满足硬件要求的设备验证需求。
最终产生的成果满足终端用户的要求。
黑盒测试
书写优质的需求文档：
最基本的原则是：需求文档应当尽量简洁，用最易懂的描述来约束系统的预期行为。如果你遵循这个原则，剩下的那些重要因素（可测试性、避免过度设计等等）都将变得顺理成章。
列举一下更详细的规则，通常会更有帮助。下面是书写优质需求文档需要遵循的步骤：
1.[...]
Read More »
一个标准的软件开发流程步骤及文档
一个标准的软件开发流程需要有哪些步骤，写哪些文档？
1、先是需求调研，出《需求文档》；
2、 然后概要设计，出《概要设计文档》；
3、然后详细设计，出《详细设计文档》；
4、然后就是编码，出软件代码，最好能出单元测试文档；
5、然后就是联调，可能有多个部分，需要联合测试；
6、最后就是软件交付了，交付软件、代码、使用说明书
软件开发流程（Software[...]
Read More »
概要设计的格式模板及相关内容说明
概要设计的主要任务是把需求分析得到的DFD转换为软件结构和数据结构。
设计软件结构的具体任务是：将一个复杂系统按功能进行模块划分、建立模块的层次结构及调用关系、确定模块间的接口及人机界面等。
数据结构设计包括数据特征的描述、确定数据的结构特性、以及数据库的设计。显然，概要设计建立的是目标系统的逻辑模型，与计算机无关。
简述
概要设计有多种方法。在早期有模块化方法、功能分解方法；在60年代后期提出了面向数据流和面向数据结构的设计方法；近年来又提出面向对象的设计方法等。
概要设计的格式
概要设计的格式如下：
1引言[...]
Read More »
如何建立自己的知识体系？
前段时间读到这篇文章：《如何建立自己的知识体系？》，特地分享给烟烟。其实这种知识总结的方法，每个人可能各有一套；在这里我想谈谈我个人的看法。
1.知识体系的问题
工作以后，特别是在进入整车企业以后担任产品工程师之后，看到的听到的材料就似乎往各个方向上交叉的内容多了起来。以前，我只需要做硬件设计的东东（电路），附带得对于流程、质量、可制造性、半导体等知识有一定的了解。但是对于一个汽车电子零部件的工程师而言，这些都是足够了。
但对于一个部件的产品工程师，知道这些知识，仅仅是个开始或者说是个有意义的补充。在接触电池和电池系统的时候，我充分的了解了关于这是一门复杂的工程学，涉及到了电化学等一些我从未涉及的概念，对于电池系统设计之中的方方面面，有时候感觉是盲人摸象般。事实上，一个人是无法承担所有的工作了，能够把所有的事情进行划分，选择一个合适的切入点，可能是比较合理的。
因此在这方面而言，切乎贪全求快。我给自己的定义，工作之上，能够搞定所有的充电问题。在工作之外能够把电池涉及电学性能的知识和部分重要的电化学知识整理齐备，搞清楚电池管理和电池系统热设计方面的内容。可能就是一个限度，如果加上机构、振动、冲击设计和相关的内容，这已经不是短时间能够搞清楚摸透的事情。
定时的，写些博文来整理自己的思路，有机会给组里面写些培训材料，锻炼锻炼Presentation的能力。
2.技能体系
其实这个与知识体系还是差得比较多的。如果说勾画一个东西称为设计的话，在某个工具内进行实施就是技能应用。我不知道是不是因为现在的工具都太强大了，往往让工程师忽略了前者，都把工具看得比方法和思考更重要了。我为自己目前设定的技能体系：
a.Office系列：PPT这个目前是汇报的神器了，升职、加薪说到底还是通过PPT汇报出来的，这是排第一的。EXCEL不仅能够计算，也能把自己的事情和进度有效的组织起来。
b.Mathcad：我觉得这个工具，能够把数学运用在工程领域，我现在试图在勾画把一些计算努力使用。
c.UG：基本的结构设计工具，验证装配，目前的起点较低。
d.热分析软件：ANSFOT可能符合公司的策略，可能还是沿用它。
e.可靠性分析软件：虽然只是可能去check，还是得自己进行力所能及的进行温习。
[...]
Read More »
对初学者有用的10个Git技巧
新兴技术是一个将开发模式和习惯做法带入主流的催化剂。有人称这是一种”真爱无价”现 象，这是一部80年代的电影名字，讲述一个书呆子想成为时尚人的故事，“租借”他高中暗恋的对象做其女朋友。最近的一个例子似乎就是Git的兴起。Git是一个开源的版本控制系统，[...]
Read More »
BugZilla在Win7下安装与配置-IIS7+mysql秘籍
不加“秘籍”不表我倒腾了一天的辛苦啊！
本来想说说BugZilla或者bug管理的重要性，但是想想，你懂的，否则咋会来这里？但我还是想说，真的很有必要，有3个人以上的项目，无论项目多小，bug管理就很必须了。
下面说说本文的重要性，但是想想，你懂的，Win7+IIS7，现在资料很少很少，配置起来很不顺利，所以，你懂的。
关键点：
1、iis7的配置
windows7旗舰版默认是没有安装iis的，所以需要你自己添加。这个吗，推荐你看看这篇文章：
http://www.360doc.com/content/10/0624/19/1872066_35018211.shtml
但是有一点必须注意！BugZilla是cgi写的，后台解释器是Perl，大神啊，我安装IIS7的时候没注意这点，后面的失败全拜此所赐啊！所以，在安装IIS7的时候，一定要勾选CGI模块解释器！
另外，最好在安装ActivePerl之前配置好IIS7.
2、安装和配置ActivePerl
这里又可以参照一个帖子：
http://www.roboby.com/install_bugzilla_in_windows.html
其中有些地方不可照搬，因为你用的是win7，而他的是xp
3、“-T”的问题
如果你碰到提示cgi文件的-T问题，那么恭喜你，你基本成功了！最有一个-T的问题，就是个参数问题。
我们在配置perl.exe作为cgi解释器时，给perl.exe传递的参数是[...]
Read More »
BugZilla在Windows下的安装
一. 安装MySQL数据库
下载 MySql 4.x: http://www.mysql.com/ ,我用的版本是mysql4.1.22 for win32
安装请看如何在Windows平台下安装MySQL(http://www.websina.com/bugzero/faq/database-mysql-win.html)。
二.安装activeperl
下载activeperl最新版本:http://downloads.activestate.com/ActivePerl/Windows/,可以安装需要选择所要的版本,我选用的是5.8.822,现在最新的版本是5.10.1002,一开始是我用的是5.10.1002这个版本,发现PPM中包含的模块反而没有5.8.822这个版本来的全,所以最终还是使用了5.8.822这个版本.但是要注意的是bugzilla3.0.3及以上版本要求activeperl版本在5.8.1以上.
安装activeperl,这个没什么可说的,默认安装即可.
三.安装bugzilla
bugzilla并不需要安装,下载完后解压到本地某个目录下即可.
http://www.bugzilla.org/download/现在最新的版本是3.1.3,我装的就是这个版本.
安装完后,在dos下执行checksetup.pl,看缺少哪几个perl[...]
Read More »
软件外包工作规程指引（适用发包方）
来源： 作者： 日期：10-01-24
电子化时代的许多经营活动需要借助信息系统管理，因此软件外包现象越来越普遍。在软件外包过程中，发包方似乎处于主动位置，可以决定是否和如何外包，哪些内容需要外包，并可以自主选择合适的承包方。但是，企业经营活动高度复杂，风险无处不在。软件外包作为软件生产的新方式同样存在各种风险，现实中有不少发包企业在实施外包项目后发现问题丛生，最终导致外包项目流产。存在风险并不可怕，可怕的是缺少风险意识和规避风险的手段。其实，通过仔细分析风险的来源和特征，在软件外包的全过程实行动态和连续跟踪和控制，可以防患于未然，有效规避软件外包风险。
一、项目前期准备阶段
(一)前期调研阶段。本阶段主要从事三方面工作
(1)审视自身的履约能力根据公司的发展目标，判断该项目外包是否符合公司发展的主要方向，公司有否必要为此项目增加新投资、添置新设备、招聘新员工，如果有此必要，公司有没有足够的能力和充裕的时间去实现这些新的投入。
(2)审核承包方的缔约资格，判断其是否有缔约权利能力和履约行为能力。寻找合适的外包合作伙伴，验证和调查公司的实际资质和开发团队的实力，有必要进行实地考察。具体包括承包方办公场所(自有/租赁)以及周围办公环境、办公环境的装修、营业面积大小、管理是否规范、人员精神风貌、开发人员数量、技术水平、男女性别比例等。尤其注意了解开发方是否设置专门的测试员岗位。此外，要注意掌握承包方的开发实例。如有必要，还需要对承包方开展信用调查，包括查看营业执照复印件，企业经营历史，企业涉讼情况，违法记录，业内口碑，主要负责人以及股东的情况。
(3)制定资信考察报告书。
(二)制作项目需求。
在项目立项初期，发包方首先要做好内部的时间进度设计和规划以及一套完整的软件系统规格说明。其中，项目进度的估算尤为重要，要避免项目发生延误，计划中要预留足够的双方沟通和确认的时间。
二、与承包方谈判、磋商阶段(与前一阶段可合二为一)
此阶段的全过程中始终不能忘记对于双方利益共同点和利益冲突线要具备清晰的认识和全面的了解;准确预测双方可能的妥协程度;对于法律法规的相关规定和本合同可能涉及的第三人利益界限有熟练的掌握和冷静的恪守。
1.发包方发出邀约邀请，将项目的时间进度设计和规划以及功能需求提交给承包方，承包方据此提交投标书，包括详细规划方案。
2.发包方收到承包方提交的项目计划后，要详细地跟本企业的计划进行比对和审核，从而了解承包方对整个项目的流程、内容、估计的工作量和资源的安排是否与项目本身的要求吻合。明显的差异需要及时澄清并建立共识。双方要将其记录入书面文档。
3.确定合作意向后，要求承包方出具详细的进度实施方案和系统整体评估方案，并对此方案进行评审和确认，旨在双方都能明确地了解项目的整体任务量和难度，做好人力物力的合理安排，避免不必要的麻烦，此过程的文档应留存备查。
4.承包方的核心参与人要书面提交对发包项目的说明报告，由发包方判断承包方是否理解发包项目的意图，了解外包项目开发人员的思路是否和设计相符。
5.项目开始前，须做足够的分析和风险评估，对可能出现的风险设计避免的方法，预先设计好替代方案，甚至外包团队都应有替代人选。
三、合同签约阶段
外包合同应明确如下内容
1.明确双方项目组沟通成员名单及其联系方式，承包方须提供所有参与人的名单及联系方式、邮件地址等。
2.明确约定开发方必须遵照发包方的需求设计文档进行开发，在开发过程中，如果出现发包方设计不周或是不合理的地方，开发方须提出问题及修改方案，必须经发包方确认后才能进行修改，并且这些修改需要记录入文档。
3、明确约定承包方项目负责人首先需要做出一个详细的、完整的项目计划，并在计划中详细地列清楚每一项工作需要哪方面人力共同执行。
4.明确约定每一个项目进度都需要发包方确认后才能继续进行。如果发包方认为有问题并提出修改意见，承包方须根据发包方意见提出书面解决方案，经过发包方确认后进行修改，如果推后时间再修改，须征得发包方同意。例如承包方在完成系统分析后，需要把分析的结果让发包方理解，确认承包方对整个系统的理解和分析与企业本身对项目的需求和分析达成一致，这样才能让承包方进行其后的模块设计。
5.明确约定项目过程中的进度汇报方式，有必要时时监控源代码，了解项目的进展情况，分阶段提交项目成果，有必要让承包方进行阶段性成果演示。如果承包方不能按时提交项目成果，须提前向发包方提出申请，且须取得发包方同意。
6.承包方每日将开发的源代码及设计说明书上传至CVS服务器上，承包方项目工作人员需每日将工作情况以日报形式上传至该CVS服务器。由发包方于第二天上午进行检查，并向承包方提出书面反馈意见。
7.每一个程序模块完成后，承包方须提交测试方案与测试结果。承包方应把有关程序的源代码列出，并把有关测试的结果打印出来，让发包方核对结果，确认承包方所说的工作已经完成。如果承包方没有列出源代码，发包方有权不予项目验收。
8.建立几个大的项目里程碑。约定在大的里程碑内发生的项目延误由承包方自我消化，大的里程碑点发生的项目延误将由双方商讨处理。
9.明确约定项目验收期限、验收内容(项目不同阶段开发方须提交的详细文档列表、提交日期、负责人及质量要求、验收成果中必须包含测试报告及测试结果)、验收方法以及双方验收小组成员(必要时需要承包方参与验收)。
10.验收报告须双方签字确认才能生效。
11.明确约定项目完成提交时需要提交的完整的交付物，其中源码作为重要，而且源码须符合规范。
12.明确约定试运行时间段以及承包方在试运行期间应尽的责任，如果发生的错误是需求内的，承包方须无条件修正，并重新验收。
13.对于发包方合理的需求调整，在工作量的一定百分比之内，承包方应当同意。如果超过此百分比，双方协商一致解决。未能协商一致的，按照原方案执行。
14.明确约定承包方负责本项目的关键人物不能临时更换。应争取让承包方项目主要负责人要做出承诺，坚持到最后。
15.如果发包方处于优势谈判地位，应约定较低的首付款，可以采取低首付，多次数的支付方式。
16.明确约定违约(预期违约、一般违约、严重违约)的责任承担和赔偿以及不可抗力或情势变更的风险承担方式和原则。
17.明确约定合同自承包方提供经双方确认后的详细需求文档时生效。
18.明确约定合同的变更、权利义务转让以及终止(对方主动终止和发包方主动终止合同)条款。
19.明确约定合同争议处理条款。
四、项目实施阶段
1.项目开发过程中应开展有效的沟通，以便及时解决开发过程中发现的结构或设计方面存在的问题。必要时安排一对一的沟通方式，即承包方的开发人员直接和发包方的具体负责人联系沟通，减少中间的传递环节，减少传递出错的几率。每项重要的沟通须记录入文档并经过双方确认。
2.有效地跟踪掌控开发情况。发包方需掌握承包方每个开发人员的开发状态和进度，及时发现和应对任何突发状况。项目中发现的任何和设计不符的地方或其他问题要及时沟通和解决，避免将问题推到项目结束后。在开发的过程中，验收也同时进行，而不应等待开发完成后才进行验收，即要分段进行阶段性验收。
3.项目第一次延期就应该介入解决。开发过程中要作严格控制，避免承包方散漫和懈怠。如果是发包方的原因导致项目延误，发包方要补足承包方时间并形成书面的确认文件。
4.验收时应严格按验收报告内容进行。按照合同约定时间进行密集型测试和验收，出现验收不合格的情况，要及时进行协商和处理，时间要尽量控制到最小范围。
5.发包方付款事项须与对方配对，在不存在对方履行义务在先的情况下，发包方须按时付款。
6.发包方须根据对方提出的项目进度表，制定发包方项目管理进度表。由项目组组长负责定期对工作计划跟踪并督促执行。完成项目工作日志，对工作进展定期汇总，汇报。
项目组成员须妥善保管来往记录、邮件、变更确认单等。
成功的软件外包是发包方和承包方互相信任、高度协作的结果。发包方软件企业需要合理外包决策，细化和筛选可以外包的内容，确定具体的外包实现方式，选择合适的承包方，规范外包的实施流程，积极地进行外包项目管理，实现全方位、全过程地监控外包过程，才能将软件外包风险降到最低。
[...]
Read More »
【转】首次敏捷项目开发实践
首次采用敏捷方式进行开发，我想把我们的做法与大家分享下，同时希望大家指出我们的不足和需要改进的地方，让我们的项目进行的更顺利，目前项目已过三分之一，客户比较满意，还算顺利。
项目简介：一个DMS小项目，预计时间14人月.客户需求不是很明确，想一边做一边提，适合引入敏捷开发（实际上用户的需求也一直在变，当他们看到每次的small[...]
Read More »
【转】常见的敏捷开发流程比较
速度是企业竞争致胜的关键因素，软体专案的最大挑战在于一方面要应付变动中的需求，一方面要在紧缩的时程内完成专案，所以软体团队除了在技术上必须日益精进，更需要运用有效的开发流程，以确保团队能够发挥综效。[...]
Read More »
【转】你是个软件架构师吗？
=========================================================
本文为转载，转载必须确保本文完整并完整保留原作者信息和本文链接
E-mail:[...]
Read More »
CruiseControl.rb初体验
版权声明：转载时请以超链接形式标明文章原始出处和作者信息及本声明http://bigwhite.blogbus.com/logs/27940065.html
我所在的项目一直以C语言作为主要开发语言，与做Java以及其他新兴语言的人不同，组内的同事似乎对新鲜的东西不是那么感兴趣，也没有主[...]
Read More »
ScrumMaster项目面谈诀窍
作者 Shane Hastie 译者 金明 发布于 2009年7月16日 上午9时58分
ScrumMaster或者迭代经理在敏捷团队里面是一个关键角色，而且，对于ScrumMaster，选择与哪个组织合作或者与哪个团队共事是非常重要的——在考虑是否接受一个新项目的时候，很重要的是创造一个取得成功的环境。
敏捷宣言强调个体胜过流程，而ScrumMaster的很大一部分职责就是创建团队氛围，让人们互相合作，有效地交付可工作的软件。
Scrum官方网站把ScrumMaster的职责定义为
ScrumMaster负责在团队中正确、完整地贯彻Scrum流程。虽然在实施开始的时候必须做一些折衷，而且因为实施环境的限制不得不放弃某些实践，但是ScrumMaster在脑海中始终要铭记实施完整的Scrum所带来的好处和价值，渐进地推动团队和组织走向完美状态。
ScrumMaster特别要对以下工作负责：[...]
Read More »