Note: this post was previewed and approved by the customer.
The customer already provided a complete high level project specification, so I will begin defining lower level requirements. First I will define an infrastructure for the project. This is a desktop application, which means defining infrastructure for it is usually simpler than it would be for a server application. We will use:
- Python 2.5
- wxPython 2.8
- Aptana Studio or similar (optional, but we will give preference to developers who use a fully featured integrated development environment (IDE)).
- Basecamp and Trac for project management.
- A Subversion repository.
- vWorker pay for deliverables (although we will consider pay for time after the initial phase).
- A customized set of coding conventions.
We divided this project into several iterations. In the first one we will use just two developers, so I will use just a few agile techniques (no product / sprint backlog and agile metrics for now).
I have found that many developers dislike the idea of using a heavyweight integrated development environment and prefer lightweight editors like notepad++, vi or emacs. But after many years as developer, I have found that a fully featured IDE saves a lot of time with features like code autocompletion, refactoring or the ability to show errors without having to compile the application.
are used to standardize the code structure and for improving code quality. Many developers prefer to do the coding “their own way”, but sometimes that is not an option when working in a team.
Basecamp will be useful for discussing high level features and milestones, as it provides a lot of collaborative tools customized to distributed software development: white boards, forums, project schedulers and trackers…
Low level development tasks will be managed via Trac, as it integrates pretty well a version control software (which allows to share the source code and see what each developer changed), a bug tracking system (where the issues and low level task are managed) and a wiki (what is useful for writing both internal and external documentation collaboratively). In the next articles I will explain more in detail how these work, and how I will use them in this project.
We will also use vWorker for selecting developers, and we will initially pay for deliverables, so we have a fixed cost. If the developers does a good work in the initial part we will consider using pay for time, as it give us more flexibility and it’s better suited for agile development.