敏捷实践的秘密 II
这是ThoughtWorks文集在InfoQ中文站发布的第三辑，也是由ThoughtWorks中国区的咨询师们独立完成的第二本合集。这本小册子继续传承ThoughtWorks人在软件领域的分享精神，内容涉及团队建设、技术探析、敏捷实践、敏捷测试等十三篇文章。
InfoQ
InfoQ
促进软件开发领域知识与创新的传播
主题/标签专用视图
Thoughtworks文集相关的内容
最新“Thoughtworks文集”相关专题内容
“Thoughtworks文集”相关文章
运用四色建模法进行领域分析
领域建模有很多种方法，对于同样的问题域使用不同的建模手段得到的模型可能也不尽相同。于是我经常听到这样一个问题：怎么才能保证建模的正确性？本文介绍的是如何运用四色建模法进行领域分析。
从敏捷宣言理解敏捷交互设计
敏捷交互设计是敏捷方法论向交互设计领域的延伸，它提倡让所有相关人参与到设计过程中，迭代演进式地进行交互设计。从2010年开始，已经有越来越的团队在不同程度上使用敏捷交互设计的方法，而放弃了流程化的传统产品设计过程。事实上，敏捷交互设计方法在很多方面都充分体现了敏捷价值观，因此，理解敏捷交互设计实践的最好方法是从记录在敏捷宣言中的价值观开始。
软件开发地基
自动化脚本之于软件开发，犹如地基之于建筑。在软件开发过程中，缺乏一个好的自动化脚本，与之相伴的往往是日常的开发工作举步维艰。在本文中， 我们将以一个Java的web项目为例，展示一个好的“地基”应具备的一些基本素质。
如何查看我的订单-REST的流程API设计案例
这是一个关于订单的故事。我们将一起来应用rest的架构风格逐步搭建一个端到端的流程管理系统，看看如何解决这个问题，这个问题就是：看在上帝的份上，让我看看我的订单。
运用系统思考，走上改善之路
除了人们常常总结的“敏捷实施模式”，或是“敏捷失败经验分享”这样的具体话题之外，是不是还有一些存在于思维模式中的更加根本性的因素，阻碍了我们对系统全景的认知，从而导致改革先行者的黯然退场？本文将通过两个案例来讲述如何使用系统思考，从全局掌握我们所处的复杂环境，做到既见树木，又见森林。
实战：持续交付中的业务分析
在需要频繁交付、不断收集用户反馈、拥抱变化、追求业务敏捷的项目中，软件的开发和交付是迭代式进行的。在这样的项目团队中，BA（业务分析师）通常需要在一个开发迭代开始之前完成该迭代开发任务的分析。但在特殊情况下，从收集客户需求到将功能细节传达给开发团队的周期会缩短到一至两天。BA可以用于思考和分析的时间远远少于可以预先做出所有设计的瀑布式项目。那么在这样的敏捷项目中，BA如何能够适应这种交付模式，完成高质量的业务分析，协同团队为客户交付高价值的软件呢？
持续集成理论和实践的新进展
最近雷镇同学将Martin Fowler先生的著名论文《持续集成》第二版翻译成中文并发布出来，掀起了国内对于持续集成理论和实践讨论的新的高潮。笔者在本文中将全面对比持续集成论文前后两版的异同，分析并展示ThoughtWorks在持续集成领域的理论和实践方面的研究成果，以图对国内企业实施持续集成起到参考和借鉴作用。
看板任务管理
作为一个开发团队的管理者，例如当你是一个团队的项目经理的时候，任务的完成情况通常是你最关心的内容之一，比如说分配的任务是否能够按时间完成，整个项目的进度是否尚在计划之中，团队内的人是不是都在高效地工作，大家有没有什么困难，这些是你经常会关注的问题。在软件开发团队中，任务的分配、跟踪和管理通常是这个团队管理者的一个重要的工作内容。
架构腐化之谜
在长期运转的项目中，架构的腐化是怎么产生的？为什么常见的面向对象技术无法解决这类问题？如何延缓架构的腐化？本文将尝试解释这一切，并提出相应的解决方案。读者需要具备相当的开发经验——至少在同一个项目的开发上一年以上；公司负责架构演进、产品演进的角色会从本文找到灵感。
“Thoughtworks文集”相关迷你书
敏捷实践的秘密 II
这是ThoughtWorks文集在InfoQ中文站发布的第三辑，也是由ThoughtWorks中国区的咨询师们独立完成的第二本合集。这本小册子继续传承ThoughtWorks人在软件领域的分享精神，内容涉及团队建设、技术探析、敏捷实践、敏捷测试等十三篇文章。