UP + Evo The UP is especially for software development, and usually for projects involving multiple iterations before production delivery. Consequently, the UP could be applied to Evo backroom development work. However, Evo's very frequent evolutionary delivery and project management style is not exactly in the same spirit as the UP, although both share an interest in early identification and mitigation of risks. The UP has its own set of workproducts and approach to requirements capture: the Use-Case Model (and thus, use cases), and Supplementary Specification for description of functions, features, and nonfunctional requirements. Evo Planguage elements, such as the Performance Requirement Specification, may be used within the UP Supplementary Specification. Evo's measurement emphasis is compatible or acceptable with the UP. The upper bound of UP's 2 6 week iteration length is not consistent with Evo too long. UP + Scrum The Scrum practices are consistent with UP practices. The Scrum Product Backlog is an acceptable portion of the UP Project Plan, and the Sprint Backlog is an acceptable version of the UP Iteration Plan. One area of potential conflict is the presence in the UP of optional but predefined activities; the UP indicates some dependent ordering of these optional activities for example, that a project vision is created before a detailed requirement is described. Scrum's rejection of defined process and predictable steps is inconsistent with this structure if the UP activities are viewed as a required formula. But, if the activities are treated as optional advice, performable in any order, and without attempt to schedule their order and duration on a project, and without assignment of tasks to individuals by a manager, it is not in conflict with Scrum. | Product and Sprint Backlog |
| See "UP as a Heavy, Defined Process versus an Agile UP Approach" |
UP + XP Most XP practices are consistent with UP practices, and many XP practices can be applied in the context of an overarching UP project. For example, test-driven development is a specialization of the UP continuously verify quality best practice. Since all UP workproducts are optional it is a misunderstanding to assume the methods are fundamentally incompatible, given XP's promotion of minimal modeling and documentation. However, although speaking of some XP practices within a UP project can have conceptual integrity, the opposite is not true, as there are some differences in style and emphasis. One area of difference is in the accepted degree of up-front modeling (diagramming, etc.). For example, within a UP project and a two-week iteration, it is considered acceptable to spend a halfday near the start to sketch and explore design ideas "at the whiteboard" (visual modeling) before programming. In XP, no more than 10 or 20 minutes before programming is considered suitable. Another difference is in the goal of the early iterations. In the UP the goal is to identify and drive down the high risks: technical, political, satisfying the customer, and so forth. Although this may happen in the XP, it is not an explicit guiding principle. A third difference is in requirements specification. The UP allows and supports the creation of relatively detailed specifications (incrementally, over a series of iterations), assuming that an onsite customer is not going to be present. These will usually take the form of the Use-Case Model and Supplementary Specification. |
