Tweet
Tweet

Slide 1

Slide 1 text

About  Agile  So,ware  Development   Ruben  Gonzalez  Blanco   @_rubengb   [email protected]   Dealing  with  So,ware  

Slide 2

Slide 2 text

How  we  Understand  So,ware   Development   A  radiography  of  the  So,ware  development  process  

Slide 3

Slide 3 text

So,ware  Development  Cliché  

Slide 4

Slide 4 text

Dealing  with  So,ware  -­‐  EvoluHon   So,ware  Crisis   So#ware  Engineering   No  Silver  Bullet   Agile  Manifesto   Cra#smanship   Manifesto   Cra,ing   Incremental   1960   1970   1980   1950   1990   2000   2010   Waterfall   IteraHve   Rapid  Prototyping   CMM   Cra,ing   PredicHve  Processes   IteraHve  Processes   Agile  Methods   Scrum,  XP,  FDD,  DSDM,  OpenUP…   Spiral,  RAD,  Objectory,    RUP   Waterfall,  CMM,  ISO9000   EvoluHonary  

Slide 5

Slide 5 text

Dealing  with  So,ware  is  about  Dealing   with  Complexity  and  Uncertainty  

Slide 6

Slide 6 text

Inherent  complexity  and  uncertainty   •  Machines  are  complex   •  Machines  are  faster  and  can  process  more  data  than  human  brain   (consciously)   •  Although  Machines  are  predictable  (based  on  math  and  logic),  the  level   of  parallelism,  speed  and  volume  of  data  and  instrucHons  processed  per   second    makes  dealing  with  machines  a  complex  and  uncertain  task   •  Modern  mathemaHcal/logical  formulas  =  so,ware  programs    needs   TesHng  to  make  sure  we  have  instructed  the  machine  properly.  Can  not   be  predicted  upfront   •  Uncertain  and  Changing  Requirements,  FuncHonal,  non  FuncHonal     created  by  Machines  and  the  Problem  to  solve  

Slide 7

Slide 7 text

Accidental  complexity  and  uncertainty   created  by  Humans   So,ware  Development  depends  on  humans  creaHvity,  knowledge,  passion,  talent   desires  …  but  also  in  their  collaboraHons  and  interacHons     So,ware  is  “so,”  or  flexible,  it  is  possible  to  express  almost  any  kind  of  abstracHon     Managing  de  Development  Process  is  complex      

Slide 8

Slide 8 text

Since  the  outcome  is  uncertain  we   need    a  ConHnuous  CreaHve  ISRF  Cycle   IntenHon   RealizaHon   Feedback   Synthesis  

Slide 9

Slide 9 text

That  is  based  on  human  creaHvity,   talent  and  knowledge  that  is  acquired   along  the    synthesis  process   knowledge   Time   Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Learning  by  doing   Deliberate  pracHce  

Slide 10

Slide 10 text

Difficulty:  understand  the  Problem  (What)     and  figure  out  possible  SoluHon  (How)   Problem   SoluHon   At  the  same  Hme  

Slide 11

Slide 11 text

at  mulHple  levels  of  detail…   What   How   What   How   What   How   User    System   Component   What   How   What   How   What   How    Domain  

Slide 12

Slide 12 text

…concurrently  ,  in  mulHple  brains  and   within  different  Hme  frames     Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis'

Slide 13

Slide 13 text

Till  the  Desired  Working  So#ware   Emerges   Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Compile  Failed   Run  Failed   Test  Failed   Test  Passed   Enhance  Idea/Design   Test  Failed   Inten%on' Realiza%on' Feedback' Synthesis' Test  Passed   Emergence  is  the  key  characterisHc  of  complex  systems.     WORKING  SOFTWARE   IntenHonal   Emergent  

Slide 14

Slide 14 text

…  in  both  the  So,ware  SpecificaHon  and  the   So,ware  RealizaHon   Both  SpecificaHons  and  Architecture  Emerge  and  Grow  along  the  process     System  “Specs”   Architecture   So#ware  System   Idea   Need   Problem   IntenHonal   Emergent   Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis'

Slide 15

Slide 15 text

