O slideshow foi denunciado.
Utilizamos seu perfil e dados de atividades no LinkedIn para personalizar e exibir anúncios mais relevantes. Altere suas preferências de anúncios quando desejar.

Bdd and Agile Requirements Boiling Frogs 2016

658 visualizações

Publicada em

Agile, Scrum, Lean Startup, Testy A/B, Zwinny Marketing, Lean Canvas, Agile Coaching, Test Driven Development, User Stories, BDD, SBE, ATDD, TDD ­ po wrzucania do jednego kotła i odpowiednim zamieszaniu otrzymujemy…(?) Przepis na sukces… Lub wiele mitów i nieporozumień!
Sukces lub totalną porażkę naszego produktu…

Współczesne metody wytwarzania oprogramowania, nowoczesne technologie i narzędzia, masowy klient/odbiorca oraz dobrze wykwalifikowani, wszechstronni developerzy dają nam możliwości, o których nie mogliśmy marzyć jeszcze kilka lat temu. Niemniej jednak nadal popełniamy wiele błedów i nasze projekt raczej stosunkowo niezbyt często kończą sie spektakularnym sukcesem.

Być może jednym z powodów tej niedoskonałości w procesach wytwarzania oprogramowania jest niekoniecznie dobre zrozumienie wspomnianych wyżej metod i narzędzi. A jeśli o zrozumienie chodzi to myślę, że najelpiej zacząć od początku naszego procesu ­ czyli od wymagań. I właśnie o tym jest ta prezentacja… Jeśli wydaje Ci się, że wiesz już wszystko na temat BDD i wymagań w Agile to… Pewnie jesteś w błędzie… Nie, nie twierdzę, że na tym wykładzie dowiesz się wszystkiego w tym temacie… Być może jednak dowiesz się o rzeczach, które nie są oczywiste i które realnie pomoga Ci w pracy.

Jeśli uważasz, że User Stories, BDD, ATDD i SBE nie mają sensu ­ to… Zgadzam sie z Tobą i z chęcią powiem Ci dlaczego w Twoim kontekście im tego sensu brakuje (wspomożemy się w tym celu Cynefin Framework).

Mowa będzie o mitach związanych z User Stories, Specification By Example, Behavior Driven Development, różnicy pomiędzy wymaganiami a specyfikacją, Cynefin Framework oraz Continuous Delivery.

  • Seja o primeiro a comentar

Bdd and Agile Requirements Boiling Frogs 2016

  1. 1. BDD i wymagania w Agile Wiktor Żołnowski http://blog.testowka.pl   http://fb.com/innypunktwidzenianajakosc    Twitter: @streser Pragmatic Coders http://pragmaticcoders.com http://fb.com/pragmaticcoders @pragmaticcoders
  2. 2. @streser As a <User> I want <some action> So <Goal>  As a user I want to log in into application So I will be logged in In order to <business goal> As a <stakeholder> I want <visible change in system> Wymagania
  3. 3. @streser Coaching? G oal R eality O pportunities W ork
  4. 4. @streser Bo chodzi o to by usuwać wymagania,  które są bez sensu... https://leanpub.com/agile­transformacje 
  5. 5. @streser Specyfikacja Funkcjonalna // given Kontekst – co jest potrzebne by wykonać testowaną funkcję? // when Wykonanie testowanej funkcjj/właściwości aplikacji // then Asercje – oczekiwane zachowanie systemu
  6. 6. @streser Co może pójść źle? // given Open login page // when Type login Type password Click login button // then Assert that main page is open Assert that login page is not open Assert that menu is clickable Assert that <a href=”/logout”> is visible
  7. 7. @streser Specyfikacja // given Start application (?) // when User log in with correct credentials // then User should be logged in
  8. 8. @streser Specyfikacja jest opisem funkcji  systemu // given Start application Log in as user with admin role assigned Navigate to admin panel // when Add new admin user // then New user should be visible in the system Should be possible to log in as new user New user has access to admin functions
  9. 9. @streser Specyfikacj może być poparta przykładami // given Bank account A with balance equals <balance A> Bank account B with balance equals <balance B> // when Transfer <amount> from account A to account B // then New account A balance should equals <new A balance> New account B balance should equals <new B balance> <error> should be thrown Examples: |balance A | balance B | amount | new A balance | new B balance| error | |100 | 100 | 100 | 0 | 200 | No errors | |100 | 0 | 100 | 0 | 100 | No errors | |100 | 100 | 0 | 100 | 100 | No errors | |100 | 100 | 100 | 0 | 200 | No errors | |0 | 100 | 100 | 0 | 100 | No money error |
  10. 10. Trzy aspekty BDD i Wymagań w Agile Requirements:  What the stakeholders require?  Functional Specification: What the product will do to meet the requirements? Technical Specification: How the product will provide the functionality?  Requirements => User Stories Functional Specification => Examples, Acceptance Tests,  Given/When/Then Technical Specification => Unit Tests, Functional Tests,  Integration Tests, Page Objects @streser
  11. 11. @streser Cynefin Simple Complicated Complex Chaotic Disorder 1. Wszyscy wiedzą jak to  działa 2. Jest przynajmniej kilka  osób, które wiedzą jak to  działa 3. Jest jedna/dwie osoby,  które wiedzą jak to działa 4. Ktoś, gdzieś na świecie  już to zrobił, ale my nie  wiemy jak 5. Nikt, nigdy jeszcze tego  nie dokonał B D D E xperim ents M onitoring BDD – u mnie NIE działa! https://cognitive­edge.com/library/more/articles/ http://lizkeogh.com/2013/07/21/estimating­complexity/ 
  12. 12. Pytania Wiktor Żołnowski http://blog.testowka.pl   http://fb.com/innypunktwidzenianajakosc    Twitter: @streser wiktor.zolnowski@pragmaticcoders.com http://pragmaticcoders.com http://fb.com/pragmaticcoders @pragmaticcoders

×