Category:support-driven development

From NB Referata Wiki
(Redirected from support-driven development)
Jump to: navigation, search


This material is (c) 2015, licensed to Wabanaki Confederacy by Efficient Civics Guild. See NB Referata Wiki:Copyrights for details. Do not copy or use for commercial purposes. Feel free to improve, and we will share your improvements with the nonprofit world. For a version focused on infrastructure see grid.referata.com. For one focused on marketing, customer relationships and etc see reframe.referata.com. - ECG

Support-driven development has several advantages over generic iterative, agile or test-driven development:

  1. learn by supporting: "Support is the fastest way to learn the product...nothing teaches you faster what your product does well and what it doesn't do well than hearing a customer have problems with something or a customer raving about the problem it solves."
  2. complain to whoever can fix it: If those who build the software also support it, then failures can often by fixed literally on the phone, without much process
  3. align incentives - "if you have to support your own work, then you'll tend to look for the best solution the first time around. And if you don't, the first time you have to support the problem you'll want to jump in and fix it."
  4. support is specification: "If engineers are doing support they'll find places that make support more challenging and will build tools to make support much quicker... time per issue will go down."
  5. customers get happy: "With everyone pitching in on support customer issues are resolved faster because the expert on a particular issue is going to see their support issue...[if you] get a support issue where a customer has had a poor experience [you are]instantly looking for ways to tweak a bit of copy to make something more clear or add new/tweak new fields to APIs to make them less of a hassle." Documentation, support, coding and specification changes can all be dealt with on just one ticket.

quotes from [1]

In test-driven development a use case is tested against first fictional and then real user stories. This can be onerous as it involves documenting every user story/experience as a sequence, preferably formally as a UML sequence. In agile methods usually the UML use cases are trusted as the sole specification method, with user stories reduced so much that they provide no value to the specification nor failures. In effect, agile assumes that developers will always be wrong about what users need or want, and tries to minimize the specification stage. Yet, agile methods still often involve tools useful only at the start of development, and not during the support phase - which is the entire lifetime of the product. Thus such tools tend to be extremely sketchy and abandoned for later releases.


In support-driven development (SDD):

User stories/experiences/tickets[edit]

User stories are short-as-possible, simple descriptions of user experience told from the perspective of the person who desires the new capability, usually a user of the system. Every support ticket is a user story, often an epic.

Inexperienced developers often try to restrict user stories to be "about" one specific feature, but real users simply never behave that way or describe their experience in the same terms as a system intends. These inexperienced developers confuse a user experience with a bug which is verified across experiences.

In support-driven development, pre-alpha functional specification stories (fictional), pre-alpha hands-off demo stories (aspirational), alpha user stories (from marketing) and beta-and-beyond user experiences (from) are all documented in the same way and ideally with the same tool - see project management. The only difference between them is their levels of detail and their degree of fictionality (true actual paying end user experience, one that came from outreach to real users but is an aggregate or proposed experience, or a fictional aspirational user story that helps guide the system design in the early phases). In other words, a specification stage user experience/story is JUST A FICTIONAL CUSTOMER SUPPORT TICKET. More on SDD [2][3][4][5][6]

Some "benefits to managing support within the same system you use for managing your issues and tasks:

  • Support tickets can be managed by a separate team but using now your support and development teams are using the same tools. This simplifies training and allows each team to have visibility into what the other is doing.
  • Managers can generate reports on support tickets and bugs in one system.
  • Support tickets can be escalated to bugs, giving a clean hand-off from your support team to your development team.
  • Support tickets can be associated with issues and tasks, retaining the relationship between them.
  • Support tickets can be part of your sprints." - [7] GForge group

Describe how to maintain user stories on that page not this one. Describe how to document customer support stories on that page, but include themes arising from actual use by Wabanaki Confederacy on this one.

Modules[edit]

Each module description includes a section of one-line summaries or titles of stories that involve those modules. This makes it easy to track which stories affect without undue clutter. Epic stories belong on their own pages but conventions vary for how themes of related short stories should be presented.

For now this wiki will outline only the themes for user stories for Wabanaki Confederacy purposes on this page and when titles are agreed, only then will the detailed user stories be fleshed out.

Describe how to maintain wiki categories on that page not this one.

Releases[edit]

For each release, a category page should list all stories and modules related to that release. From that page, anyone can follow the links for the user stories that most closely relate to the concerned plan, action or module.

Themes initially represent user roles, that is, how a given type of user perceives the whole system.

Themes will, over time, vary considerably from the module plan, as it becomes clear how users experience and gripe about things.

Describe how to [[maintain releases] on that page not this one.

Project:Copyrights[edit]

All pages in this category draw on material from ECG corpus and is licensed royalty-free for use in Wabanaki Confederacy-supported projects only. Non-generic and protectible product-specific specifications of that product or service are copyright the Confederacy or its Allies.

Pages in category "support-driven development"

The following 5 pages are in this category, out of 5 total.