1 / 9

BA Team: Product Ownership, Analysis, and Solution Design BA Bi-Weekly Mini-meeting Feb 3, 2011

BA Team: Product Ownership, Analysis, and Solution Design BA Bi-Weekly Mini-meeting Feb 3, 2011 01-2011. SDD – More than just a Deliverable.

holding
Télécharger la présentation

BA Team: Product Ownership, Analysis, and Solution Design BA Bi-Weekly Mini-meeting Feb 3, 2011

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. BA Team: Product Ownership, Analysis, and Solution Design BA Bi-Weekly Mini-meeting Feb 3, 2011 01-2011

  2. SDD – More than just a Deliverable December and January were the months of tackling the SDD – Solution Description Document/Diagram. Now it’s time to take a couple steps back, and look at what EIM’s PMO is expecting from the BA team on a project that led to the SDD requirement.

  3. The key is to provide Top-Down Direction It’s not about the SDD, it’s about driving the entire software development process from an agreed-upon vision of the solution rather than driving the solution from 1000 functional requirements… The SDD simply represents a top-down “compass” that helps drive all other decisions, from architecture to SME sessions. We don’t need to collect 1000 requirements if 700 will build the right solution… A Top-down approach is the best way to prevent over-gathering of requirements or misdirected gathering of requirements. Top-Down map the forest boundaries before filling in trees Bottom-Up define every tree & wait for a forest to emerge Every possible detail is recorded, someone or some team then has to synthesize all the details in hopes that a solution emerges... Inherent in this approach is that no 2 people will “synthesize” the details the same way, and too many details make a quick assessment of “do we have the right things defined” impossible. The big-picture solution is clarified up front, so that everyone from the customer to the implementation team has a very clear idea of the end-goal. Once the high-level solution is agreed upon, the team will “decompose” the vision to determine the details that are required to achieve the vision.

  4. Software hasn’t traditionally followed other design industry Approaches Automotive Industry Conceptualize/Sketch Model and Prototype Produce Car • Build actual car using detailed specs • Create a model or mock up of the car, work out kinks. • Determine more detailed specs… • Sketch a high-level design, see if it flies with potential consumers…

  5. Software hasn’t traditionally followed other design industry Approaches Film Industry Storyboard for plot Finalize Character Sketches Produce Movie • Storyboard a plot, work out kinks to determine a flow that works… Character traits are in development. • Add details to characters to match plot… • Produce Movie

  6. Software hasn’t traditionally followed other design industry Approaches House Building Industry Sketch/Determine Basics Finalize Designs and Details Produce House • Select type of house (basic style that is appealing) • Select main elements (# rooms, bathrooms, garage) • Detail the floor plan • Finally work with contractor who determines all the “how”s • Build house using detailed specs.

  7. Software hasn’t traditionally followed other design industry Approaches Bottom-up Development Record every detail Build to Functional Req’s Emerged Solution Fixes • Endless cycles of change requests once the customer actually sees how their functional requirements emerged into a “solution”. • Developers must synthesize 1000+ pages of requirements. • Developers “interpret” and translate into GUIs. • Generate giant docs full of all the details.

  8. Software hasn’t traditionally followed other design industry Approaches Top-down Development Storyboard Solution Define Requirement Details Build the Right Solution • Element of “surprise” is limited. • Updates occur during building process. • Focused SME sessions - collect the right requirements only. • Collect by priority… • Solution Descript. Diagram. • GUI Mocks.

  9. The Product Owner provides Top-down direction As a PRODUCT OWNER: This means that the first thing we do is seek to understand and create the high-level solution. That really means a combination of a high-level, user-friendly flow (the SDD) and a set of GUI mocks. • Order Matters – the SDD (and GUI Mocks) should drive iterative requirements gathering sessions. • Extensive SME sessions need to target specific areas in the SDD/GUI Mocks. • The SDD and Mocks, not the SRS, should drive the huge majority of requirements gathering sessions. If you can’t draw, you have to at least be able to direct someone who can. • Requirements Documents should never be finalized before the SDD and GUI Mocks. • Requirements that are collected that fall outside the scope of the SDD/GUI Mocks will be easier to identify as out of scope, and should be recorded in a separate area of a requirements document. The Product Owner role moves a BA away from being requirements gatherer to being a product visionary, who first and foremost understand what needs to be built (first things first), and can then use that knowledge to provide the type of leadership that EIM is looking for from the BA team! Moving forward, every project must have someone who is comfortable driving the product from a visionary perspective, in addition to having support for gathering the traditional requirements to support that vision.

More Related