CHEN Jian's Java Blog

项目整合(integration)管理     书上说，“整合”兼具统一、合并、连接和一体化的性质。还是不太明白它的意思，反正它包括的过程有：       1. 制定项目章程          a. 代表“正式批准”          b.能反映“干系人期望”          c.提供资金的人或组织，即“启动者”，应该有一定的职权          d.启动者在章程上签字，则标着志项目获得批准       2. 制定项目管理计划          a.要体现生命周期          b.要有变更管理计划、沟通计划、配置管理计划等子计划          c. 计划确定后应成为基线(baseline)，作为以后绩效测量的基准；基线本身不能乱改       3. 指导与管理项目执行          a.产生真正的成果          b.还要收集工作绩效信息，如实际进度       4. 监控项目工作          a.监督：监视项目的健康状况          b.控制：制定纠正或预防措施          c. 将实际绩效与基线进行比较，识别新风险等          d.输出：提出变更请求 　　  ５. 实施整体变更控制           a.变更请求应以书面记录           b. 若变更被批准，则应制定新的计划基线       6. 结束项目或阶段 …

PMBOK 学习笔记 3.2 项目整合管理 Read More »

   PMI认为项目管理的知识有以下几个领域：      1.整合管理(integration)      2.范围管理      3.时间管理      4.成本管理      5.质量管理      6.人力资源管理      7.沟通管理      8.风险管理      9.采购管理

   项目管理过程(process)：确保项目顺利进行的一系列相互关联的行动和活动，如收集需求，风险管理等等。    每个过程都有：输入、工具和技术，以及输出    PMI把所有过程分类为五大过程组，并认为任何项目都要经历这五大过程组：      1. 启动过程组(Initiating)          a. 过程：定义项目，明确授权，确定项目经理和干系人，并定义初步范围          b. 输出：项目章程和干系人名册          c. 启动过程可以加强干系人的主人翁意识；如果项目有多个阶段，则每个阶段最好都有一个启动过程      2. 规划过程组(Planning)          a. 过程：项目管理计划，收集需求，定义范围，项目估算，任务计划，进度计划，质量计划，开始风险管理等          b. 输出：需求文档和各种计划书      3. 执行过程组(Executing)          a. 执行，QA，调整计划，组建团队，建设团队，管理团队绩效，管理干系人期望等          b. 输出：可交付成果，更新了的项目计划等等      4. 监控过程组(Monitoring and Controlling)          a.过程：跟踪，审查，控制变更，控制进度，控制成本，控制质量，监控风险等          b.输出：变更了的计划，变更了的成本、风险登记册，绩效报告等      5. 收尾过程组(Closing)          a.过程：验收，评价，经验教训，文件归档          b.输出：最终产品移交

项目管理中的一些基本概念   PMBOK: Project Management Body of Knowledge，作者是PMI(美国项目管理协会)。这本书的宗旨是：        1.识别项目管理知识体系中被普遍公认为良好做法的那一部分        2.提供和推广一套项目管理专业的通用词汇，用于讨论、书写和应用 基本概念：      项目：为…而进行的临时性工作，有 明确的起点和终点      项目管理：将知识、技能、工具和技术应用于项目活动。PMBOK认为项目管理可按时间顺序分为五大过程组，共42个过程      项目通常处于战略计划的大环境之中，因此项目的利益要服从于组织的整体利益（可参见“项目集”和“项目组合”的概念）      项目管理办公室(PMO): 对各项目进行集中协调。可以直接管理项目，也可以只提供管理支持和监督      项目经理须具备的能力：           1.通用的管理方面的能力和项目管理知识及实践能力           2.特定应用领域的知识或技能           3.个人素质，包括：态度，合适的人格特征和领导力       项目生命周期(lifecycle)：一系列项目阶段(phase)的组合。基本的生命周期结构：启动项目 => 组织与准备 => 执行项目工作 => 结束项目。       项目阶段之间可以采用严格的顺序关系，也可以互相存在交叠以压缩进度，还可以一次只规划一个阶段，根据这个阶段的结果来规划下一个阶段（迭代式）       项目干系人(stakeholder)：            1. 会积极参与项目            2. 或者其利益可能受项目的影响，包括积极影响和消极影响       在“干系人”这方面，项目经理要：            1.及早 识别所有干系人，理解他们对项目的影响力；如果这项工作到后期才做，可能导致代价非常高的产品变更。            …

