好厉害的

物联网智慧烟感报警系统+对IoT感兴趣，认真学习

微信昵称：华仔华为云账号：zhangyaohua敏捷和精益里面的另一种方法 —— 看板方法 软件领域中的看板方法包含3个原则：1.进度可视化2.限制在制品（Work-in-progress, WIP）3.观察和改善流动进度可视化，除了可以使用进度让所有人看到外，还可以识别整个交付从左到右的各道工序哪里是瓶颈。堆积最多卡处的那道工序就是瓶颈，识别瓶颈是流程改善的关键。一切瓶颈以外的改善都是徒劳的。需要跨项目、跨团队合作时，一人分饰多角时，维护类型的项目适合使用看板。在观察 看板时，我们要关注的是有没有空闲任务，而不是有没有空闲的人中同。传统的管理思维只关注是不是所有人都在忙碌，但如果人不是忙在最在价值的事情上，也是浪费。 “哈哈哈，我能让你闲着吗？ 怎么还有人有空玩手机？ 坏坏的笑笑”（下次使用JIRA时注意看下看板功能 —— Agile 或 Board  还有另一个功能 JIRA Service Desk）很是赞同李俊对常规开发的“新交付方式”：1.拥抱变化 —— 适应任何需求变化以满足业务部门的最终需求。拆分原始需求并快速交付其中最重要的部分获取反馈并及时修改。2.拆分 —— 把大的需求拆分成最小可交付需求来缩短交付时间和实现持续交付3.简化流程 —— 最终用户与IT工程师直接沟通，减少交接与签署，不再依赖繁文缛节的文档。

微信昵称：华仔华为云账号：zhangyaohua这样的编排方式，刚开始看的时候会觉得的有点啰嗦，但有时候很容易理解和进入到故事当中去。PO 和 IT团队一起开Sprint 计划会议，PO会对Product Backlog中的用户故事进行排序，选出最重要的用户故事。经过PO和IT团队的协商，确定哪些用户故事会放到在这个Sprint的Backlog里，作为Sprint的开发范围。IT团队每天会组织一次站会（昨天做了什么，今天会做什么，昨天遇到了什么问题），要控制到15到20分钟。Sprint结束的时候，PO和IT团队又聚在一起开Sprint评审会议，IT团队向PO展示这个Sprint的交付，PO有任何反馈，甚至需求变更都可以定义成新的用户故事放到Product Backlog里重新排队，这也是敏捷应对需求变化的方法。又一次的看到敏捷宣言：1.个体与交互胜于过程与工具2.可工作的软件胜于面面俱到的文档3.与客户的协作胜于基于合同的谈判4.响应变化胜于遵循计划敏捷所有的改变，就是为了一件事情 —— 快速反馈：1.短迭代开发 —— 让PO更快、更早地看到成品，给予反馈； 2.每日站会 —— 每天都能看到进度和阻碍3.回顾会议 —— 每个迭代都反思改进点，形成持续改善的机制。其实一个小的团队还是比较容易执行敏捷的，可以从某一个小改进开始，比如：每日的会议，我觉得不一定要站点开吧！！！有个一单词Sprint拼写成Spring了。在第二章的末尾，王章给出敏捷启动建议的第4点中。

微信昵称：华仔华为云账号：zhangyaohua就如推荐序中所说“似曾相识”，在本书中找到了那些领导、客户、同行、同事，当然还有自己。启动方案：1.全面扫盲2.体察民情3.教育客户管理层自上而下的推动力对敏捷转型的重要性。这一点非常重要，如果变革得不到管理层的认可，几乎不可能实现。瀑布模型下，业务部门的痛点：1.逾期交付2.超支3.看到成品时项目已接近尾声4.缺乏透明度，不知道具体进度5.很难变更需求6.最终发现开发出来的产品不是他们想要的7.贻误战机，丢失市场机会那IT部门的痛点：1.过度承诺2.难以一次性消化所有需求3.惧怕需求变更4.不断重复5.后期压力巨大6.加班！加班！加班！敏捷开发的流行的开发方法论：Scrum、极限编程、看板方法。Scrum引入若干个新的概念：Product Owner (PO) —— 用户/客户/业务的代言人，就是可以做出业务决策的人Scrum Master —— 熟悉Scrum流程的人，指导和确保团队以Scrum的方式进行交付，敏捷教练User Story —— 用户故事。具有业务价值的交付单位，一个项目/产品是由很多用户故事构成的。Product backlog —— 可以理解为项目的代办列表，由用户故事构成。Sprint Backlog —— 一个Sprint的待办列表，确定Sprint里有哪些用户故事，框定Sprint 的开发范围。补充：第二章中有个错误字”代办列表“，应该是”待办列表“吧？

华为云账号：zhangyaohua微信昵称：华仔截图：

