One of our developers works from home. What tools should be used to manage him?
Edit: The way we currently work is - Issues are assigned to him via Mantis - Once he has completed an issues he puts his changes into version control (SVN) - He changes the status of the issue to Resolved in Mantis - If QA is happy the issues is closed else is re assigned to him
How can the above process to be improved ?
Trust. Evaluate his performance based on the results he produces.
By tools I'm hoping you aren't thinking about using VNC to monitor his keystrokes or something crazy. Just let the guy have his process, and if he delivers you don't actually need to know his exact workflow, if he is wearing a bathrobe, etc.
Then again, what tools are you using to monitor your in-house employees?
On a related note, when I work form home the tools I find most useful to help collaborate are: a VoIP client and an chat client, email (of course) and lastly the phone. It usually feels more casual to start communicating with something other than a phone call, and upgrading only when there is much to be said.
A good source control tool. You can ask him to check-in the source every night..
In my oppinion, this is not a question of tools but a question about processes.
If he's working from home all of the time, then ensure he understands the tasks given to him and the background. (what he should do and why)
The need for tools should be driven by development methods (e.g. scrum, extreme programming). Let Your developers decide what's best for them.
a webcam. Actually, come to think of it, don't....
Trust him to do the work, but make sure his code gets sent back to base very regularly. You can check up on progress through milestones and deliverables at regular times that you set. Its pretty much the same for in-house employees, what makes you think they aren't surfing SO all day long? Take the same methods you use to ensure they're working hard and apply them to the off-site developer.
If your methods of ensuring your in-house devs are working is to look and see if they're sat at their desks typing away, then shame on you :)
Don't let them "go dark", by this I mean work on something big for weeks without needing to show any intermediate results. I'm going to rewrite this message bus to work 10x faster, should take a month, I'll show it to you when I'm done. This is never a good scenario, in house or remote, but even more likely to fail to meet the needs when done remotely.
I'm not implying that they are going to lie to you and go to the beach, just that that having no input for a long time is never a good plan. None the less, it is tempting to give off site people dark projects since it seems to fit the situation.
The most important factor would be the role he/she is responsible for. If the programmer is involved in support activities, the infrastructure needed would be completely different. For general purpose programing, the bare minimum requirements would be:
There are certain other constraints you need to look into, for example the licensing agreement your organisation has when it comes to properietary software. Also there might be other security issues regarding access to company network. Is it acceptable to provide access to Databases? What about data security?
Assuming you've got the standard tools for everyone working at the office - some sort of source control tool, some sort of project management bug/task tracking system, etc, the only other tool you're likely to need is an inter-office IM system - we use Skype, ourselves, and it allows us to keep in touch with our out-of-office employees, both for business reasons and to keep them feeling like they're part of the team by having them participate in our off-topic chatroom.
Beyond that, you need to stay in touch with your out-of-office worker, just like you'ld stay in touch with one working in the next room - chat with them at the beginning and end of the day to see how they're progressing on the tasks you've given them and to see if they're stuck on anything that somehow hasn't gotten to your attention. We also track the hours that people work on different projects, so at the end of a day we can get a rough idea of how hard folks are working on different things, and how long. That may be helpful as well.
Stay in touch with them, make it easy for them to stay in touch with you, and keep an eye out for any signs that things aren't going as well as you'ld expect. If you're the manager, it's the same, you just need to remember to stay in touch, since you're not going to see him in meetings and at the coffee urn.
Update: Someone commented with "What do you use to keep track of the hours someone has worked?" We're using Unfuddle at the moment. It's good enough for now, although it doesn't fit our needs as well as we'd like.
I would say that the "first best" tools would be job specifications and schedule of deliverable milestones.
If the specs and milestones are defined, then you should be able to measure the developer's performance based upon his ability to deliver the agreed upon items.
I don't like to let an offsite developer get more than a week out without a summary and an invoice indicating how he is contributing to the overall project.
From the technical perspective one thing which could help you to establish good working relationship is the use of automatic code validation tools which should be fired on SVN commits. This way you could ensure that the code contributed to your project meets the coding standards.
Aside for that you need to establish good communications - i.e. if the person who works from home could not attend team meetings install an IM like Skype and make sure that everyone participate in the chat room so she could speak to all team members as a group and initiate one-to-one conversations as needed.
From the personal perspective - you need to pay extra attention to the tasks given to people you could not talk to face-to-face. They have to be twice as unambigous as the ones you give to the developers on-site. Make sure you could provide additional details as needed and these details are documented somewhere (a Wiki works great)
Have you considered doing a code review with this person 1 - 2 x a week? You'll need to build time with each other that you normally would get at work, and this will foster that interaction to some extent.
The real question is how well do you know this person? That is, have you worked with this person long enough to gauge reactions / attitudes by voice alone? A schedule of frequent meetings and check-ins will maintain a feeling of trust while allowing you to frequently inspect the work completed.