Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "EclipseCon 2009/BoF/Agile"
| Line 6: | Line 6: | ||
* lack of out-of-the-box CI support | * lack of out-of-the-box CI support | ||
* legacy code that gets in the way of doing design using doing TDD and mock-objects | * legacy code that gets in the way of doing design using doing TDD and mock-objects | ||
| + | * checking in broken code | ||
on being 'agile with agile': | on being 'agile with agile': | ||
| Line 16: | Line 17: | ||
* less fat in the UI -- better APIs in the core, that can be tested | * less fat in the UI -- better APIs in the core, that can be tested | ||
| + | |||
| + | Anti-Patterns: | ||
| + | * Commenting out Tests to get the Build Green. | ||
| + | * Fudging the I-Builds so that it looks like the build passed, when it is broken. | ||
| + | * Varying Iteration Lengths. | ||
| + | * Delaying Refactoring | ||
| + | * Integrating code only at the end of the day. | ||
| + | * Less than 80% code coverage in unit tests. | ||
| + | * Code checked in that isn't covered by a test. | ||
Agile Estimating and Planning | Agile Estimating and Planning | ||
Revision as of 23:36, 8 March 2009
- agile applied to agile: you need to be agile with agile
- try out small changes to your process
- put in measures to detect failures early
crutique about things that slow you down
- lack of out-of-the-box CI support
- legacy code that gets in the way of doing design using doing TDD and mock-objects
- checking in broken code
on being 'agile with agile':
- if agile does not work for you then you need to change it
- there's no process, but there's still order in the percieved chaos
- the process is not the king, people are
- many forms of Agile, even RUP can be agile if done right
- working through the problems, not around it (1 day code freeze to stabilize things is not a solution, repetitive builds with tests that run every check in is)
- less fat in the UI -- better APIs in the core, that can be tested
Anti-Patterns:
- Commenting out Tests to get the Build Green.
- Fudging the I-Builds so that it looks like the build passed, when it is broken.
- Varying Iteration Lengths.
- Delaying Refactoring
- Integrating code only at the end of the day.
- Less than 80% code coverage in unit tests.
- Code checked in that isn't covered by a test.
Agile Estimating and Planning
- What makes a plan Agile?
- Updated every iteration.
- Backlog reviewed every iteration.
- Detail plan only one iteration out.
- Planning for Eclipse Projects
- Bugzilla as a Backlog
- Every feature, bug, or work item must have a bugzilla entry.
- Only assign work that is to be worked on.
- Iteration Reviews