addressing team awareness by means of a requirement prioritization tool
TRANSCRIPT
Addressing Team Awareness By Means Of A Requirement
Prioritization ToolPaolo Busetta, [email protected]
Presented by Matteo Pedrotti, [email protected]
PrioRE’17 Workshop at RESFQ 201727 February 2017
The participants to this experience (first semester of 2016)• Delta Informatica is an Italian SME operating in the IT market• DeltaLab is D.I.’s R&D department, involved in research projects
• Including Horizon 2020-funded SUPERSEDE
• At the time, PRESTO was DeltaLab’s major project• Funded by the local government• In collaboration with FBK, University of Trento• Addressing end-user development and run-time control tools in virtual reality and serious games for
training
• Paolo Busetta, DeltaLab’s research coordinator, was in charge of supervising the projects by DeltaLab, in addition to other duties• including PRESTO and SUPERSEDE
• Matteo Pedrotti, DeltaLab’s most senior engineer, was in charge for PRESTO’s pilot project, among other tasks
The situation that led to the experience• With respect to a normal software engineering project, PRESTO missed a few
key ingredients:• Reasonably detailed functional requirements (in any form)• Real end-user involvement• Permanent product management or a product champion / evangelist
• Rapid prototyping adopted to compensate• Wishful thinking – the republic of developers turned out to be anarchy• Nobody had any previous exposure to similar products and users
• Assuming that anyone in the world had, given PRESTO’s novelties• And, real engineers don’t read specifications, let alone project proposals!
• Indeed, high level of disagreements among developers and between developers and management about:• Who were the users and their expectations• Which functionality was more important and more urgent
The case study:A very controversial user interface
PRESTO Scripting’s controller is the key tool for a trainer to start and direct a training session
Experimenting a (semi-formal) process
Extracted from Bordin et al, 2017 (to appear)
The requirement prioritization process• 16 requirements, grouped under 4 categories• 2 criteria for evaluation (effort and user value)• AHP (pair-wise comparison) applied by the tool• Prioritization in form of an asynchronous game played on the Web during
business hours• Gamification aspects included different user roles, overall progress of the game, points
given according to promptness
• 8 people (engineers and the research coordinator) involved• All providing their opinion• The coordinator had the role of negotiator in case of major conflicts (that didn’t
occur)
Discussion and conclusions• Even in exploratory work, requirements determine where to spend precious
resources, thus prioritization is fundamental• Lack of formality meant that, even when there was agreement (and this was not
typically the case), technical solutions were divergent• The applied process allowed everybody to have a forum where to clarify ideas
• This lead to awareness about who was the expected user base
• The use of requirement prioritization tool was a reason to put ideas in writing and have a clear picture of the options at stake, their costs and their value• This lead to better reciprocal understanding • Voting was eventually a minor exercise, given the small setting in terms of people and
number of requirements, but using a tool removed stress
• While advantages on efficiencies are clear (less reworks, errors prevented), effects on product quality are hard to assess