.从师弟的日报中copy的个人认为非常详细充实之后会自己复盘并把这个与自己的做一个对比

什么是敏捷开发?

• 1、本体
• 
  
•     a..形式：一种思想（像一个宗教）
• 
  
•     b.概念：使用结果导向，进行高效的沟通合作，从而达到去文档化，去流程化。
• 
  
•     c.缺点：去文档化：管理者需要维护更为精细的需求池。去流程化：对团队的耦合度要求较高。
• 
  
•     d.重点词汇
• 
  
•      sprint:短跑冲刺，一个个sprint首尾相连，构成一个项目.分析：所以具有周期性。
•      scrum：一股脑争球的战术.分析：全员统一结果导向
•      Product backlog：主要记录待开发任务和任务优先级。分析：项目主管（多由产品经理）对每个具体项目有深入了解，然后根据协商来对每个项目进行细节分层，然后列表完成需求池。
•      story board：故事模板：一个完整的产品流程，通过可视化的逻辑流程来向项目组传达来进度。分析：由于产品的应需求而生，所以故事模板能够帮助项目组组员明白自己的任务效果及优先级，甚至可以在每个阶段添加反馈的环节来不断改进模板。
•      bum down chart(燃尽图）：人/时是一个固定值，一个将流程结合时间的可视化记录图表。分析：便于区分任务的优先级及安排协作，相当于故事模板的 逆向图表，和故事模板有异曲同工之妙。
• 
  
• 2.必要条件：
  
• 
  
• a.scrum master.(敏捷教练），建立需求池——>计划完成时间——>分解需求优先级及任务操作——>开会与小组成员讨论完善项目流程。——>评估需求池及预计时间——>建立故事模板——>绘制燃尽图。
• 
  
• b.每日站会：1.总结昨日问题2.根据昨日问题，调整余下时间及操作3，测试完成功能
• 
  
• c.敏捷开发对于各组员的要求：此岗位人员具有敏捷思维或者此岗位人员一起加入每一个流程中合作，列如：设计师、派送员、客服
• 
  
• d.敏捷开发需要文档吗？
• 敏捷开发只需要必要的文档:产品文档（产品逻辑）概要文档（功能解释）.接口文档（接口说明）
• 
  
• 3.归纳特点：
• 
  
• 文档的存在是为了协调记录每个个体一起完成同一个项目，而人数则增加了每个个体的耦合难度，流程的长度则决定了记录的重要性。所以需要人数越少流程越短的项目敏捷开发效果越好。如果人数多流程长的巨无霸项目，那么我们把它分解成一个个小敏捷项目就好。实际即使只有一个人开发产品，你会发现依然需要敏捷开发的每个步骤，所以敏捷开发只是假设团队只有你一个人时你所必要的开发产品流程操作而已。
• 
  
• 4、延伸材料
  
• 《Manifesto for Agile       Software Development》（敏捷宣言）
• 4个核心价值：个体和互动高于流程和工具、工作的软件高于详尽的文档、客户合作高于合同谈判、响应变化高于遵循计划
• 12原则：
• 1.通过早期和连续型的高价值工作交付满足“客户”。
• 2.大工作分成可以迅速完成的较小组成部分。
• 3.识别最好的工作是从自我组织的团队中出现的，
• 4.为积极员工提供他们需要的环境和支持，并相信他们可以完成工作。
  5.创建可以改善可持续工作的流程。
  6.维持完整工作的不变的步调。
  7.欢迎改变的需求，即使是在项目后期。
  8.在项目期间每天与项目团队和业务所有者开会。
  9.在定期修正期，让团队反映如何能高效，然后进行相应地行为调整。
  10.通过完成的工作量计量工作进度。
  11.不断地追求完善。
  12.利用调整获得竞争优势。

二.如何做需求分析？

笔记总结：

• 所以，我们做需求分析的流程应该是：

1.收集用户需求，用七宗罪（人性）来判断用户需求背后的动机

2.筛选掉伪需求，使用马斯洛理论进行进一步推导

3.模拟用户的环境、行为调整结果

4.结合我们的生产资料，再进行最后调整。

5.锁定目标用户，持续进行反馈更新。

6.对于需求价值的判断应该在上面每一步的选取调整时介入四要素。

三、怎么理解程序员会写出Bug这种事情，可不可以要求他们做到无Bug交付？怎么衡量Bug的修复时间和项目的上线时间冲突问题？ 

a.正确的代码，在某些环境中会变成BUG；正确的代码，在某些人眼中，会视为BUG；正确的代码，在上完线以后，会引起BUG。只要某些事物被至于某系统中，与其他事物配合驱动运行，而系统作为一个动态变量，则此事物永远无法摆脱BUG。从细节上讲：不止是程序员，同样我们的客服、外卖的配送员、哪怕是厨师都不能避免BUG的出现，所以我们要随时准备着应对方案。从宏观上讲，我们的世界是动态的、变化的、市场也因此有了活了和竞争力，所以有些正确的事会变成BUG，但是解决他们，正是我们的能力。可以要求他们

b.假设开始没提，后来发现，就是需求;假设开始提了，后来没做，就成了BUG。所以BUG并非执行者（程序员、外卖员、司机、厨师等）一方的事，无BUG本身就涉及到执行者和交付者，那么跟执行者的监督、沟通及指导就变得非常重要，作为产品经理，我们有责任能够让每一个协作者来共同朝着无BUG这个目标工作。当然也基本都是要求他们做到无BUG交付，可是你敢不测试吗？

c.项目的上线时间是有参考量的，就是在这个时间上线，我们的目标是什么？我们会得到什么？我们会损失什么？如果BUG的存在让我们的损失大于我们预期得到的，或者让我们不损失但是也无法完成根据时间制定的目标，那么我们上线就没有任何意义，当然以修复BUG为准，然后再次制定符合的时间。反之亦然。