Team Project Managment, how do you do it?

Ye' old general discussion board. Basically, for everything that isn't covered elsewhere. Come here to shoot the breeze, shoot your mouth off, or whatever suits your fancy.
This forum is not for asking programming related questions.

Moderator: General Moderators

User avatar
Zoxive
Forum Regular
Posts: 974
Joined: Fri Apr 01, 2005 4:37 pm
Location: Bay City, Michigan

Team Project Managment, how do you do it?

Post by Zoxive »

I always developed in php alone, but now i just got a new job and there will be a few guys working on the same projects, and i was wondering what you guys use to Manage the files, and keep track of who did what and not accidentally save over a file someone else just changed.

And from what i herd we will be using Linux servers if that affects anything.

I've tried searching but didn't know what to use as keywords, and i figured it would be best to ask.
User avatar
John Cartwright
Site Admin
Posts: 11470
Joined: Tue Dec 23, 2003 2:10 am
Location: Toronto
Contact:

Post by John Cartwright »

subversion, subversion, and subversion ;)

Did I mention subversion?

And why is this in the Testing Side of Development board?

Moved to General Discussion.
User avatar
Zoxive
Forum Regular
Posts: 974
Joined: Fri Apr 01, 2005 4:37 pm
Location: Bay City, Michigan

Post by Zoxive »

Jcart wrote: And why is this in the Testing Side of Development board?

Moved to General Discussion.
Because the poster is clueless.
alex.barylski
DevNet Evangelist
Posts: 6267
Joined: Tue Dec 21, 2004 5:00 pm
Location: Winnipeg

Post by alex.barylski »

1) Learn to delegate duties.
2) Use XP as a guideline.
3) Keep people away from architectural decisions as much as possible
4) Make junior developers focus more on implementation than interfaces
5) You and another experiences developer should hammer out the interface and unit tests ASAP.
6) Use a project management system (bugtracker, gantt charts, SVN, etc)
7) Establish a project coding convention and standard.
8) Delegate janitorial duties to a random individual once a week for an hour a day
9) Delegate documentation to someone willing - if not, do like janitorial.
10) Use source code tools like xdebug, profiling, source browsing, etc.

As a project manager you need insight into your project more than anyone else. I like to consider myself something of the captain of the ship and the coordinator of my fellow seamen. :P

Note: Some people would advocate that unit tests come before anything(aka: test infected) personally in my experience, you need something of a "proof of concept" or protoptype to really understand that system. I usually wait until I am sure the interface is stable before incorporating tests. Some might argue tests give you insight into the interface, which is partially true, but I find it more efficient to prototype first, then test.

Use documentation generators and as many tools to streamline your job as possible. Your time is precious and anything wasted is forever gone.

Have fun and good luck. :)
User avatar
Jenk
DevNet Master
Posts: 3587
Joined: Mon Sep 19, 2005 6:24 am
Location: London

Post by Jenk »

Hockey wrote:1) Learn to delegate duties.
2) Use XP as a guideline.
3) Keep people away from architectural decisions as much as possible
4) Make junior developers focus more on implementation than interfaces
5) You and another experiences developer should hammer out the interface and unit tests ASAP.
6) Use a project management system (bugtracker, gantt charts, SVN, etc)
7) Establish a project coding convention and standard.
8) Delegate janitorial duties to a random individual once a week for an hour a day
9) Delegate documentation to someone willing - if not, do like janitorial.
10) Use source code tools like xdebug, profiling, source browsing, etc.
Good pointers, but for 4+5, everyone should be involved - juniors may be juniors, but they'll still be able to provide valuable contributions to any design and/or discussions - if for nothing more than their own gain. For 9, try to use documentation tools like phpDoc and documentation really does become minimal, if any at all.

Also for 7.. try to emphasise that everyone looks after their own "mess." No one likes Janitorial duties, so remind everyone to keep check on their own "mess."

Gantt charts and timelines are a no-no. SCRUM (Agile) all the way baby.
User avatar
CoderGoblin
DevNet Resident
Posts: 1425
Joined: Tue Mar 16, 2004 10:03 am
Location: Aachen, Germany

Post by CoderGoblin »

Jenk wrote:
Hockey wrote:...9) Delegate documentation to someone willing - if not, do like janitorial...
For 9, try to use documentation tools like phpDoc and documentation really does become minimal, if any at all.
For coding documentation phpDoc/unit tests are usually sufficient. I still like to have someone as a single point of contact for the requirements who is responsible for keeping a "requirements specification" up to date (dated,versioned and preferably signed off by the client). I am sure most of us have had the problem of requirement creep..

