2018年10月_艾-小小雨

原创 22.敏捷估计与规划——Why Agile Planning Works笔记

 00.经常进行重规划，是敏捷规划和估计为有效探索新产品开发解决方案控件提供支持的方法之一。在每次迭代开始时，都要建立该迭代的计划。发布计划要么在每次迭代后背更新，或者最差的时候也要在每几次迭代后被更新。计划要保持有用，就需要把这些新知识结合到计划中。敏捷估计和规划过程暴露出我们的知识总是不完整的，要求随着我们了解更多的知识来修正计划。 01.基于功能而不是基于...

2018-10-21 20:37:00 302

原创 21.敏捷估计与规划——Communicating about Plans笔记

 00.我们希望所有的沟通，尤其是有关估计和计划的沟通，是频繁的、诚实的和双向的。 01.在一次发布所占据的更长的时间内，项目的利益相关者和参与者需要深入了解项目相对发布计划的进度，并对计划作为修正。 02.如果缺乏信任，就很难有诚实的沟通，所以必须非常严肃地看待失去信任的行为。如果开发人员知道特定的任务需要的时间比当前的预期长得多，他应该感到与包括经理在内...

2018-10-21 20:04:00 211

原创 20.敏捷估计与规划——Monitoring the Iteration plans笔记

 00.任务板具有双重目的，它给开发小组提供了组织工作的方便机制，也是让他们对还剩多少工作一目了然的途径。重要的是任务板让开发小组在如何管理工作方面具有很大的灵活性。 01.绘制发布耗散图是了解项目是否走入歧途的很好的办法。 02.记住可变性是所有估计的组成部分。无论做了多少工作来改善估计结果，开发小组从来都不可能进行完美地估计。 03.如果我被迫要在独...

2018-10-21 19:47:00 229

原创 18.规划多小组的项目——Planning the Multiple-Team Project笔记

 00.规划一个大型的、多小组的项目可能需要：　　*建立估计的共同基准　　*更早给用户故事添加细节　　*进行前瞻规划　　*在计划中加入馈送缓冲区　　01.我从来没有使用过大于一次迭代的馈送缓冲区，也几乎没有使用过长于半次迭代的缓冲区。每当我遇到可能需要这样做的时候，我就会之一自己的假设并回顾整个计划，看看我能够做些什么来缩短吧交付功能从一个小组传递到另一...

2018-10-21 19:15:00 229

原创 17.敏捷估计与规划——Buffering Plans for Uncertainty笔记

 00.她们要么具有很高的额外的不确定性，要么一旦出错就会产生更为严重的后果。 01.帕金斯定律：工作总是要拖到最后一刻才能完成。　　学生综合症:是在只在快要不能成功的最后时刻才剋是做一件事。 02.进度缓冲区是在除去局部保险的估计值的和上增加的必要安全边界。 03.关于缓冲区建议：　　*增加进度缓冲区的时候，应使用本章所描述的两估计值的方法，或者确...

2018-10-21 18:46:00 153

原创 16.敏捷估计与规划——Estimating Velocity笔记

 00.历史值估计需要回答问题：　　*使用的技术是否一样?　　*所针对的领域是否一样？　　*开发小组是否一样？　　*产品所有者是否一样？　　*使用的工具是否一样？　　*工作环境是否一样？　　*对项目估计是否由相同的人进行？　01.把用户故事扩展成任务并对任务进行估计，重复这样做直到我们发现已经填满了可用的小时数。不需要按照优先级顺序来扩展故事。您真...

2018-10-21 16:54:00 532

原创 15.敏捷估计与规划——Selecting an Iteration Length笔记

 00.选择迭代长度时考虑的因素　　*正在处理的发布时间长度　　*不确定性的多少　　*获得反馈的难易程度　　*优先级可以保持多久不变　　*不用外部反馈自行工作的意愿的强弱　　*迭代的系统开销　　*紧迫感的产生有多快 01.在客户或用户到底想要什么、小组的速度是多少等方面，以及项目的技术方面都常常会存在不确定性。不确定性越多，无论是哪种类型，迭代就应...

2018-10-21 16:22:00 105

原创 13.敏捷估计与规划——Release Planning Essentials笔记

 00.发布计划很重要原因：　　a.她可以帮助产品所有者和整个开发小组判断他们在获得一个可发布的产品之前，必须花多长时间开发多少东西。产品越早发布，开发公司就可以越早开始获得他在此项目中投资的回报　　b.发布计划传递了对于在多长时间内可能开发什么内容的期望。很多公式需要这个信息，因为它可以用于其他的战略规划活动　　c.发布计划可以作为项目小组前进的路标。如果没...

2018-10-21 16:05:00 917

原创 12.敏捷估计与规划——Splitting User Stories笔记

 00.学会如何看待分割用户故事的方法并不是一种很难获得的技能，但他确实需要实践和经验。 01.分割大用户故事的最佳方法之一就是按照它将要支持的数据进行分割。按照用户故事所支持数据的边界来分割大型用户故事。 02.CRUD操作——建立（Create）、读取(Read)、更新(Update)和删除（Delete）---边界来分割用户故事。 03.不要把大型...

2018-10-21 14:39:00 185

原创 10.敏捷估计与规划——Financial Prioritization笔记

 00.预测主体的经济价值是产品所有者的责任，但是则热是和小组的其他成员——程序员、测试人员、分析员、项目经理，等等所共同承担的。 01.把来自新客户的收入和来自现有客户的额外的、增加的收入区分开，往往是有益的。　　a.促进现有客户购买更多的许可　　b.包含了可以独立出售的可选、附加模块　　c.包含允许提高收费的功能　　d.促进对咨询服务 02.把将...

2018-10-21 14:09:00 121

原创 09.敏捷估计与规划——Prioritizing Themes笔记

 00.主题的价值很难确定，而且敏捷开发项目的产品所有者得到的建议往往是模糊的、最没有意义的：“要根据业务价值确定优先级”。 01.开发活动优先级时必须考虑的4个因素　　a.获得这些功能带来的经济价值　　b.开发新功能所需的成本　　c.开发新功能所产生的学习和知识的量及重要性　　d.开发这些功能所减少的风险 02.产品知识就是关于要开发什么的知识。这...

2018-10-21 13:44:00 144

原创 08.敏捷估计与规划——Choosing between Story Points and Ideal Days笔记

 00.有利于故事点的考虑因素　　a.故事点有助于驱动跨功能的行为　　b.故事点估计不会过期　　c.故事点是纯粹对规模的度量　　d.故事点估计通常更快　　e.我的理想日不等于您的理想日 01.敏捷开发小组包含了来自于构建产品所需所有学科的成员，包括程序员、测试人员、产品经理、可用性设计师、分析员、数据库工程师等。 02.以故事点方式进行的估计比以理...

2018-10-21 12:03:00 189

原创 06.敏捷估计与规划——Techniques for Estimating笔记

 00.估计值不是由开发小组中的单个人建立的。敏捷开发小组并不是依靠某一位专家来进行估计。除了众所周知的将要做次工作的人对工作做出估计比其他人做出的更准确意外，最佳的估计是由包括将要作词工作的人在内的小组合作得到的。 01.史诗(epic)：对于还不确定是否需要的功能（在投入过多的投资之前，需要首先对它进行初步的成本估计）或者在最近不会实现的功能，写一个更大型的...

2018-10-19 17:13:00 196

原创 05.敏捷估计与规划——Estimating in ideal Days笔记

 00.理想时间(ideal time)是某件事在剔除了所有外围活动之后所需要的时间。耗用时间(elapsed time)是始终上显示出流逝掉的时间。 01.理想日进行估计：　　a.所估计的用户故事是您将处理的唯一工作　　b.您所需要的所有东西在您开始工作的时候都会准备好　　c.不会被打断 02.对小组中不同角色的强调，会让小组成员的想法偏离“我们是一...

