On 3/18/07, Adam Hardy <[EMAIL PROTECTED]> wrote:
I want the software house where I work to go to the next level with maven from where we are at the moment, which is a case of gross under-utilisation. We use maven as a glorified ant script to run tests and build jars. There are several other projects in-house which have not been mavenised but could be, there is a great opportunity to implement maven's release cycle management, and the need for configuration, filtering and profiles is huge. No-one on the project management side though has much interest in all the reports, the QA, test coverage, continuous integration or release management. I have a meeting with a chief PM lined up and I have to present hard data in terms of developer-days saved if we put maven into place. What is the best way to nail down potential future gains from mavenization into easily grasped cost savings? Are there any good stories out there on this sort of stuff? Does anyone have some experiences they would like to share in this area?
Introducing a new technology will always incur a cost. And resistance to change. So focus on the maven benefits and on the strategy to make these changes happen. Maybe can you start moving all projects to maven then improve your use of maven. Or maybe you should start. Probably a mix of both. * on projects not using maven. Compare them to those using maven. If maven is already helping, and people in the team already recognize the benefits, then this case is easier to argue. Further, you reduce the amount of technology used across projects making it easier to move people around (or when you take in new employees), or have site technology champions. Try to first migrate the projects which are related to the ones that already use maven (maybe because they use similar, or they share a pool of developers, or are on the same network and share the same development server). * on projects already using maven, you identify the gap doing 2 things: ** for each plugin listed under maven.apache.org and mojo.codehaus.org, see if you're using it. If not, estimate what would be the cost of introducing it, how often you would use it and what it would bring. Select the 4-5 most relevant plugins. I guess the release one should happen there. ** look at your process, and identify areas where automation/uniformisation would help. The plugin might exist, but it may not. Where do people make recurrent costly errors (during development/deployment/maintainance/...)? Can those be detected ? Think how you could make this part of the build. * identify one project and start adding the things yourself. Don't start with a too big of a project. Do this on your own time if you don't get approval. Make it in a branch if necessary. After some weeks, compare the before & after states. Be objective. Still for each costs look if these costs would go down if you were to share them across projects. If the boss is not happy for you to taking initiative, consider that you at least improved your own knowledge. * Look at indirect savings. Do they have problem to hire the right people ? Do people leave because they feel they don't learn new things? Is the motivation low because of problems that this change could address (at least in part)? Etc... 3 last things: * identify the right people to convince. Sometime to convince your boss you have to convince the right coworker. Or a respected person in your company * know the person you are talking to and identify the words he wants to hear. * be patient. Hope that helped. And come back with a summary of how it went ! Cheers, Jerome
