Software Engineering

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

项目整合(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 »

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

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

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

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

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

“激励对生产率的影响比任何其他因素都大” 不同人在工作上有不同的需求：      开发人员最大的五种需求：成就感，发展机遇，   工作乐趣， 个人生活，  成为技术主管的机会      项目经理：                   责任感，成就感，     工作乐趣， 受任可程度，发展机遇      普通人：                      成就感，受认可程度，工作乐趣， 责任感，  领先    以上说法可能并不准确，而且个体差异很大；但重要的是： 如果管理者用对自己有效的方式来激励开发人员，则很可能会遭到挫折。 开发人员在MBTI上的表现：     更“ 内向”， 更“ 理性”， 更倾向于“ 推理”。理性的开发人员对于“不现实的目标”并不怎么买账 适用于开发人员的具体激励手段：   1. 满足成就感       a. 自主权：为实现自己设定的目标工作时，会比为别人更加努力地工作       b. 设定目标：他们会为指定的目标工作，但你得告诉他们目标是什么       c. 管理人员过多干涉会挫伤积极性     2. 发展机遇：希望技术能够持续进步      a. 技术培训      b. 买书，鼓励自学      c. 让他们参加能够学到东西的项目      …

《快速软件开发》学习笔记 – Part 2.6 激励开发人员 Read More »

共同合作，有时会产生1+1>2的结果，但有时也会产生1+1<1的结果 如何建立高业绩的团队：     1.竖立起共同愿景。愿景确立后，可以避免在小的决策上浪费时间     2.建立成员认同感和主人翁精神     3.结果驱动：角色明确，沟通顺畅，绩效考核，以事实为依据     4.选择能够胜任的团队成员：本项目需要的技能、工作愿望和善于合作     5. 让成员对团队作出承诺：为了团队利益可以做出个人的牺牲     6. 相互信任：诚实，开放，一致，尊重。让大家看到你把团队的利益放在心上。     7. 彼此相互依赖，让人人都觉得自己很重要     8. 真诚地沟通，不隐瞒坏消息     9. 微观管理可能可以把事情做的更好，但也可能打击士气    10.团队因为工作需要资源时，尽量去满足    11.成员数最好少于8-10人，并多于4人    12.多搞点乐趣    13.必要的时候开除破坏团队合作的人。其他成员的士气的提升可以弥补开除一个人带来的损失

各种团队：    1. 业务团队：一个技术领导 + 多个各司其责的成员。这是最常见的结构，可以适用于各种项目，但效率未必总是最优的    2. 首席程序员团队： 首席程序员就像主刀的外科医生，处理手术中的大部分事情； 其他成员只为他提供支持。适用情况：存在这样一个程序员，他的效能是他人的十倍，而且他生活简单，愿意每天工作16小时。这种团队的生产率非常高。    3. Skunk Works团队: 一群有才华、有创造性的团队。享有高度自治，公司对他们几乎没什么管理，团队内也没有官僚体制的影响。这种团队可以激发出很高的创造性，适合需要创新的项目；但缺点是不能给管理层提供足够的可视性。    4. Feature Team，即工作团队，又称项目组，各个成员来自不同的部门，临时组建，在项目进行时需要向各自部门的经理报告 （没太懂这种团队的优缺点）    5. 搜索救援团队: 专门用于快速解决一个短期的问题    6. SWAT团队：像一个特警小组一样，每个人在自己的领域都非常熟炼； 他们可以快速组建和动员，然后专业迅捷地完成一个目标清晰的项目。    7. 运动员团队：？    8. 戏剧团队：？ 技术领导与管理者的职责分工问题 　 如果分工没处理好，就会出现这样的问题： 两个人对同一件事重复负责，因为他们都以为自己对这件事负责；两个人都某件事都没负责，因为他们都以为对方应对这件事负责    推荐的分工办法：