All  depends  on  Talented  Individuals     inspired   creaHve   passionate   team  player   Knowledge     Mastery   Talent   MoLvaLon     CreaLvity   InspiraLon   Passion   Genius  

Slide 16

Slide 16 text

Requires  MulHple  Disciplines  in  a   Team  CollaboraHng  together   Domain  Experts   Ux  Designers   Business  Analysts   Product  Managers   So#ware  Developers   Testers   System  Engineers   Deployment  Engineers   So,ware  Architects   Human  Factors   Users   Project  Managers  

Slide 17

Slide 17 text

Dealing  with  So,ware  “a  la”  Agile  

Slide 18

Slide 18 text

Agile  So,ware  Development  is  just  a   set  of  Principles,  Values,  and  PracHces   for  dealing  with  so,ware  complexity   and  uncertainty   The  purpose  :  Effec3ve  So6ware  Development  

Slide 19

Slide 19 text

Agile  Manifesto   We  are  uncovering  bemer  ways  of  developing  so,ware  by  doing  it  and  helping  others  do  it.   Through  this  work  we  have  come  to  value:     Individuals  and  interacLons  over  processes  and  tools     Working  so#ware  over  comprehensive  documentaHon     Customer  collaboraLon  over  contract  negoHaHon     Responding  to  change  over  following  a  plan     That  is,  while  there  is  value  in  the  items  on  the  right,  we  value  the  items  on  the  le,  more   hmp://agilemanifesto.org/  

Slide 20

Slide 20 text

Our  highest  priority  is  to  saLsfy  the  customer   through  early  and  conLnuous  delivery  of   valuable  so#ware.   Welcome  changing  requirements,  even  late  in   development.  Agile  processes  harness  change   for  the  customer’s  compeHHve  advantage.   Deliver  working  so#ware  frequently,  from  a   couple  of  weeks  to  a  couple  of  months,  with  a   preference  to  the  shorter  Hmescale.   Business  people  and  developers  must  work   together  daily  throughout  the  project.   Build  projects  around  moLvated  individuals.   Give  them  the  environment  and  support  they   need,  and  trust  them  to  get  the  job  done.   The  most  efficient  and  effecHve  method  of   conveying  informaHon  to  and  within  a   development  team  is  face-­‐to-­‐face   conversaLon.   1 2 3 4 5 6 7 8 9 10 11 12 Working  so#ware  is  the  primary  measure  of   progress.   Agile  processes  promote  sustainable   development.  The  sponsors,  developers,  and   users  should  be  able  to  maintain  a  constant   pace  indefinitely.   ConHnuous  amenHon  to  technical  excellence   and  good  design  enhances  agility.   Simplicity—the  art  of  maximizing  the  amount   of  work  not  done—is  essenHal.   The  best  architectures,  requirements,  and   designs  emerge  from  self-­‐organizing  teams.   At  regular  intervals,  the  team  reflects  on  how   to  become  more  effecHve,  then  tunes  and   adjusts  its  behaviour  accordingly.   12  Agile  Principles  

Slide 21

Slide 21 text

Agile  Manifesto  cloud  

Slide 22

Slide 22 text

Copyright 2007 Dean Leffingwell What  Paradigms  Is  Agile  Breaking?   Culture   Measure     of  Success   Waterfall   Development   IteraLve  Development   IteraLve  and   Incremental   Development   Parallel   Development   Acceptance   Test  Driven     Development   Command-­‐and-­‐Control   Leadership  /CollaboraLve   Conformance    to  Plan   Response  to  Change   Design   QA   Process   Big  Design  Up  Front   ConLnuous/Emergent   Big  Test  on  Backend   ConLnuous   Agile  Development   Tool  Support   Highly  specific   Fully  Integrated  

Slide 23

Slide 23 text

Agile  Grounds   Value  Driven   Culture   AdapHve  Management  

Slide 24

Slide 24 text

Agile  Grounds   Value  Driven   Culture   AdapHve  Management  

Slide 25

Slide 25 text

Understanding  IteraHve  Development  

Slide 26

Slide 26 text

