10 2018 档案

摘要:00.经常进行重规划,是敏捷规划和估计为有效探索新产品开发解决方案控件提供支持的方法之一。在每次迭代开始时,都要建立该迭代的计划。发布计划要么在每次迭代后背更新,或者最差的时候也要在每几次迭代后被更新。计划要保持有用,就需要把这些新知识结合到计划中。敏捷估计和规划过程暴露出我们的知识总是不完整的,要 阅读全文
posted @ 2018-10-21 20:37 艾小小雨 阅读(289) 评论(0) 推荐(0) 编辑
摘要:00.我们希望所有的沟通,尤其是有关估计和计划的沟通,是频繁的、诚实的和双向的。 01.在一次发布所占据的更长的时间内,项目的利益相关者和参与者需要深入了解项目相对发布计划的进度,并对计划作为修正。 02.如果缺乏信任,就很难有诚实的沟通,所以必须非常严肃地看待失去信任的行为。如果开发人员知道特定的 阅读全文
posted @ 2018-10-21 20:04 艾小小雨 阅读(140) 评论(0) 推荐(0) 编辑
摘要:00.任务板具有双重目的,它给开发小组提供了组织工作的方便机制,也是让他们对还剩多少工作一目了然的途径。重要的是任务板让开发小组在如何管理工作方面具有很大的灵活性。 01.绘制发布耗散图是了解项目是否走入歧途的很好的办法。 02.记住可变性是所有估计的组成部分。无论做了多少工作来改善估计结果,开发小 阅读全文
posted @ 2018-10-21 19:47 艾小小雨 阅读(122) 评论(0) 推荐(0) 编辑
摘要:00.规划一个大型的、多小组的项目可能需要: *建立估计的共同基准 *更早给用户故事添加细节 *进行前瞻规划 *在计划中加入馈送缓冲区 01.我从来没有使用过大于一次迭代的馈送缓冲区,也几乎没有使用过长于半次迭代的缓冲区。每当我遇到可能需要这样做的时候,我就会之一自己的假设并回顾整个计划,看看我能够 阅读全文
posted @ 2018-10-21 19:15 艾小小雨 阅读(178) 评论(0) 推荐(0) 编辑
摘要:00.她们要么具有很高的额外的不确定性,要么一旦出错就会产生更为严重的后果。 01.帕金斯定律:工作总是要拖到最后一刻才能完成。 学生综合症:是在只在快要不能成功的最后时刻才剋是做一件事。 02.进度缓冲区是在除去局部保险的估计值的和上增加的必要安全边界。 03.关于缓冲区建议: *增加进度缓冲区的 阅读全文
posted @ 2018-10-21 18:46 艾小小雨 阅读(189) 评论(0) 推荐(0) 编辑
摘要:00.历史值估计需要回答问题: *使用的技术是否一样? *所针对的领域是否一样? *开发小组是否一样? *产品所有者是否一样? *使用的工具是否一样? *工作环境是否一样? *对项目估计是否由相同的人进行? 01.把用户故事扩展成任务并对任务进行估计,重复这样做直到我们发现已经填满了可用的小时数。不 阅读全文
posted @ 2018-10-21 16:54 艾小小雨 阅读(255) 评论(0) 推荐(0) 编辑
摘要:00.选择迭代长度时考虑的因素 *正在处理的发布时间长度 *不确定性的多少 *获得反馈的难易程度 *优先级可以保持多久不变 *不用外部反馈自行工作的意愿的强弱 *迭代的系统开销 *紧迫感的产生有多快 01.在客户或用户到底想要什么、小组的速度是多少等方面,以及项目的技术方面都常常会存在不确定性。不确 阅读全文
posted @ 2018-10-21 16:22 艾小小雨 阅读(155) 评论(0) 推荐(0) 编辑
摘要:00.发布计划很重要原因: a.她可以帮助产品所有者和整个开发小组判断他们在获得一个可发布的产品之前,必须花多长时间开发多少东西。产品越早发布,开发公司就可以越早开始获得他在此项目中投资的回报 b.发布计划传递了对于在多长时间内可能开发什么内容的期望。很多公式需要这个信息,因为它可以用于其他的战略规 阅读全文
posted @ 2018-10-21 16:05 艾小小雨 阅读(418) 评论(0) 推荐(0) 编辑
摘要:00.学会如何看待分割用户故事的方法并不是一种很难获得的技能,但他确实需要实践和经验。 01.分割大用户故事的最佳方法之一就是按照它将要支持的数据进行分割。按照用户故事所支持数据的边界来分割大型用户故事。 02.CRUD操作——建立(Create)、读取(Read)、更新(Update)和删除(De 阅读全文
posted @ 2018-10-21 14:39 艾小小雨 阅读(175) 评论(0) 推荐(0) 编辑
摘要:00.预测主体的经济价值是产品所有者的责任,但是则热是和小组的其他成员——程序员、测试人员、分析员、项目经理,等等所共同承担的。 01.把来自新客户的收入和来自现有客户的额外的、增加的收入区分开,往往是有益的。 a.促进现有客户购买更多的许可 b.包含了可以独立出售的可选、附加模块 c.包含允许提高 阅读全文
posted @ 2018-10-21 14:09 艾小小雨 阅读(135) 评论(0) 推荐(0) 编辑
摘要:00.主题的价值很难确定,而且敏捷开发项目的产品所有者得到的建议往往是模糊的、最没有意义的:“要根据业务价值确定优先级”。 01.开发活动优先级时必须考虑的4个因素 a.获得这些功能带来的经济价值 b.开发新功能所需的成本 c.开发新功能所产生的学习和知识的量及重要性 d.开发这些功能所减少的风险 阅读全文
posted @ 2018-10-21 13:44 艾小小雨 阅读(131) 评论(0) 推荐(0) 编辑
摘要:00.有利于故事点的考虑因素 a.故事点有助于驱动跨功能的行为 b.故事点估计不会过期 c.故事点是纯粹对规模的度量 d.故事点估计通常更快 e.我的理想日不等于您的理想日 01.敏捷开发小组包含了来自于构建产品所需所有学科的成员,包括程序员、测试人员、产品经理、可用性设计师、分析员、数据库工程师等 阅读全文
posted @ 2018-10-21 12:03 艾小小雨 阅读(218) 评论(0) 推荐(0) 编辑
摘要:00.估计值不是由开发小组中的单个人建立的。敏捷开发小组并不是依靠某一位专家来进行估计。除了众所周知的将要做次工作的人对工作做出估计比其他人做出的更准确意外,最佳的估计是由包括将要作词工作的人在内的小组合作得到的。 01.史诗(epic):对于还不确定是否需要的功能(在投入过多的投资之前,需要首先对 阅读全文
posted @ 2018-10-19 17:13 艾小小雨 阅读(126) 评论(0) 推荐(0) 编辑
摘要:00.理想时间(ideal time)是某件事在剔除了所有外围活动之后所需要的时间。耗用时间(elapsed time)是始终上显示出流逝掉的时间。 01.理想日进行估计: a.所估计的用户故事是您将处理的唯一工作 b.您所需要的所有东西在您开始工作的时候都会准备好 c.不会被打断 02.对小组中不 阅读全文
posted @ 2018-10-19 16:41 艾小小雨 阅读(206) 评论(0) 推荐(0) 编辑
摘要:00.故事点是用来表达用户故事、功能或其他工作的总体规模的度量单位。 01.有意义的知识分配给不同用户故事的点值的相对大小。 02.故事点知识对要进行的工作的规模估计。 阅读全文
posted @ 2018-10-19 13:00 艾小小雨 阅读(250) 评论(0) 推荐(0) 编辑
摘要:00.敏捷开发过程承认每个人都具有特定的能力(以及缺点)并对之加以利用,而不是试图把所有人都当作一样。 01.敏捷开发小组认为可用软件的价值重于复杂的文档。其原因在于,可用的软件可以帮助开发人员在每次迭代结束时获得一个稳定的、逐渐增强的版本,从而允许尽早开始,并且更为频繁地收集对产品过程的反馈。 0 阅读全文
posted @ 2018-10-18 22:05 艾小小雨 阅读(776) 评论(0) 推荐(0) 编辑
摘要:00.当进度比计划快的时候,人的本性就是用多余的时间做一些对我们自己有价值,而对别人不一定有用的事。 01.规划失败的原因: a.他们强调的是各项活动的完成而不是对功能的交付。 b.多任务处理,也就是同时处理多个任务。 c.制订的计划没有按照对用户和客户所具有的价值大小来排列工作的优先级。 d.不承 阅读全文
posted @ 2018-10-18 21:48 艾小小雨 阅读(138) 评论(0) 推荐(0) 编辑
摘要:00.预算估计偏差表 2.为什么还要进行估计和规划? a.我们所在的公司通常要求我们提供对项目估计。 b.如准备市场推广、安排产品发布活动、对内部用户进行培训等,都会需要项目计划和进度表。 c.要求我们去进行困难的估计和规划活动。 3.估计和规划并不仅仅是确定一个合适的最终期限和进度表。规划(尤其是 阅读全文
posted @ 2018-10-18 21:26 艾小小雨 阅读(198) 评论(0) 推荐(0) 编辑
摘要:00.您的项目进行的怎样?遇到了令人诅丧的变化?不确定性?还是产品错过了标志点和最终期限?Mike Cohn清晰明了地展示了如何有效地开发具有高商业价值的软件。通过敏捷估计与规划,即使环境发生了变化,您仍可以将经理专注于真正需要的地方。 01.规划对任何敏捷开发项目都是不可缺少的组成部分。 02.敏 阅读全文
posted @ 2018-10-18 08:18 艾小小雨 阅读(152) 评论(0) 推荐(0) 编辑
摘要:00.非功能性需求可以表达各种系统需求 *性能(performance) *准备性(accuracy) *可移植性(portability) *可重用性(reusability) *可维护性(maintainablility) *可操作性(interoperability) *可用性(availab 阅读全文
posted @ 2018-10-15 21:25 艾小小雨 阅读(183) 评论(0) 推荐(0) 编辑
摘要:00.本用户故事源自于基线编程,所以故事能够很自然地狱基线编程的其他时间形成一个体系。不过,用户故事作为一种管理需求的方法,也可以应用到其他类型的软件过程中。 01.一轮迭代过程是一种持续改进的过程。开发团队首先针对系统的一部分开始开发。团队十分清楚系统还是不完备的,有些地方甚至比较差。 02.一个 阅读全文
posted @ 2018-10-15 21:06 艾小小雨 阅读(1053) 评论(0) 推荐(0) 编辑
摘要:00.如果感觉划分故事过于频繁,应该考虑扫描剩余的故事,找出真正需要划分的故事。 01.症状:客户不愿意写用户故事,也不愿意为故事安排优先级 讨论:在一个总是互相指责的传统组织中,很多人认为最好能够不承担任何责任。如果不用为某件事负责,也就不会由于事情的失败而被指责。更有甚者,及时是获得成功,有些人 阅读全文
posted @ 2018-10-15 20:07 艾小小雨 阅读(156) 评论(0) 推荐(0) 编辑
摘要:00.用户故事好处 a.用户故事强调口头沟通 b.人人都可以理解用户故事 c.用户故事的大小适合做计划 d.用户故事适合于迭代开发 e.用户故事鼓励延迟细节 f.用户故事支持随机应变的开发 g.用户故事鼓励参与性设计 h.用户故事传播隐性的知识 01.在尝试之前,你或者会天真地以为只需要把一堆软件需 阅读全文
posted @ 2018-10-15 19:49 艾小小雨 阅读(493) 评论(0) 推荐(0) 编辑
摘要:00.对于任何方法,总会碰到不顺的情况,我们会看看发生问题时的一些不良征兆或者信号。 01.大部分时候,当我们看到两个小组为基本相同的文档编写了单独版本时,我已经知道他们正把自己拽人到项目最后的责任推卸会议中,兵辩称自己了解文档的意图。使用用户故事时,不会犯这种愚蠢的错误。随着用交谈代替文档,团队会 阅读全文
posted @ 2018-10-15 17:09 艾小小雨 阅读(169) 评论(0) 推荐(0) 编辑
摘要:00.敏捷软件开发的一个优点就是项目开始时不需为项目需求写冗长完整的说明。 01.敏捷团队都承认客户不可能预先知道所有事情的事实。 02.每日燃尽图反应的是剩余工作量,而不是在一个故事或人物上锁话费的工作量。好处远远不能抵消记录花费时间所带来的负面作用 03.一个很有效的方法是把本章中的所有的图做得 阅读全文
posted @ 2018-10-15 16:12 艾小小雨 阅读(153) 评论(0) 推荐(0) 编辑
摘要:00.迭代计划会议的一般内容: a.讨论故事 b.从故事中分解出任务 c.开发人员承担每个任务的职责 d.讨论过所有故事,并且接受所有任务后,开发人员单独估计他们承担的任务,以确保他们不会做出过于乐观的承诺 01.迭代计划会议是客户为团队调整故事优先级的最佳时机 02.会议开始时,客户从最高优先级的 阅读全文
posted @ 2018-10-15 15:51 艾小小雨 阅读(237) 评论(0) 推荐(0) 编辑
摘要:00.开发路线图,需要回答两个问题:a.我们想在什么时候发布?b.每个故事的优先级是什么? 01.小心,不要太迷信发布计划!本描述的方法将帮助你估算项目所需的大致工期,让你可以声明“在5~7轮迭代后,可以准备发布产品”。但是,这些方法不足以精确说明“我们会在6.3完成”。 利用发布计划可以设立初始期 阅读全文
posted @ 2018-10-15 15:17 艾小小雨 阅读(353) 评论(0) 推荐(0) 编辑
摘要:00.估算故事最好方法: *无论什么时候获得有关故事的新信息,都允许我们改变之前的想法 *适用于史诗故事和小故事 *不需要花很多时间 *提供进度和剩余工作的有用信息 *不太精确的估算也不会有太大问题 *可以用来制定发布计划。 01.程序员估算时,客户也可以参加,但是他不能提供他人人的估算或者在听到自 阅读全文
posted @ 2018-10-13 14:50 艾小小雨 阅读(473) 评论(0) 推荐(0) 编辑
摘要:00.一个更好的办法是换一种方式编写故事,每个故事都提供某种程度的完整(end-to-end)的功能。 01.尽管不十分完美,即使只提供部分功能,但只要发布的功能可以跑,就可以放心地把应用程序发布给用户使用。 02.一直困扰着软件需求方法的问题之一是将需求和解决方案混在一起。 03.编写故事的职责在 阅读全文
posted @ 2018-10-13 14:25 艾小小雨 阅读(237) 评论(0) 推荐(0) 编辑
摘要:00.测试两个流程:将测试要点记录在故事卡的背面,任何时候发现新的测试,都可以记录到故事卡的背面,任何时候发现新的测试,都可以记录到故事卡的背面;将测试要点变成全面的测试,这些测试可以用来演示故事已正确、完整地实现。 01.故事编写代码钱就开始制定验收测试 *开发人员和客户讨论故事且需要记录明确的细 阅读全文
posted @ 2018-10-13 14:08 艾小小雨 阅读(435) 评论(0) 推荐(0) 编辑
摘要:00.选择合适的用户代理对于项目的成功至关重要。我们要考虑潜在用户代理的背景和动机。有营销别境的用户代理识别故事的方法,不同于领域专家担当的用户代理。重要的是要识别到这些差异。 01.用户的经理有时候是错误信息的来源。只要有可能,就要通过与实际用户交流来求证这些信息。 02.让开发经理担任用户代理, 阅读全文
posted @ 2018-10-13 11:52 艾小小雨 阅读(113) 评论(0) 推荐(0) 编辑
摘要:00.用户并不知道所有的需求,所以不能单纯依靠引出(elicitation) 01.不同大小的网用来捕获不同大小的需求。第一遍,我们可以用大网眼的渔网捞一遍需求池,一次得到所有的大需求。通过这些大需求,形成对软件的整体感觉。接下来,用网眼稍微小一些的渔网得到中等大小的需求,暂时还不用顾忌那些小需求。 阅读全文
posted @ 2018-10-13 11:14 艾小小雨 阅读(170) 评论(0) 推荐(0) 编辑
摘要:00.软件需求是一个沟通问题。需要新软件的人(使用或销售软件的人)必须与开发新软件的人进行交流。一个项目的成功,依赖于很多不同的信息,这些信息来自各有不同的人员:一方是客户和用户,有时还有分析人员、领域专家和其他从业务或组织视角来审视软件的人;另一方面是技术团队。 01.一旦任何一方在沟通中把持绝对 阅读全文
posted @ 2018-10-09 12:08 艾小小雨 阅读(195) 评论(0) 推荐(0) 编辑
摘要:00.我们贴近我们的用户,向用户展示我们一点一滴,这样便在不知不觉中发现一个不需要漂亮的需求文档就可以成功的方法。 01.a.大量预先的需求收集和文档会以很多方式导致项目失败。最常见的是需求文档编程软件开发的目的。应当只在对交付软件有用时才写需求文档 b.大量预先的需求收集和文档导致项目失败的另一个 阅读全文
posted @ 2018-10-09 11:56 艾小小雨 阅读(190) 评论(0) 推荐(0) 编辑
摘要:00.《用户故事与敏捷方法》介绍了如何编写理想的用户故事,造成用户故事不理想的原因有哪些,如果在无法与用户交流情况下有效地搜集用户故事,如果对已经写好的用户故事进行整理、排列优先级及再次基础上进行计划,管理和测试。 01.因为不同的参与者有不同的需求。项目经理想跟踪进度,开发人员想实现系统,产品经理 阅读全文
posted @ 2018-10-09 11:44 艾小小雨 阅读(142) 评论(0) 推荐(0) 编辑

点击右上角即可分享
微信分享提示