Flex与JSON及XML的互操作
平台需要互操作性。在这篇文章中，作者仔细研究了Flex和JSON及XML的互操作性。文章也包含了使用E4X库来将XML映射到图表和表格组件的内容，还演示了如何使用as3core库来解码JSON消息。
新闻
正确设定用户故事的大小
作者 Mark Levison译者 李剑 发布于 2008年2月11日 上午3时32分
资深的敏捷实践者都会知道，敏捷过程中最困难的部分之一就是如何正确地编写用户故事。最近，Pat Kua解答了一个核心问题：故事里应该放入多少细节？用户故事是敏捷项目中轻量级需求的表达形式，用来取代传统项目中长长的用例。面面俱到的用例并不易于适应客户需求的变更。而作为替代，用户故事提供 了恰好够用的信息来开始开发人员与产品拥有者（Product Owner）之间的对话。它同时也是可以为最终用户提供价值的最小的功能片段。下面是来自Mike Cohn的用户故事表述需求的27条优势一文中的几个例子：
- 用户可以在网站上张贴简历。
- 用户可以搜索工作机会。
- 公司可以发布新的工作机会。
- 用户可以限定谁可以看到她的简历。
用Bill Wake发明的助记词来形容就是，我们为优秀的故事投入时间和精力（INVEST）：它们是独立的（Independent），可以磋商的（Negotiable），有价值的（Valuable），可以估算的（Estimable），短小（Small）而且可以测试（Testable）。
按照Patrick的说法，知道故事里需要编写多少细节、何时编写这些细节以后，就掌握了编写用户故事的诀窍。如果像用例那样早早就写下太多细节，一个故事在被实现之前就会被重写很多次了。如果写的细节太少，那开发人员就无从计划、无从下手实现。Patrick说道：
对于那些需要被立刻实现的故事，你就应该提供足够的信息以供开发人员和测试人员明晰需求所用。因为没有足够的细节而造成的浪费肯定会在后续的活动中不断地重现。
……对那些在遥远的将来才会被实现的故事，就不需要同样丰富的细节了。在早期捕获过多细节所造成的浪费必将在分析层面上持续上演。
所以，答案就是视情况而定：故事离你越远，它的细节就应该越少。只有那些即将进行处理的故事才应该拥有测试用例和相关细节。
在Pat Kua的站点上有故事里应该放入多少细节这篇文章的全文。
查看英文原文：Right-Size Your User Stories
太棒了
发表人
James Tong
发表于
2008年2月11日 上午10时4分
Re: 太棒了
发表人
凉粉 小刀
发表于
2008年2月14日 上午3时41分
-
这一直是我想不明白的一个问题
-
在ScrumAlliance上还有一篇佳文：
www.scrumalliance.org/articles/87-writing-the-p...
2 条回复
回复