
敏捷合同
传统的瀑布式模型,与公司采购的方式完全契合:先整理出需求,一家供应商提供一个报价,大家都签署一个法律上的捆绑协议。这种方式写出来的合同很少有敏捷方法使用的空间。本文检查了4种不同的模型,供供应商和客户使用,以建立敏捷相关的合同。

传统的瀑布式模型,与公司采购的方式完全契合:先整理出需求,一家供应商提供一个报价,大家都签署一个法律上的捆绑协议。这种方式写出来的合同很少有敏捷方法使用的空间。本文检查了4种不同的模型,供供应商和客户使用,以建立敏捷相关的合同。
最近一段时间,随着双十一、双十二等优惠打折季的过去,有关电商网站的可靠性设计受到国内社区的热烈讨论。在知名问答网站知乎上,有人提出了这样一个问题:“京东今天还在用.NET 架构的原因是什么?”,半年来得到了许多技术圈内人士的回复,其中不乏有意思的内容,对读者朋友很有启发作用。
非功能需求一般和系统的状态有关而与系统需要提供的功能无关。通常是系统的“ ilities”功能,比如可扩展性(scalability)、互操作性(interoperability)、可维护性(maintainability)、移植性(portability)、性能和安全性都包括在此类。敏捷团队经常纠结于定义和估算项目的非功能需求。
本书的内容有些另类,绝不似书名所呈现的中规中矩,但确实体现了一种美,是一种简单到极致的优雅,似乎又繁复如星空般的深邃,包容如峭立千仞之高的山壁。这是一本可以称之为轻松加愉快的思想随笔,又是一篇如杜拉拉升职记般的职场小说,它还贯穿了整个软件开发过程,揭露了从方法论、需求、架构设计、编码实现,到测试与维护以及团队管理的诸多要诀。这正是本书的另类之处。

Roman Richler探讨了如何有效地梳理产品待办事项列表(backlog)及其相关技术,也讨论了一些应用产品待办事项列表的复杂情况,包括如何处理非功能性需求以及如何在大型项目中使用产品待办事项列表。本文摘录自Roman的新书《Scrum敏捷产品管理》。

Software Education的首席知识官Shane Hustie点明了一个敏捷的迷思——我们不需要业务分析人员,同时他指出:只要以正确的方式向业务看齐,而不是以开发团队为导向,业务分析师就可以帮助敏捷团队成功。

近日InfoQ有幸独家专访了微软Visual Studio Business Applications团队的总经理潘正磊,与她探讨了微软研发团队管理的相关问题:技术人员的职业发展、如何培养接班人、如何管理不同规模的研发团队等等。

如何设计能深刻反映业务领域的领域模型?领域模型设计的未来发展方向是什么?……本书是Eric Evans的《领域驱动模型》一书的精简版,让你在短时间内理解领域驱动设计的内容。这本书没有介绍任何新的概念,它只是概要总结了领域驱动设计的本质,抽取了Eric Evans原书中关于这一主题的大部分内容,以及其他相关资料。这本书可以让你快速了解领域驱动设计的基础知识,但不能替代Eric书中提供的大量事例和案例研究或者Jimmy书中提供的动手事例等。