A quick introduction

My college semesters include a 8 week project working for an actual company with a software need in order to get some much needed practical experience. I have just started such a project with 5 other students. We're required to spend roughly 40 hours a week per student on this project. We're working with SCRUM as the software development method, this was assigned by our teachers.

The question

Day one of the project just ended which has created some questions for me as to how to start a project in the 'real world'. Our first day included working on a project planning document (not sure what the English term is), creating a appointment with the company for an introduction and the opportunity to start specifying the requirements and setting up some standards for the behavior within the group.

However these items didn't take that long to finish. We've made some concrete plans for tomorrow and the day after we'll meet the company. This still leaves several hours of 'work-time' unspent. Is it usual not being able to fill every hour of a day for work at the start of a project or are we simply too inexperienced to see what work needs to be done at this stage of a project, or are we, perhaps, going through the above list too fast?

How does this work in the 'real world'? Do you spend your time wondering 'what should I do now', or do you have a clear view of what you're supposed to do at that moment?


For the specific project there's not much you can do until you find out what the client wants. However, there are some things you can do now so your team is ready to go.

  1. How are you going to handle version control?
  2. Will you do code reviews?
  3. When will the daily standup meetings be held? What are the rules?
  4. What role does everyone play?
  5. How are builds handled?
  6. Where to put documents so everyone can have access?

Have the group work on a very simple project to test all of this out either in a required language or pick one familiar to the team.

| improve this answer | |
  • 2
    And when that's all done and you still have time left over, do what everyone else does and go on YouTube, Slashdot, StackOverflow, etc. – James Apr 10 '12 at 20:47
  1. Set up your version control system and document its configuration
  2. Set up an automated build system
  3. Set up automated Unit tests that integrate with the build system
  4. Set up a web server to serve up static content like automatically generated docs and reports from your Continuous Integration System.
  5. Set up a Continuous Integration server to run your builds and tests and publish the results
  6. Set up a Wiki to use for "live" documentation of the project and other things.

  7. Determine what you are going to use to manage your backlog of features and tasks

  8. Determine who is product owner and responsible for tracking all the work
  9. Determine who is going to make sure the team stays focused on the committed work
  10. Determine how often builds will be released to your product owner, and stick to this schedule.
| improve this answer | |

My internal alarm is ringing when I see the opportunity to start specifying the requirements and these items didn't take that long to finish together. While other answer provide great ways to set up an healthy environnement, be sur that one of the biggest peril is under specifications. So you might spend some time on this phase. It can be a week (full-time) in your 8 week project.

The hard part is finding the missing spec, and the things that are not working in the current specs. It is really difficult to criticize your own work. What you should do is a bit or role playing. Some people are the client, and the other the project members. The client is someone who will judge your work (teacher, mentor...). He could be an external member of the project (find someone with some experience with this kind of project). Iteration should go this way:

  • client reads the requirements
  • client ask questions about missing requirements, feature specification, possible failures assessement, tests organization, framework choice...
  • project team answers & update the documents

One you knwo what you want to do you may begin to set up a workflow for your team.

At the end of this work you should have a set of features with basic task breakdown for each of them. Set up milestones (week 3 we need to have finished milestone 1 & 2, week 6 we need to have stable source code to test it on weeks 7 & 8 and stick to small bugfix + documentation writing ...). When you start a milestone, publish a list of tasks somewhere (you can use an excel sheet or even a bug tracker for this) and agree on who starts with what. When someones finishes his task, he takes another one (and communicates about it). Before that, someone else should have a quick look at what he has done to check if it is correct and complete.

Setting up all this workflow is kind of hard for beginners, but is far more important than having a nice wiki service. You need to take at least a week to think about how you will work. You don't need to apply the organization I have described here (this is just really an exemple) but you should take some time to think about anything that works with you, and set up the necessary tools. The goal is to engage everyone. There should always be an easy answer to the question "what should I do now?".

| improve this answer | |
  • As for your internal alarm, we just started to roughly index the requirements until we have the opportunity to meet the client. As far as your time table goes, my teachers appear to agree with you, as they've specified that the pre-game ( read: before we start our sprints ) portion of the project should last roughly 2 weeks. – Willem Apr 10 '12 at 15:50
  • Then maybe you can add some context about the material you have right now. Is it a topic? A title? Do you have domain knowledge about what you are going to build? Do you know the framework the client wants you to use? Do you know what items you client will request you to deliver? You probably have a lot of question to ask about those. I would recommand working on this kind of questions. Will you need to design a UI? If so you can draw some mock ups to use as a basis for discussion. – Simon Bergot Apr 10 '12 at 16:28

Yes, starting a project is slow and will often not fill the whole day due to the need to concert with others which may have their own schedule. (Some other questions have proposed things you may want to consider, but the company partner in your project may also have requirement for them, speak about those and be ready to propose something if it doesn't matter for them).

Back to what I think is the core of your question. In my practice, starting a project is made incrementally -- only part of the team start work on the new project and only partial time -- while completing the previous one.

| improve this answer | |

What should happen at the start of a software project? How does this work in the 'real world'? Do you spend your time wondering 'what should I do now', or do you have a clear view of what you're supposed to do at that moment?

What I look to do at the start of a software project is spend time getting to know the people I am working with.

I like to develop and modify team practices and procedures over time, however the start of a project or a team can be a good time to agree on some initial ground rules or 'charter'.

Look to find a way to work together that works for the team for whatever situation and mix of members you have, and find the best tools for email, im, ticket tracking, wiki, etc. for the situation at hand. Become comfortable with using and adapting these tools to meet your specific needs so that when the time comes for quick changes you are proficient in making them.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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