Tuesday, November 18, 2008

Best Practices for Developing with Flex in a Team Environment

The session didn't have much to do with Flex at all, it was more generally about project management.



Control Scope – the idea is to actually decrease the scope of the application as the cycle progresses

Pitfalls
Deprioritizing management in favor of development
Lack of baseline metrics to monitor impact and change
Decisions are based on intuition rather than evidence (e.g. estimates)
Not adapting project delivery style to fit project
Not planning for failure (ask what the problems are) – Ask what you will do should all of the bad things happen

The earlier you flag a problem, the better the project will run

If you find out in advance that you can’t meet the deadline, you have the option to decrease scope.

Tips and risk migration
Set top priority for delivery (small pieces - fully functional)
Make scope re-evaluation known up front
Avoid process just for the sake of process
Establish what the metrics will be up front

2 to 1 or 3 to 1 ratio for schedule compression – diseconomy of scale

When you don’t give management bad news, you rob them of the opportunity to make a decision

Forgetting the big picture – distracted by “real cool stuff”

Solving the problem that doesn’t exist

Don’t forget that when you are done, somebody else will have to maintain the code

Wait until the third time you have to solve the same problem before refactoring the code to provide an abstract common solution

Pitfalls
Not providing time in the schedule to allow for refactoring
Lack of developer lead testing
Lack of instrumentation for handling all cases

Tips and risk mitigation
Choose a framework and then stick with it

Define service contract and default data set so that services and UI teams can start working without having to wait on each other.

Flex 4 – adds flex unit for unit testing – builds test case based on definition of activescript classes

Automation tags on things that need to be exposed to Quick Test Pro

Determine the quality level that is acceptable for release (zero bugs will not happen)

Automated builds, unit tests, stress tests and creation of issues all done automatically.

Decision can then be made as to whether manual testing should be done on the build.

Suggest looking at products like Hudson for continuous integration

No comments: