敏捷开发.点滴积累
-- 201212-201301项目实践经验
图源自Team Leader（@jieouy）所作PPT，赞！表示一下激动，Leader一直以来为项目投入激情，启发并引领大家，赞！同时感谢之。
- 敏捷感言
敏捷开发最基本要素还是人，注重的是人与人之间密切、及时的沟通与协调。正所谓以人为本。
敏捷开发，拥抱变化、迅速迭代。
敏捷开发，其流程（规则）与参与人之间互相作用，流程不断推动人积极参与，人不断完善更新流程。还有很重要一点就是，不同参与人之间相互推动（包括督促）的作用。
敏捷开发，需要所有成员的积极主动，凝聚起来形成强大的推动力与执行力。
“敏捷开发的计划管理体系中，发布计划、迭代计划、迭代回顾与每日站会相辅相成。通过计划多层次管理，逐步细化，确保敏捷开发具备灵活响应变化的能力。”
- 实施过程
> Story，就是把一个项目慢慢的拆分一个个目标明确的小需求。Story的生命周期包括：
1 需求阶段。由需求方提起，经大家讨论确定合理，最终提交至白板或其他地方。
2 开发阶段。根据确定的需求，开发者具体去实现功能，并要求完成自测通过。完成之后，提交测试进入下一阶段。
3 测试阶段。根据功能（需求）提出不同测试案例，并实践验证。若发现问题（BUG）或疑问及时反馈开发人员，必要时通知产品设计人员或项目管理者，此时Story回到开发阶段。注意：一个Story可能在2,3直接来回多次属于正常现象。
4 完成阶段。直到程序通过所有的测试案例，Story提交至该阶段，可以将Story交由需求方验收。
> 若项目的管理工作适合于敏捷开发流程，则项目包含的Story需要具备这样的特性：
可讨论，可评估，可测试，独立性，有价值，细分的（小的）。
> 强烈建议或要求，项目的开发、测试、产品设计等同事们始终保持在一起工作。
> 每天一次站立的短会（如晨会），控制在15分钟之内，每天轮流一人负责召集、组织会议。主要讨论各自工作情况包括：昨天完成什么，今天做什么，遇到什么问题等。
> 每周一次迭代会议，时长控制在一小时之内，需有专人（轮流）同时负责会议记录并邮件群发会议纪要。主要讨论项目进度情况，遇到问题，安排或修改story，协调人力、资源问题等。
- 管理工具
有一工具大家一定相当熟悉，可能在很多地方都见识过，原始而实用，就是白板+便签贴纸。白板上主要分区，大概描述如下：
a 根据Story进度情况划分，需求、开发、测试、完成。
具体部分还可以再细分如需求{待讨论的需求池、真正的需求}，开发{开发，解BUG}。具体如何细分最好，需依不然项目情况做安排，在此不多累书。
b 根据Story业务方向划分，客户端、服务端、通用工具等。这样做的目的是更明确标明Story属于哪些人。
两者结合，以a结构为主，b为辅。
还有一种很酷的电子版工具Trello，包括Web版，移动版，确实很适用的工具，给力。
- 价值观与原则（引用）
敏捷开发的价值观：
- 人和（人与人的）交互 优先于过程和工具。
- 可以工作的软件 优先于求全责备的文档。
- 客户协作 优先于合同谈判。
- 随时应对变化 优先于循规蹈矩。
其中位于右边的内容虽然也有其价值，但是左边的内容最为重要。
敏捷建模（Agile Modeling，AM）的价值观包括了XP的四个价值观：沟通、简单、反馈、勇气，此外，还扩展了第五个价值观：谦逊。
宣言中还包括以下原则：[3] [4]
- 对我们而言，最重要的是通过尽早和不断交付有价值的软件满足客户需要。
- 我们欢迎需求的变化，即使在开发后期。敏捷过程能够驾驭变化，保持客户的竞争优势。
- 经常交付可以工作的软件，从几星期到几个月，时间尺度越短越好。
- 业务人员和开发者应该在整个项目过程中始终朝夕在一起工作。
- 围绕斗志高昂的人进行软件开发，给开发者提供适宜的环境，满足他们的需要，并相信他们能够完成任务。
- 在开发小组中最有效率也最有效果的信息传达方式是面对面的交谈。
- 可以工作的软件是进度的主要度量标准。
- 敏捷过程提倡可持续开发。出资人、开发人员和用户应该总是维持不变的节奏。
- 对卓越技术与良好设计的不断追求将有助于提高敏捷性。
- 简单——尽可能减少工作量的艺术至关重要。
- 最好的架构、需求和设计都源自自我组织的团队。
- 每隔一定时间，团队都要总结如何更有效率，然后相应地调整自己的行为。
参考：
题外话：最近早晨，我还躺在床上的时候都会从窗外传来一阵阵小学生的朗朗读书声，遥想当年儿时我也一样……
“风声雨声读书声声声入耳，家事国事天下事事事关心。”
（完）
没有评论:
发表评论