敏捷
对 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 部门的关系等。
避免失败的最好办法是:向失败学习。如果能够避免再次犯同样的老错误,那么就代表着我们在不断地取得进步。 过去十多年来,我获得的一个印象是,除了企业和团队文化、客户关系等因素之外,软件开发的需求问题(如何时才能控制需求没完没了的变化等等),工艺流程问题(如瀑布还是迭代,重载还是轻载等等),以及架构设计,大概是导致国内软件工程、软件开发项目失败最主要的、被大家谈论最多的三个方面。 | |||||||||||||||||||||||