I’m in a team of two developers and currently we have no formal processes for software development and testing – I’d like to adopt one solo initially.
Where I need some opinions is really on the matter of where to begin? Having read various books it isn’t terribly clear what the best starting point would be.
Recently I put in place a simple sharepoint/access database for recording issues and resolutions, and a changelog. Beyond that, testing is a manual process.
In my control is the process by which I design and develop any of my own tools or content and would very much like to adopt a lightweight agile methology that works well for a single developer but is intended to be a “follow my example” for the company to pull all the software development into it.
I do like picking out items from various projects I have on the go and refactoring them or adding functionality; one of the notions I was considering was the notion of user stories whereby I could cherry pick out various stories when I was in the general project to which it applies.
Anyone else in a similar single developer position who has adopted agile/other ‘ology?
8
I did this in my current position not in case we hire another developer, but to manage the current situation. I do: support, training & materials, documentation, requirements gathering, and make a presentation to C-level execs each quarter
A Sprint lasts a week. I built a small database to track any project that has multiple pieces. Most projects are just a one page document that is probably a consolidation of a few email messages. There’s no way I could plan my schedule any further into the future.
Project Owners I work with different people in different departments on many small apps, reports, changes, etc. The goal is to work as closely as possible with these people to work out the details. If I feel a higher-up manager won’t have the time to do this, I’ll suggest working with someone else who is a little closer to using the project. Very few people can conceptualize what the “really” want until they see something (prototype) and they come up with a better idea of what they want. No detailed specs or contracts here.
Adding one more developer could change this depending on the reason for the new hire. If it was the result of a large project, we would lengthen sprints, try to review each other’s code, share more information, and coordinate the project together. If it was because there is a backlog of these little projects, most of this wouldn’t change. The goal would be to get the new person up to speed and each one would work independently on the small projects. Of course, we’d like to have more exchange of knowledge and prepare for the “hit by a bus” scenario, but the reality is, management isn’t going to be happy if we add another developer and not get a lot more done.
1
If you only added one thing, I’d suggest regular retrospectives. From there you’ll be able to find out where your current (non) process makes you hurt, and you can start there.
My uninformed guess is that you pretty soon will realize that you need a good interface between you and whoever is responsible for the requirements of the systems you’re developing.
Delivering in short fixed-time iterations is generally considered a good idea in order to reduce amount of work in progress, managing expectations and establish a short feed back loop.
This is a rather defensive way of introducing some agile methodology. If you prefer a more agressive way, just read up on, for instance, scrum and try using that methodology although your team is smaller than a typical scrum team.
1