官术网_书友最值得收藏!

Feature-driven development

The primary unit of work in a Feature-Driven Development (FDD) process is a feature. Those features are the end result of a detailed System Modeling effort, focusing on creating one-to-many domain models in significant detail, mapping out where features live in the system's domain, how (or if) they are expected to interact with each other—the sort of information that should come out of use casesdata structures, flow models, and Interprocess Communication models. Once the overall model is established, a feature list is constructed and prioritized, with a specific view to at least trying to keep the implementation time frame of each feature in the list at a reasonable maximum—two weeks seems to be the typical limit. If an individual feature is expected to take more than the longest acceptable time, it is subdivided until it can be accomplished and delivered in that time period.

Once the complete feature list is ready for implementation, iterations around completing those features are planned around a fixed time period. In each iteration, features or sets of features are assigned to developers, singly or in groups. Those developers work out a final implementation design, and review and refine it if needed. Once the design is deemed solid, development and testing of code to implement the design take place, and the resulting new code is promoted to the build- or distribution-ready code base for deployment.

FDD goes hand-in-hand with several development best practices—automated testing, configuration management, and regular builds so that, if they aren't a full, formal Continuous Integration process, they are very close to being one. The feature teams are generally small, dynamically formed, and intended to have at least two individuals, at a minimum, on them, with the intention of promoting collaboration and early feedback, especially on a features' designs and implementation quality.

FDD may be a good option for large and complex systems—by breaking work down into small, manageable features, even development in the context of very large, very complex systems is going to be maintainable with a good success rate. The processes around getting any individual feature up and running are simple and easily understood. Barring occasional check-ins to make sure that development isn't stalling for some reason, FDD is very lightweight and non-intrusive. Feature teams will usually have a lead developer associated with them, who has some responsibility for coordinating the development efforts and refining implementation details when and if needed. That does mean, however, that the lead developer is less likely to contribute to the actual code, particularly if they are spending much of their time executing coordination or design-refinement efforts, or mentoring other members of the team.

主站蜘蛛池模板: 奉新县| 渭源县| 南靖县| 潮安县| 宜城市| 昌图县| 文昌市| 鄂州市| 抚宁县| 博白县| 通城县| 常熟市| 九寨沟县| 孝感市| 丽江市| 石城县| 焉耆| 丹阳市| 云和县| 霞浦县| 蒲江县| 宝兴县| 拜城县| 德钦县| 临泉县| 阜宁县| 北安市| 田阳县| 普洱| 从江县| 阿拉善右旗| 海丰县| 集安市| 始兴县| 天气| 成安县| 秦皇岛市| 武功县| 登封市| 丰镇市| 南昌市|