Monday, April 6, 2009

My Custom Agile Flashcards

In a previous post I mentioned how impressed I was by the concept of Agile Flashcards, I started to put together some of my own flashcards to reflect on some of the best practices that I use on my projects. Here they are below:


Domain Driven Design


by Eric Evans



  • Articulate and encapsulate the business logic of the system into one or more software models

  • Organize and abstract the knowledge of multiple business SMEs, partitioning business logic into:


    • Entities

    • Value Objects

    • Aggregates

    • Repositories

    • Factories

    • Services

    • Specifications

  • Refactor the model to reflect the realities and limitations of the target technical platform (avoid ivory tower models)

  • Build a model that both technology and business can understand, providing a Ubiquitous Language for the project

Agile Documentation


by Scott Ambler


Document...


When the Business Asks you to


For Clarity Across Teams working in different locations


To establish appropriate business and technical Context for the solution


To define Interfaces across systems


To Enable your Next Effort


Informally


To Understan


To Communicate


Don’t Document...


To Specify


Because your Process Says So


Unproven ideas (prototype it first)


Without obtaining the structure from your Intended Audience


Without Considering Maintenance and cost of ownership


Implementation and Design Details that can be just as easily expressed in the solution itself


Essential Documents


Operations and Support


Developer Setup & Manuals


User Manuals


Delivery Plan


Phases of a Product Based Lifecycle


Lightly apply the concepts of a product based SDLC lifecycle on large-scale, enterprise projects...



  • Inception generate a vision, build the business case and obtain funding

  • Elaboration address technical risks, clarify on certain requirements, experiment and prototype, and build the foundation

  • Construction expand the team, run the assembly line, and manufacture the complete solution

  • Transition train users, transition to operations, and hand over the solution

Remember that contributions from a combination of disciplines (requirements, design, build, test, etc.) are required in some shape or form through all phases of the lifecycle



Enterprise Stakeholders


On large projects extend the typical agile definition of a product owner to include the following stakeholders:



  • Operations Manager

  • Enterprise Architects

  • Developer Teams dependent on code you are building

Be sure to solicit their input when defining requirements for the system.


Agile Modeling


by Scott Ambler


Software modeling can be incredibly useful, but models are expensive to create, and incredibly expensive to maintain.To maximize ROI,


Model...



  • To communicate an idea

  • To understand the concept

  • Using Collaborative Techniques like CRC Cards

Don’t Model...



  • Without an audience in mind

  • Just because your process says so

Focus Modeling on...



  • Integration interfaces between teams and systems

  • Complex business logic

  • Code being reused across multiple teams
test

3 comments:

  1. On the product life cycle, you left out the final one, "litigation". ;-D

    ReplyDelete
  2. Maybe I could put one also called the "real waterfall" pattern
    -requirements
    -design
    -build
    -test
    -f*ck

    :-)
    Jeff

    ReplyDelete
  3. Useful list of Flashcards. Thanks for putting this together.

    Venkatesh
    http://agileworld.blogspot.com

    ReplyDelete