2018-10-19 16:41:00 521

原创 04.敏捷估计与规划——Estimation Size with Story Poinst笔记

 00.故事点是用来表达用户故事、功能或其他工作的总体规模的度量单位。 01.有意义的知识分配给不同用户故事的点值的相对大小。 02.故事点知识对要进行的工作的规模估计。 ...

2018-10-19 13:00:00 203

原创 03.敏捷估计与规划——An Agile Approach笔记

 00.敏捷开发过程承认每个人都具有特定的能力(以及缺点)并对之加以利用，而不是试图把所有人都当作一样。 01.敏捷开发小组认为可用软件的价值重于复杂的文档。其原因在于，可用的软件可以帮助开发人员在每次迭代结束时获得一个稳定的、逐渐增强的版本，从而允许尽早开始，并且更为频繁地收集对产品过程的反馈。 02.寻求客户合作的价值重于对合同的谈判。原因在于敏捷开发小...

2018-10-18 22:05:00 230

原创 02.敏捷估计与规划——Why Planning Fails笔记

 00.当进度比计划快的时候，人的本性就是用多余的时间做一些对我们自己有价值，而对别人不一定有用的事。 01.规划失败的原因：　　a.他们强调的是各项活动的完成而不是对功能的交付。　　b.多任务处理，也就是同时处理多个任务。　　c.制订的计划没有按照对用户和客户所具有的价值大小来排列工作的优先级。　　d.不承认不确定性的存在。　　e.在每个估计中都包含...

2018-10-18 21:48:00 125

原创 02.敏捷估计与规划—The Purpose of Planning笔记

 00.预算估计偏差表 2.为什么还要进行估计和规划？　　a.我们所在的公司通常要求我们提供对项目估计。　　b.如准备市场推广、安排产品发布活动、对内部用户进行培训等，都会需要项目计划和进度表。　　c.要求我们去进行困难的估计和规划活动。 3.估计和规划并不仅仅是确定一个合适的最终期限和进度表。规划（尤其是一个正在进行的迭代方式的规划）是对价值的探求...

2018-10-18 21:26:00 212

原创 01.敏捷估计与规划——前言笔记

 00.您的项目进行的怎样？遇到了令人诅丧的变化？不确定性？还是产品错过了标志点和最终期限？Mike Cohn清晰明了地展示了如何有效地开发具有高商业价值的软件。通过敏捷估计与规划，即使环境发生了变化，您仍可以将经理专注于真正需要的地方。 01.规划对任何敏捷开发项目都是不可缺少的组成部分。 02.敏捷开发方法强调实际交付价值而不是做出一些非凡的但是无法实现...

2018-10-18 08:18:00 157