I also agree a basic prototype is needed as the first thing. Just getting a client to agree on "this page will do this and move to that page" can often be a major step forward. The requirements often change drastically during this stage.
User avatar
Jenk
DevNet Master
Posts: 3587
Joined: Mon Sep 19, 2005 6:24 am
Location: London

Post by Jenk »

CoderGoblin wrote:
Jenk wrote:
Hockey wrote:...9) Delegate documentation to someone willing - if not, do like janitorial...
For 9, try to use documentation tools like phpDoc and documentation really does become minimal, if any at all.
For coding documentation phpDoc/unit tests are usually sufficient. I still like to have someone as a single point of contact for the requirements who is responsible for keeping a "requirements specification" up to date (dated,versioned and preferably signed off by the client). I am sure most of us have had the problem of requirement creep..
In steps Agile/SCRUM.. you have a member of the client team working with you. By with you, I mean sat in the same area as your team developing along side you. :)
CoderGoblin wrote:I also agree a basic prototype is needed as the first thing. Just getting a client to agree on "this page will do this and move to that page" can often be a major step forward. The requirements often change drastically during this stage.
In steps Agile/SCRUM once again.. weekly client meetings for breaking stuff down to bitesized chunks, and daily 5min standing meetings between developers for updates and issues. Not forgetting you have a client member sat with you for those quick "What about this?" questions :)

It's about adapting rather than controlling. "Process Control" involves all the timescales, deadlines, defined requirements etc. etc. but in reality that can be VERY hard work to maintain, and very hard to enjoy! Agile and SCRUM are about a real-world attitude to working - you start working and adapt when the need arises.
User avatar
Maugrim_The_Reaper
DevNet Master
Posts: 2704
Joined: Tue Nov 02, 2004 5:43 am
Location: Ireland

Post by Maugrim_The_Reaper »

On the OP's original questions - subversion. In won't repeat it three times as if chanting a prayer though...;).

Subversion will let you track all changes, who made them, and when made. You can also retrieve files from any previous date, or version. As a bonus it's relatively easy to learn it. As for tracking who did what, there's a "svn blame" function which can output files line by line with the username of whoever last changed that line clearly visible.
Bear in mind subversion needs all developers to work from a central repository - so all changes are easily updated to all other team members. So subversion would work across the network or intranet of your location.
User avatar
jayshields
DevNet Resident
Posts: 1912
Joined: Mon Aug 22, 2005 12:11 pm
Location: Leeds/Manchester, England

Post by jayshields »

Jenk wrote:Gantt charts and timelines are a no-no.
Not necessarily. Using project plans (and gantt charts) is still the most widely taught team management method.

It's specifically aimed at projects which have to stick to a time line though. If you have no time line, then I agree Agile development is a better way to tackle project management.
User avatar
Jenk
DevNet Master
Posts: 3587
Joined: Mon Sep 19, 2005 6:24 am
Location: London

Post by Jenk »

That's the whole purpose of Agile.. there is no deadline. The software you develop will continue to be improved upon, and progress is exactly that.. progress. Not 3 weeks of mayhem because "it must be finished by x" and a problem has arisen, etc. leaving you with an application that will need those cut-corners pasted back on, and a team full of a bored and frustrated developers/testers.

Agile development isn't just what you, as the developer, does.. it's also what the client does. Of course, you aren't just going to be able to switch your client(s) onto Agile, but I make damn sure they know I would prefer them to be, just as much as I ensure we are on the same page.
timvw
DevNet Master
Posts: 4897
Joined: Mon Jan 19, 2004 11:11 pm
Location: Leuven, Belgium

Post by timvw »

Jenk wrote:That's the whole purpose of Agile.. there is no deadline. The software you develop will continue to be improved upon, and progress is exactly that.. progress.
Imho, scrum has many deadlines: each sprint the teams commits to a packet of work and the deadline is the end of that sprint.

In my experience there are just too many businesses out there that first sign a multibillion contract and then assign IT to deliver a solution, with a FIXED delivery date, which is far from agile :P
User avatar
Jenk
DevNet Master
Posts: 3587
Joined: Mon Sep 19, 2005 6:24 am
Location: London

Post by Jenk »

That's what you get when people who don't know how development and IT in general works, are in charge of IT companies (or to be more specific, the sales team are clueless about IT development and support.)

