Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

As I've written about in other questions here, the project that I'm working on now has no software process. That means no documentation (including hard copy requirements or specification), no source control, no bug database, bugs are "fixed" (hopefully) and new code is added at the same time, and no formal testers - we would fail the Joel Test so bad, it's not even funny.

Yesterday, my manager asked me to write a document about how to begin to fix these shortcomings. Note that I'm just an intern, here for 6 months. I'll be leaving around Thanksgiving in November to return to school. However, I think that I can perhaps get this project moving in the right direction, but I'm not sure where to even begin. I'm currently using CiteSeer and Wikipedia to attempt to find some papers and such that describe software processes and implementing them, but any advice, personal experiences, or links to blogs, papers, wiki articles, or anything else would be greatly appreciated.

share|improve this question

migrated from stackoverflow.com Dec 2 '11 at 19:01

This question came from our site for professional and enthusiast programmers.

    
Good-Fast-Cheap-Process - when a project gets behind, pare down the process. –  ChuckCottrill Oct 9 '13 at 5:58

6 Answers 6

up vote 7 down vote accepted

I would suggest that you look into Agile programming.

There's lots of variants, but they tend to have a few things in common:

  • Regular review and re-prioritisation of features.
  • Continuous integration and automated unit tests.
  • Focus on communication over documentation (in practise this means wiki-style documentation as you go over huge inflexible specs written in advance).
  • Flexible estimates resulting in burn-down charts and velocity metrics.
  • Regular prototypes that are reviewed over 200 page specs with sign-offs.
  • Quality at source, or as close as possible.
  • Regular stakeholder review - an extension of understanding your customers.
  • Get software out to market (and making money) ASAP.
  • Direct communication as much as possible.

A good place to start would be MSF Agile or Scrum.

share|improve this answer

We use Prince2 for the processes of project management, and it works very well. I would suggest it would seem tortuous for a company with no project management in place, though!

share|improve this answer

We adapted the development pipeline outlined in this video to our own needs, using TeamCity as our CI server.

http://channel9.msdn.com/shows/ARCast.TV/ARCastTV-Tuning-The-Development-Process-at-Spot-Runner/

TC is the only CI system I'm aware of that does a repository-push rather than pull, which means (theoretically) no more broken builds ever!

share|improve this answer

Given the situation, you being gone in 6 months and the team starting from no process whatsoever, I would limit the scope of what you introduce to one or two things that can be reasonably implemented and take hold in the time you are there. If it were me I would take a look at a source control tool and a bug tracker.

The reason I would start there is because getting these tools in place will help you to establish a baseline for the teams current performance and possibly identify recurring issues. Process changes are nice but these are basic foundation items that should be in place first.

share|improve this answer
    
Yes, I plan to limit the scope of what I do, but I also want to leave them with a roadmap so they won't be left wondering what to do next, especially if things start to go better. –  Thomas Owens Aug 19 '08 at 13:14
    
@Thomas Owens I think it is laudable that you want to leave the team a roadmap for after you are gone. However, it is unlikely that anyone will refer back to a roadmap built by an intern. This is not a reflection on your skills and abilities. That being the case I would pour as much effort as I could into getting the first steps in place. Do not underestimate the effort it will take to change the habits and processes of an existing team. In fact trying to get both source control and a bug tracker implemented in six months may be more than can be reasonably done. –  N8g Aug 19 '08 at 13:21
    
I think it can be done. This is a team of 5 people, excluding me. Two are full-time developers, one is a part-time developer on this project and part-time on other projects, one is a manager, and one is a marketing type. Both full-time developers are on board for a process and the manager wants to see improvements for the team's performance. It's not like it's being forced against their will. –  Thomas Owens Aug 19 '08 at 13:27

Just to echo the sentiments of some of the above, those teams who have no structure will fit better with an agile structure. Get source control today just start putting your changes into SVN and show some of your developers a diff when you are bug hunting. Start adding revision logs. If they can't see the benefits and ease of use of SVN then they are doomed.

share|improve this answer

Check out these articles on Continuous Integration for .NET programming using MSBuild, CruiseControl.NET, FxCop, NUnit, NCover and Subversion...

From the software development trenches

share|improve this answer
    
@Zack: We do not use .NET programming. I'm looking for general advice that can be used on any project using any technology stack. Things like choosing a model, implementing that model, and so on. –  Thomas Owens Aug 19 '08 at 12:36

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.