Talkin’ about…
acceptance tests agile use cases antipatterns AONW apologies assumptions Christopher Alexander communication customer service data and algorithms design for test design patterns design roots documentation drawing driven meme DSLs emergent design Eric Evans fun habitable software icebreaker IEEE design column index cards JAOO living software OOPSLA open space parametric polymorphism PLoP podcast problem frames Responsibility-Driven Design SD Best Practices software development processes software history structured design TDD teamwork terminology test-driven development travel use cases wizard-of-oz prototypes workshopsPast Entries
- March 2012 (2)
- September 2011 (1)
- August 2011 (5)
- July 2011 (3)
- May 2011 (1)
- February 2011 (1)
- January 2011 (1)
- December 2010 (1)
- July 2010 (1)
- April 2010 (2)
- October 2009 (1)
- August 2009 (1)
- June 2009 (2)
- March 2009 (1)
- January 2009 (1)
- November 2008 (1)
- September 2008 (1)
- August 2008 (2)
- June 2008 (1)
- April 2008 (1)
- February 2008 (2)
- November 2007 (1)
- October 2007 (1)
- September 2007 (1)
- June 2007 (1)
- May 2007 (1)
- April 2007 (3)
- February 2007 (3)
- January 2007 (1)
- September 2006 (2)
- August 2006 (2)
- July 2006 (2)
- June 2006 (1)
- April 2006 (2)
- February 2006 (3)
- January 2006 (3)
- November 2005 (4)
- October 2005 (7)
- September 2005 (1)
- July 2005 (3)
- June 2005 (5)
- May 2005 (3)
- April 2005 (2)
- December 2004 (2)
Reactions…
- Talman Stoner on How far should you look ahead?
- Talman Stoner on Agile Architecture Myth #5: Never Look Ahead
- John Schwartz on Agile Architecture Myth #5: Never Look Ahead
- Rebecca on Agile Architecture Myth #5: Never Look Ahead
- Chris Collins on Agile Architecture Myth #5: Never Look Ahead
Category Archives: Requirements
Agile Architecture Myths #4 Because you are agile you can change your system fast!
Agile designers embrace change. But that doesn’t mean change is always easy. Some things are harder to change than others. So it is good to know how to explain this to impatient product stakeholders, program managers, or product owners when … Continue reading
Who Defines (or Redefines) Landing Zone Criteria?
Who should be in on discussions that set landing zone criteria? Because most landing zone have architectural implications, someone knowledgeable about the system architecture, in addition to the product owner and other key stakeholders should have a lot to say … Continue reading
Posted in Agile, Requirements, Software Architecture
Tagged facilitation, landing zones
Leave a comment
Landing Zone Targets: Precision, Specificity, and Wiggle Room
A landing zone is a set of criteria used to monitor and characterize the “releasability” of a product. Landing zones allow you to take product features and system qualities and trade them off against each other to determine what an … Continue reading
Posted in Agile, Requirements, Software Architecture, Software Design
Tagged landing zone, target values
Leave a comment
Agile Landing Zones
In my last post I introduced the idea of landing zones, a set of criteria used to monitor and characterize the “releasability” of a product. A landing zone contains system attributes that must be achieved to declare “success”, along with … Continue reading
Posted in Agile, Requirements
Leave a comment
Introducing Landing Zones
On an aircraft carrier, the landing zone describes a small section of deck that a pilot must touch down in to land the plane safely. By analogy, a landing zone for a product describes a range of measurable attributes that … Continue reading
Posted in Agile, Requirements, Software Architecture
Leave a comment