Software Best Practices

Hi,

This issue of software requirements is one that concerns me a lot.

I'm a software developer and work on a outsourcing company, so they basically "sell"

resources to other companys. Usually we are integrated on a team and we are given

specific tasks, sometimes coding, other times design it depends.

Now, at the customer, usually they own the project so the rules are made by them.

If they don't have anything to manage the requirements, how can a external resource fight this, if he can ?

On other projects we had this same issue, but being a external resource we are not able to do nothing, I guess

that can have impact on the way you develop and manage "your requirements", since we are given taks . . .

Shall we have our own way of managing completely our taks, when no requirements management process

is implemented on the customer ?

Thanks in advance for any input.

Best regards

Luis

Hi Luis,

So, if I get this right, you are a individual contributor contractor who does not get any say in the development methodology of your client. The client has poor requirement practices especially around managing requirements (traceability, prioritizing).

There are a few things you might be able to do. First, if there is any kind of risk management, raise a risk. You can state that you have found with previous clients the lack of <X> requirements practice has led to <Y> impact. Because you have seen this situation before, you can state with some authority the likelihood of suffering some project pain because of the lack of a good practice. This may help them justify improving their requirements practice.

Second is that you should use good practices yourself. Often projects don't use good practices because they really don't know what good practices look like. The state of development is actually skewed to the side of poorer practices so that many people have actually been on a well run project with good development practices. You can help them see what those good practices might be like.

Third, you may want to evaluate your own participation. It may be completely impracticable but you could refuse to work on a project you consider too poorly run to participate on. If you have that option, that can be a powerful statement.

Finally, you can keep pointing out that there are better ways to do the requirements work. Sometimes the squeaky wheel gets the grease. Sometimes, see the previous paragraph :-)

Almost all outsourcing, I've seen, just sucks.

Hi Louis,

I have to treat this as a risk problem. There is a risk to the project for not using good practices and there is a risk to yourself/company for being blamed for not doing the job correctly (because they wouldn't do the good practices...).

Sometimes, it seems that even if you try your best the company/management will make decisions that you believe put the project at risk. It is the company's/management's prerogative to do so. They can determine how much risk they want to face. If they want to take it on (by not doing what we believe are sound practices) that is a call they can make. We inform, they decide. So, if the project is risker than it should be, we did what we could.

The second part of the risk is to yourself/your corporation for being blamed for, lack of a better phrase, malpractice. At that point ignore the book that says do not use "ad hoc" practices and do what you believe is necessary to lower your own personal risk. Use an Excel spreadsheet, Enterprise Architect, or some other simple tool to trace the most important requirements (trace route: Source -> Set (e.g. use case) -> Individual Requirement -> Test; don't trace to design/code).

I have some contracting work going on in my home right now. I noticed that I don't force or expect the contractor to use my tools, I expect that the contractor has tools that are better suited to the job the contractor is doing for me. I wonder if that makes sense in the software world as well.

After reading your reply and I must say I agree with what you have written.

On more risky situations, my company asks the consultants to inform them

on a regular basis so that they can be aware of what’s going on.

This don’t eliminate the risk, of the project not being delivered on time and

so on. But at least they are aware of what’s happening and like you said we

inform and that’s the customer decision, nothing to do about that.

Regarding the tools, for what I’ve seen so far when working with Microsoft technology

I found little more than the IDE a SCM system, and of course a version of Office.

That’s why I asked about the tools and what we can do on such working environments.

Regarding to the good practices, I was reading an article of Scott Amble, and found something interesting; he talks about PSP – Personal Software Process. He says that

we should use this when “A prescriptive software process for individual developers.”

Sometimes that’s the way I fell on some costumers J

Thank you for your replies.

Best Regards

Luis