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