9. “ What is simplest thing
that could possibly work?
”
WARD CUNNINGHAM / KENT BECK
12. Learn: what do we know?
(numbers are good)
Hypothesis: what do we believe?
(numbers are good)
Test: how can we check reality?
Analyze: does the data support our
hypothesis?
21. Instance OR Class Method?
it "executes code" do it "executes code" do
called = false called = false
Perf.new.execute do Perf.execute do
called = true called = true
end end
called.should be_true called.should be_true
end end
51. Summary
1. Reality Check before we write code
2. Talk to Customers
3. Validate Assumptions before we feel ready
4. Document Why not what
52. @ultrasaurus
Sarah Allen
Blazing Cloud
http://blazingcloud.net
http://ultrasaurus.com
Editor's Notes
I will talk about what we need to think about before we write code. How do we define a product with a holistic & effective design without falling into the anti-patterns seen waterfall development.\n
Just like artisans before the industrial revolution, \nwe are responsible for not only the means of production, but for product design and delivery to the customer. Artisans knew their customers personally, as Software Artisans, so should we.\n
\n
Desktop Software Products\n
Web Applications\n
Mobile Apps\nSoftware that is used by 100s, 1000s, 100s of 1000s of people\n
\n
\n
As agile developers, we want to start with the simplest think that could possibly work.\nWhen we think about what works, we need to think beyond making our tests green, \nwe need to think about what actually works for the customer.\n
\n
\n
\n
\n
the most important tool is using our words to talk to real people\nhttp://www.flickr.com/photos/shawnecono/145424142/sizes/o/\nhttp://www.flickr.com/photos/klamurke/2538792775\nhttp://www.flickr.com/photos/andry_portfolio/5080170314\nhttp://www.flickr.com/photos/iamthebestartist/2987217969/\nhttp://www.flickr.com/photos/sammers05/3503699510/sizes/l/\n
\n
\n
\n
\n
Write the test, watch it fail, write the code, run the test, watch it pass, then refactor\nWhen I first learned TDD, I thought it was all about testing -- I thought it was about getting this distasteful task out of the way early, so I didn’t have to do it at the end. But after doing it for a while, I realized that...\n
\n
\n
How do we apply a similar methodology to product design?\n
\n
How do we apply a similar methodology to product design?\n
\n
\n
Lifetime Value, general benchmark of $10/user or less\n
\n
\n
The first landing page test we created was for an email insight product -- sometimes we’ll do this before the product exists at all, but in this case there was an MVP and we wanted to expand the number of people participating.\n\nWe’re expecting this test to fail -- we plan to build a mobile app after all. We don’t expect weekly emails to be compelling,\nbut maybe some users will sign up and we’ll learn something from them... and of course, then we’ll have some users.\n
Anectodal Findings: Privacy Policy & Feedback\n
\n
\n
Even though the test failed, we still had more users that we could add to our MVP\n
\n
analagous to writing coding \n
\n
\n
learn about why something fails, not just whether it fails \nunlike automated testing where we can can create a definitive success or failure and point the cause, \nits impossible to do that with a whole product -- it could be a failure of messaging or of product definition or execution (such as an invisible sign up button). Qualitative testing with real humans helps with this.\n\n
resist telling them about the product\n
\n
\n
\n
Would you sign up? is not the interesting question\n