Methodology Most Software Projects Fail How to

Methodology Most Software Projects Fail

How to not be like Most Projects Lean Software Development – Mary & Tom Poppendieck Lean Principals Eliminate Waste Build Quality In Create Knowledge Defer Commitment Deliver Fast Respect People Optimize the Whole

Eliminate Waste Must first recognize waste: that which does not add value Processes that take time but do not result in value Unneeded features Partially done, incomplete work Every bit of unnecessary code adds complexity that can result in defects and added maintenance Myth: Early Specification reduces waste

Build Quality In Reduce defects by not putting them there in the first place Inspect / Review code often and in small increments Functional and Unit tests written before code is submitted by developer Tests are run each time code is checked in If the build breaks, it is fixed immediately Automated tools like PMD, Cobertura used to check quality and test coverage. Checkstyle to enforce coding standards

Create Knowledge The idea that knowledge in the form of requirements exists prior to and separate from coding is false. Early design does not anticipate later complexity and feedback to product. Early release of minimum features for user evaluation and feedback Daily builds and rapid feedback from integration tests

Create Knowledge Cont. Team and or Leader with the experience and instincts to make good decisions. A modular architecture that supports the ability to easily add new features or modify existing ones. Development process encourages learning and seeks to improve the development process itself.

Defer Commitment Schedule irreversible decisions to the last responsible moment. Planning is not commitment. (We should be striving to not have too many irreversible decisions) Tackle tough decisions through experimentation leaving critical options open until a decision must be made. “In preparing for battle, I have always found plans are useless, but planning is indispensable. ” --Dwight Eisenhower

Deliver Fast Requires built in quality. Develops a user understanding that since you deliver fast, you can afford to take experimental approaches. Not hacking. Speedy delivery requires a team confident in being able to rapidly deliver defect free code. Engaged thinking people can be trusted to make good decisions.

Respect People Leadership focuses on fostering engaged thinking people and focus their efforts on creating a great product. Expert technical work force. Technical expertise is nurtured and projects are staffed with needed expertise to accomplish their goals. Responsibility-Based Planning and Control. Teams receive general plans and reasonable goals and are trusted to self-organize to meet the goals.

Optimize the Whole Optimize the entire value-stream. Most delays occur when responsibility is handed from one group to another. Optimization by Decomposition is a myth. Measuring individual silos leads to the collection of more metrics. Optimizing individual pieces of the value stream hides inefficiencies in the entire process and may induce additional waste.

Traditional Value Stream

RUP Value Stream

Proposed Bio. Data Value Stream

Who Attends? Demo and Acceptance COTR (Remote Go-To Meeting) User (Remote Go-To Meeting) Dev Team, CCC PM (Projector Conference Room) Retrospective - follows immediately afterwards, same attendees. Iteration Planning and Function Review – Follows immediately afterwards, same attendees.

Who Attends? cont. Estimating – Members “Bid” tasks, break into functional groups or individually for estimating tasks. Development Team Members CCC PM, COTR (optional) Reconvene to Refactor and Commit to tasks Development Team Members CCC PM, COTR (optional)

Who Attends? cont. Stand-up – Daily status meeting, no more than 15 minutes. All Development Team Members CCC PM, COTR (optional) Mid-Iteration Review - Like a stand-up, but looks at iteration as a whole and identifies any problems. Stay within 15 minute time-box. All Development Team Members CCC PM, COTR

Who Attends? cont. Iteration N + 1 Planning – This meeting is optional and may be handled via Wiki or email if no adjustments are anticipated from release plan. CCC PM COTR BUG Representative Dev Team Lead Data Center Rep (optional if agenda includes related issues)

Stand-up Meetings One of the heart-beats of agile practices Team picks the time of day. Strictly time-boxed (15 minutes max, 1 -2 minute individual reports) Same time, same location every day Primary purpose is to share information regarding progress (what I did yesterday -- what I'm going to do today, identify obstacles) No Problem solving or technical discussions.

Testing Unit testing – All significant custom code has unit tests using the Junit test framework. We don't write unit tests for third-party java frameworks, just for the code we write. Encourage Test-first development - Tests are written before the implementing code Require tests for custom code check-in. Cobertura used to report on test coverage. Developers encouraged to run tests locally, continuous build and integration runs all tests each time code is checked into SCM.

Testing cont. Integration testing. Junit and Junit-extensions to test Component and application Seams Web services Security Services Data access layer Other external system Sometimes requires “Mocks” when there is no Dev integration system. Documents assumptions and allows graceful interface changes.

Testing cont. Functional Testing – For each function, tests are written to demonstrate compliance with requirements. Selenium and Jmeter are tools used for functional tests. Functional test suite is run daily. Developers may run at will locally. Can be used to demonstrate compliance with external requirements by integrating other 3 rd-party tests.

Testing cont. Current stable build (last iteration) available for User review and testing. Provide access to wider number of BUG members for feedback and defect detection. Exercises application. Application logs monitored by development team for unexpected problems and conditions.

Continuous Build and Integration Hudson used to implement continuous build, test, integration, on-demand deploy. Entire system is built after each developer checks in code. Developers are encouraged to check code in multiple times a day to reduce merge and integration problems. Unit and integration tests are run each time changes to SCM are detected. May include one or more check-ins. If build “breaks” entire team is informed. Members may check Hudson “dashboard” to determine who needs to do what.

Continuous Build and Integration Fixing the build takes precedence over other tasks. Maven is used to configure the build and deploy. Good integration with Hudson is plus for Hudson over other systems. Once a day(night) full functional test suite and reporting suite is run to provide metrics on health and state of the system Cobertura, PMD, Java. Docs Deployment automated on-demand through Hudson

Out of the Swamp Lean: Reduce Waste and continually seek process improvement Each iteration results in tested, productionready code that has been accepted by the user The development process embraces change by building confidence through disciplined testing and continuous integration.