Iterations are not deadlines. If you haven't finished your "chunk" within the iteration, it's fine. (Providing it's not down to you slacking, of course.)
alex.barylski
DevNet Evangelist
Posts: 6267
Joined: Tue Dec 21, 2004 5:00 pm
Location: Winnipeg

Post by alex.barylski »

Jenk wrote:but for 4+5, everyone should be involved - juniors may be juniors, but they'll still be able to provide valuable contributions to any design and/or discussions - if for nothing more than their own gain
I agree, what I really meant by that comment though, is don't leave those choices exclusively to the inexperienced (which is common practice).
Jenk wrote:For 9, try to use documentation tools like phpDoc and documentation really does become minimal, if any at all
I disagree. Proper documentation takes time and a certain skillset (hence the asking someone who enjoys it first - yields higher quality docs). Relying soley on phpDocumentor is not usually enough for any project beyond hell world.

Compare the MSDN with even PHP and the clear winner hands down is M$. Yea PHP is sufficient (once your up to speed) but MSDN really shines in this area. The point it, docs are usually more than just functional comments or module level comments. Programmers often get writers block, especially while switching from logic mode to english mode and back again.
Jenk wrote:Also for 7.. try to emphasise that everyone looks after their own "mess." No one likes Janitorial duties, so remind everyone to keep check on their own "mess."


I want to work with your teams then. :P You can preach this as much as you like but people still get lazy, having a routine "cleanup" time really helps in my experience. Personally I can take a Sunday off to spend a couple hours cleaning code, no problems. :)
Jenk wrote:Gantt charts and timelines are a no-no. SCRUM (Agile) all the way baby.
I disagree. For the most part your "stakeholders" will not be Ron Jefferies or Kent Beck and they will want some kind of deadline. This is where I differ slightly from an "Agile-ist" - while I agree with most principles. Keeping a Gantt updated isn't really alot of work if your experienced at project estimation. I never suggested it would dictate your project from start to finish right from square one, but rather it evolves with the development process.

Sure you hammer out some ideas before development, as even Agile suggests some fore-thought. I can crank out an API for an object in 15 minutes or less so a couple hours of planning (sketching the GUI, discovering objects, estimating atomic delivery times) can easily be entered into a project mangment program and give you some ongoing idea as to where you stand in the SDLC (helpful to stakeholders and Agile managers). It helps you refine your estimating abiilities as a project manager in my experience.
CoderGoblin wrote:For coding documentation phpDoc/unit tests are usually sufficient.
If your the sole developer and the only person going to use the source code, that maybe true. When you work on a real project with other real people, expecting them to rely on tests and API docs alone will almost *always* make the learning curve greater than it needs to be. This is epcially true if the architecture isn't a qualified/standard implementation of MVC - which in PHP applications is usually the case.
CodeGoblin wrote:I also agree a basic prototype is needed as the first thing. Just getting a client to agree on "this page will do this and move to that page" can often be a major step forward. The requirements often change drastically during this stage.
While I agree, that isn't what I was refering to, but instead I meant the object interface (not the user interface). Test infected people advocate that you hammer the API out then write tests immediately. I disagree because the API cannot be fully known without some prototype or proof of concept. Once the object has been normalized (DBA term but for objects) then I write tests and re-implement/refactor the implementation to do as expected.
In steps Agile/SCRUM.. you have a member of the client team working with you. By with you, I mean sat in the same area as your team developing along side you
You know what tickles me pink about this community and it's zeal for Agile, XP and design patterns. These books are written by industry veterans who work on million/multi-million dollar projects which are beyond most of us, so many of those principles or best practices are merely meant to be suggestions.

I highly DOUGHT that any of us here work on anything close to that magnitude, so this is where I define myself as a "Versatile" software developer. Meaning I have enough insight to make my own decisions based on my environment.

Expecting to have a stakeholder or end user available to you while developing in a small scale, is highly unlikely. Most small/medium businesses simply do not have the resources or people available to borrow one to you for more than an hour or so a week.