微信昵称：华仔华为云账号：zhangyaohuaDay03精益需求管理 用户画像（Persona)是根据用户的社会属性、生活习惯和消费行为等信息而抽象出的某个用户群体的细节特性描述Backlog item的优先级：MoSCoW:Must HaveShould HaveCould HaveWon't Have不同粒度的需求：EPIC 史诗级Story 用户故事级3CsCard 卡片Conversation 讨论Confirmation 确认用户故事是从用户角度描述产品条目的方式用户故事的原则I Independent 独立的N Negotiable 协商的V Valuable 有价值的 （架构开发、前端页面不属于用户故事）E Estimable 可估算的S Small  T Testable 可测试的被验收的用户故事拆分用户故事太大，不能放到一个sprint 里完成拆分方法：按照操作步骤按照角色/ Persona按照数据域按照输入方法 Day04看板：加速价值流动看板方法的六个实践：可视化工作流程限制在制品数量（在制品： Work In Progress ，简称WIP）度量和管理工作流显示化定义规则构建反馈环用科学方法和模型评估改进机会，提升协作，实验性演进利用约束理论识别和管理瓶颈：第一步： 识别约束（瓶颈）第二步： 决定如何最大化利用约束（瓶颈）资源第三步： 所有其他活动服从于第二步的各种措施第四步： 提升约束（瓶颈）的效能第五步： 如果约束（瓶颈）已经突破，回到步骤1），别让惰性成为约束，持续不断地改善DevCloud中项目规划的逐级关系是Epic > Feature > Story > Task DevCloud项目管理用户的角色类型不包含Scrum Master给自己留下几个问题，继续学习：如何有效的保存并传递有用的文档，文档在什么时间点补充？由谁来编制、审核？Scrum master 的职责是什么或者说是他的主要工作是什么，由原项目团队中的哪些角色的人担任比较好？燃尽图的具体怎么看？ 如何更好的理解、控制迭代？

微信昵称：华仔华为云账号：zhangyaohuaDay02 敏捷转型的主流实践：Scrum VS 看板第二天的自测题尽然错在了人员角色及分工上，没搞清楚 scrum master 主要职责，特别是与产品经理、项目经理容易混为一谈。Scrum包括三个角色，分别是：产品负责人（Product Owner）主要负责确定产品的功能和达到要求的标准，指定软件的发布日期和交付的内容，同时有权力接受或拒绝开发团队的工作成果。流程管理员（Scrum Master）主要负责整个Scrum流程在项目中的顺利实施和进行，以及清除挡在客户和开发工作之间的沟通障碍，使得客户可以直接驱动开发。开发团队（Scrum Team）主要负责软件产品在Scrum规定流程下进行开发工作，人数控制在5~10人左右，每个成员可能负责不同的技术方面，但要求每成员必须要有很强的自我管理能力，同时具有一定的表达能力；成员可以采用任何工作方式，只要能达到Sprint的目标。Scrum方法是本意是共享目标，团队为完成一个共同的目标。包括三个角色：product owner、 scrum master、 scrum teamScrum Master 负责Scrum的成功实施，具体主持Scrum流程/去除障碍/保护团队不受外界干扰/领导团队自管理并持续改进 （清道夫/保护者）步骤：1.sprint plan 2.迭代式的开发（每日站立会议） 3.sprint review 4.sprint回顾 反思改进看板方法是一种增量式、渐进式地组织过程改进方法看板：可视化流程管理系统，提示团队生产什么，何时生产，生产多少看板方法的四个原则 ：从现在的工作方式开始实施渐进式变革启动时，尊重现有的角色、职称和工作职责 鼓励各级领导力Scrum的任务板：SprintBacklog  > ToDo > Doing >  Done看板示例：Backlog > 准备好 > 开发（进行中、完成） > 测试（进行中、完成） > 验收（进行中、完成） > 上线看板，限制在制品，来控制团队不要过载（开发不超过5个）。共同点都是敏捷方法都是拉动式的工作方式都用任务板做可视化管理都基于任务板或看板召开每日站会都鼓励团队自组织都关注价值的快速流动实际项目中应该怎么选择？1.Scrum方法 ： 新产品开发、业务需求变动可以固定迭代周期、拥抱变革，变革风险承受能力强的组织。2.看板方法 ：  服务类、维护类、技术预研的项目、业务 需求变动无法固定迭代周期、保守型企业、变革风险承受能力弱的组织 Scrumban 是组织或团队在使用Scrum框架的情况下结合看板原则和方法的应用，做渐进式过程改进方法。

微信昵称：华仔华为云账号：zhangyaohua学《Day01 敏捷转型的系统方法》后：这是我又一次的学习了敏捷开发，我最早接触是在10几年前了，那时刚入行，团队一位师兄带着学习了，但完全不知道她的好处（还听说了极限编程、结队编程）。这算是我第三次接触了，我们公司小、团队小从整体上去学习、推行敏捷暂时还不需要，但可以从一个小项目试着实行或者说是练习。在这10几年中间接触了瀑布式的开发，也有幸学习了CMMI的知识。与CMMI相比他们也有一定的共同之处。都是在改变组织文化，同样需要领导层的足够支持，就是老师所讲的Top3挑战：改变组织文化人们对组织变革的抵制管理层没有给予足够的支持这次我站在了赞同推行、使用敏捷的阵营，因为我希望交付客户满意的软件、愿意看到能够满足客户业务需求的软件产品交付、希望看到客户那认可、满意的目光。敏捷宣言：个体和交互 重于 过程和工具可工作的软件 重于 面面俱到的文档客户合作 重于 合同谈判响应变化 重于 遵循计划虽然右项也具有价值，但我们认为左项具有更大的价值。老师讲非常好，按照老师的步骤执行就好：敏捷实践敏捷思想敏捷文化长线规划：团队级敏捷产品级敏捷企业级敏捷

微信昵称：华仔华为云账号：zhangyaohua