The requirements of the system are not laid out from the beginning. So what we have is a set of interrelated statistic related calculations performed ... None of this is known from the onset by the developer. The developer is forced (rightly or wrongly) to follow an agile approach ... an agile team should perhaps enforce the SQL-92 standards.
Unclear requirements are a very common problem. I see them so often I wrote a series of articles about it. If you and your team are suffering from chronically unclear requirements, the SQL-92 standards won't save you.
Instead, you need to have the courage and honesty/transparency (often lauded in Agile) to have a serious conversation with your Product Owner, explaining that it is wasteful and disrespectful to your Dev team to ask them to proceed with unclear requirements. Be proactive: if your Product Owner is lacking resources (goes with the territory in my experience) volunteer your team to do an initial sprint with the sole goal of clarifying requirements, using some of the techniques mentioned in Building the Right Thing (Part III): Customers such as:
In reply to Re^6: Have SQL standards gone too far?
by eyepopslikeamosquito
in thread [OT] Reflecting on SQL. Meditating on Perl. Do languages meet requirements of Agile?
by betmatt
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |