[Zope] Managing networked projects / Outsourcing work

Heimo Laukkanen huima at iki.fi
Fri Oct 31 18:56:16 EST 2003


Hi ya all,

I would like to open discussion and collect some thoughts - and why not 
even best practices - on how people have and are managing Zope-projects 
that are too big for their companies or go momentarily over their capacity.

Like we all know, outsourcing or hiring a contractor is not as straight 
forward as some people might think. Even with a well written 
specification - during the production issues might be raised that need 
elaboration and tightly knit co-opration between the customer and people 
who do the work.

It is no wonder that user centric design and extreme programming ( 
usecases, usecases, usecases ) have become popular methodologies within 
Zope development. Distributed development has worked very well, though 
I'd say that is more thanks to certain individuals who are champions of 
a certain product or idea and make sure that those issues will be solved 
- rather than a development style or methodology.

The facts that Zope and Plone evolve very fast are possibly issues that 
limit the amount how much people can and are willing to outsource. Since 
there are no designpatterns and well known metrics by which to measure 
developer's work for an non specialist it could be next to impossible to 
judge the quality of work during the project. Results can naturally be 
judged by the fact whether software works and meets the requirements.

Also because of the nature of development I believe that for a lot of 
people/companies/organisations doing it by themselves and figuring out 
problems on their own is essential part of learning the system and 
becoming also better developers, adding more value to their own 
intellectual capital.

If you would like to extend the framework - you most likely would like 
to get your new tools included into the framework core and share the 
future development costs with others. However this adds a new layer of 
complexity to the project management, since now the requirements are not 
solely your requirements but suddenly there are others who contribute 
their thoughs and want to change things. Naturally you could just 
release the readymade code - but that would not guarantee that anyone 
would take it and use it - or want to contribute back to it.

So - when would I outsource or use contractors?

If possible, I would only outsource clear bits of the whole product - 
something that requires as little as possible continuous communication 
and co-operation with other teams during the development. Optimal would 
be that each outsourced bit could be developed as their own separate 
projects / processes.

If we would be talking about doing something that either party hasn't 
done before - I would definitely require someone from the contractor to 
join the onsite team if economicly feasible. Same would go if for 
example the reponsibility of creating an architecture would lay on the 
shoulders of the contractor. Reasons for onsite work are mainly for 
transferring ic from contractor to the onsite team, so that the work a 
contractor does would not create automatic lock in to just that contractor.

How to do the work?

If possible, a shared coding standard or a sort of concensus would be great.

In any case a shared code repository and code review throughout the 
project would be a must.

Tracker to manage bugs and other issues, including changes to 
requirements - and documentation written during the work, for example to 
a wiki.

Regular meetings online or offline. Irc is good, but it is much better 
to have voice discussions and shared whiteboard / workspace.

Clear metrics by which the project will be judged and payments paid.



How others have done it?


( Just a good read :
http://www.nwc.com/story/singlePageFormat.jhtml;jsessionid=LZX3DXZCSO1U0QSNDBGCKHQ?articleID=15201900
)

-huima




More information about the Zope mailing list