Suggestions on Working Style [closed]_问答_开发者

Closed. This question is opinion-based. It is not currently accepting answers.

Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.

Closed 3 years ago.

Improve this question

My question is about more general workflow of a development team rather than a direct coding problem, and I don't know if this type of questions are allowed here.

We have created a digital agency-like brand in a multi-brand company. All of us (currently 4 people) are experienced freelancers but none of us worked in a serious development team that has its own co开发者_Go百科ding standarts, procedures, project management style etc.

Currently, we're doing just fine. But we absolutely think that we have to improve our way of working. Because, we merely catch our deadlines. Even that, most of the time we miss our deadlines or withdraw from some of the cool aspects of our projects. Although we're working hard, we accomplish little.

Now, you can rightfully ask that why our supervisors don't make some improvements. Actually, we're a strange group -or at least i think that way-, we're our own bosses. Most of the time, no one gives us directions or orders and we're free to do whatever we want to do. Now, before I go to them and tell them about the disturbance i have, I want to learn some ways to do this right, or how do others do it and try to apply it first.

Sorry, It's been a longer message than I planned.

Thanks in advance.

Read Software Estimation by Steve McConnell. It'll tell you a lot about the difference between an estimate, a target and a wish. :p

Seriously.

I think that, without fully embracing agile methodologies, some of its ideas may help you. For ex.

Do an early stand-up so everyone knows what people will do during that day and what was done the day before
Have short cycles (e.g. 2 weeks) with clear & tangible goals
Aim for a "staged delivery" process
Incorporate customer's feedback early in the process
Aim for test-driven development, don't write without writing tests

Even if this doesn't work for you guys, you should adopt some process in order to improve from something. The real mistake is to not adopt any of them all.

As you grow organically, you will find some things that work, some that don't, etc. Don't follow blindly any methodology.

As a start I suggest spending less than ten minutes to rate your team using "highly irresponsible" but nonetheless legendary Joel Test.

It seems you need a bit stronger overview of the amount of work planned and outstanding at any given point coupled with a more realistic view of teams capabilities. An easy-to-use and easy-to-learn project management software could be a good start.

As such, FogBugz is great, I recommend at least giving it a try, as it allows to keep track of both estimates and actual time spent. And I'm not affiliated with Joel in any way.

If you don't already, I would suggest having some coding standard. This will help you make your code easier to share and you will spend more time on functionality than decrypting each others code. You don't mention the language you are using, but you can probably borrow one from a similar project and adapt it to your needs. If you are working with other people code, you might need to be flexible on this.

I have a very good experience of agile methodology, especially with small motivated team such as yours. It is important to have a list of the features, you will then want to focus on what is the most risky and/or what is the most important for the project (instinct often lead to start with what is easier for us, which is a bad thing in the end).

The exercise of splitting features into smaller tasks, done in group, will help you clarify on how things will be done. Is is easier to evaluate smaller tasks. Poker planning have given me the best estimates, even with unexperienced team, each time my teams get better at it. Everyone should be included in this process, especially more junior people who learn a lot from this.

Code review each others' code, you will learn a lot this way, and may save time on debugging. This can be done in pair on a daily baiss, and bring the biggest challenges to a group code review once in a while.

Don't worry, working hard is the true solution at becoming better, patience is the key!

Whilst I hate to simply point you at a link, the following Wikipedia article on software development methodology is a great starting point

http://en.wikipedia.org/wiki/Software_development_methodology

You don't mention the level of experience you have and whilst a lot of the information may be a given to you, it provides links to additional information on current methodologies such as Extreme programming, Agile, etc. which may prove to be of use when you're looking at how you can improve the project management/development practices within your team.

I think you should look into agile methodolory(http://en.wikipedia.org/wiki/Agile_software_development) such as scrum.Your advantage is you are a small team with only 4 people and so you know each other's strength and ability this can also be very use full for any type of project management.
From personal experience working in a small team where most of the people were new to development (<1 year experience), agile had a very small learning curve and we used bit of different agile methodlogy such as scrum and xp to have a mothod of working that greatly improve our effieciency and help us keep our deadlines.
Regards
Shivam