Welcome! This site specializes in providing tips and tools for Business Analysts and systems development in general. If you're new here, you may want to subscribe to my RSS feed. If you'd prefer, you can also receive my posts directly to your e-mail. Thanks for visiting!

(Updated post title - 11/03/07)

Here are some noteworthy quotes and concepts I’ve come across this week.

Nancy Knettell, Agile development: Don’t forget the documentation. Great article. I’d actually begun to outline a post on this recently, but see no need for it now. I like the idea of delivering functionality more quickly, but wouldn’t sacrifice quality documentation to get there. I’ve felt the pain of not having sufficient documentation often enough to know that if it doesn’t get you now, it’ll get you later. You simply have to have good specs and good design docs.

Often the goal of these agile methodologies is to have as little documentation as possible. I am all about timely communication and rapid time to market, but you need documentation. What concerns me is seeing everyone run away from the dumped “waterfall” bathtub without checking to see if the baby has to go, too…..Yes, the goal of all of these new approaches is to ensure that the software development process is more nimble to deftly handle changing customer needs. Rigid signoff software cycles have to make way for more agile forms of methodologies that allow for that feedback loop. But the question still remains: Why is everyone trying to kill the software functional specification?

Rob Appman, What requirements gathering technique should you use? We’ve begun to place more emphasis on visual methods in my shop recently. Although I’m not quite as comfortable with modelling as I am with traditional, natural language specs yet, I can appreciate Rob’s point below.

Methods that involve visualization of the requirements, such as prototypes, storyboards, scenarios, and to a certain extent use cases are beneficial when you have a business user who may not be concerned with the ins and outs of the technical solution or have a very long attention span for validating the requirements in a long-winded document. Using visual methods to gather and eventually validate the requirements with the user allows the analyst to drive the discovery more effectively than simply reading through a document with a prospective user.

Scott Barber, Smoke and sanity testing. Per Scott, Smoke and Sanity testing are terms that are used interchangeably. In my experience, the smoke test was the last kick of the tires prior to implementation, and the sanity test was the small, targeted test conducted in production immediately after code is deployed to make sure the new functionality works, and that selected key functionality hasn’t been broken. I didn’t know the origin of the term “smoke test,” though. Thanks Scott!

If you’re interested, the term “smoke test” comes from plugging in an electronic device after it has been shipped to a distribution point but before delivery to the final customer. If the device smoked when it was plugged in, the distribution point would send that device back to the shipper and request a replacement instead of sending it on to the final customer.

Mike Schaffner, Gimme the Names. Mike’s article here is on using metrics to give a true measure of whether or not a project has met it’s objective(s).

A way to truly judge the effectiveness of a project is through the use of adequate metrics… Developing a specific metric related directly to what the project is about can show a true before and after picture… The difficulty is that these specific metrics probably are not generally collected and there will be some hesitancy to go to the effort to collect the necessary data. However, if you make it part of the project and it is seen as a way to help get the project approved you’ll get more acceptance. You might also consider making the data collection temporary to be used to establish a “before” scenario and then drop it after you are sure the “after” scenario has reached a steady state.

Bill Miller, Part 1: How To Manage An Unrealistic Schedule. Sometimes making the date requires “all hands on deck” in a true team effort. This article made me think about the importance of cross-training and understanding all the roles in your company’s systems development process. You never know when your ability to “switch hats” might make the difference.

Nobody has only one job responsibility on this team; any task required to deliver the project can be performed by anyone on the team. If you need developers to test, then they put their QA hats on to test. If you need them to write documents, then they write documents. This is a team effort, and there is no room for prima donnas on a team - especially one that is delivering on a tight schedule.

Conceptual Thinking from Trials and Tribulations of a Business Systems Analyst. I’ve begun to outline a post of my own on a similar topic. Mine will be on the the importance of the analyst’s ability to draw concepts to their logical conclusions, whether that be decomposing high-level concepts, or rolling up details into higher-level bullet points.

Conceptual thinking is very important to an analyst. Not only the conceptual thinking itself but the ability to apply concepts to real world problems…. We can have all of the most advanced technological knowledge available but if we can’t apply the technology to the problem in an efficient manner it is meaningless…. The ability that you want to develop is the ability to see a problem from different angles. You want to envision it and turn it over and over in your mind looking at each moving part. You need to envision more than one solution and then you need to choose the solution most appropriate to the problem.

What are your thoughts on these quotes and articles? What articles have you come across this week that you thought worth noting? Do share!

Related Posts