PMBOK 学习笔记 1. 项目管理中的一些基本概念 Read More »

与“敏捷”相关的实践太多了，我曾经沉迷于各种敏捷实践，不加思索就奉为宝典。后来我才发现，很多东西并不现实，再后来我觉得，对敏捷，抓住它的核心价值才是最关键的。 我的结论是： 敏捷过程要解决的核心问题是解决“客户需求会在开发过程中产生变化”这样一个问题   1.首先， 这是一个项目过程问题；而不是设计、开发、文档和测试方面的问题。也就是敏捷过程的核心价值在于项目风险控制，而不是设计、开发、文档和测试。   2.敏捷之所以可以解决这样一个问题，是因为它的iterative特性。 分迭代实现产品，每个迭代可以较快地完成并及时让客户看到，客户随后再决定后续的产品应该怎么做。这样你就可以保证："doing the right thing"，产品能够符合客户需要，客户关系得到维持。    如果不使用迭代，而是等到开发完成才反馈，那这个反馈就太晚了，后果你懂的。    你可能会问为什么不用一次原型法，它也可以提供形象的反馈啊。我的看法是对原型的投入很难控制，做的太差，反馈效果不好；做的太好，时间浪费过多。而迭代法相当于演进原型法，原型即产品，不会浪费。   3.不过，迭代法在项目管理上有一定的代价：对整个项目的估算的准确性会很差。敏捷开发中， 只有最近几个迭代的需求才比较精确，所以你只能对最近几个迭代有比较准确的估算，整个项目（或第一个可发布版本）的工期和交付日期都会很难预估，管理层对此未必会满意。所以，要玩敏捷，就需要所有利益相关者都愿意接受这样一个事实：每个迭代可以做到精细控制，做到很好的可视性，但最后的上线时间可能会有较大的误差；利益相关者还需要把迭代的完成当作一种成功，把过程和结果都当作绩效评价指标。   4.对上面说的这种问题不可一厢情愿地视为小问题，你最好要搞清楚管理层的风格才行事，否则就应该想办法变通。 首先可以先问下自己，在这个项目里“客户需求会在开发过程中产生变化”这种问题是否真的存在？比如说“用新框架将本系统重写一遍”这种项目并不需要迭代模式。 　　其次，可以再问一下，“项目能否拆分成多期，每一期完成后即可交付运营？”　如果答案是肯定的，就可以对当下这一期的工期进行细致估算，交付时的进度表现就会比较好看；虽然整个大项目的结束日期仍然未明，但既然时时有东西上到生产环境产生经济效益，管理层就不会管那么多了。   5.另一个问题是，如果迭代只是为了提供反馈，那为什么每个迭代开发完成后还要测试，而不能等到准确交付时再一起测呢？　我认为这主要是为了让测试可以在开发过程中就参与进来，不必等到所有开发完成才进入，这样可以跟开发人员并行工作，实现节省时间的目的（当然也可以起到及早发现bug、及早修复的作用）。但我还认为， 每个迭代都做测试并不能帮助我们解决核心问题，开发人员的自测，已经可以使系统足够健康，应对客户的检视了；如果测试的人力资源紧张，等到交付前再让他们对整个系统进行测试其实也是可以的。   总之，我认为，敏捷过程针对的 核心问题是“需求会在开发过程中变化”，应对这个问题的 策略是及早给用户提供反馈，具体的 手段则是迭代式开发。你会说迭代并不是敏捷的专利，没错，本文的标题应该改成“基于迭代的各种软件生命周期要解决的核心问题有且只有一个” 　最后，说一下为什么我认为敏捷的核心价值只体现在“拥抱变化”上，而跟“设计、开发、文档和测试”没多大关系。 因为我觉得敏捷开发在“设计、开发、文档和测试”方面的实践要么意义不够巨大，要么普适性很弱，要么根本就是宅男说梦。比如说User Story，它一定就比需求规格说明书好用么？再比如“按最简单的方案来实现　+　频繁重构”，认为简单的代码即使设计不够柔性，改起来也会很容易，这太一厢情愿了。至于“结对编程”、“测试驱动开发”、“一套可作为检验重构正确性的Test Suite”云云，都太强人所难了，这些想必很多人都有体会，就不一一细说了。