原创 16.用户故事与敏捷方法——其他话题笔记

 00.非功能性需求可以表达各种系统需求　　*性能（performance）　　*准备性(accuracy)　　*可移植性(portability)　　*可重用性(reusability)　　*可维护性(maintainablility)　　*可操作性(interoperability)　　*可用性(availablility)　　*易用性(usab...

2018-10-15 21:25:00 121

原创 15.用户故事与敏捷方法——Scrum与用户故事笔记

 00.本用户故事源自于基线编程，所以故事能够很自然地狱基线编程的其他时间形成一个体系。不过，用户故事作为一种管理需求的方法，也可以应用到其他类型的软件过程中。 01.一轮迭代过程是一种持续改进的过程。开发团队首先针对系统的一部分开始开发。团队十分清楚系统还是不完备的，有些地方甚至比较差。 02.一个递增的软件过程是指团队按照功能点开发和发布软件。每个功能点...

2018-10-15 21:06:00 521

原创 14.用户故事与敏捷方法——用户故事不良征兆一览笔记

 00.如果感觉划分故事过于频繁，应该考虑扫描剩余的故事，找出真正需要划分的故事。 01.症状：客户不愿意写用户故事，也不愿意为故事安排优先级　　　讨论：在一个总是互相指责的传统组织中，很多人认为最好能够不承担任何责任。如果不用为某件事负责，也就不会由于事情的失败而被指责。更有甚者，及时是获得成功，有些人也会吹毛求疵地区指责不足之处。处在这种文化氛围中的个人往...

2018-10-15 20:07:00 151

原创 13.用户故事与敏捷方法——用户故事的优势笔记

 00.用户故事好处　　a.用户故事强调口头沟通　　b.人人都可以理解用户故事　　c.用户故事的大小适合做计划　　d.用户故事适合于迭代开发　　e.用户故事鼓励延迟细节　　f.用户故事支持随机应变的开发　　g.用户故事鼓励参与性设计　　h.用户故事传播隐性的知识 01.在尝试之前，你或者会天真地以为只需要把一堆软件需求写下来，开发人员就能够精确地...

2018-10-15 19:49:00 192

原创 12.用户故事与敏捷方法——故事不是什么笔记

 00.对于任何方法，总会碰到不顺的情况，我们会看看发生问题时的一些不良征兆或者信号。 01.大部分时候，当我们看到两个小组为基本相同的文档编写了单独版本时，我已经知道他们正把自己拽人到项目最后的责任推卸会议中，兵辩称自己了解文档的意图。使用用户故事时，不会犯这种愚蠢的错误。随着用交谈代替文档，团队会发现没有必要追求一成不变。看起来像合同的文档总是让人觉得他是不...

2018-10-15 17:09:00 110

原创 11.用户故事与敏捷方法——测量并监控速率笔记

 00.敏捷软件开发的一个优点就是项目开始时不需为项目需求写冗长完整的说明。 01.敏捷团队都承认客户不可能预先知道所有事情的事实。 02.每日燃尽图反应的是剩余工作量，而不是在一个故事或人物上锁话费的工作量。好处远远不能抵消记录花费时间所带来的负面作用 03.一个很有效的方法是把本章中的所有的图做得很大并且放在大家都可以看到的地方。如果公司内部有绘图仪...

2018-10-15 16:12:00 129

原创 10.用户故事与敏捷方法——迭代计划笔记

 00.迭代计划会议的一般内容：　　a.讨论故事　　b.从故事中分解出任务　　c.开发人员承担每个任务的职责　　d.讨论过所有故事，并且接受所有任务后，开发人员单独估计他们承担的任务，以确保他们不会做出过于乐观的承诺 01.迭代计划会议是客户为团队调整故事优先级的最佳时机 02.会议开始时，客户从最高优先级的故事开始。读给开发人员听。然后由开发人员提...

2018-10-15 15:51:00 290

原创 09.用户故事与敏捷方法——发布计划笔记

 00.开发路线图，需要回答两个问题：a.我们想在什么时候发布？b.每个故事的优先级是什么？ 01.小心，不要太迷信发布计划！本描述的方法将帮助你估算项目所需的大致工期，让你可以声明“在5~7轮迭代后，可以准备发布产品”。但是，这些方法不足以精确说明“我们会在6.3完成”。　　利用发布计划可以设立初始期望，但之后如果获得新的信息，应该不断重新调整期望。监控每轮...

2018-10-15 15:17:00 124

原创 08.用户故事与敏捷方法——估算用户故事笔记

 00.估算故事最好方法：　　*无论什么时候获得有关故事的新信息，都允许我们改变之前的想法　　*适用于史诗故事和小故事　　*不需要花很多时间　　*提供进度和剩余工作的有用信息　　*不太精确的估算也不会有太大问题　　*可以用来制定发布计划。 01.程序员估算时，客户也可以参加，但是他不能提供他人人的估算或者在听到自己不赞成的估算时发表意见。 02....

2018-10-13 14:50:00 404

原创 07.用户故事与敏捷方法——优秀用户故事准则笔记

 00.一个更好的办法是换一种方式编写故事，每个故事都提供某种程度的完整（end-to-end）的功能。 01.尽管不十分完美，即使只提供部分功能，但只要发布的功能可以跑，就可以放心地把应用程序发布给用户使用。 02.一直困扰着软件需求方法的问题之一是将需求和解决方案混在一起。 03.编写故事的职责在于客户，不能转嫁给开发人员。 04.故事卡的主要目...

2018-10-13 14:25:00 166

原创 06.用户故事与敏捷方法--用户故事验收测试笔记

 00.测试两个流程：将测试要点记录在故事卡的背面，任何时候发现新的测试，都可以记录到故事卡的背面，任何时候发现新的测试，都可以记录到故事卡的背面；将测试要点变成全面的测试，这些测试可以用来演示故事已正确、完整地实现。 01.故事编写代码钱就开始制定验收测试　　*开发人员和客户讨论故事且需要记录明确的细节时　　*在迭代开始时，在写代码钱作为一项专门的任务　...

2018-10-13 14:08:00 294

原创 05.用户故事与敏捷方法--与用户代理合作笔记

 00.选择合适的用户代理对于项目的成功至关重要。我们要考虑潜在用户代理的背景和动机。有营销别境的用户代理识别故事的方法，不同于领域专家担当的用户代理。重要的是要识别到这些差异。 01.用户的经理有时候是错误信息的来源。只要有可能，就要通过与实际用户交流来求证这些信息。 02.让开发经理担任用户代理，是最坏的选择之一，除非你们开发的软件就是给开发经理用的。尽...

2018-10-13 11:52:00 129

原创 04.用户故事与敏捷方法--搜集故事笔记

 00.用户并不知道所有的需求，所以不能单纯依靠引出（elicitation） 01.不同大小的网用来捕获不同大小的需求。第一遍，我们可以用大网眼的渔网捞一遍需求池，一次得到所有的大需求。通过这些大需求，形成对软件的整体感觉。接下来，用网眼稍微小一些的渔网得到中等大小的需求，暂时还不用顾忌那些小需求。 02.拖网表达了另一个含义：需求会想鱼一样，会成长，也可...

2018-10-13 11:14:00 154

原创 01.用户故事与敏捷方法——起步笔记

 00.软件需求是一个沟通问题。需要新软件的人（使用或销售软件的人）必须与开发新软件的人进行交流。一个项目的成功，依赖于很多不同的信息，这些信息来自各有不同的人员：一方是客户和用户，有时还有分析人员、领域专家和其他从业务或组织视角来审视软件的人；另一方面是技术团队。 01.一旦任何一方在沟通中把持绝对地位，项目就会遭受损失。　　如果业务方把持绝对地位，他们就会...

2018-10-09 12:08:00 381

原创 00-B.用户故事与敏捷方法前言笔记

 00.我们贴近我们的用户，向用户展示我们一点一滴，这样便在不知不觉中发现一个不需要漂亮的需求文档就可以成功的方法。 01.a.大量预先的需求收集和文档会以很多方式导致项目失败。最常见的是需求文档编程软件开发的目的。应当只在对交付软件有用时才写需求文档　　b.大量预先的需求收集和文档导致项目失败的另一个方式是记录语言的不准确性。　　c.对于表达像软件这么复杂...

2018-10-09 11:56:00 135

原创 00-A.用户故事与敏捷方法序言笔记

 00.《用户故事与敏捷方法》介绍了如何编写理想的用户故事，造成用户故事不理想的原因有哪些，如果在无法与用户交流情况下有效地搜集用户故事，如果对已经写好的用户故事进行整理、排列优先级及再次基础上进行计划，管理和测试。 01.因为不同的参与者有不同的需求。项目经理想跟踪进度，开发人员想实现系统，产品经理向要灵活性，测试人员想要度量，而用户想要一个可用的系统。 ...

2018-10-09 11:44:00 121

艾小小雨的博客