Udostępnij za pośrednictwem


Methodologies at a Glance

Note: This article is updated at Agile Practices at a Glance.

I'm a fan of simple maps to help drill in. After all, it's hard to explore the concepts if you don’t know they exist, or you don’t know what they are called.  Below is a work in progress.  I’m making a quick, simple map of the key activities for a some software project-relevant processes.

I’m sure I’m missing key practices and some of the names have changed.  So I’m sharing it, so that folks can help share what they know, to get to a map that includes the right top level names of key practices.

Process Practices
Kanban
  • Limit WIP (Work in Progress)
  • Measure the Lead Time
  • Visualize the workflow
Scrum
  • Burndown Chart
  • Daily Scrum
  • Definition of Done
  • Estimation
  • Impediment Backlog
  • Product Backlog
  • Product Owner
  • Retrospective
  • Scrum Master
  • Scrum Team
  • Sprint
  • Sprint Backlog
  • Sprint Demo
  • Sprint Planning Meeting
  • Velocity
XP
  • Coding Standard
  • Collective Code Ownership
  • Continuous Integration
  • On-Site Customer
  • Pair Programming
  • Planning Game
  • Refactoring
  • Simple Design
  • Small Releases
  • Sustainable Pace
  • System Metaphor
  • Test-Driven Development
MSF Agile Activities
  • Build a Product
  • Capture Project Vision
  • Close a Bug
  • Create a Quality of Service Requirement
  • Create a Scenario
  • Create a Solution Architecture
  • Fix a Bug
  • Guide Iteration
  • Guide Project
  • Implement a Development Task
  • Plan an Iteration
  • Test a Quality of Service Requirement
  • Test a Scenario
Artifacts (Work Products)
  • Architectural Prototypes
  • Bug Reports
  • Change Sets
  • Check In Notes
  • Classes
  • Development Tasks
  • Interface Models
  • Personas
  • Scenarios
  • Storyboards
  • System Architecture (See DSI and Whitehorse)
  • Test Plan (see Context-Driven Testing)
  • Test Cases
  • Unit Tests
  • Vision Statement
RUP Activities
  • Analyze Runtime Behavior (Implementer)
  • Architectural Analysis (Architect)
  • Assess viability of Architectural Proof-of-Concept (Architect)
  • Capsule Design (Capsule Designer)
  • Class Design (Designer)
  • Construct Architectural Proof-of-Concept (Architect)
  • Database Design (Database Designer)
  • Describe Distribution (Architect)
  • Describe the Run-time Architecture (Architect)
  • Design Testability (Designer)
  • Design the User-Interface (User-Interface Designer)
  • Develop Installation Artifacts (Implementer)
  • Elements (Designer)
  • Execute Developer Test (Implementer)
  • Identify Design Mechanisms (Architect)
  • Identify Design Elements (Architect)
  • Implement Design Elements (Implementer)
  • Implement Developer Test (Implementer)
  • Implement Testability Elements (Implementer)
  • Implementation Model (Software Architect)
  • Incorporate Existing Design Elements (Architect)
  • Integrate Subsystem (Integrator)
  • Integrate System (Integrator)
  • Plan Subsystem Integration (Integrator)
  • Plan System Integration (Integrator)
  • Prototype the User Interface (User-Interface Designer)
  • Review Code (Technical Reviewer)
  • Review the Architecture (Technical Reviewer)
  • Review the Design (Technical Reviewer)
  • Structure the (Software Architect)
  • Subsystem Design (Designer)
  • Use-Case Analysis (Designer)
  • Use-Case Design (Designer)
Artifacts
  • Analysis Class
  • Analysis Model
  • Architectural Proof-of-Concept
  • Build
  • Capsule
  • Data Model
  • Deployment Model
  • Design Class
  • Design Model
  • Design Package
  • Design Subsystem
  • Event
  • Implementation Element
  • Implementation Model
  • Implementation Subsystem
  • Integration Build Plan
  • Interface
  • Navigation Map
  • Protocol
  • Reference Architecture
  • Signal
  • Software Architecture Document
  • Test Design
  • Test Stub
  • Testability Class
  • Testability Element
  • Use-Case Realization
  • User-Interface Prototype

Comments

  • Anonymous
    January 21, 2011
    I respect your effort but I don't quite get the point of it. If someone is a pro in any of these processes, he knows the practices. So this list has not much value for him. If someone is not a pro, those words have no meaning - which also makes this list useless. I think this list would be of much more value if every word would have a link to an article whith further information.

  • Anonymous
    January 21, 2011
    The point is for the pros to see if I'm missing any practices or got the names of the practices wrong.  For example, there are two flavors of the XP practices, I'm not sure if this is the right set of Scrum practices, and I couldn't confirm Kanban with an authority (and the RUP list is old, and I'm checking on MSF.  So it's a strawman for crowd-sourced input. Next step, from the topology map, is to find the best prescription for each practice. Yes, the list would have more value if it was linked -- that would be a vNext.

  • Anonymous
    January 21, 2011
    Great, Thank you, Astonishing Big Picture of Methodologies

  • Anonymous
    January 23, 2011
    do u put this content to any collaborative space yet? i saw u also have your own wiki there'd easier for collaboration? btw, ur blog is nice place to gain 1st sight. so, can here show live snap from ur wiki ?

  • Anonymous
    January 25, 2011
    "Visualize the workflow" is often part of XP and Scrum In Scrum, most Stories are small enough to be "finished" in a single sprint. XP is often combined with Scrum but can also be combined with Kanban

  • Anonymous
    February 09, 2011
    As Ian's comment illustrates, most of these methodologies have common roots so use the same or similar practices and artifacts.  The approach and management of the work is what differs between them - making sure the "bite of the elephant" is just right and matches the amount of risk, time or resources the sponsor is willing to provide for that set of deliverables.   Of course, you will watch out for the items that are labeled similarly but have different content and/or context.