Likewise, team programming, while I can see it being effective, simply isn't realistic on small/medium business budgets.
It's about adapting rather than controlling. "Process Control" involves all the timescales, deadlines, defined requirements etc. etc. but in reality that can be VERY hard work to maintain, and very hard to enjoy! Agile and SCRUM are about a real-world attitude to working - you start working and adapt when the need arises
EXACTLY. So the steps I offered reflect my experience and my environments, not yours. Instead of focusing or suggesting corrections in my own, would it not have been easier to just state your own perspective in a point by point basis?
jayshields wrote:It's specifically aimed at projects which have to stick to a time line though. If you have no time line, then I agree Agile development is a better way to tackle project management.
No timelines??? haha...have you seriously ever worked on a project where the stakeholder said: "Go ahead take as long as you want?" I think you have misinterpreted Agile/XP.
Jenk wrote:That's the whole purpose of Agile.. there is no deadline
Haha. Read my last reply to jayshields

You guys seriously need to hook me up with a job where you guys work. :P No deadlines, no pressure...talk about job security. :lol:

While it's common knowledge in the development community, that the one constant in software development is change itself, this is usually easy to convince stakeholders of too. The problem is, deadlines are absolutely required. What book on Agile or XP did you read where it suggests no estimation or project deadlines? How is a business supposed to budget with no time estimate? Agile might not require a hardened deadline, but you have a deadline, it's just more flexible.

The books I've read on the subject (plus countless articles) suggest not that there is "NO" deadline, but rather, "getting real" which you are clearly not IMHO. Getting real is reducing waste and following KISS principles. That means developing only what is required and growing with that, rather than trying to get everything spot on first round.

Many developers try and hammer out the perfect API on the first go, Agile suggests just developing what is needed for that given time and thats it. XP advocates refactoring and refactoring often.

Team programming, for instance, although effective i'm sure, isn't "Agile" if there are only 3-5 developers in the company. This is where I always felt the they kinda contradict themselves. Keeping things simple, keeping things small (in terms of team size) and yet pairing when there are only a handful of developers. I'm personally not convinced pair programming is a best practice or something I would employ in my business model.
timvw wrote:In my experience there are just too many businesses out there that first sign a multibillion contract and then assign IT to deliver a solution, with a FIXED delivery date, which is far from agile
Hook me up wth a job... :)

Cheers :)
User avatar
Jenk
DevNet Master
Posts: 3587
Joined: Mon Sep 19, 2005 6:24 am
Location: London

Post by Jenk »

Laugh all you want Hockey, I have my client sat at the desk opposite me, who is currently reviewing my test cases. :)

We operate as close to SCRUM as we can here, and I have been involved in some large projects in past roles which did quite the opposite (on a side note, I even had one project manager tell me to stop working on a project, to concentrate on fixing a report system.. which was used to tell the client how the project was going to be late..)

Deadlines are deadlines. They apply pressure to the workforce, they are exactly what they say on the tin - if you have one in your contract you stand to lose money. Agile does away with those burdens and providing both you and the client understand it, there is no need for a deadline. The client will have understanding in your ability to get the job done, they don't need you to say "I'll have it done by next month" they may ask you how long, but that's just in the same context as you asking them "How does this look?"

Without deadlines you also do away with the lazy procrastinators. Everyone just gets on with it, not putting it off because "It's not due for another 3 weeks". This is also why we have daily 5minute meetings.

As for the Janitorial stuff.. it depends how you approach things. Our code is readable, and that's all we care. If something needs refactoring, it is spotted 9/10 within the unit testing.

"Proper" documentation consists of what? I prefer PHP's documentation to MSDN's by far. I don't want to read a book, I want to see what a function/method does. Perhaps an example but anything else and the test case and code itself do the talking. :)

Anyway.. hometime 8)
alex.barylski
DevNet Evangelist
Posts: 6267
Joined: Tue Dec 21, 2004 5:00 pm
Location: Winnipeg

Post by alex.barylski »

I'm laughing at your explicit use of "there is no such thing as a deadline".

I want you to find me a book ar article from a credible source which stipulates just that?

I cannot recall (if I did read) any book ever making a mention there is no such thing as a deadline. Software has versions for a reason, don't you think?

You set specs, agree on them, estimate a timeline, charge your rate add on padding and voila.

If you don't have deadlines, your not properly setting your specs in the first phase of the SDLC. Yes Agile and XP advocate allowing feature creep or "change" but no where have I read that you should ignore deadlines. Rather the idea I got from it all was KISS. Keep problems small so estimating is accurate. Refactoring is essential to keep code clean.

But no deadlines? I realize the only constant in software development is change it self...it's truely a living organism, but no deadlines? Software (more specifically) wouldn't be economically feasable with with timelines/deadlines...

Time is an essential component in any business usually.

Cheers :)
Post Reply