For those who missed Part 1, I wrote on how to use low tech tools such as paper, Post-IT Notes, whiteboards, etc. to gather requirements.
In this post, I'll describe how to better use tools such as Office, Project, Visio, etc. to gather requirements.
Here are my recommendations about approaching tools such as these in an agile context:
1. Use "Just Enough" tools. Don't use Rational Rose for UML diagramming if Visio will do quite nicely.
2. Buy the absolutely best tools for the job. In theory, you can write .NET applications using Notepad and command lines tools and save a few bucks on licenses. But the productivity will be poor and learning curve will be worse. Don't allow your organization to scrimp on tool costs - in my experience if its the right tool for job, paying the $500-1000 for a particular tool is worth the cost.
3. Invest in tools that are standardized. If you're working in Java, use Eclipse. If you're working in .NET, using Visual Studio. If you're an Oracle DBA, get Toad in your office. If you want a source control tool, get VSS, Subversion or CVS and not Seapine. That way when you go hiring for new developers, they've probably used your tools before.
4. Get really good at using the tools. It sounds like a basic suggestion, but I don't know how many project managers I've worked with don't really understand Microsoft Project. If you set up project in particular ways such as exposing the dependency columns, splitting the window to have the resource allocation on the bottom instead on the side, getting rid of the GANTT chart altogether, etc. productivity goes up considerably. Same thing with Word - the first thing I do with any document sent to me is look at how many Styles are being used and typically I find hundreds of them. Whomever wrote the document didn't understand how styles work, why they improve productivity, etc.
5. Buy tools that are easy to learn. Again, another dumb suggestion but I look for tools that a junior developer or programmer can understand. In many cases, this means buying more tools as the simplest ones can be single purpose. I've rarely come across a monster tool that works as a really good Swiss Army Knife for all occasions. The profiler I use though is stupid simple - its from RedGate and you load it up, point it at your project and start profiling in about 30 seconds. Its dumb simple to learn and cheap as well.
6. Have everyone have access to all the tools and have everyone knowledgeable about them. For example, I've worked in organization where only the Senior Project Managers were "allowed" to have Microsoft Project. If you weren't a Senior PM, then you had to either use Excel or find a Senior Project Manager to help you build a project plan. Technical resources should be able to open up a project plan as well - if you want your team to be accountable for deliverables, telling them that they're not important enough to see the plan sends the wrong message!
7. Automate work as much as possible. Use Continuous Integration, Test Driven Development, build scripts, O/R mapping layers, code generators, documentation generators, etc. where appropriate to automate drudgery work. Invest in time sheet systems, collaboration spaces, source code control systems, etc. where appropriate instead of tracking things manually.
8. Remember that every document, artifact and tool costs money to buy and to maintain. Every software license has maintenance costs. Every document takes up space on a file server. Artifacts have to be managed, secured, backed-up, etc. So travel light as product just enough documentation. Use just enough tools to do the job which also usually means use the ones that are the most productive. Remember that emails are documents as well - if you're finding that you're getting hundreds of emails a day, figure out how to get your team to be more concise, more action oriented and spend the majority of their time producing deliverables instead of documents!
9. Get the fastest computers you can afford. Get two monitors minimum for every developer. Get a good video card. If you have to wait 20 minutes to do a build, trying to do agile development is going to be tough. If paying an extra $500-1000 will cut that build time to 5 minutes then I would pay the money as it will result in massive productivity improvements on a daily basis.
Subscribe to:
Post Comments (Atom)
Subscribe Now
Blog Archive
-
▼
2007
(99)
-
▼
June
(12)
- Communication of Software Risks
- Developer Weasel Words
- How to be an Effective Stakeholder - Part 2
- Problem with Shoutwire Tag
- How to be an Effective "Stake Holder"
- Why Agile Software Projects are Good for Customers
- Agile Just Feels Natural
- How to Use Microsoft Project Efficiently
- Low Tech Approaches to Requirements Gathering - Pa...
- Low Tech Approaches to Requirements Gathering: Part 1
- I'm Somehow Ranked 6 for the Google Phrase "Buy Bo...
- Check out Funny or Die
-
▼
June
(12)

No comments:
Post a Comment