A big
project has bigger risk, so to
reduce the risk a big project requires:
- Better project planning & team coordination. A big project has
more dependencies between teams so you need to smoothen the workflow. Pay
more attention to communications between teams.
- Better to avoid technology risk (use familiar technology &
development methodology, hire consultants that have experiences with the
technology.) You better to try out new technologies/methodologies in
smaller pilot projects instead of a big project. The use of familiar
technology/design will also prevent hours of argumentations over
architecture details.
- Change one thing at a time.
Don't try to do too much things once. Use incremental development, deliver smaller improvements early
& often.
- It's more critical to follow best practices (e.g. standard/guidelines, architecture governance, domain modelling, design
patterns, design & code review, refactoring, requirement scrub, test driven development). You can't get away with breaking the
rules or take shortcuts such as in smaller projects.
- Pay more attention for reuse, avoid duplication of works
by different teams.
- Pay more attention to QA (e.g. continuous integration
test, automatic build & test scripts).
- Use available tools/framework for your infrastructure (e.g. Trac
for project/bug tracking, SOAPUI for web service tests, Selenium for GUI
tests, OSB or Spring Integration for ESB). Don't build your own tools
since it will add more risk and maintenance burden.
Source: Steve's blogs
http://soa-java.blogspot.com/
Any comments are
welcome :)
Reference:
Surviving Object-Oriented Projects by Alistair
Cockburn
Rapid Development: Taming Wild Software
Schedules by Steve McConnell
No comments:
Post a Comment