Agile software development my own way, part 1/3

By on 17 January 2013, in Blog, Development, Method

Having worked a lot on Python/Django projects, some involving OpenERP, I once wrote an essai about agile software project management/development and work-time estimation and tracking, for my own use and memories. It could eventually be helpful to others. I will split it in 3 parts on this blog for easier reading. Blog posts are only sumups. The original essai gives more examples and a bunch of reasons-why for each point. But I consider these part of my personal experience, and everyone has to forge their own.

General time allocation

Here is a list of different tasks and times I consider required to allocate for a software project to succeed. Succeed means the final customer is fully satisfied (graphically, functionaly and deadliny-wise) and the developer is fully satisfied too (quality, maintainability, and restfuly-wise). I didn’t mention money nor fun but they implicit in the satisfaction of both. Given that I achieved some projects alone assuming all related jobs (project leader/manager, developer, HTML/CSS integrator, interface designer, system adminstrator, user supporter), my typical week (= one iteration) includes:

  • 1 day for project management (minimum). It depends on how heavy relations with the customer and external partners are. But counting only reporting/demo time, planification/prioritization and internal briefings or team management, plus common tasks like finding dates for everyone, tracking and imputing spent time on tickets/issues, we could easily spend more than a day per week on PM. Thus 1 day is really a minimum, and I pre-allocate it on every iteration.
  • for each specific sub-project (eg. a supplier I/O flow), 1/2 day for supplemental project management, to handle specific external relations (get the specs, get a remote tech to test the I/O flow with supplier, etc).
  • 1/2 day for standard refactoring (no deep nor architectural change). Without this, code quality decreases over time. By explicitely dedicating time for this task, I can clean code and avoid middle-term issues with copy’n’paste growing-like-blob code. A junior will need more time: he/she typically will produce more code than a senior, and will need more time to clean it.
  • 1/2 day for deployment on multiple environments. This includes specific tests, database schema migrations, etc. On an OpenERP project this is particularly important because I had to upgrade some plugins too, and there are two database-related operations (OpenERP and Django). There can be time needed to sync between production and pre-prod DBs, to be able to run the test-suite in pre-prod environment with real-world data, or clean user sessions or even the memcache backend. This point is very specific so allocated time may vary.

This let us 2,5 days for design/code/integration/sysadmin/support, if working alone. Two people would allow more time for these production tasks, but would require a little more PM time too, for synchronisation and ideas sharing. Pair-programming will obviously decrease unique coding time but will increase code quality and reduce standard refactoring time. I have an essai on that too, this will go in a future post.

These allocation types will obviously be not consecutive (eg. 1/2 day refactoring can be done as one hour per day IRL). This is particularly true if you deploy small subsets in pre-production more than once per iteration, which is my case. But knowing that I have 2,5 days for design/code allows me to announce global development durations/delays with a greater accuracy.

After four iterations (thus weeks, for me), the next is dedicated to deep-refactoring, architecture optimization and external (new-eye) code review. The exact time allocated is subject to vary given the size of the project, the coverage of the testsuite and the maturity of the developer-team. During this week, there should be time allocated to refactor the functional testsuite if possible. I’m not talking about unit testing, which should have evolved in sync with the code.

As this refactoring allows quicker future developments and better maintainability, this is a real value for the software and it should be paid like other iterations. Obviously, if this refactoring can be done along the way, this is easier to defend to the payer because every iteration will bring new features for him/her. But I often found myself unable to achieve deep architectural changes in standard iterations: this is not the same job. The required mental visions are very different. Allocating dedicated time makes the whole process smoother and allows me to go faster, because I don’t have conflicting-interest ideas while I work on each task.