《看板方法》读书心得
软件开发的工作是无形的，不像生产线那样能看到有形的产品。所以软件开发的进度和情况对客户、对管理者来说都是一块心病，往往都不知道开发同事在忙什么、忙得怎么样了。
而借鉴自精益生产的看板管理，恰好能解决这个问题，让软件开发的工作可视化，让客户、管理者、其它团队成员能直观的看到项目的情况，有助于整个项目的价值流流动。
在这本《看板方法》中，有三个核心的概念：可视化、拉动系统、在制品限额（WIP)。
看板系统，他的定义就是：首先以价值流（Value
Stream)对软件开发生命周期的工作流程进行建模，然后建立一个可视化跟踪系统，此后，当新工作“流”经该系统时，通过跟踪其状态的变化，便可识别出瓶颈。
在实际过程当中，看板是一个工具。就像丰田生产方式的创建者之一大野耐一曾说过：“丰田生产方式的两大支柱，是及时生产和有人工介入的自动化。驱动这个体系运转的工具，便是看板。”
在软件开发过程当中，涌现出了很多编程的理论，包括从早期的瀑布模型到现在的敏捷模型，其核心就是想让软件的开发更接近工程科学的精确性和可预测性，提高软件开发的质量和减少浪费。在作者看来，软件开发成功有以下6个秘诀：
- 专业于质量
- 减少进行中的工作
- 频繁交付
- 根据交付速率来平衡需求请求量
- 进行优先级排序
- 消除变异性的根源，提升可预测性。
以上秘诀加上看板这个工具，能有效的提高软件开发的效率和成功率，提高客户满意度。
看了这本书以后，在我们预结算项目组采用了电子看板系统Trello，整体感觉还不错。知道大家都在干什么了、各项工作的进展怎么样了、瓶颈的情况是在哪里等等。并且结合每日10分钟的晨会，整个项目组对整体的工作目标及优先级、各自工作在整体工作目标中的位置和重要性都一目了然。
BTW：后来想了想，其实看板就是我们老板以前提出的地铁报站指示图，就是车辆到达一站，该站就变红色，未到的站点是绿色。房地产的全流程（价值流图），从拿地、规划、设计、报建、施工、验收、销售、物业等也是一种价值流。并且对一个地产项目来说，每个环节都有很多工作，通过看板就能简单实现（地铁那个因为只有一个红绿色，站点下面不能再分，不符合业务实际），并且每个工作都能通过定义卡片来识别工作事项、负责人、要求完成时间、当前状态、工作的前置条件、后置条件等。
以下是比较好的资料：
平安7年精益敏捷转型之路
《精益开发实战——大项目看板管理》读书笔记
文章摘要
- 精益方法是以快速高质量交付、减少浪费为目的。
- 报告准时交付的达成情况（due-date performance)
- 破坏负载（Failure Load）：因早前的质量问题引生的工作。
指返工活动，或者那些为了修复早前的不良实现而提交到看板系统中的需求开发工作。
- 大型软件开发是一场马拉松，不是短跑冲刺。
- 看板（kan-ban)是一个日语词汇，英文字面意思是“信号卡”。
- 人们只有释放组织中的大部分压力，才能够集中精力准确高质量地完成工作。
- 为了能够得到持续改善，需要具备富余时间。
- 在新系统发布一个月后，这些应用程序开发团队一般都会解散，而源代码则转交到维护团队手上。（超过15个开发或测试天数的较大请求，必须作为正式项目提交立项，按照项目进行管理。）
- 不管怎么变，情况都不会变得比当前更糟！是该有人去尝试变革了。
- 任何处于代办项列表中已经超过6个月的请求项，都可以从列表中清除出去。
- 在工作中，如果全体员工能够持续专注于提高质量、生产率和客户满意度，那么这种文化便可称为改善文化。
- 在敏捷软件开发圈子里形成的一个基本共识是，稳定的节奏十分重要。...稳定的“心跳”对于项目十分重要。
- 减小用户故事的规模，使其粒度变得更细，降低用户故事规模的变异性。
- 对于固定交付日期类的工作，团队会倾向于提早启动工作，以确保能够做到准时交付。这并非最优解。通过改善估算质量，才能提升以价值和交付速率来衡量的全局效能。
- 受到充分激励且经验丰富的员工对组织绩效有着巨大的影响，人才保留对于组织是至关重要的。
- 只有超负荷工作才能完全挖掘出知识工作者的产能----这是一种极其错误的观点。超负荷工作的状态，维持一两天或许可行，但可持续性不会超过一两周。为员工创造工作/生活平衡，决不让他们超负荷工作，这才是明智公司的经营决策。
- 在项目过程中需要舍弃一些东西进行权衡时，传统的项目经理可能会选择延期交付、增加资源投入、缩减范围或者三者不同程度的兼而有之；敏捷项目的明确共识是缩减范围，保障交付。
- 编写一个用户故事的模板：作为一名<用户>，我希望有一个<特性>，以便于<交付一些价值>。
- 同一时间只能有一个加急事项。
- lead time:交货时间 ，引申为前置时间。
backlog 积压
grooming 梳理
sprint 冲刺
