ServerZen.Net

Technology news centering around Python

Archive for February 2006

Project Management, eXtreme Style!

The 1.0 final release of eXtremeManagement (hereafter called xm in this entry) has been thrust upon us today. For those unaware, xm is a project management tool for Plone that follows eXtreme programming practises.

The Theory Behind XM

The big idea behind xm is to break up tasks into organized components that can be managed in a sane manner and then to ensure these components are worked on together by both the customer and the project team. And of course provide organization on a per-project basis.

The three types of components are:
  1. Tasks
  2. Stories
  3. Iterations

Tasks

Starting with the more fine grained component, tasks are basically todo items. The important thing is that tasks are kept relatively small and well-defined. Individual tasks get assigned to persons for completion. And it is the responsibility of the person(s) assigned to the task to estimate how long the task will take (there is a field for this).

Stories

Stories are a way of grouping tasks in a logical fashion. Stories should always include overview text of the entire “feature” or piece that needs to be built and often times when a person is working on a task included in that story they will have to refer to the story text itself.

Iterations

Iterations are what would often be referred to as phases or milestones. The customer and project manager/team decide together what stories can be reasonably completed in a certain timeframe and those stories are assigned to the given iteration. Stories that have been decided upon but not yet assigned to any particular timeframe (for example, the client has to get further budget approval) can be left outside of any iteration to be organized later.

For those of you with project management requirements, the author highly recommends (based on active experience) taking a strong look at the eXtrememManagement tool. Even if eXtreme programming techniques are not desired, using xm as a general-purpose project management tool can make projects much more manageable.

Feb 27, 2006 10:59:00 AM by rocky, 0 comments

Plone And Zope 3

For a little while now Plone development has been moving towards Zope 3 development styles, conventions, and techniques via the Five product on Zope 2. There is much documentation available on the internet today for following this path (at least from the perspective of Zope 3). One of the largest benefits of this is being able to use the Zope 3 Component Architecture (CA) which promises to provide us with more manageable and reusable components.

The repercussions of such a system is that developers have a more robust framework for developing applications and when components are developed by one developer, there is a higher chance that this component can be reused by another developer in another project (and of course by the same developer in other projects).

Business Impact

Benefits

Of course further development, refactoring, and refining the base architecture generally provides a more robust solution to such an extent that businesses have to spend less time and effort managing and supporting deployed solutions. Having reusable components means less time spent developing new components and more time spent plugging in existing components which proves to take less time and thus less expense.

Risks

Migration of existing sites can get quite complicated. Also having to deal with switching frameworks such as making it difficult to maintain backwards compatibility with third-party products. Of course this gets easier as more and more third-party products adopt the same Zope 3 develop techniques which means education of this process moving forward is vitally important.

Random Non-Plone Impacts

From the perspective of a traditional Zope 2 developer deciding whether a new project should be developed and deployed on Zope 2 VS Zope 3 there are two different types of people:

  1. Zope 2 developer who is accustomed and familiar with Zope 2 development techniques with no interest to move outside of the Zope 2 development model.
  2. Zope 2 developer who is interested in Zope 3 development techniques but due to missing functionality (Zope 2 has obviously been around a lot longer than Zope 3) in Zope 3 has to develop and deploy on Zope 2.

Obviously the move to Zope 3 development techniques for #1 Zope developer doesn’t make any sense. But developer #2 would be very interested in getting equivalent (in capability) functionality from Zope 2 into Zope 3. And once enough of the required Zope 2 functionality has found a capable equivalent in Zope 3, #2 developers will have a path to fully migrate to developing and deploying on Zope 3.

In order for a full set of Plone components to deploy and run on Zope 3 a lot of this traditional Zope 2 functionality will have to have equivalents on Zope 3. So in the process of providing this functionality for Plone on Zope 3, Zope 2 developers will have much of their wanted/needed functionality migrated as well. This means non-Plone Zope 2 developers will have a higher likelihood of being able to deploy on Zope 3.

Conclusion

It is the recommendation of this author that moving to Zope 3 development techniques is a required manner of evolution for Plone and the Plone software stack (which is in agreement with the Goldegg effort of course). And related to this, the development process and attitude should be to build Zope 3 components on Zope 3 and build them so they (for the some finite time period) can be deployed on Zope 2 until the convergence of Zope 2 and Zope 3 is complete.

Feb 3, 2006 12:03:00 PM by rocky, 0 comments