[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