Emixa Mendix Meetup 11 April 2024 about Mendix Native development
Rapid Minimalist Agile Design
1. Rapid Iterative Design (RID):
A Minimalist Approach to Requirements-
Gathering and Interface Design
for Agile Software Developers
HighEdWeb 2010
October 11, 2010 | Cincinnati, Ohio
Beth Snapp (snapp.6@osu.edu)
College of Arts and Sciences | Technology Services | Web and Data Solutions
2. [Rapid] [Iterative] Design (RID):
A [Minimalist] Approach to Requirements-Gathering
and Interface Design
for [Agile] Software Developers
HighEdWeb 2010
October 11, 2010 | Cincinnati, Ohio
Beth Snapp (snapp.6@osu.edu)
College of Arts and Sciences | Technology Services | Web and Data Solutions
3. [Rapid] [Iterative] [Minimalist] [Agile]
You – Agile software developer
Goal – Define product Rapid
Speed – Very quickly Iterative
Methods – Simple
Design*
Project – Iteration-friendly
*Or, how to spend more time writing software
and less time writing documents
College of Arts and Sciences | Technology Services | Web and Data Solutions
5. Where is the customer?
How can I get
R.I.D.
We are evaluated on of some of these
documents?
whether we have
delivered something
that helps our customers
meet their goals.
College of Arts and Sciences | Technology Services | Web and Data Solutions
6. What does our customer need?
Software that Works!
http://agilemanifesto.org
Agile Alliance
College of Arts and Sciences | Technology Services | Web and Data Solutions
7. How much is enough?
Just Enough,
Just in Time!
Analysis Paralysis
Cowboy Coding
College of Arts and Sciences | Technology Services | Web and Data Solutions
9. Collaboration is the Key
“The problem with abstractions (like reports and documents)
is that they create illusions of agreement. A hundred
people can read the same words, but … they’re imagining a
hundred different things. That’s why you want to get to
something real right away.” (from Rework)
College of Arts and Sciences | Technology Services | Web and Data Solutions
10. Something Real Right Away
Vision
Personas
Paper
Scenarios
Prototyping
User Stories Develop-
ment
11. Personas
What is it?
• Representative users
• Become “members” of your team
• Behaviors, skills, experience,
attitudes, demographics
Why do it?
• Visualize real users
• Elicit users’ goals
• Avoid programmers programming
for other programmers
Good resource: About Face 3, Alan Cooper Schwab.com
College of Arts and Sciences | Technology Services | Web and Data Solutions
12. A Real Persona
Jen, GEC Academic Advisor
Goal: “I’m busy. I have a lot of
advising notes to enter, and I
need to do it fast.”
• Experienced: has worked for OSU for 10 years
• Technically-savvy
• Very knowledgeable of GEC requirements
• Specializes in more challenging cases Hint: you’ll probably only need 3-
5 short personas. No need to get
carried away.
College of Arts and Sciences | Technology Services | Web and Data Solutions
13. Scenarios
What is it?
• Narratives of real situations
your personas will find
themselves in
Why do it?
• Elicit business rules
• Test your assumptions
• Discover stuff you didn’t think
about
Hint: Defer the edge cases.
College of Arts and Sciences | Technology Services | Web and Data Solutions
14. A Real Scenario
Jen, GEC Academic Advisor
Goal: “I’m busy. I have a lot of
advising notes to enter, and I
need to do it fast.”
Jen had a one hour appointment earlier today with a student
who had been dismissed from the university a couple years
ago due to poor academic performance. The student asked Jen
to help her file a petition for reinstatement. The student was
also visibly upset about some personal issues. Jen wants to
record what they talked about for future reference.
College of Arts and Sciences | Technology Services | Web and Data Solutions
15. A Real Scenario
Jen, GEC Academic Advisor
Goal: “I’m busy. I have a lot of
advising notes to enter, and I
need to do it fast.”
Jen had a one hour appointment earlier today with a student
who had been dismissed from the university a couple years
ago due to poor academic performance. The studentCan save Jen
asked drafts
of notes?
to help her file a petition for reinstatement. The student was
also visibly upset about some personal issues. Jen wants to
record what they talked about for future reference.
College of Arts and Sciences | Technology Services | Web and Data Solutions
16. User Stories
What is it?
• Short statements of functionality written by
the user
• Focus on “what,” not “how”
Why do it?
• Placeholders for later conversations
(“just in time”)
• Fast way to get requirements
• Collaboration tool As a <persona>,
I want to <task>,
so that <business goal>.
Hint: All developers
should be in attendance.
Adapted from Mike Cohn, User Stories Applied
College of Arts and Sciences | Technology Services | Web and Data Solutions
17. Real User Stories
As a <persona>, I want to <task>, so that <business goal>.
As an academic advisor,
I want to enter a note after an
appointment with a student, so that there
is a written summary of what we
discussed.
As an academic advisor,
I want to see a student’s entire history of
Hint: Hold a time- notes, so that I can prepare ahead of time
boxed story-writing for my appointment with the student.
workshop.
College of Arts and Sciences | Technology Services | Web and Data Solutions
19. Paper Prototyping
What is it?
• More than a sketch!
• Build the system with paper
• End user simulates task
completion
Why do it?
• Easy to create/easy to change
• Doesn’t look finished
• Communication vehicle
• Validate design
• Test usability
Hint: Keep focused on
interaction, not interface!
College of Arts and Sciences | Technology Services | Web and Data Solutions
20. Ingeping89 (Inge Nahuis, Netherlands)
http://www.youtube.com/watch?v=AtfWM2jRS2w
College of Arts and Sciences | Technology Services | Web and Data Solutions
21. A Real Paper Prototype
College of Arts and Sciences | Technology Services | Web and Data Solutions
22. A Real Paper Prototype
College of Arts and Sciences | Technology Services | Web and Data Solutions
23. A Real Paper Prototype
College of Arts and Sciences | Technology Services | Web and Data Solutions
26. How much is enough?
Just Enough,
Just in Time!
Analysis Paralysis
1. Personas
2. Scenarios
3. User Stories Cowboy Coding
4. Paper Prototypes
College of Arts and Sciences | Technology Services | Web and Data Solutions
27. Final Thoughts
Value working software over excessive
documentation
Get to something real, real quick
Stay focused on your customer’s goals
College of Arts and Sciences | Technology Services | Web and Data Solutions
28. Resources & Acknowledgments
Rework Jason Fried and David Heinemeier Hansson
About Face 3 Alan Cooper
User Stories Applied Mike Cohn
The Art of Agile Development James Shore Many thanks to:
Paper Prototyping: The Fast and Easy Way to • Diane Dagefoerde
Design and Refine User Interfaces Carolyn Snyder • Jennifer Belisle
• Ryan Stocker
Blog: Agile Product Design, Jeff Patton
• George Abraham
• Ousmane Kebe
College of Arts and Sciences | Technology Services | Web and Data Solutions
Notas del editor
Abstract:A priority for developers practicing agile software development is to re-evaluate the role of documentation in the software development lifecycle. On many traditional software development projects, the outcome of the analysis and design phases is a lengthy technical specifications document which is turned over to the developers with the charge, “build this.” In reality, adhering to “the plan” rarely happens, because life is not static--the plan changes as new information is revealed. Hence, agile developers place a lot of value on continuous face-to-face communication with the customer, iterative development, and minimalist documentation. We seek lightweight development techniques, so that we spend the bulk of our time on writing software, not writing documents. This presentation will detail how our team has combined four simple techniques—1) task-based scenarios, 2) personas, 3) user stories and 4) paper prototyping--into an agile approach for gathering requirements and designing interfaces for custom applications. The primary advantage of this approach is that it is very light-weight: functional requirements can be generated very quickly, so that coding can begin earlier in the project. The deliverables are essentially stacks of sticky notes and hand-drawn sketches of interfaces. That’s it!
Abstract:A priority for developers practicing agile software development is to re-evaluate the role of documentation in the software development lifecycle. On many traditional software development projects, the outcome of the analysis and design phases is a lengthy technical specifications document which is turned over to the developers with the charge, “build this.” In reality, adhering to “the plan” rarely happens, because life is not static--the plan changes as new information is revealed. Hence, agile developers place a lot of value on continuous face-to-face communication with the customer, iterative development, and minimalist documentation. We seek lightweight development techniques, so that we spend the bulk of our time on writing software, not writing documents. This presentation will detail how our team has combined four simple techniques—1) task-based scenarios, 2) personas, 3) user stories and 4) paper prototyping--into an agile approach for gathering requirements and designing interfaces for custom applications. The primary advantage of this approach is that it is very light-weight: functional requirements can be generated very quickly, so that coding can begin earlier in the project. The deliverables are essentially stacks of sticky notes and hand-drawn sketches of interfaces. That’s it!
![[Rapid] [Iterative] Design (RID):
A [Minimalist] Approach to Requirements-Gathering
and Interface Design
for [Agile] Software Developers
HighEdWeb 2010
October 11, 2010 | Cincinnati, Ohio
Beth Snapp (snapp.6@osu.edu)
College of Arts and Sciences | Technology Services | Web and Data Solutions](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)