作者给出了快速软件开发的“27项最佳实践”（见下图）。我个人认为好像没啥特别的，有的还太老了。所以我就不展开介绍了，大家见仁见智，看到对自己胃口的可以自己研究下。

项目修复（挽救濒临失败的项目）    濒临失败的项目的特点：       1.进度严重延迟，开发、管理层和客户都不抱信心       2.开发加班严重，开发、管理层和客户之间关系紧张       3.项目处于被取消的边缘，士气低落      解决办法： 扔掉一些功能，提升生产率，必要时抛弃原进度计划    关键： 强势出击，控制这个项目       人员方面： 采取一切措施恢复开发组的士气，包括放假、及时减压、提供更好的办公条件、并去除害群之马       过程方面：纠正过程方面出现的问题， 不辞辛劳地做好风险管理，及时发现问题并做出决策       产品方面： 砍掉不重要的需求，修正甚至重写错误的系统设计，控制好缺陷

谨慎对待生产率工具（可以提高生产率的工具）    工具包括：开发语言，编译器，IDE, 框架，第三方包，版本控制器，issue追踪系统等等 工具的局限性： 往前走3步，再往后退2步    1.它可以帮你提高很多东西的自动化水平，节省很多时间    2.每个工具往往都有它的局限性，导致有些地方你要花很多时间，甚至遭遇很大风险 具体的策略：     1.尽早识别有希望的新工具 — 不要等到需要新工具时才着手调研，可以成立一个“工具组”全职或兼职地研究市面上的工具     2. 全面地评价新工具 — 考评预计收益，供应商稳定性，质量，成熟度（版本号>1），学习曲线，适用性，与现有工具的兼容性,以及是否满足你们未来的产品规划     3.快速地部署被证明有效的新工具     4.避免使用被证明低效的新工具 – 如果项目里使用了新工具，应该在项目结束后对这个工具进行评价，为后面的项目提供参考。     5.继续使用久经考验的旧工具 – 不要轻易更换，否则你会很疲惫 误区：银弹综合症。看到一个有诱惑力的新工具后，就一厢情愿地认为它可以大幅度缩减项目时间。 银弹症在软件开发界是一种常见的职业病。   

功能限定（即需求控制）   “由于需求蔓延而导致的变更，使产品不稳定甚至产品根本不可能完成”    功能限定的三个着力点：      1.项目早期控制      2.中期控制      3.晚期控制 早期控制： 不要引入不必要的功能。具体有三种方法：     1.规格说明最小化：规格说明书里没必要记录一些无关痛痒的需求（如按钮阴影），这样可以缩短需求阶段的工期，还可以避免开发人员把过多时间浪费在不重要的功能上     2.需求筛选（最有效的方法）：减少产品的尺寸和复杂性     3.版本开发：将某些功能推迟到后续版本中实现 中期控制： 在开发过程中控制需求变更     变更的来源：       1.客户希望变更，因为在开发过程中有了新的想法       2.开发人员希望变更，因为想把产品做得更完美    控制变更的办法：       1.在项目早期帮助客户找到他们的真实需求，从根源上减少变更的发生频率。很多变更之所以发生就是因为客户在看到产品前并不知道自己要什么。在这方面，“原型”是一个有效的手段       2.对客户提出的变更请求作出成本收益分析，去掉其中不划算的部分       3.提高作出变更的难度，比如约定“提交变更请求时，必须附上书面表单和相关的分析说明”       4.说服客户把变更放到后续版本中实现       5.指出短的发布周期的好处：我们可以迅速把产品推出市场，这比一次性做一个完美的产品更重要       6.成立需求变更委员会 后期控制： 如果进度落后于计划，则去除低优先级的功能