请用 Firefox 54+ 浏览
我的文章 我的评论 我的书评 我的知乎*
书单 书讯 书评
需求知识体系 特性 用例 统一用例方法 用户故事 需求工具
业务建模 UML OOD
敏捷知识体系 敏捷方法 敏捷问答 敏捷工具 敏捷评论 敏捷资源
业务模式 需求模式 架构模式 设计模式 大道至简:实话设计模式 Web 应用架构模式
.NET Java JS 笔记
Amazon* ITPub* Martin Fowler* Wikipedia* 教程
需求分析需求模型非功能需求业务需求分析
SpringJSF
> >
在线/83 登录/0

案例库

  
 
敏捷


案例分析:跌跌撞撞的持续集成之路 (4652)

对 InfoQ China 上一个遇到麻烦的 CI 案例的分析和评论。太极敏捷建议用 Daily Build/Smoke Test/Nightly Test 以及每日集成(Daily Integration)取代遇到性能瓶颈的持续集成方案。


案例:TDD 实践之实用主义 (10637)

对一位 ThoughtWorks 敏捷教练发表在 InfoQ China 上的一个海员管理系统 TDD 实践案例的分析和评论。太极敏捷建议尽量避免采用中文方法名、过长的方法名,不要把冗长的测试条件、测试说明作为方法名。


案例:一个典型传统团队的敏捷改进 (5218)

以小见大、举一反三,从小项目、小团队的经典情况考察敏捷与传统的区别。从瀑布思维转向迭代思维是改进的重点和难点。


案例分析:当敏捷团队遭遇了公司政治 (6017)

对 InfoQ China 上一个“异常复杂”的敏捷(Scrum)实施案例文章“一个敏捷教练中止越轨列车的故事”的分析。


一次有益的敏捷 XP 失败 (9137)

这是国内最早公开报道的一个敏捷 XP 案例,2003 年 5 月首发于 IBM developerWorks 网站上。

一个采用了每日晨会、持续集成、小步发布等诸多敏捷实践的敏捷项目为什么还会遭到彻底失败,遭遇重大挫折?显然,沉浸在敏捷热度中的项目成员们,一定是忽视了某些远比时髦的敏捷实践(比如持续集成、结对编程和 TDD)更为重要和关键的东西。

尽管已经过去了 5 年,我仍然建议当今和今后的每一位敏捷、XP 爱好者认真地回顾一下这个案例,吸取其中的宝贵经验和教训。


用例不是这样的-对 TW 厦门项目的几点疑问 (28621)

Use Case 和 User Story 这两种需求分析技术必然都存在各自的优缺点,有各自不同的适用性。项目的成功不应该建立在对这两者关系和异同的错误认识之上,务实的软件工程实践尤其应该避免那种先入为主的偏见。

 
架构


Web 应用框架 zxweb 的设计与实现 (23446)

介绍本站底层软件的开发架构。如何在 Web 应用架构的基础之上开发出一个高度可重用的软件工程知识库系统。


综合


2010 最佳案例 (7936)

2010 最佳案例


2009 年度最佳案例 (4532)

对 itpub 上几个典型案例的分析,涉及到瀑布过程、业务建模、需求、业务部门与 IT 部门的关系等。


导致软件开发失败的三大“杀手” (13177)

避免失败的最好办法是:向失败学习。如果能够避免再次犯同样的老错误,那么就代表着我们在不断地取得进步。

过去十多年来,我获得的一个印象是,除了企业和团队文化、客户关系等因素之外,软件开发的需求问题(如何时才能控制需求没完没了的变化等等),工艺流程问题(如瀑布还是迭代,重载还是轻载等等),以及架构设计,大概是导致国内软件工程、软件开发项目失败最主要的、被大家谈论最多的三个方面。
 
 
 

首页 | 使用指南 | 站点地图 | 版权声明 | 联系方法 | © 2005-2018 张恂 版权所有. 沪ICP备05023401号