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

　　其实敏捷开发的幅度很宽，有多种灵活、实用的做法，并非只有 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 天时间。若当天无法完成，此开发状态将延续到第二天。