On Business Analysis in an Agile Setting
While the titles of who performs the work may differ, business analysis skills are critical in any methodology.
Read MorePosted by JB | Feb 6, 2008 | Business Analysis |
While the titles of who performs the work may differ, business analysis skills are critical in any methodology.
Read MorePosted by JB | Feb 6, 2008 | Methodology |
The way I see it, offshore outsourcing of IT work – chiefly development and QA – is not going away. Those of us stateside will have to learn to adapt and thrive in this new type of environment in order to remain marketable. For many of us, retooling may be necessary.
Read MorePosted by JB | Feb 1, 2008 | Business Analysis |
Mitigating the waterfall effect.
Read MorePosted by JB | Jan 28, 2008 | Business Analysis |
For some reason, last week I picked up and began reading from Benjamin Franklin’s autobiography. In it, he mentions a mutual improvement society that he and several of his acquaintances founded in colonial Philadelphia to compare ideas, to critique each other’s publications, and to gather sociably. They called it “Junto.” The idea behind Junto was that in gathering like-minded individuals with a common cause for civil discourse, all participants stood to benefit.
Read MorePosted by JB | Jan 22, 2008 | Requirements |
Use cases are atomic functions that are portable and not dependent upon a certain situation. They are requirement “objects” in the “object oriented” sense. I think that modularity and “reusability” are among the most valuable aspects of using use cases to express requirements.
This modularity can be undermined, though, if we allow our use cases to get too far into specifics and implementation detail.
The book “Use Cases: Requirements in Context”, by Kulak and Guiney, provides us with a couple simple ways to self-check our use cases to ensure that they include the appropriate level of detail, but aren’t reaching too far into design.
Read More