IteraHve  vs  Waterfall  Development   So,-­‐NOT-­‐aware   So,ware   Waterfall   Requirements   Analysis&Design   ImplementaHon   TesHng   Deployment   SpecificsHons   Architecture   So,ware   So,ware   Paperware   Itera3on1   Itera3on2   Itera3on3   Release1   Working  So,ware   Release2   Release3   Focus In Executable Software You  can't  know   everything  at  the   beginning   You  learn  as  you   work  

Slide 27

Slide 27 text

Why  IteraHve   •  It  accommodates  changing  requirements   •  IntegraHon  is  not  one  "big  bang"  at  the  end  of  a  project   •  Risks  are  usually  discovered  or  addressed  during  early  integraHons   •  Reuse  is  facilitated   •  Management  has  a  means  of  making  tacHcal  changes  to  the  product   •  Defects  can  be  found  and  corrected  over  several  iteraHons,     •  It  is  a  bemer  use  of  project  personnel.     •  Team  members  learn  along  the  way.   •  The  development  process  itself  is  improved  and  refined  along  the  way  

Slide 28

Slide 28 text

IteraHon  general  pamern   PLANNING   REVIEW   ITERATION  N   PLANNING   REVIEW   ITERATION  N+1   Product  Backlog   •  User  Stories   •  Features   •  Architecture  Stories   •  Issues/Bugs   new  reqs   Working  So,ware   PLANNING   REVIEW   ITERATION  N+2  

Slide 29

Slide 29 text

IteraHon  a  la  mini-­‐waterfall   Requirements   Analysis&Design   ImplementaHon   TesHng   Deployment   PLANNING   REVIEW   ITERATION  N   Product  Backlog   Working  So,ware  

Slide 30

Slide 30 text

Requirements   Analysis&Design   ImplementaHon   TesHng   Deployment   IteraHon  a  la  agile   PLANNING   REVIEW   ITERATION  N   Product  Backlog   Working  So,ware   Concurrent  &  Blended   around  people  collaboraHon   2-­‐4  weeks  

Slide 31

Slide 31 text

IteraHon  a  la  agile  example  :    D/B/T  teams       User  Story1   UserStory2   UserStory3   Feature1   Feature2   …   define   build   test   define   build   test   define   build   test   ITERATION     DBT  user  story  1   DBT  component  2   DBT  Feature1   Backlog  n       UserStory2   UserStory3   NewUserStory4   Feature2   NewFeature3   …   Backlog  n+1   PLANNING   REVIEW   Working  So,ware   D/B/T  :   •  User  story   •  Feature   •  Technical/Architecture   •  Bug  

Slide 32

Slide 32 text

IteraHons  a  la  ¿agile?  Example   interleaved  “waterfalls”   PLANNING   REVIEW   ITERATION  N-­‐1   PLANNING   REVIEW   ITERATION  N   Product  Backlog   •  User  Stories   •  Features   •  Architecture  Stories   •  Issues/Bugs   PLANNING   REVIEW   ITERATION  N+1   Requirements  N   Analysis&Design  N   ImplementaHon    N   TesHng  N   PLANNING   REVIEW   ITERATION  N+2   Deployment  N   Acceptance  N   Acceptance  N-­‐3   Requirements  N+1   Requirements  N+2   Deployment  N-­‐1   Acceptance  N-­‐1   Deployment  N-­‐2   Acceptance  N-­‐2   Requirements  N+3   TesHng  N-­‐1   TesHng  N-­‐2   Analysis&Design  N-­‐1   ImplementaHon  N-­‐1   Analysis&Design  N+1   ImplementaHon  N+1   Analysis&Design  N+2   ImplementaHon  N+2   TesHng  N+1   Deployment  N-­‐3  

Slide 33

Slide 33 text

IteraHons  IteraLng  and  IncremenLng  

Slide 34

Slide 34 text

“iteraHng”  builds  a  rough  version,   validates  it,  then  slowly  builds  up  quality   1 2 3 IteraHng  allows  you  to   move  from  vague  idea   to  realizaHon   From  Jeff  Pamon  :  hmp://www.agileproductdesign.com/blog/dont_know_what_i_want.html  

Slide 35

Slide 35 text

35 ©  2006-­‐2009  Jeff  Pamon:  hmp://www.agileproductdesign.com/blog/dont_know_what_i_want.html  

Slide 36

