How can I divide a web development project among a team?

Question

I and some of my friends want to start a web development project. We all know basic HTML, CSS, javascript, php and a database(mysql) separately but we dont know how to work in a professional way. Is there any link or tutorial, which can help me to build a proper team with perfect workflow of web developing.

Answer 1

Some things to think about:

Identify who your stakeholders are. These are the people who will be using the product you are working on. Once you know who they are, decide how you will show them new functionality and how frequently this will happen. A lot will depend on how quickly you expect the team to turn out new functionality. Perhaps you could consider showcasing your progress every two weeks? Or perhaps once per week? Regular showcasing is important as it is a good way to receive feedback from your stakeholders. Will you showcase from your production environment? Will you use a separate website to show work in progress?

Identify a Product Owner. The Product Owner will be the person who decides on priorities, i.e. what you will work on next. The Product Owner will also serve to turn incoming requests for work in to a clearly prioritised backlog of tasks. Ideally the Product Owner is just one person. They could be a member of your development team or possibly somebody from the sales/marketing side of your business.

Then, start to think about your 'definition of done'. This is what you consider to be a complete piece of work. This might include developed, tested, documented and released to a production environment. The definition of done will determine the quality targets for your team. For example, you could say that for each new piece of functionality you add, you will write an automated Selenium regression test. Regression testing is important in web site development as the more functionality you add, the more risk there is that you will break something that is already released.

Next, think about how you want to do planning. Most teams will look to plan weekly or fortnightly. Some teams will plan more frequently, especially if they are following a Kanban style agile framework. Regular planning is important as it will allow you to respond to change, such as adjusting to the feedback you get from showcasing your progress.

Finally, think about how you will handle improving the way you work. A regular 'retrospective' can be useful. This is where you look at how things have been going recently and then think of ways to improve.

Answer 2

It sounds like you've got a great cross-function team there, so my best advice is to not divide yourselves. I notice your question is tagged as "Agile", so I'll assume you're ok taking that approach. If you create a prioritized backlog of work to be done, work from the top and just pull stories in. Whenever you can, team up with each other to move stories to Done before grabbing another story.

Scrum is a pretty nice framework with work in, but that's your call if you want to do that. If you want to get a better feel for scrum, ScrumAlliance and Scrum.org both have good info and I'm personally a big fan of this book as an introduction: Agile Project Management with Scrum by Ken Schwaber

As far as improving your workflow, I'd look at Kanban. It's a way of managing and improving process, so you can use it alone or in addition to other processes and frameworks like Scrum. Leankit's blog on Kanban is one of the better introductions to it out there. David Anderson's book is probably the de facto starting point, but maybe others could offer some other good books.

I hope that's helpful. I tried to give a concise answer to a very open question.

Edit: You may also want to take a look at the accepted answer on this post, which has a link to a mini-book introducing scrum and Kanban.

Answer 3

I agree with everything that Daniel said with one exception:

I wouldn't go for SCRUM, Kanban, XP or some other philosophy right off the bat. My advice for you - check books like Agile Samurai.

This provides everything that touches on the subject without making you go through 400 pages.

After that, when you know what makes one different from another, you can decide whether to go for SCRUM, Kanban, or a little more complex XP.

Answer 4

My quick and direct answer is: Start with Kanban.

Put everyone on the meetings, make a product backlog and start to put tasks on some physical board.

Some links that can help you:

http://www.everydaykanban.com/what-is-kanban/

http://leankit.com/kanban/what-is-kanban/

This is not all, it's just to start. Following all the suggests from the other members will put you on the right way, but you asked for some link or tutorial, so, it's there. ;)