Question about how projects are managed within software companies

Delirium

Howdy everyone.

I've a non-coding question. It's still related to development, at least from my perspective.

I'm currently working in a company and I've reached the end of my tether with a problem.

It's about how things are discussed, worked on and released. Just so people know, I don't have a degree in computer science/programming etc. I did a basic programming course with city & guilds to get in the door, and subsequently just learned as I went. I mean that in a "how do I fix this?" way as opposed to doing courses within the company.

To give a simple example. A customer rings up about a modification to our program. We then discuss how these changes are to be made. The only person who is expected to take notes of this work, is the person who will be doing the coding.

Everyone else just discusses it, but doesn't take notes so as to maybe be able to double-check later the work is done. The person does the work, and does the majority of the testing on the modification. Another person might, but not always, do a secondary test to verify the work is ok.

Now if the person assigned to do the work forgets to do the work, it's possible that the work won't be done and will just be forgotten about, as was discovered last week.

So I'm basically asking to see what is the professional way to essentially manage a project so as things are documented to be done and can be overseen easily.

I've said it in work that I refuse to believe this is the norm for a software program to be developed.

I imagine the regulars on this forum have worked in a variety of companies so would have a variety of opinions as to how it should be done. I haven't mentioned the development environment deliberately as I don't want to get bogged down in a mode of thinking specific to certain languages.

I'm looking for ways to manage a project from receiving a request from a customer to approving it for general release.

I look forward to your responses.

murphaph

Well we use a project management/tracking tool in some shape or form for all our projects. Depending on complexity (and budget) we will use anything from http://en.wikipedia.org/wiki/Trac to Basecamp to Jira to track project milestones, bugs, feature requests etc.

Having one lad jot down what he's supposed to do and then forgetting it doesn't sound too professional at all. With a proper project management tool the team lead/project manager would assign a ticket with the feature/bug story attached to a developer for fix/implementation. The feature/bug then moves to QA (perhaps to be assigned to someone else to test). Things should either be open or resolved, but not just forgotten about. With a proper project management software package it's easy to check outstanding tasks etc.

Procasinator

Even in lieu of great project management, a basic bug/feature tracking system should be used.

There are plenty of ones out there, some open source (e.g. Bugzilla, Trac, etc) and commercial (JIRA, Fogbuz, etc) options available.

Usually someone should create the bug in the system (preferable a PM who checks work has been done). This bug can have a milestone, priority, etc. The developer can document the solution or problems encountered in the bug, if appropriate, and mark the bug as resolved when the work is done. If the developer is busy doing something else, the bug can be assigned to someone else. By doing this, a developer knows all the work they need to do. A project manager can also see how much work is left for a milestone and/or release.

This is useful in code too, as you can leave comments in the code such as "//Bug 503: Fixed the flux capacitor so no more fires are started on activation" and if people need more information, they can refer to the bug management system for more information.

Delirium

Thanks folks, that's exactly the sort of stuff I'm looking for.

I know how things are done in my company aren't professional with regards to managing the projects. Thats exactly why I started the thead.

So thanks for pointing me towards a place to start:)

hanleyc2

koth wrote: »

A customer rings up about a modification to our program. We then discuss how these changes are to be made. The only person who is expected to take notes of this work, is the person who will be doing the coding.

Maybe this is some new form of super charged Agile development

srsly78

COYW

Understand your frustration OP. In relation to on of the above posts, how have people found Agile and TDD?

hanleyc2

I find Agile works well in my org where the product development teams are small. It has its draw backs, such as lesser documentation will be produced, but I think that the flexibility it allows compared to a methodology such as waterfall outweighs the negatives. With Agile, new or changing requirements can usually be catered for with little impact. The end user/customer can get to see the working functionality much earlier and give their feedback earlier in the cycle.

As for TDD, that is a harder one as it requires a change in the mindset of the developers. If implemented fully, the software quality would surely be of a much higher standard than what is probably being produced in a non-TDD environment.

The Corinthian

hanleyc2 wrote: »

Maybe this is some new form of super charged Agile development

It's called 'cowboy coding' and it's been around for a while.

Delirium

I've give the boss stuff from the suggestions on this thread to look at. Seem receptive enough about it.

If he doesn't go for it, how do I manage my own work on projects so as to keep track of everything? Do I use a bug tracker or project manager type program just for myself?

The Corinthian

koth wrote: »

If he doesn't go for it, how do I manage my own work on projects so as to keep track of everything? Do I use a bug tracker or project manager type program just for myself?

If it's just for your own use, I'd probably put together some form of bug/change request tracking system using a spreadsheet, if I were you.

yop

The Corinthian wrote: »

If it's just for your own use, I'd probably put together some form of bug/change request tracking system using a spreadsheet, if I were you.

Good point that, even for your own work its important to do that. It very easy to get lost in the load of work.

We use Dropbox, as I work remote for the companies, and we have a spreadsheet for bugs and work done and to be done.
Also a document there for the boss if he comes up with some new features or questions. I then update these accordingly.

Creamy Goodness

also stick a H - High, M - Medium, L - Low beside each bug so you can categorise and prioritise each one.

Saint_Mel

I used PVCS Tracker in one company I worked in.

p

It's important to have a "Product Owner" who vets all decisions with the client. The coders can still be there, but they work with the client to prioritise features. If you just say yes to everything the client says, then you'll most likely end up with a complete mess of unusable software at some point.

Also, having some kind of QA process is important. Everyone makes mistakes so you can't always trust the coder to verify it. Your project might not be large enough QA staff, but really the Product Owner & client can do that role.

Some colleagues of mine have told me they do 'code reviews' with each other in order to check functionality



One piece of advice when trying to improve your workflow. Try make it better bit by bit. It takes time to introduce new practices, and not everyone will agree with them, so take it slowly rather and focus on making things better, not making things perfect.

Good luck & let us know how you get on.

Freddio

Another project / bug tool which you can divide up and give selective access to

Mantis


http://www.mantisbt.org/

Sparks

The Corinthian wrote: »

If it's just for your own use, I'd probably put together some form of bug/change request tracking system using a spreadsheet, if I were you.

