A big part of being agile is doing ‘Just Enough’

Just Enough Requirements: The idea is not to get down to the finest details up front, capture just enough information which will enable team to estimate the development time for the requirement (in a form of user story) with a window to have a discussion with customer at a later time for the needed functionality. By going lazy with the requirement gathering, we are sure what is being developed is really what the customer want. Guy Beaver supports this in his article on The Challenge of Enterprise Requirements Management

The suggested solution is to replace early detailed specification with solution road maps that can be detailed by collaborative teams at just the right time. Agile methods provide the structure and mechanics to allow business vision to lead product development with cross-functional teams that unfold detailed requirements when needed

Package Structure

It might get very interesting and tricky to layout the packages, no I am not talking some skeleton directory structure which is generally created when we create a new eclipse project or run maven, it is more about the way packages should be structured to avoid cyclic dependencies.

When we start we start out with a very basic bare minimum structure but it starts to get ugly as code evolves and we start to unknowingly and unintentionally start creating cyclic dependencies.

What are they : Package A depends on package B and package B starts to use a class of package A

Why Not: Hard to maintain code where a change in package A leads to change in package B which in turn might again need a change in package A. So a small change starts to propagate throughout the module or may be beyond. Hard to reuse code as it will not possible be to take out a package and convert it into a module due to high dependencies across packages.

How to measure it: There are certain static analyzing tools which help in finding out the cyclic dependencies and a free and very popular one is JDepend.

If already in it how to get out: Common set of classes spread across packages into a single utility package or may be in a full blown module.

Rule of thumb: Packages should have one-way dependencies