I am looking for resources that will help me lead a software development team. I have had little mentoring and need a quick startup that would allow me to manage a small project with a small team. Basicly, I'm looking for somethign along the lines of: 1. Create function specs (explanation). 2. Tech specs. 3. etc.
Does anyone here know of any books or websites that could help me? I have been searching, but haven't found anything geared for complete newbies.
For a small team, I'd probably use something along the lines of eXtreme Programming. There is a good intro at www.extremeprogramming.org
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Originally posted by Balaji Loganathan: You may need a free tool like gantt chart
Uh, no, that is likely to do more harm than good. Software projects don't translate well into gantt charts, in my opinion, let alone that they provide enough usefull information for the work they require.
The activities in writing software may or may not fit a Gantt chart, but coordination with other groups who require certain lead times for their services often does. I like the visual representation of time and dependencies. It could be the more "phasist" your project style, the more you might them. Curiously, our management folks use MS Project heavily but focus on the spreadsheet of dates and durations and rarely work with the chart side. [ July 07, 2005: Message edited by: Stan James ]
A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
Joined: Jul 11, 2001
Originally posted by Stan James: The activities in writing software may or may not fit a Gantt chart, but coordination with other groups who require certain lead times for their services often does.
Mhh. Do you have an example?
I like the visual representation of time and dependencies.
I don't like it for software development because
- it doesn't show variability in estimates/scope, thereby depicting a false accuracy and failing to extrapolate reasonable delivery dates, and - there are few, if any, true unavoidable task dependencies in software development, anyway.
Gantt charts work well for optimization projects, where you know exactly how long each task takes, and optimizing business value is mainly a function of reducing the costs of the project. They don't work well for exploratory projects. Almost all software development projects worth doing fall into the latter category.
Joined: Jan 29, 2003
Examples: We have to order hardware, software installs, network capacity and such with a certain lead time, the folks who configure each level of the software need at least "n" days to do their bit. They all like to see when their part comes up on the plan so they can be ready and balance resources. It's more like being the general contractor on building a house than anything to do with software, but certainly part of "project management".
I agree a fine level of detail - charting individual programming tasks - is not helpful. We did that up to a couple years ago and it hurt a lot. But I like it at the release level where we have some phases and milestones. Yes, refactoring the pictures when things change is a pain, but I've only had to spend an hour every couple months for the level of stuff I like to see.
"""""""looking for resources that will help me lead a software development team. I have had little mentoring and need a quick startup that would allow me to manage a small project with a small team. Basicly, I'm looking for somethign along the lines of: 1. Create function specs (explanation). 2. Tech specs. 3. etc. """"""
project management is not a big issue.....the only difference is instead of managing yourself you are now going to deal with more people... Coming to functional specs...what i feel is.. 1) understand the functioning of the project... Write you specs as clearly as possible ......using WORD, EXCEL, VISIO where ever required as these softwares can be effectively used to communicate your thoughts... Once you are done with the Fucntional specs....i prefer having a meeting with the developers and testing team ...askin them what they feel and how many days they would take to complete it...these guys will also give you enough info on what are the latest technologies and how effectively u can put them to use...so hear them...then start writing you technical specifications...
Then comes your role ..you decide on the time frame you want to give them,,,you can squeeze them to get max work or be generous enough to allow them more time...
Hope this can help you Suresh
identify your developers..talk to them
SCJP aspirant<br />SCWCD aspirant
Joined: Jul 11, 2001
Originally posted by suresh koutam: you can squeeze them to get max work
Notice that this is likely to backfire. There is some research suggesting that a software development team working to a tight deadline actually becomes less effective. One of the suggested reasons is that by trying to hurry up, they don't take enough time to think about how to work more effectively; they live with design compromises that cause more work later in the project etc.
Much better than managing by the deadline is managing by scope. That is, set a fixed milestone deadline and adjust *what* (how much) will be done until that deadline according to the actual velocity of the team.
Even though it has a strong .Net/Microsoft bias, "Coder to Developer" is brief, practical, covers an awful lot of ground in its relatively few pages and, I believe, contains a lot of "tips" and "wisdom" about precisely the kinds of issues I think your team might be likely to face.
It's a good resource: I'd encourage you to check it out!
My web site has links to some book reviews by Mike Gunderloy, Mike Clark, JavaRanch Sheriff Ernest Friedman-Hill and others. My blog discusses some of the book topics (as well as some topics that didn't make it into the book).
The goal of the book is to walk you (personally or as a team) through building software. We don't cover gathering requirements (which you mentioned) but it does cover implementing those requirements. It's much simpler than most processes and tries to be very lightweight and stay out of your way. It can provide a very easy way to run the team and implement the requirements you gather from any source.
We call Ship It! a gateway drug for processes. It will get you started quickly and make you aware of other processes/resources so that you can investigate them and try them at your own pace instead of trying to do all the research and get everything working while you are also trying to build a product on a deadline.
Also, fyi, we have a JavaRanch book promotion coming up in August (2nd-5th).
That's enough of an ad for now.
Check out <b>Ship It! A Practical Guide to Shipping Software</b><br /> <br /><a href="http://www.pragmaticprogrammer.com/titles/prj/" target="_blank" rel="nofollow">http://www.pragmaticprogrammer.com/titles/prj/</a>
Can any one pls tell me how a Good Project Management helps to release a successful Project to the Client.
Under certain pressure how the ppls at the higher level Handle ppls at the bottom level.
another question is like when a project meets his Deadline and the project is not close to finish how to handle that suituation??? whether the no of man hours to finish the project is to be increased or the no of developers on the Project can be raised to meet the deadline.