What are “Teeth”  in Development?

The management of a traditional project consists of a project management tool to document the reported progress by the Development Team and the supporting Solutions Teams.

This process queries the development resource for a percentage of completion of assigned task. The progress is tracked to completion of 100% of the assigned task.

The assumption at this point is that the acceptance criteria requirements have been successfully completed.

… This Process Lacks Validation of Delivery

…… There are No “Teeth” in this Process

The Problems with the Traditional Process:

1. It is an “Open Loop” process that only report possible development efforts

2. There is not a process that validates that a viable solution was ever created

3. It is a “Fox in the Hen House” process: The Developer validates its own work completion

4. The current state of development for the Business Stakeholder’s Acceptance Criteria cannot be monitored by the most important team: The Business Team

5. Change Requests for a given delivered Acceptance task cannot be easily regressively tested and reports viewed by the Business Team

What is required is a “Closed Loop” process that validates that the Business Acceptance Criteria, as defined as Development Scenarios, has been completed and verifiable.

A Closed Loop Development Process:

Alphabet Development delivers the “Teeth” required for a closed loop development process that is more than a status in a document

The Vertical Development Process uses Acceptance Test Driven Development (ATDD) to map the Business User Story Acceptance Criteria to Behavior Driven Development (BDD) scenarios for Developers to deliver quality code.

1. The Business Acceptance Criteria has been defined for the developer as an Acceptance Scenario Development Task as defined in the Sprint Planning process

2. An ATDD Web page has been created for viewing by the Business Team

3. The Business Team validates that the “YELLOW” Acceptance Criteria Scenario test has been defined correctly by the Architect Team

4. Once the Business Team certifies that the defined expected results have been interpreted correctly, the BDD test is moved from the “YELLOW” stage to the “RED” accepted but not yet started stage

5. The current stage of all BDD Acceptance Scenario tests are viewable, at all times, by all Team Members

6. The Development Scenario Task is accepted by the assigned Developer for development and moved to Test Driven Development

7. Once the “RED” test acceptance criteria has been certified by the QA Team as completed TDD horizontal tests, the highest level of abstraction, the Web Services in the Services Stack or the Application Controller in the Web Application Stack, is then repurposed for the Acceptance Scenario’s “GREEN” test vertical validation

8. This process produces the “Teeth” that validate that the Business expectations have been Designed Developed, QA tested and ready for deployment to the emulated Production Environment: Staging

The Horizontal Test Driven Development (TDD) Process:

1. The assigned task Developer creates the concrete solutions using the Test Driven Development (TDD) process

2. Development begins with generating a “RED” failing test that acts as a “To Do” list for the Developers development process

3. The “RED” tests become “GREEN” working Unit Tests consuming “Mock” dependencies as Single Unit of Work true unit tests

4. The Unit Tests, within the test assembly, are made “GREEN” using any means possible

5. Best Practices and Code Standards are waived at this stage and do not have to be in full compliance if it will validate the developers design premises as quickly as possible

6. The functional “GREEN” test code is moved to the Project Assembly Module in the proper namespace folder structure.

7. The “GREEN” tests are run again to validate that the code has been migrated successfully

8. The final “YELLOW” stage of TDD is the Refactor Stage

9. The Working “GREEN” test are refactored into Objected Oriented Programming Best Practices using the TMD Design Principles, Code Standards and relevant Design Patterns that will allow the code base to pass the Code Review process

10. The completed “YELLOW” code base is submitted for Design Code Review and certified ready for the Application Integration development Stage

11. The approved Developed code is integrated into the Development Environment as an integrated design deliverable

12. All Code base Unit Tests are cloned into Integration Tests within the Test assemblies

13. The Unit Tests are marked as “Ignored” in the Test Assemblies in order to improve automated testing run performance as the code base under test is being exercised by the Integration Tests at this point and the Unit Tests would be redundant and time-consuming

14. The passing integration code base is submitted for Integration Review to ensure that the QA Objectives has been met before delivery to the QA Environment for QA Certification

15. Once all horizontal TDD code has been certified by the QA Team that it meets the QA Objectives then the code is returned to the BDD development process for refactoring into the “GREEN” BDD tests for viewing on the ATDD Website by all Team Members

Final Thoughts

Some may say that this process adds unnecessary complexity to the development process.

The community that supports the concepts defined above disagree.

They believe that the processes creates business solutions with a much lower Cost of Ownership (TCO).

The processes add a greater Degree of Clarity during development that far outweighs the relatively short learning curve required by all the teams to gain the quantifiable benefits of Alpha Development.

Wisdom Pearl # 122 – Open Your Mind to Possibilities

There are Generally a Hundred Ways to Accomplish some Task

… But Only a Handful of Good Ways

…… Have an Open Mind to other Possibilities