To be honest, in that sort of a situation, I'd use trac and install it in such a way that the others on the dev team could use it as well if they wanted. It's a little more work to start (say, 2-3 hours to install and read the docs and set up if you've not used it before), but (a) it's far more flexible than a spreadsheet, (b) it's far easier to add in new bugs and track existing ones, and (c), when the others see it makes your life easier and it's just there and they can use it, they'll start using it too, which in turn makes your life easier in the long run. It's change by stealth, but in some outfits (and I'm afraid it does sound like the place you're in is a cowboy outfit, it's a deeply familiar sort of story for many of us), that's the only way to improve things (ie. without looking for resources or effort from higher up to get it done).

You may find you've now become the guy in charge of the ticket tracking system and you may find you're not being paid for that, but if it makes your life easier and looks very good on your cv (and "introduced and managed more professional practices" generally does), then you're effectively being compensated indirectly.

The Corinthian

Sparks wrote: »

when the others see it makes your life easier and it's just there and they can use it, they'll start using it too, which in turn makes your life easier in the long run.

They won't. Seen it tried before. Doesn't work until they're finally ordered to do so.

Sparks

The Corinthian wrote: »

They won't. Seen it tried before. Doesn't work until they're finally ordered to do so.

Some won't. Others, I've seen jump at it because they know they're in the weeds and it'll help.

Mind you, if management sees one of the trac-fed dashboard displays, they tend to give those orders... they just tend not to think they're worth it until after they've seen them. At least, not in the cowboy part of our industry.

croo

I use Trac myself - there are some nice scrum variants of it too like "Agilo for Scrum"

I use eclipse so I particularly like Mylyn and how it is integrated with Trac (and lots of others like Jira & Bugzilla too). I find the "context" idea of Mylyn brilliant and you can store a context on a Trac issue so if you have to come back to an issue after a week or more (or pass the issue to someone else) the context really helps in finding your place & train of thought again quickly.

ChRoMe

You want to use http://balsamiq.com/ for doing any sort of design notes and it integrates with JIRA, mentioned previously

The Corinthian

Sparks wrote: »

Some won't. Others, I've seen jump at it because they know they're in the weeds and it'll help.

Depends on if they are in the weeds or can see the benefit. Many see the problem, but don't really see it as their problem, unless it affects them rather than the client. Others shy away from the extra work involved in keeping such systems up to date, in much the same way that commenting and proper documentation is a chore that they cannot see the benefit to because they're the only one on the project.

Certainly if a tangible benefit to them is demonstrated, then they'll jump at it. But often as not I've seen resistance against such systems from the rank and file coders.

ChRoMe

The Corinthian wrote: »

Depends on if they are in the weeds or can see the benefit. Many see the problem, but don't really see it as their problem, unless it affects them rather than the client. Others shy away from the extra work involved in keeping such systems up to date, in much the same way that commenting and proper documentation is a chore that they cannot see the benefit to because they're the only one on the project.

Certainly if a tangible benefit to them is demonstrated, then they'll jump at it. But often as not I've seen resistance against such systems from the rank and file coders.

Its actually less work once you start using it(JIRA or whatever)

I cant imagine any developer I've met not recognising the value of such systems.

Trojan

koth wrote: »

I've give the boss stuff from the suggestions on this thread to look at. Seem receptive enough about it.

If he doesn't go for it, how do I manage my own work on projects so as to keep track of everything? Do I use a bug tracker or project manager type program just for myself?

The Joel Test is old but a true classic. Here's a slightly updated version.

If your current employer is totally resistant to change (i.e. improvements) then I'd serious consider looking elsewhere. It's ok to start somewhere without good processes, and introduce them, but it's career suicide to remain somewhere that eschews industry practices*, you won't be employable in a few years time.

* I was going to say "industry best practices", but they're not even "best" practices - they're the most basic elements possible.

The Corinthian

ChRoMe wrote: »

Its actually less work once you start using it(JIRA or whatever)

I cant imagine any developer I've met not recognising the value of such systems.

Depends on the developers you have working with or under you. Some may see the value of such systems. Others will see the value of such systems, but will instead want do use their own system. Others can't see the value of such systems. And others again don't care, because the buck does not stop with them.

As a simple example, I once had a developer under me who was quite talented, but had little formal education in IT. He took to using Helvetica Narrow in his IDE, so that he could get more code on one line. Naturally, complaints began to reach me from the other developers about this and so I tried to explain to him the importance of a mono-spaced, standard font. He wasn't interested, because he was both used to his way and his way worked for him.

In short, you'd think that any developer would recognise the value of such systems, but you'd be surprised how often such systems won't 'stick' for all sorts of reasons.

ChRoMe

The Corinthian wrote: »

Depends on the developers you have working with or under you. Some may see the value of such systems. Others will see the value of such systems, but will instead want do use their own system. Others can't see the value of such systems. And others again don't care, because the buck does not stop with them.

As a simple example, I once had a developer under me who was quite talented, but had little formal education in IT. He took to using Helvetica Narrow in his IDE, so that he could get more code on one line. Naturally, complaints began to reach me from the other developers about this and so I tried to explain to him the importance of a mono-spaced, standard font. He wasn't interested, because he was both used to his way and his way worked for him.

In short, you'd think that any developer would recognise the value of such systems, but you'd be surprised how often such systems won't 'stick' for all sorts of reasons.

I dont think I could stay at any company with people not willing to improve their processes with stuff like continuous integration etc etc. Even if they are capable of writing good code, it really doesn't matter if they dont understand the whole software development cycle.

BostonB

I can only echo the above.

Managing development badly tends to institutional in my opinion. In that it become and ingrained habit, and changing it is very difficult. I would say it has to happen from the top down. Someone has to force the change, and it has to be someone with the authority to enforce it.

Probably the first thing all developers should be asked to do, or learn in college is write a development management database. Indeed development managers should be taught to use them too.You can't manage a software product if you've no metrics on bugs, or new development, testing, and release.

If they haven't realised that, I doubt they'll ever get.

That said most of the places I've work don't manage development well at all. So its very common.