01.软件项目管理与敏捷方法——敏捷方法笔记

01.软件项目管理与敏捷方法——敏捷方法笔记

00.在生存竞争中,最适应的物种以牺牲敌人为代价最后生出,因为他们能够成功地改变自己更好地适应环境.——查尔斯.达尔文

 

01.信仰的飞跃、冒险进入到未知世界,这是一个认知的发现过程,有时会产生不可预期的结果。

 

02.敏捷方法(Agile)描述了一组交付软件的原则和实践。

 

03.如同志愿者,知识工人不喜欢被呼来换取。相反,他们指向被雇佣,希望参与,想知道他们处于什么位置以及他们的工作队其他人会产生什么影响。他们希望接受挑战,感觉仿佛自己的努力受到重视。者意味着命令工人的旧式方法必将被提倡信息共享和劝导的心方法所替代。

 

04.敏捷宣言: 

  *我们正在通过亲自去做以及帮助别人做来发现更好的软件开发方式。通过这项工作我们获得了价值:

  *个体和交互胜过过程和工具

  *可工作的软件胜过全面的文档

  *同客户的协作胜过合同谈判

  *对变更的响应胜过遵循计划

  *换句话说,尽管右边陈述的条目也有价值,但是我们还是更强调左边陈述的价值

 

05.“自我超越”(self-transcendent):其含义是项目团队应该处于“为达到顶点而永不停歇寻求”的状态。有能力的项目团队能够依据管理者给出的指导原则创建自己的目标,他们能够以一个团队的方式设计出独特的解决方案从而找到解决问题的出路。

 

06.这被称为“产品评论”(product review)。考察可工作软件让我们能够对象的真实状态做出合适的响应。所有东西都是可见的,能够基于系哪有的产品做出决策,而不是只依据有关的文档形式的材料。

 

07.如果一个人给了我一份40页的文档然后告诉我去编码,我将不知道应该首先做什么。事实上,我很可能更愿意首先开始研究系统的体系结构,或者做我敢兴趣或零我兴奋的事情。这些事情很可能不是客户认为最有价值的特性。因此,现在编写文档这种资源浪费的形式中有夹杂了编码形式的浪费,这些编码是我自认为应该开始做的一些东西——但这些东西很可能不是当时应该做的正确的事。

 

08.为了开发出恰当的系统,客户的反馈信息是必不可少的。敏捷项目团队重视客户(或客户代表),能够学会如何让客户来做出业务决策。反过来,客户也依赖项目团队提供的重要的技术信息来做出合适的决策。优势客户在没有看到东西之前并不知道自己想要的是什么。

 

09.敏捷方法下的“客户协作”意味着客户已经成为开发过程的组成部分。

 

10.在计划驱动的环境中,所有需求都是被实现规定的,它们被分解到任务的层次并得到评估。成本和完成日期是根据这些粒度较细的任务通过自底向上的计算得到的。计算所得到的进度计划成为项目的一个基线,用于度量项目的性能。因此,严格根据计划执行任务、控制范围蔓延在计划驱动的项目非常重要,因为只有这样做才能限制或消除成本超支或进度拖延。

 

11.敏捷宣言12条敏捷原则:

  *我们的最高优先级任务是通过尽早和连续地交付有价值的软件满足客户的需要。(客户交付价值)

  *即使到了开发后期也欢迎需求变更。敏捷过程考虑到客户获得竞争优势的需要而同意变更。

  *经常交付可工作软件,交付周期从几个星期到几个月不等,时间间隔越短越好。(时间盒timebox)

  *业务人员和开发人员必须自始至终共同完成项目的日常工作。(业务需要)

  *围绕积极的个体构建项目。给予他们所需要的支持和环境,相信他们能够完成工作。(时间盒内是自我管理)

  *面对面地交谈是开发团队中最有效的信息交流方式。

    尽管这条原则表面看上去只是一个常识,但是实质上意味着语言去替代某些文档。例如,开发团队成员并不编写详细的设计规约,而是共同工作并探讨和研究软件应该如何被构建思想。这病不是说敏捷项目不编写文档——他们确实编写文档。这条原则说的是文档不是主要的沟通工具。我们知道,许多项目团队所在的地理位置相隔数千英里,优势唯一的沟通方式是通过多种类型的文档,然而,还有许多项目团队成功地实现了即时消息通信、视频会议、wiki、最新的工程开发环境以及采用其他各种技术来支持有效的协作。

  *可工作软件是项目进展状况的主要度量。

  *敏捷过程提倡可持续的系统开发。资助方、开发方和用户应该能够维护一种不确定的、持续的步调。

  *对卓越技术和良好设计的持续关注有助于提高项目的敏捷性。

  *简化(尽量让可以不做或少做的工作量达到最大)也是至关重要的。

    简单性是敏捷方法的“反镀金机制”。敏捷项目团队值构建客户想要的,此外不关注其他。这条非常简单的原则确保了项目团队不会去构建客户不想要的或者不用的功能。

  *最佳的架构、需求和设计都源于自我管理的团队。

  *在有规律的时间间隔中,项目团队要思考如何提高后面的工作效率,然后相应地调整自己的行为。

    尽管每次迭代结束时可以检查和修改产品,但是这条原则讨论的是过程调节的必要性。为了确保过程工作的质量,敏捷项目团队需要回顾以前的过程。项目团队成员一起工作,共同解决过程中存在的任何挑战,并且关注长期的过程改进。

