敏捷开发日常跟进系列之1-6
敏捷开发流程的8个步骤
敏捷开发流程的8个步骤
1、目标制定，目标对齐：通过市场调研、业务思路、风险评估制定公司规划和目标，根据这一目标产生所有部门的目标并实现对齐；
2、产品规划：产品研发部门根据目标制定产品关键路线图，这个路线图中分布着不同的产品特性和其完成时间；
3、组织产品待办列表：产品规划产生的需求、客户需求、市场人员收集到的缺陷等将组成产品待办列表；
4、需求梳理：然后产品负责人(Product Ower)对这个列表进行梳理，并在需求梳理会(Backlog Grooming Meeting)讲解具体每一个需求，团队成员根据需求的复杂程度评估每个任务的工作量，输出本次迭代的待办事项列表，完成优先级排序等工作；
5、迭代规划：通过Sprint计划会，明确要执行的工作、冲刺目标等，
6、迭代开发：期间会进行每日站会、性能测试、CodeReview、Demo、测试等工作；
7、Sprint评审：由每个任务的负责人演示其完整的工作，由PO确定Sprint目标是否完成，版本什么时候对外发布，新增bug的紧急程度等等。
8、开回顾会议：回顾会议由Scrum团队检视自身在过去的Sprint的表现，包括人、关系、过程、工具等，思考在下一个Sprint中怎么样可以表现得更好，更高效，怎么样可以和团队合作地更愉快。
敏捷开发方法教程
敏捷开发方法教程敏捷开发（Agile Development）是一种以人为核心、快速迭代、灵活应变的软件开发方法。
它强调团队协作、持续交付和快速反馈，可帮助开发团队更好地应对需求的变化，提高项目的成功率。
本教程将介绍敏捷开发的基本原则、常用方法和最佳实践，帮助读者全面了解敏捷开发的精髓。
一、敏捷开发简介敏捷开发起源于1990年代的极限编程（Extreme Programming）方法，在过去几十年中不断演化和发展。
与传统的瀑布模型相比，敏捷开发注重快速迭代和用户参与，能够更好地应对需求变化和项目风险。
二、敏捷开发原则敏捷开发遵循以下核心原则：1. 个体和互动高于流程和工具：注重团队协作和沟通，激发创造力和创新。
2. 可以工作的软件高于详尽的文档：通过快速迭代交付价值，提供及时的产品演示和用户反馈。
3. 客户合作高于合同谈判：与客户积极合作，灵活应对需求变化和优先级调整。
4. 响应变化高于遵循计划：在需求变化时调整方向，保持高度灵活性和可调整性。
三、敏捷开发方法敏捷开发有多种方法和框架，下面介绍几种常用的方法：1. 极限编程（Extreme Programming，简称XP）：强调团队合作、持续集成和测试驱动开发（TDD）等实践，推崇简单和高质量的设计。
2. Scrum：通过定义角色、仪式和工件等，实现实时掌控项目进度和风险。
将项目拆分为若干个迭代周期（Sprint），每个迭代周期都可以交付部分功能。
3. 敏捷建模（Agile Modeling）：强调可视化和简化的建模技术，帮助团队更好地理解问题和需求。
4. 结对编程（Pair Programming）：两位开发者合作完成一个编码任务，提高代码质量和团队协作效率。
四、敏捷开发实践实践是敏捷开发成功的关键，以下是几个重要的实践建议：1. 迭代开发：将开发工作划分为若干个迭代周期，每个迭代都能交付可工作的软件。
每次迭代结束后，团队根据反馈进行优化和调整。
敏捷开发的管理办法
**敏捷开发的管理办法**敏捷开发是一种以迭代、增量和协作为核心的软件开发方法。
它强调快速响应变化、持续交付价值和团队自组织等原则。
为了有效地实施敏捷开发，需要采取一些管理办法来提高团队的协作效率和项目的成功率。
以下是一些敏捷开发的管理办法，包括明确目标、制定优先级、迭代规划、持续反馈、团队自组织、跨功能合作、持续改进和适应变化。
一、明确目标在敏捷开发中，明确目标非常重要。
团队成员应该清楚地了解项目的愿景和目标，并将其转化为可执行的任务和需求。
明确的目标有助于团队集中精力、协调行动，并提高工作效率。
二、制定优先级在敏捷开发中，团队应该根据项目的价值和风险，制定任务和需求的优先级。
通过设定优先级，团队可以集中精力解决最重要的问题和需求，并在每个迭代中交付高价值的功能和成果。
三、迭代规划敏捷开发通过迭代的方式进行工作。
团队应该进行迭代规划，即在每个迭代开始时确定要完成的任务和需求。
迭代规划需要考虑项目目标、优先级和资源等因素，并制定相应的计划和时间表。
四、持续反馈敏捷开发强调持续反馈和学习。
团队应该与利益相关者保持密切的沟通和反馈，及时了解需求变化和用户反馈，并据此做出调整和改进。
持续反馈有助于提高产品质量、满足用户需求，并增加团队对项目的理解和参与度。
五、团队自组织在敏捷开发中，团队应该具备自组织和自主决策的能力。
团队成员应该共同决定任务分配、工作流程和问题解决方法等。
团队自组织有助于激发成员的创造力、承担责任和合作精神。
六、跨功能合作敏捷开发强调跨功能合作。
团队成员应该具备不同领域的技能和知识，并互相协作，以实现项目的成功。
跨功能合作可以促进知识共享和团队的全面发展，提高工作效率和质量。
七、持续改进敏捷开发是一个持续学习和改进的过程。
团队应该不断反思和评估自己的工作方式和结果，并寻找改进的机会。
这可以通过定期的回顾会议、团队讨论、客户反馈等方式来实现。
持续改进有助于提高团队的协作能力、产品质量和项目交付效率。
敏捷开发scrum的步骤
敏捷开发scrum的步骤
Scrum是一种敏捷开发方法论，适用于团队协作开发软件和其他复杂产品。
以下是Scrum的基本步骤：
1. 产品待办清单（Product Backlog）：根据项目需求，列出所有需要完成的任务，这些任务按照优先级排序，并且进行明确的描述。
2. 冲刺计划会议（Sprint Planning Meeting）：团队在冲刺期开始前，通过讨论和评估来确定下一个冲刺要完成哪些工作，并将这些工作分配给各个团队成员。
3. 冲刺（Sprint）：一个冲刺通常持续两周到一个月（具体时间由团队决定），在这个时间内，团队集中精力完成之前确定的工作。
4. 每日站立会议（Daily Scrum Meeting）：每天团队成员在15分钟内互相汇报工作进展情况、遇到的问题和解决方案，以确保所有人都知道项目的状态。
5. 冲刺回顾会议（Sprint Review Meeting）：在冲刺结束后，团队成员要进行回顾，检查他们所完成的工作是否达到了预期目标并探讨如何改善。
6. 冲刺回顾和改进计划（Sprint Retrospective and Improvement Plan）：团队评估过去的冲刺，找出改进的方法，并且创建下一个冲刺计划的待办清单。
以上就是Scrum流程的基本步骤，每个步骤都有具体的执行规
则和时间要求，团队需要按照这些规则和要求进行协作和沟通，以确保项目能够按时完成并达到预期效果。
敏捷开发迭代流程及其核心价值
敏捷开发迭代流程及其核心价值敏捷开发的迭代流程包括需求分析、规划、设计、开发、测试和发布等多个阶段，每个阶段都包含多个迭代周期。
在每个迭代周期内，团队会根据客户需求和项目目标制定具体的任务和计划，并在周期结束时进行评审和反馈，然后根据反馈结果对下一个迭代周期进行调整和优化。
通过不断迭代的方式，团队能够及时发现和解决问题，逐步改进产品，最终实现客户需求的满足。
下面将详细介绍敏捷开发的迭代流程及其核心价值。
1. 需求分析阶段需求分析是敏捷开发的第一个阶段，团队需要通过与客户沟通和讨论，了解客户的需求和期望，然后将需求转化为可执行的任务和计划。
在这个阶段，客户需求的准确理解和表达是非常重要的，团队需要通过不断的沟通和协作来确保需求理解的一致性。
同时，团队还需要根据客户需求的优先级制定任务计划，并确保任务的可执行性和时间可控性。
在这个阶段，团队往往会制定一个需求规格说明书或者用户故事地图，将客户需求清晰地表达出来，并作为后续迭代周期的指导。
在需求分析阶段，团队迭代的核心价值在于及时理解和满足客户需求，通过不断的迭代和优化，确保产品能够满足客户的期望，并且减少因需求变更而产生的成本和风险。
通过迭代周期的持续交付，团队能够更好地适应客户需求的变化，提高产品的交付速度和灵活性。
2. 规划阶段规划阶段是敏捷开发的第二个阶段，团队需要根据需求分析的结果制定具体的任务计划和迭代周期，确保任务的合理分配和时间的可控性。
在这个阶段，团队需要对任务的复杂度和风险进行评估，并制定相应的开发策略和计划。
同时，团队还需要根据客户需求的优先级，确定产品功能的发布顺序和时间表，保证产品能够按时交付和满足客户需求。
在规划阶段，团队迭代的核心价值在于制定合理的任务计划和时间表，确保团队能够按时交付高质量的产品。
通过不断的迭代和优化，团队能够及时发现和解决规划中的问题，确保产品开发的可控性和效率性。
3. 设计阶段设计阶段是敏捷开发的第三个阶段，团队需要根据规划结果制定具体的产品设计方案和技术实施方案，确保产品的功能和性能能够满足客户需求和期望。
PMP培训精讲之敏捷开发流程管理三要素
PMP培训精讲之敏捷开发流程管理三要素敏捷开发流程是一种以迭代、自组织和持续交付为基础的项目管理方法。
在敏捷开发流程中，有三个关键要素，分别是团队合作、产品待办事项和冲刺。
第一个要素是团队合作。
在敏捷开发流程中，团队合作是至关重要的。
团队成员之间需要紧密合作，互相协作，共同努力完成项目目标。
团队成员之间应该有高度的沟通和协调能力，能够有效地交流信息和解决问题。
此外，团队成员还应该具备自我组织和自我管理的能力，能够主动地分配任务和解决困难。
团队合作是敏捷开发流程成功的基石。
第二个要素是产品待办事项。
在敏捷开发流程中，产品待办事项是一个核心概念。
产品待办事项是由产品负责人和团队成员共同确定的，详细描述了项目的需求和目标。
产品待办事项是项目中需要完成的工作项的集合，包括功能需求、技术任务、缺陷修复等。
产品待办事项应该按照优先级进行排序，并且可以根据实际情况进行调整。
通过不断地迭代和优化产品待办事项，团队能够更好地满足客户需求。
第三个要素是冲刺。
冲刺是敏捷开发流程的基本单位，通常为一个短期的时间段，一般为1到4周。
每个冲刺都有一个明确的目标和一组产品待办事项。
团队成员根据冲刺目标和产品待办事项制定计划，并在冲刺周期内完成工作。
在冲刺过程中，团队成员应该进行日常的站立会议，及时沟通项目进展和问题，并根据实际情况进行调整。
冲刺的周期性使得团队能够在较短时间内快速交付具有商业价值的成果。
综上所述，团队合作、产品待办事项和冲刺是敏捷开发流程管理的三个关键要素。
通过团队合作，团队成员能够高效协作，共同努力完成项目目标；通过产品待办事项，团队能够清晰地了解项目需求和目标，并根据实际情况进行调整；通过冲刺，团队能够在短期内快速交付具有商业价值的成果。
这些要素的有效管理能够帮助团队实现敏捷开发流程中的高效、灵活和持续交付的目标。
敏捷开发标准
敏捷开发是一种以人为核心、迭代、循序渐进的软件开发方法。
它强调团队合作、客户需求和适应变化，通过持续交付小而实用的功能，快速验证和满足客户需求，并灵活应对变化。
敏捷开发标准通常包括以下几个关键要素：1. 价值观：敏捷开发强调团队合作、快速交付、持续改进和适应变化。
这些价值观贯穿整个开发过程，指导团队成员的行为和决策。
2. 原则和方法：敏捷开发基于一系列原则和方法，包括快速交付、小而实用的功能、频繁交付可工作的软件、持续改进、关注客户需求和灵活应对变化等。
这些原则和方法为团队提供了明确的指导，确保开发过程的敏捷性和有效性。
3. 迭代式开发：敏捷开发采用迭代式开发模式，将软件项目分解为一系列小型、迭代式的工作单元。
这些工作单元通常称为“冲刺”或“迭代”，每个迭代都专注于完成一部分功能，并尽早验证和满足客户需求。
4. 沟通与协作：敏捷开发强调沟通与协作，鼓励团队成员之间建立开放、透明和信任的关系。
通过定期的面对面交流、简报和评审，确保信息的及时传递和问题的及时解决。
5. 反馈驱动：敏捷开发强调持续反馈的重要性，通过收集客户、团队成员和其他利益相关者的反馈，不断改进和优化软件产品。
这些反馈用于指导开发过程中的决策和调整，以确保交付高质量的产品。
6. 技术选择：敏捷开发不强调特定的技术或工具，团队可以根据项目需求和技术环境选择适合的技术栈。
然而，技术选择应该能够支持敏捷开发的价值观、原则和方法，并具备可扩展性和灵活性。
总的来说，敏捷开发标准提供了一套适用于软件开发的方法和框架，旨在提高软件开发的效率和产品质量。
它强调团队合作、客户需求和适应变化，通过持续交付小而实用的功能，快速验证和满足客户需求，并灵活应对变化。
这些标准有助于建立高效、协作的软件开发环境，提高客户满意度和降低项目风险。
敏捷开发的12条原则
敏捷开发的12条原则敏捷开发是一种以迭代、循序渐进的方式进行软件开发的方法论，它强调团队协作、反馈机制和不断学习的理念。
为了更好地理解和应用敏捷开发，以下是敏捷开发的12条原则。
原则一：最重要的是满足客户需求，通过早期且持续的交付可行产品来获得客户的反馈并作出相应调整。
客户的满意度是成功的关键。
原则二：要频繁地进行交付。
通过将开发过程划分为多个短期的迭代周期，每个周期都会生成一个可运行的软件版本，有助于团队及时发现问题并进行修正。
原则三：以面对面的沟通为主。
通过直接交流和面对面的会议，而不是仅仅通过文档进行沟通，可以更好地理解需求和解决问题。
原则四：团队成员之间要保持密切合作。
通过组建稳定的开发团队，每个成员都能充分发挥自己的优势，提高工作效率和协同能力。
原则五：激发项目团队的动力和信任。
给予团队成员更多的自主权和责任感，鼓励他们提出优化方案和解决问题，以实现项目的成功。
原则六：追求技术卓越和良好的设计。
通过适当地应用技术手段和工具，能够提高软件的稳定性、可扩展性和可维护性。
原则七：注意可持续发展。
要在一个可持续的开发速度和进展方向之间取得平衡，避免过度投入或过度延期，以确保项目的健康发展。
原则八：保持简单和持续改进。
通过尽量简化开发过程和减少不必要的工作量，能够更高效地开展工作并保持团队的积极性。
原则九：注重团队反馈和自我调整。
通过及时收集团队成员和客户的反馈意见，进行项目的调整和优化，以便更好地满足需求和改善产品。
原则十：灵活应对变化。
要接受需求的变更和不确定性，并通过迅速调整和适应来应对变化，以保持项目的进展和质量。
原则十一：倡导自主组织和自我管理。
给予团队成员更多的决策自由和责任感，能够提高工作效率和积极性。
原则十二：关注可视化和透明度。
通过适当的可视化工具和技术手段，可以使工作进展和问题得以及时跟踪和解决，提高项目的透明度和沟通效率。
总之，敏捷开发的12条原则以客户满意、持续交付、个体和团队协作、不断反思和改进等为核心，使软件开发更加高效、灵活和贴近用户需求。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
敏捷开发日常跟进系列之一：燃尽图（上）这个系列将涉及燃尽图（Burndown Chart）、故事板（看板）、每日立会等内容，描述在计划会之后，评审会之前，敏捷开发团队内部产出与产品经理和项目经理的各种活动。
日常跟进中的某些内容比如团队工作模型、预估会议、用户故事跟进等在之前的松结对编程、团队管理、用户故事、产品管理等系列中有所描述。
在这个系列之前，还应该有一个敏捷计划系列，描述敏捷开发的从版本规划到计划会估算的详细内容，未来将会补上，当前可以参考2.29版的《火星人敏捷开发手册》，有5页与其相对应。
燃尽图燃尽图Burdown Chart也叫燃烧图，是罕见的敏捷度量，以至于每当有人问起“敏捷中有度量吗”的时候，第一反应就是它。
燃尽图的全称，应该是“总剩余时间的燃尽图”，就是本次迭代中，所有故事（或拆分的任务，以下仅称故事）的剩余时间总和，随日期的变化而逐日递减的图。
图中左侧460是迭代开始的第一天，所有故事的未完成时间相加为460天，而在最右侧则表明在第17天，所有故事的剩余时间相加变为0，也就是所有故事都完成了。
为什么总和会递减呢？因为每个组员每天都要汇报一件事情：当前正在做的故事，还剩余几天，如果昨天剩余3天，今天剩余2天，那么就为燃烧图贡献了1天的进度。
由于可能出现“昨天剩余3天，又工作了一天后本以为会只剩下2天，结果感觉可能还要3天（甚至变成5天了！）”这种情况，所以燃尽图常常有一些起伏。
燃尽图的“指纹”图中的燃尽图尽管有一些起伏，依然是属于比较完美的燃尽图。
实际上每个团队完成迭代的过程差别很大，常见的情况包括：先鼓起后落下原因是计划会以常常漏掉一些事情，所以开工后不但不燃尽，还发现了很多新的任务。
先完美燃烧，然后突然停止燃烧一种很常见的情况，如果任务划分太粗，比如长达10天，很容易“做了1天，剩9天；做了1天，剩8天；……到剩2～3天的时候，哎呀，好像搞不定了”。
先缓慢燃烧，然后到快燃尽的时候剩下一堆没完成的任务，被推迟到下个迭代之前提到过敏捷开发的MoSCoW方法，有些故事是次要的“可以不做的”，所以这种燃烧图也很常见；但是常常有团队没有使用MoSCoW方法，只是被动地发现有些故事没有完成。
……为了改进这些不完美，有些团队设置了一些度量项来改进燃尽图的结果，比如“迭代按时燃尽的次数”“剩余故事占总故事的比例”……其实不用因为燃尽图的不完美而伤脑筋，在般若敏捷的“无住”中曾经提到，这些方法都非我们的目的，而只是一个中间的工具，因此为了完成我们的最终目的，这些工具和方法都可以灵活变通，而不要追求工具和度量数据本身的完美。
但是，迭代的最终目的到底是什么呢？有哪些“灵活变通”可以应用在燃尽图中呢？且待下回分解。
敏捷开发日常跟进系列之二：燃尽图（中）迭代及燃尽图的目标燃尽图的目标是完成迭代的目标，迭代的目标是什么呢？1. 按产品经理的要求，交付计划会中计划的用户故事2. 尽量完成1之后还会看到，这个定义还有狭隘之处，在系列后面的文章中会提到。
为什么燃尽图不能直接地达成这个目标？潜在的问题包括：1. 如果燃尽图按时完成，有可能是为了按时完成，同时牺牲了所有故事（重要和不重要的）的质量，换取了进度。
2. 如果燃尽图未按时完成，有可能不是一个故事没有完成，而是所有故事都剩下点活没做完，导致所有故事都无法交付。
3. 如果燃尽图未按时完成，没有完成的故事中，有可能包括了极其重要的一些。
只从燃尽图的形态看，是无法提前识别这三者的，也就因此带来了很多的风险，到迭代的末尾让人大吃一惊。
怎么办呢？“阶梯燃尽图”之前听过这个方法，但是刚才在网络上没有找到图片。
方法就是在每个故事完成的时候才把整个故事突然剪掉，从而形成阶梯状。
阶梯状燃烧图的缺点也很明显：刚开始的时候很难看到有燃尽，甚至那些向上拱起的弧形也被掩盖了，日后回顾时，一些细节也很难记起来。
所以一种解决方案，是把普通燃尽图和阶梯燃尽图混合使用，就是同时画两条线。
“跟进图”跟进图是一些大型团队的创造，由于团队巨大，所以不能指望在迭代的最后用2小时评审完所有工作，所以常常是做完一个评审一个，这就要给每个工作分配一个“跟进人”，他隶属产品部门，没事就盯着“跟进图”看看有没有自己关心的工作做完了。
在为一家游戏公司提供咨询的时候，他们一款产品的团队人数高达88人（另一个甚至到了200人），墙上就用手绘制了一幅巨大的跟进图，每天更新动态，甚至直接在纸上画上小图标，每月画满了，就重新打印一张。
下面这张，是火星人中的跟进图。
图中绿色粗线，就是传统的燃尽图；每当一个故事完成，就会有一个蓝色的标记及完成故事的名字，从而提醒跟进人进行现场预评审；如果长期没有故事完成，燃烧图却还在燃烧，就肯定出现了之前说过的问题了。
右下部分还有一个暗红色的细线，是“溢出时间”，就是超出预期的工作的时间，表明这段时间出现了新的任务；新任务出现的太早不好，因为一般在迭代前期都先完成最重要的故事，不应该引入新任务；但在后期随着最重要的故事完成、评审、因不满意而返工，团队会倾向于把最重要的任务更好地完成，而非草草地把所有故事都凑合完成，在产品研发中，这往往是更能提升产品价值的。
一家叫做广联达的公司在实践中把溢出时间作为负数倒着画，称为“基线下沉”，就是说要去的地方不是0了，而是那个负数，是一个类似目的的很好的实践。
我试了一下也不错，就是图表会变高，显示起来不方便，所以还是改了回来。
这样的跟进图看起来已经很强大了，但是还有一些问题没有解决：1. 有哪些故事正在做，还没有做，已经开工了但没完成……？2. 最后剩下了哪些故事没完成？3. 有没有人不是一个一个完成故事，而是同时开工了很多故事？（这个是最后很多故事都开工了但都差一点完成不了的主要原因）4. 如果有跟进人，谁负责跟进哪个？有些问题需要后面的故事板（看板）解决，有些则需要一个叫做“跟进表”的东西，之后我们说完故事板再回来详细说明。
敏捷开发日常跟进系列之三：故事板，看板故事板和看板其实不是一个东西，前者是最初的敏捷开发里边的东西，受到了后者的启发产生的；而后者是制造业的东西，具体内容请参考末尾的百度百科。
但是在敏捷开发里边提到这两样东西，可以认为大致相同。
故事板简单说，故事板是展示迭代中的用户故事和任务的方法，在《硝烟中的Scrum和XP》的封面上就印着一个典型的故事板：一般故事板分为三列：To Do还没做的, Doing正在做的, Done做完的（有各种各样的中英文写法，大同小异）有些团队的分工比较多，会出现一些中间状态，比如“还没做的/正在开发的/等待测试的/正在测试的/等待评审的”是一种典型的开发与测试分离的故事板。
故事板的用法要解决的问题故事板可以帮助解决一些燃尽图解决不了的问题（见上篇）：1. 有哪些故事正在做，还没有做，已经开工了但没完成……？故事板的三列正好解决问题。
2. 最后剩下了哪些故事没完成？最左边剩下的就是。
3. 有没有人不是一个一个完成故事，而是同时开工了很多故事？（这个是最后很多故事都开工了但都差一点完成不了的主要原因）这个复杂一些，下面讲。
同时开工很多故事，很容易造成思绪散乱、最后全部完不成的情况，确切说瀑布模型就是同时开工所有故事的典范。
为了防止这一点，如果是手工做的故事板，，那么注意中间一个“正在做的”列一点要窄一些，这样当里边的故事挤不下的时候，就是一个危险的很多故事都在开工的信号。
还有一种做法，是每个人只准放一个故事在中间，做完一个，才能再做一个。
这个严格坚持有难度，因为经常遇到被卡住的情况，但是作为一种思路和精神应该尽量坚持。
4. 如果有跟进人，谁负责跟进哪个？可以在卡片上写上当前负责人、跟进人的名字。
通常的做法有很多种，比如每个人用自己颜色的即时贴，可以比较容易地看出每个人有多少个故事，分别处于什么状态。
不过，这样就需要在“尚未开始的”里边提前分配人员了，不太利于后期的互动和互相关注；当然还可以在开始的时候重新用有颜色的即时贴重新抄一个，看大家的习惯了。
介质尽管有很多故事板/看板工具，使用纸质方法仍然是一个很好的选择，原因就是作为“迭代中的任务”这种东西，其生存期很短，基本上2个月后价值为0，人们也就用纸片来对付了。
不过如果想在未来做几件事情，那么及早采用电子故事板/看板还是有必要的，这些事情包括：1. 希望统计和分析哪些故事容易完不成、每个月的完成情况等2. 大型团队，分布式团队3. 希望留下历史数据作为以后估算的参考值和参考故事下面这个是免费工具火星人中的故事板，做了两个案例来说明一下情况。
上面这个图是不好的情况，开发中的故事一大堆，没几个完成的，很容易造成最后所有故事都差一点。
下面这个要好的多，每个人只开工了1个（每种底色是一个人，案例中只有cheny和yock 两个人），剩下的要末完全做完了，要么一点没做，即使到期末不能全部完成，也不会把太多时间卡在半截的故事上。
2012-03-07补充：昨天下午仔细调整了美术效果，现在的故事板外观如下：更多敏捷开发日常跟进系列之四：跟进表这是敏捷开发日常跟进系列的第四篇。
（栏目目录）跟进表是大型敏捷团队的一种实践。
在一个80多人的网络游戏团队中，他们为了清晰地显示整个团队的运作方式，使用了这种方法。
跟进表以上面的网络游戏团队为例，说明一下跟进表上的信息：1. 哪些故事完成了在故事板中也能表达，但缺少结构性。
故事板中的故事都是平等的，较难显示大小、父子包含关系等。
2. 谁在跟进案例中这个人一般是策划人员，故事的创建者和验收者。
3. 谁在开发案例中这个一般是若干个开发人员、脚本、美术的群体，也可能只有其中一个工种。
4. 某个任务大概可能在何时开始、结束。
在故事板、燃尽图上均无法表达。
5. 哪些故事被搁置了可能遇到了困难，也可能有其他原因，甚至可能做了一半干别的被忙忘了。
……实例这是一个在“火星人”研发中已经完成的迭代的跟进表案例。
实例一我们先看看这个迭代的燃尽图（看不清楚请右键-图片另存为后观看）：对于跟进图的5个作用，上面这个已经扩展了的燃尽图只能完成第一个，就是“哪些故事完成了”，而一般的燃尽图连这个作用也没有。
为了完成另外四个目标，就需要下面的跟进表。
先看左边的蓝框，里边是所有迭代中的故事（Sprint Backlog），为什么要显示成这个树状结构呢？因为如果是小团队，只有10～20个故事，那么人们即使从只有3个字的故事名称比如“新界面”上，大家也能记住和理解说的是什么意思。
但是如果故事多了，就比较困难，会导致故事的名字不得不很长，比如“计划会-讲解故事-的新界面”，而这样表达看似还行，但由于没有清晰的父子包含关系，多了也乱。
所以蓝框中以父子关系的方式表达，对于大型产品的研发更清晰一些。
蓝框右边两列是负责人（对应跟进人，案例中的策划人员）和当前负责人（开发人员），由于我们的团队小，不存在两个部门，所以没有设置跟进人，所以也就没有“负责人”。