— IT-skills — 2 min read
Below article is not written by me, but i found it accidently and the article is very good. I am copying it here, so that i can refer to it or read later. Check references for author details.
This is from Medium article and the link from which this content was copied doesn't work anymore. There is no point in saving links in todays world. Thats one of the reasons i copy good content, so that i can read it later.
Don’t be afraid of documenting requirements. The cost of recording knowledge is small compared to the cost of acquiring that knowledge.
The realistic goal of requirements development is not to create a perfect set of requirements, but to create requirements that are good enough to let the team proceed with construction at an acceptable level of risk. That risk is having to do excessive, unplanned rework because of overlooked, unnecessary, incomplete, ambiguous, or poorly communicated requirements.
The first question to ask when someone proposes a new requirement is, “Is this in scope?” If yes, it must be addressed. If no, it does not, at least not now. But if the answer is “No, but it ought to be,” then you must adjust the scope to accommodate it. This has implications for cost, schedule, resources, commitments, priorities, and trade-offs.
Don’t give anyone an estimate off the top of your head. The best response to a request for an estimate is, “Let me get back to you on that after I’ve thought about it.”
No matter how much pressure others apply, never make a commitment you know you cannot fulfill.
Unless you record your estimates and compare them to what actually happened, you will forever be guessing, not estimating.
An estimate you give someone should not be influenced by what you think they want to hear.
The project manager must have some flexibility around at least one of the five key dimensions: scope, schedule, staff, budget, and quality. If these are all imposed as constraints, you will fail.
When it comes to software quality, you can pay me now or you can pay me a lot more later.
Strive to have a peer, rather than a customer, find a defect. Technical peer reviews are a proven technique for improving quality and productivity.
Software people are always looking for cool tools, but remember that a fool with a tool is just an amplified fool.
Unless you take the time to conduct retrospectives, study lessons learned, and continuously improve your team’s process, there’s no reason to expect the next project to go any better than the last project.
You can’t change everything at once. Identify those process changes that will yield the greatest benefits and begin to implement them next Monday. I’m not kidding: next Monday!
Many teams are being asked to do more with less. Too often, though, they aren’t provided with ways to enable them to do more with less. Without training and process improvement to increase efficiency and effectiveness, don’t expect higher productivity to magically happen.
If there’s one thing the software industry is repeatable at, it’s doing the same silly things on project after project. Use retrospectives to learn, to understand, and to improve continually.
An ounce of design is worth a pound of refactoring.
Hold your thumb and index finger one inch apart. Most of the time that’s the only difference between quality and crap. It’s a matter of listening a little bit more, checking your work, running the test again, referring to the checklist, reading the directions, asking one more question. Often that’s all it takes to close the crap gap.
Software development is perhaps 50 percent about computing and 50 percent about communication. But business analysis is entirely about communication. We are much better at the computing part.