Jerome Lacoste on 18/03/07 19:13, wrote:
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 !
Just a quick note as a follow-up to the discussion above. I put together a
presentation detailing where I thought maven would be useful and why, putting
forward many of the points above, illustrated by rough estimates of time and
resources involved or saved, and management benefits.
On the whole all points were well understood and the dept will definitely
implement a couple of the proposals immediately, but the majority of the
mavenisation is something that may or may not happen over the long run,
depending on the ability of the managers to devote time to developing the maven
/ agile environment.
What would have been very useful and what I didn't have because I'm a consultant
who has only worked there for a few months, is a few examples of set-backs in
the company that maven would have prevented.
The managers are IMHO far too accepting of the seat-of-your-pants approach. The
additional start-up effort of mavenisation, learning the code quality statistics
and imposing the paradigm all seem a bit too much work, on top of the everyday
fire-fighting that they are involved in. I think the fire-fighting will have to
get more painful before any wholesale changes are made, but perhaps being
optimistic there may be a gradual implementation of more and more mavenisation
over the coming months.
Thanks for the initial advice,
Adam
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