posted @ 2019-01-22 10:23 艾小小雨 阅读( ...) 评论( ...) 编辑 收藏
  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
目录   译者序   第2版前言   第1版前言   第0章不可知和不可说   0.1和解析体验相关的问题   0.1.1解析模式的冲突   0.1.2检测解析模式   0.1.3思考不准确的思想   0.2沟通的不可能性   0.2.1内部重新组织   0.2.2触及共享体验   0.2.3管理不完美的沟通   0.3聆听的三个层次   0.3.1三个层次和方法集   0.3.2三个层次与本书   0.3.3守-破-离   0.4那么,明天我做什么   第0A章不可知和不可说:演进   0A.1沟通和共享的体验   0A.2守-破-离   第1章创造和沟通的合作博弈   1.1软件和诗歌   1.2软件与博弈   1.2.1博弈的类型   1.2.2软件与攀岩   1.2.3创造和沟通的博弈   1.2.4软件与工程化   1.2.5软件与模型构建   1.3再论合作博弈   1.3.1程序员成为沟通专家   1.3.2更快地博弈   1.3.3标识物和道具   1.3.4减少回报   1.3.5对于首要目标的充分度   1.3.6对于积淀的充分度   1.3.7博弈中的博弈   1.3.8开放源码开发   1.4这对我意味着什么   第1A章创造和沟通的合作博弈:演进   1A.1沼泽游戏   1A.2合作中的竞争   1A.3其他领域的合作博弈   1A.4软件工程的重建   1A.4.1这一词汇从哪里来   1A.4.2我们从哪里走错了   1A.4.3重建软件工程   1A.4.4技艺   1A.4.5合作博弈   1A.4.6精益制造   1A.4.7重建后的软件工程   1A.4.8其他工程化中的协作   第2章个人   2.1人是古怪的   2.1.1寻找特征函数   2.1.2古怪性格的元素   2.1.3不可避免的多样性   2.1.4技术的作用   2.1.5相互冲突的共同点   2.2克服失败模式   2.2.1犯错误   2.2.2宁可失败也要选择保守   2.2.3创新而不研究   2.2.4不能始终如一的习惯动物   2.2.5使用纪律和容忍来应对   2.3以一些更好的方式工作   2.3.1具体化   2.3.2实物   2.3.3在某些东西的基础上进行修改   2.3.4观察和聆听   2.3.5支持专注和沟通   2.3.6工作分配要与个性相匹配   2.3.7天赋   2.3.8奖励要能保留乐趣   2.3.9组合奖励   2.3.10反馈   2.4利用成功模式   2.4.1善于四处寻找   2.4.2人们学习   2.4.3可塑性   2.4.4贡献和采取主动   2.4.5组合成功模式   2.4.6英雄也是普通人   2.5明天我该做什么   第2A章个人:演进   2A.1策略平衡   第3章团队的沟通与合作   3.1信息的对流   3.1.1延迟和机会损失成本   3.1.2尔格-秒   3.1.3渗透式沟通   3.1.4穿堂风   3.1.5信息辐射源   3.1.6热空气理论的应用   3.2跨越沟通的鸿沟   3.2.1沟通的形态   3.2.2去掉某些形态所产生的影响   3.2.3利用各种形态   3.2.4黏度与跨越空间的鸿沟   3.3团队就是集体   3.3.1友善和冲突   3.3.2工作时间的公民意识   3.3.3敌意的XP与友善的XP   3.3.4使用胜利来建立“团队”   3.3.5团队文化与亚文化   3.4团队就是生态系统   3.5我明天该做什么   第3A章团队:演进   3A.1一个修订后的办公室布局样本   第4章方法集   4.1一个交付软件的生态系统   4.2方法集中的概念   4.2.1结构术语   4.2.2范围   4.2.3概念术语   4.2.4发布一个方法集   4.3方法集的设计原则   4.3.1常见设计错误   4.3.2在方法集上成功的项目   4.3.3与作者的相关性   4.3.4七条原则   4.4细看XP   4.4.1XP简介   4.4.2剖析XP   4.4.3调整XP   4.5到底为什么使用方法集   4.5.1方法集解决什么问题   4.5.2如何评估一个方法集   4.6明天我应该做什么   第4A章方法集:演进   4A.1方法集与策略   4A.2组织级的方法集   4A.3过程就是循环   4A.4更简单地描述方法集   第5章敏捷与自适应   5.1轻但足够   5.1.1刚好足够   5.1.2对于编制文档的建议   5.2敏捷   5.2.1最佳击球点   5.2.2虚拟团队的麻烦   5.3变得自适应   5.3.1不厌其烦地进行反思   5.3.2方法集成长技术   5.3.3反思研讨会技术   5.4明天我该做什么   第5A章敏捷与自适应:演进   5A.1对于寓意的误解   5A.1.1迭代必须简短   5A.1.2敏捷团队必须驻扎在一起   5A.1.3敏捷团队不需要计划   5A.1.4架构已死;重构是你全部所需要的   5A.1.5我们不需要什么经理   5A.1.6敏捷开发在纪律上要求很低   5A.1.7敏捷只适合最优秀的开发人员   5A.1.8敏捷是既老又新的、失败的、没有尝试过的   5A.2敏捷方法集的演进   5A.2.1XP第2版   5A.2.2Scrum   5A.2.3实用主义和无名的   5A.2.4可预测、计划驱动和其他中心调整   5A.2.5约束理论   5A.2.6精益开发   5A.3新的方法集话题   5A.3.1敏捷项目管理   5A.3.2测试   5A.3.3用户体验设计   5A.3.4规划管控、Burn图和系统工程   5A.3.5用例和用户故事   5A.4经久不绝的问题   5A.4.1最佳击球点和下降   5A.4.2固定价格、固定范围的合同   5A.4.3敏捷、CMMI和ISO9001   5A.4.4何时停止建模   5A.4.5高科技/高接触的工具箱   5A.4.6敏捷的中心   5A.4.7你有多敏捷   5A.4.8引入敏捷   5A.5软件开发之外的敏捷   5A.5.1项目组合管理   5A.5.2客户关系   5A.5.3合同   5A.5.4将变更引入组织   5A.5.5程序员读哈佛商业周刊   5A.5.6建造房屋   5A.5.7机场建设   5A.5.8图书出版   5A.5.9会议组织和敏捷模型的限制   第6章Crystal方法集   6.1对Crystal家族塑形   6.1.1核心Crystal元素   6.2CrystalClear   6.2.1CrystalClear的简要描述   6.2.2CrystalClear的反思   6.3CrystalOrange   6.3.1CrystalOrange的简要描述   6.3.2CrystalOrange的反思   6.4CrystalOrangeWeb   6.4.1CrystalOrangeWeb的简要描述   6.4.2CrystalOrangeWeb的反思   6.5明天我该做什么   第6A章Crystal方法集:演进   6A.1Crystal基因代码   6A.1.1合作博弈的理念   6A.1.2方法集的重点   6A.1.3方法集设计原则   6A.1.4高度成功的项目的7个特性   6A.1.5技术与选择   6A.1.6样本方法集设计   6A.2CrystalClear   6A.3把CrystalClear扩展到Yellow   附录A敏捷软件开发宣言   附录Aa敏捷软件开发宣言和相互依赖声明   附录BNaur、Ehn、宫本武藏   附录BaNaur、Ehn、宫本武藏:演进   附录C后记   参考文献

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值