Slide 36 text

“incremenHng”  builds  a  bit  at  a  Hme     1 2 3 But,  incremenHng  calls   for  a  fully  formed  idea   ©  2006-­‐2009  Jeff  Pamon:  hmp://www.agileproductdesign.com/blog/dont_know_what_i_want.html  

Slide 37

Slide 37 text

In  so,ware,  iteraHons  combine  iteraHve   and  incremental  development   •  To  find  out  “what”  and  “how”   •  To  improve  the  System   •  To  release  funcHonality  incrementally   •  To  gradually  add  parts  to  the  System  when  “what”  and  “how”  are  known   ITERATIVE   INCREMENTAL   ©  2006-­‐2009  Jeff  Pamon:  hmp://www.agileproductdesign.com/blog/dont_know_what_i_want.html  

Slide 38

Slide 38 text

IteraHve  Development  is  a  form  of   AdapHve  Management  

Slide 39

Slide 39 text

Agile  is  about  dealing  with  so,ware  uncertainty   through  AdapLve  Management  

Slide 40

Slide 40 text

Agile  Grounds   Value  Driven   Culture   AdapHve  Management  

Slide 41

Slide 41 text

Value  Driven   SOURCE  :  DSDM   Based  on  Dean  Leffingwell  scaling  agile  blog   Fixed   Scope   Time   Resources   Time   Scope   Plan     Driven   Value   Driven   The  Plan  creates  cost/ schedule  es1mates   feature  intent  &  commitment  to   deliver  the  max  value   Resources   Fixed   EsLmated   IntenLonal  &   Max  Possible  

Slide 42

Slide 42 text

The  happy  IteraHve  project   •  User  Stories   •  Features   •  Architecture  Stories   •  Issues/Bugs   ITERATION1   ITERATION2   ITERATION3   ITERATION4   Final   RELEASE   Backlog   Fixed  Time  

Slide 43

Slide 43 text

The  unhappy  IteraHve  project   •  User  Stories   •  Features   •  Architecture  Stories   •  Issues/Bugs   ITERATION1   ITERATION2   ITERATION3   ITERATION4   Final   RELEASE   Backlog   New  Req   “Embracing  the  Change”   Fixed  Time  

Slide 44

Slide 44 text

Value  Driven  Strategies   •  PrioriLze  and  reduce  goals  to  hit  the  release  date   –  Less  goals  =>  less  So,ware   •  Do  not  commit  to  early:     –  Decide  what  to  deliver  by  experimenHng  in  the   iteraHons.     –  Remember  that  both  Specs  and  Architecture  emerge   •  Avoid  Big  UpFront  Designs  and  Specs  (BUFDS)   •  Grow  Features  quality  iteraHon  by  iteraHon   –  Start  with  simplest,  minimal  feature  soluHon  and  add   more  quality  iteraHon  by  iteraHon   Based  on  Jeff  Pamon:  hmp://www.agileproductdesign.com  Embrace  Uncertainty  presentaHon  

Slide 45

Slide 45 text

Agile  Grounds   Value  Driven   Culture   AdapHve  Management  

Slide 46

Slide 46 text

Schneider  Culture  Model  

Slide 47

Slide 47 text

Agile  Culture  

Slide 48

Slide 48 text

Agile  Methods  

Slide 49

Slide 49 text

RUP  Process  Framework   Overview  of  Processes/Methods   Low  Ceremony     Limle  documentaHon   Light  process   High  Ceremony     Well  documented   Traceability   CCB   CMM-­‐I   CMM   IteraHve   Risk  Driven   ConHnuous  integraHon  and  tesHng     Waterfall   SequenHal,  Few  risks   Late  IntegraHon  and  tesHng   Open  UP   DSDM   XP   SCRUM   Agile   Source:  Per  Kroll/  Philippe  Krutchen  

Slide 50

Slide 50 text

