敏捷
对 InfoQ China 上一个遇到麻烦的 CI 案例的分析和评论。太极敏捷建议用 Daily Build/Smoke Test/Nightly Test 以及每日集成（Daily Integration）取代遇到性能瓶颈的持续集成方案。
对一位 ThoughtWorks 敏捷教练发表在 InfoQ China 上的一个海员管理系统 TDD 实践案例的分析和评论。太极敏捷建议尽量避免采用中文方法名、过长的方法名，不要把冗长的测试条件、测试说明作为方法名。
以小见大、举一反三，从小项目、小团队的经典情况考察敏捷与传统的区别。从瀑布思维转向迭代思维是改进的重点和难点。
对 InfoQ China 上一个“异常复杂”的敏捷（Scrum）实施案例文章“一个敏捷教练中止越轨列车的故事”的分析。
这是国内最早公开报道的一个敏捷 XP 案例，2003 年 5 月首发于 IBM developerWorks 网站上。 一个采用了每日晨会、持续集成、小步发布等诸多敏捷实践的敏捷项目为什么还会遭到彻底失败，遭遇重大挫折？显然，沉浸在敏捷热度中的项目成员们，一定是忽视了某些远比时髦的敏捷实践（比如持续集成、结对编程和 TDD）更为重要和关键的东西。 尽管已经过去了 5 年，我仍然建议当今和今后的每一位敏捷、XP 爱好者认真地回顾一下这个案例，吸取其中的宝贵经验和教训。
Use Case 和 User Story 这两种需求分析技术必然都存在各自的优缺点，有各自不同的适用性。项目的成功不应该建立在对这两者关系和异同的错误认识之上，务实的软件工程实践尤其应该避免那种先入为主的偏见。 | 架构
介绍本站底层软件的开发架构。如何在 Web 应用架构的基础之上开发出一个高度可重用的软件工程知识库系统。 综合
2010 最佳案例
对 itpub 上几个典型案例的分析，涉及到瀑布过程、业务建模、需求、业务部门与 IT 部门的关系等。
避免失败的最好办法是：向失败学习。如果能够避免再次犯同样的老错误，那么就代表着我们在不断地取得进步。 过去十多年来，我获得的一个印象是，除了企业和团队文化、客户关系等因素之外，软件开发的需求问题（如何时才能控制需求没完没了的变化等等），工艺流程问题（如瀑布还是迭代，重载还是轻载等等），以及架构设计，大概是导致国内软件工程、软件开发项目失败最主要的、被大家谈论最多的三个方面。 | |||||||||||||||||||||||
