Two of the challenges faced in every project are the task of identifying milestones and distribution of work. Many systems and methodologies have been created to help address these issues but there is little information about using these practices in Drupal development. This post is an attempt to identify a methodology and tool set for managing the development of a Drupal based project. I'm going to outline both the modules we use and the process we take to take projects from a conceptual overview to a finished item. The goal of this process is to allow for both in-house development as well as remote development while providing the mechanisms to evaluate progress. The information in this post is by no means a definitive solution. We'd be interested in hearing how others are approaching this problem with Drupal.
Before getting into the process let's take a look at the modules being used in this process. We are running our project management site on Drupal 5.1. Each project will be entered as an Organic Group so that we can track content on a project basis. Case Tracker will be used to create cases or tasks to assign to developers and themers. Once a fundamental understanding of the client's needs are in place a book is created. The Content Construction Kit is also utilized to allow for cases to be related to book pages that will be created to visualize the project.
In addition to Drupal we use Subversion to manage client documents, meeting information and media as well as development code.
Extreme Programming was utilized as a basis for the methods outlined in this document. It is a good system that has proven itself over time. We needed to balance the full gamut of Extreme Programming with a workable solution that integrated itself with Drupal. As a result, we focused primarily on the concept of "Use Cases" and spent most of our focus in determining what the project needed to have to be considered successfully complete.
The first step involves a high level of customer communication as the requirements for the project are extracted. Each client has a decent concept of what they want but typically has little understanding of how their needs map to Drupal. During this stage any information that can be received from the client is valuable. A new project is created in Subversion to track the documents and notes we gather from the client. Generally this structure is followed:
Client communications including office documents, pdf files, and text files are stored in client-docs. Meeting and developer notes are placed in the client-notes while design comps are stored in design-comps. Once development begins, code is stored in www.
Typically we have up to three developers involved in direct client communication to extract requirements. It is the responsibility of these developers to formulate the first ideas of what will be necessary to implement the client's project. Once all relevant information is recorded in CVS a project manager begins the process of translating the information in the svn repository to a Drupal book. Design comps and initial requests from the client should be finalized before the initial creation of the book pages.
Morbus is the maintainer of the casetracker module and posted a good explanation (here and here) on how to approach the integration of these modules. There is also an issue on drupal.org. It is worth reading to understand why we are approaching this problem in the fashion we are.
We begin the process by creating two new content types Client and Case at q=admin/content/types.
After adding the content types we need to use CCK to add a few fields. If you are following along with this post this happens at q=admin/content/types/content-case/fields. We are going to add 2 fields: Description and Related Book.
Now that we have both our custom content types and our custom cck fields defined we are going to attach the fields to the content type content_case. Content_case is the (q=admin/content/types/content-case/add_field) only content_type we need to add field_description and field_related_book to.
The last configuration item we take a look at is the Organic Groups configuration at q=admin/og/og. We are interested primarily in the Group Home Page section. We want to provide the "river of news" Group Home page focused on the Client node type we just created.
The project manager is now responsible for reviewing the notes and documents stored in svn for the client's project. As the notes are absorbed the project manager creates a book that stores the raw structure of the project. This structure identifies all of the necessary modules, views, pages, processes and users of the system as it relates to Drupal. When I perform this process, I often start with the following basic index for the book:
Time is then spent translating the client documentation that is stored in svn to the book pages. Each child page in the above tree is filled in to the best of the project managers abilities. Even though most of what is recorded in the book is normally represented and stored in svn it is entered directly into the book vs. referring to svn. This allows for a simple environment both client's and developers can collaborate in. Design comps are inserted to visually describe key areas. Once the development staff agree that all items are represented correctly, the client is invited to evaluate the book. Many times it is prudent to sit down with the client and help them evaluate the book. Once the client agrees that their project is represented accurately in the book a requirements freeze is put in place. Ideally, no new changes or functionality are introduced and both the client and the developers have a solid picture of what will be delivered.
Once everyone is in agreement with the contents of the book, the project manager takes each page of the book and generates a ticket that represents the functionality described. Because of the modifications we made earlier, each case can be related back to one or more book pages. When you create the case you will have a Related Book area that supports free tagging. Typing the title of the parent book page is sufficient to relate the case to the book. CCK uses the title to create a node reference to automatically display a list of related cases on a books page. Once all book pages are represented as cases, the project manager prioritizes to create the small releases suggested by the Extreme Programming model. The core functions needed to complete other tasks are given the highest priority and collectively form the first milestone or release.
The Extreme Programming model is a proponent of many small releases intermingled with constant customer communication. While not always practical to have that level of customer interaction, it is a good idea to have an internal meeting to evaluate progress. During this stage each member of the development team gives feedback on the project and the direction it is taken. Items that have been missed in the original project plan are identified, documented in the client's book and distributed through the case tracker as necessary.
The next milestone or release is set by re-prioritizing the remaining tasks. Development work resumes and the "Release" cycle repeats. The final rounds of this cycle tend to focus heavily on theming indicating you are getting close to a final release. Once everything is complete a final internal meeting takes place in which the entire project is evaluated against the content of the client's book. Once the development team agrees it meets the client's expectations, the client is invited to evaluate the work that has been performed. If changes are requested by the client, the book is modified and the process continues until the client is satisfied.
While this is not a perfect system, it does make considerable progress towards using Drupal to help manage a team of developers and ensure the product they create reflects the needs of the client. It is important to remain flexible and understand that no matter how well executed the project may be the client's end goal is always an elusive target. If you have additional ideas, methods or tools that could improve this process we would love to hear them.
]]>