使用敏捷开发模型的敏捷程序员的一天

　　大家敏捷开发，每天开发人员的日程是如何安排的?本文讨论的是一个需求子任务的开发过程，相当于软件开发的微循环、微迭代。

　　其实敏捷开发的幅度很宽，有多种灵活、实用的做法，并非只有 Scrum+XP 一种唯一、正确的做法。下面介绍太极敏捷推荐的实践，几种可行敏捷开发模式中的一种，并比较与 Scrum+XP 做法的不同。

　　太(泰)极敏捷以下用 Tai-ji 或 TP(Tai-ji Programming)代称。

　　上午

　　每日例会

　　Daily Scrum or Daily Stand-up Meeting

　　Scrum 的每日站会通常安排在早上(例如 9:30-10:00 之间)，规定不能超过 15 分钟，会上不讨论如何解决问题，通常这么短时间的例会是不够的。

　　Tai-ji 建议采用 DTM(Daily Team Meeting)，一般 30-40 分钟，最长不超过 1 小时。这是对 Daily Scrum 的扩展，以便大家更深入地讨论和交流技术问题。

　　如果大家觉得每日例会过于频繁，也可以采用 WTM(周三例会)。

　　挑选任务

　　例会上由程序员主动挑选当天的开发任务，或者由 PM、架构师等分配任务(若无人认领)。在 Tai-ji 中这叫双向任务分配(BTA)。

　　状态更新

　　...

　　需求细化-状态

　　程序员和用户、BA、RA 一起细化当前任务的需求，确认 UML 模型和 Use Case 文本中待实现的需求是相对准确和稳定的。

　　当前任务的需求明确后，Tester 可以立即开始编写相关的测例(Test Cases)和自动测试程序。

　　Tai-ji 采用 UDD 和 PPoD 开发模式，开发与测试工作是并行的。

　　XP

　　XP 采用用户故事，需求细化涉及到把粗粒度的用户故事分解为多个细粒度的用户故事，一个用户故事可能需要几天时间完成，可以再把该用户故事分解为若干(开发)任务。

　　XP 的需求细化主要通过故事卡片分解，口头沟通完成，未强调书面记录、分析需求的细节，这是一个主要的缺陷。

　　很多人以为 XP 开发是 TDD，一上来就是对着故事卡片写单元测试代码，这是误解。XP 也有需求细化的环节，由于有 Onsite Customer，需求任务一旦沟通明确后，现场客户就开始在开发人员的帮助下写自动验收测试了(ATDD)。

　　TP 建议需求细化，主要是对用例文档与模型中的需求细节的分析和更新，包括各种功能需求和非功能需求(如业务规则)。

　　尽早开始编写自动验收测试是个最佳实践，但与 XP 不同的是，TP 提倡 UDD over ATDD over TDD，用 Use Case 来指导编写系统验收 Test Case 是更好的做法。

　　设计建模-状态

　　程序员针对当前的需求任务，进行必要的架构和模块概要设计，画 UML 静态图和活动图，更新系统设计文档和模型。

　　设计建模的内容还包括：UI 原型设计，数据库/表设计，算法设计，数据结构设计等等，可能涉及到多人。

　　此时的设计，主要是做一种概念性设计，在实际编码(相当于详细设计)之前获得一种基本可行的开发思路和方案，包括模块划分和职责分配(在 TP 中叫预构-Prefactoring)，预估开发中可能存在的风险和问题... 所以此时的设计，不应该追求完美、成熟，而基本保证逻辑上的合理、正确即可。

　　敏捷设计与建模的时间，一般不要超过一小时。

　　在敏捷开发实践中，事先不做基本和必要的需求分析、概要设计，上来直接写代码的做法，往往是一种差实践。

　　建立分支(checkout and branch)

　　程序员为当前开发任务(需求、特性、用例)建立一个独立的代码分支。

　　Tai-ji 采用 AI(自适应集成)开发方式，一般情况下建议不要直接在主干上工作，以免相互产生干扰。

　　XP 的 CI 鼓励大家都在主干上开发，好处是随时随地可以更新，获得主干的最新代码，省去了 branch and merge 的麻烦。CI 同时也有些缺点。

　　代码开发，是都在主干上好，还是在独立分支上好?这其实是一个需要根据实际情况进行权衡、取舍的问题。

　　下午

　　编程开发-状态

　　完成当前开发任务，实现系统需求。

　　一个具体的开发任务通常由程序员一人、双人或多人联合开发完成，在 Tai-ji 中这叫 PPoD(按需结伴开发)。

　　通常在程序员编写实现代码的同时，至少有一个 Tester 同时为其编写测例和测试程序。

　　完成当前任务开发，通常需要 1-2 天时间。若当天无法完成，此开发状态将延续到第二天。

　　复杂软件开发，是一个不断探索、试错、迭代的过程。在此开发过程中，有可能要不断地澄清、更新需求，更新架构和模块设计，更新测试程序，更新相关文档和模型...

　　分支测试-状态

　　程序员在自己的分支上，完成必要的测试(单元测试、功能测试、非功能测试等)。

　　纠错(Debug)-子状态

　　测试发现错误，程序员要不断进行查错、定位、改错、再测试的开发循环。

　　重构优化-状态

　　测试通过、确认功能实现后，程序员对已有代码进行必要的重构优化，改进代码质量。

　　重构代码后，仍需要进入测试、纠错、重构、再测试的循环。

　　checkin

　　程序员一天之内应该多次 checkin 自己的代码，这个 checkin 是检入到自己的任务分支上，而不是团队主干。

　　合并(merge)-状态

　　程序员把自己分支上达到提交质量的新代码合并到团队主干上。

　　合并到主干的操作，对于某一位程序员来说，并非每天都发生。程序员完成开发任务，一般需要一至两天时间，这是正常的。

　　系统集成与测试-状态

　　当天代码全部合并后，进行系统集成测试、冒烟测试、单元测试等。

　　通常整个团队一天可以设置中午、下午和晚上两至三个合并窗口。

　　晚上

　　你司加班是否家常便饭?

　　敏捷开发反对无节制的、长期高强度加班，但“每周 40 小时工作”只能是理想口号，不解决任何现实问题。

原文转自：http://www.ltesting.net