The  Agile  Methods   •  Each  IteraLon  delivers  working  so#ware:  Ready  to  be  demonstrated  to   Business  Customer  and  deployed  in  producHon  environment   •  All  development  disciplines  (requirements,  analysis  and  design,   implementaHon,  test…)    are  nearly  concurrent  :  FiDng  all  ac3vi3es  in  a   short  3me  itera3on   •  Teams  are  self  managing  :  Bomom-­‐up    vs  Top-­‐down  management   •  Use  of  specific  pracLces  that  keep  the  code  base  fresh  and    flexible:  Pair   programming,  code  refactoring,  test  driven  development,  conHnuous   integraHon   •  Lean  principles  and  techniques  eliminate  waste  whenever  possible  

Slide 51

Slide 51 text

Agile  Methods   DSDM   FDD   Crystal   PragmaHc  Programming   AdapHve  So,ware  Development   The most extended methods under the Agile umbrella are Scrum and XP  

Slide 52

Slide 52 text

Embrace  Change   Embrace  Uncertainty   Be  Value  Driven   Use  AdapLve  Management   Agile  AdopHon  

Slide 53

Slide 53 text

In  any  case    Remember  that  in  so,ware   development  there  is  not  silver  bullet   Fred  Brooks  

Slide 54

Slide 54 text

….and  you  must  Adapt  Methods  to  the   Team,  not  the  opposite   DSDM   FDD   Crystal   PragmaHc  Programming   AdapHve  So,ware  Development  

Slide 55

Slide 55 text

THE END!

Slide 56

Slide 56 text

Books: Scaling Software Agility: Best Practices for Large Enterprises, Dean Leffingwell Agile Estimating and Planning, Mike Cohn Agile Project Management with Scrum, Ken Schwaber The Enterprise and Scrum, Ken Schwaber Scrum And XP from the trenches, Henrik Kniberg Succeeding with Agile. Software Development using Scrum. Mike Cohn Specification by Example. Gojko Adzic Agile References (II)

Slide 57

Slide 57 text

Presentations: Building Better Products Using User Story Mapping – Jeff Patton Embrace Uncertainty – Jeff Pattong http://www.agileproductdesign.com/presentations/index.html Websites: Agile Community: https://agile.telefonica.com Agile Alliance http://www.agilealliance.org Scrum Alliance http://www.scrumalliance.org Mountain Goat Software http://www.mountaingoatsoftware.com/scrum http://www.scrumalliance.org/articles/46 http://www.leadingagile.com/2009/08/scrum-of-scrums.html (how to handle dependencies) http://geekoff.blogspot.com/2008/12/big-org-small-bandwidth.html Agile References (III)

Slide 58

Slide 58 text

Kanban  (Lean)  

Slide 59

Slide 59 text

Kanban  (Lean  Development)  

Slide 60

Slide 60 text

Kanban  in  a  nusthell   •  Visualize  the  workflow     –  Split  the  work  into  pieces,  write  each  item  on  a  card  and  put  on   the  wall     –  Use  named  columns  to  illustrate  where  each  item  is  in  the   workflow.     •  Limit  WIP  (work  in  progress)  –  assign  explicit  limits  to  how   many  items  may  be  in  progress  at  each  workflow  state.     •  Measure  the  lead  Hme  (average  Hme  to  complete  one   item,  someHmes  called  “cycle”),  opHmize  the  process  to   make  lead  Lme  as  small  and  predictable  as  possible.    

Slide 61

Slide 61 text

No content

Slide 62

Slide 62 text

Cra,smanship   raising  the  bar  

Slide 63

Slide 63 text

Cra,smanship  Manifesto   As   aspiring   So,ware   Cra,smen   we   are   raising   the   bar   of   professional   so,ware     development   by   pracHcing  it  and  helping  others  learn  the  cra,.    Through  this  work  we  have  come  to  value:                                     That  is,  in  pursuit  of  the  items  on  the  le,  we  have  found  the  items  on  the  right  to  be  indispensable.   Not  only  working  so,ware,    but  also  well-­‐cra#ed  so#ware     Not  only  responding  to  change,    but  also  steadily  adding  value     Not  only  individuals  and  interacHons,    but  also  a  community  of  professionals     Not  only  customer  collaboraHon,     but  also  producLve  partnerships   hmp://manifesto.so,warecra,smanship.org/  

Slide 64

Slide 64 text

No content

Slide 65

Slide 65 text

No content

Slide 66

Slide 66 text

No content

Slide 67

Slide 67 text

No content