What methodology/process/tools support remote and “on the bench” development? [closed]

Question

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.

---

Want to improve this question? Update the question so it's on-topic for Stack Overflow.

Closed 3 years ago.

Improve this question

I work for an IT services company that develops products as enablers for further services consulting. We have technical consultants/developers that need to be able to develop remotely and when back in the office "on the bench".

What methodology/process/tools support development by consultants when they are remote, or "on the bench", in particular how to support the management of the deliverables.

I have looked at DVCS systems, along with KanBan board tools, but I'd like to get opinions in the best way to handle this style of product development when it's not a traditional back room development situation.

Answer 1

Here's my TFS pitch.

Your developers/consultants need to be able to work in house, remotely or offline. That means local workspaces. TFS 2012 has that.

With the high rate of turnover, you need managers to be able to easily and quickly assign specific tasks to developers. With TFS you can create work items, break them into subtasks and easily assign them to any team member. When the developer begins working, you'll be able to see it and any check ins can be quickly associated (semi-automatically) with the subtask. So you'll know who did what task, and be able to see the exact code they implemented to accomplish it.

If you have managers maintaining the product backlog, all a developer needs to do is select one of the tasks assigned to him, get the latest from the source and start developing. Minimal overhead for him/her.

With Web Access you can see/edit your entire product backlog, get burndown charts (and other reports), see who completed what and when, assign tasks to team members, change team members, etc. All without VS installed, so no need to have a license for a manager if they don't develop.

Finally, fully integrated automated builds will allow you to ensure that consultants don't break your source. Gated check ins are great for this kind of team. The changeset is stored, and a build is ran. If the changeset would break the build, the check in is denied. You can also automate builds on the other side, post check in.

Any file created outside of VS can be easily added to source control. Once the file is added, TFS monitors the file for changes and you can easily add the changes to a changeset. Once in source control, its fully in source control and available to everyone.

You never really mentioned any database requirements, but the new SSDT is awesome for declarative SQL development. So far, I've not had to write a single ALTER script, which makes me very happy.

There is also fully integrated support for code reviews, build verification tests, automated deployments, architecture tools (with rules that can be enforced) and more. The rabbit hole goes pretty deep, but if you don't need it, none of it is forced on you.

So, the methodology I would suggest is a KanBan style set up, with managers pushing tasks rather than developers pulling them. This way you can reduce the impact of your high turnover rates without overly micromanaging your consultants. You'll be able to easily give them a task, let them accomplish it, and have complete visibility of the work they perform. I'm not sure how you gather your requirements, and how much input in the dev process your customers have, so its hard to go into more detail. TFS supports storyboards associated with work items, so you can give detailed specs to your developers. Also the Feedback Manager can facilitate in getting feedback on working software from product owners.

You could go Scrum with defined sprints, but I think a lot of the overhead of sprint reviews and sprint planning may be a waste for you, if you consultant turnover rate is high, and/or you don't need/want a lot of input from your consultants on user story breakdowns/requirements gathering.

Answer 2

There are several leaders in the ALM space, including VersionOne, Rally, ThoughtWorks Studios Mingle + Go + Twist, Jira Greenhopper, and others. These are all fundamentally iterative in nature, supporting Scrum+XP. There is a new crop of tools coming up that support Kanban, if that's your preference.

The key, though, is to decide what approach you plan to take. Iterative or flow?

Beyond that, if you're using a continuous integration server - whether open source like Jenkins or commercial like Go - then that combined with an SCM system (git, for instance) gives you visibility into what's been produced and the ability to distribute that work.

Back to your specific challenge, it seems to me that iterative wouldn't suit you, since you have people coming and going as they enter and leave the bench. Mingle supports this quite nicely, as do a few of the others. In fact, I'd suggest that the leading methodologies don't really lend themselves to your situation, as you will have neither iterations nor flow, most likely.