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.

Let The Elephants Leave The Room - Tips For Making Your Development Life Leaner

These are the slides that I presented at "Lean Kanban Istanbul 2014" event on 8th of November, 2014

  • Entre para ver os comentários

Let The Elephants Leave The Room - Tips For Making Your Development Life Leaner

  1. LET THE ELEPHANTS LEAVE THE ROOM Tips for Making Your Development Life Leaner LEMl URHAN ERGlN Agile Software Craftsman
  2. Agile Software craftsman Scrum, Kanban ve XP Practitioner Architect, Coach, Leader Sony & eBay Alumni @lemiorhan fifi lemiorhanergin. com Q) @| emiorhan §
  3. WE ARE NAIVE optimistic by default assumes all goes well of course we’lI succeed
  4. AND OVER-CONFIDENT super heroes smartest guy on planet write perfect code design the best do it right for the first time understand customer needs manage people 6 projects build elegant solutions
  5. ms . .._
  6. DRDWNED IN WASTE ' thewron 'ng ' thething rong poor itg bugsand cts slow and unpr tive endless depen cies redundanttasks
  7. the languages we code the technologies we use the refactorings we need the dependencies we have the processes we follow the feelings we have
  8. their problems to be understood and solved
  9. THINK LIKE A CUSTOMER ourjob should be maximizing the values we can deliver
  10. l. EAl' ii A T'l7lll. lT (If! F W
  11. Maximizing value for the end customer by removing waste
  12. Preserving value with less work
  13. Any action or process that a customer would be willing to pay for
  14. Anything that doesn’t add value lfrom customer perspective) to the product
  17. Industry average is about 15 - 50 errors per 1000 lines of delivered code. Steve Mctonnell from of the book “Code Complete“
  18. DDDIND WITHDUT WASTE Keep your codebase tiny Delete code while refactoring Make code more readable I Could use SDA or Microservices ‘EQ-
  19. . FDLLDW THE PRINCIPLES YAGNI - Yo ’t (ion ed It KISS-Ke ple. S pi DRY-Do’ epeatYourself
  20. Absolutely Useless Objects by Katerina Kamprani httpzllx"7;w. kkstudio. gr
  21. 64% of features are rarely or never used
  22. Optimism is an occupational hazard of programming. Feedback is the treatment. Kent Beck from the book “Extreme Programming Explained: Embrace Change“
  23. Minimum viable product Build-Measure-Learn loop Persevere or pivot Continuous deployment Get out of the building % '. !.*->__''$_->%
  24. ~_‘f’O’ "$31. _I. u TECHNICAL DEBT mm
  25. . m fig DEBT IS COUNTING I hing that makes your product di ' ult to change Any refactoring you postponed Any workaround, t m rary fix, TDDD, unmerged branch, sted code
  26. LEGACY CDDE Code without tests is legacy code Michael Feathers from the book “Working Effectively with Legacy Code"
  27. There is no difference between living with technical debt and cutting of the branch you are sitting on. Sooner or later you will fall.
  28. PAY YDUR DEBT Write automated tests Practice TDD and BDD Keep track of technical debt in a backlog Do not complete unless it is refactored Document tricks and workrounds Pay the debt continuously
  30. “we zzombify people by using wrong practices“ Niels Pftaeging -( , ‘«, »'<; .:nxr, .«'[:5:; f
  31. Develop and bug fix Big upfront design Manual testing Add comments to codebase Big releases Fix and test Release and get feedback Develop and refactor Emergent design Fully automated testing Make codebase clean Frequent short releases Reproduce in test and fix Get feedback and release
  32. WASTE DRIVEN DEVELDPMENT Unhandled defects 99% done tasks Rework slow (I builds Complex release procedures Insufficientdocumentation All development on single branch Unsynchronized branches Long deployment steps
  33. THINK DIFFERENTLY Handle defects continuously Define definition of done and obey Refactor continuously 10 minute Cl builds Simple release procedures Agile documentation Topic branches or Toggling theckin codebase frequently Automatic continuous delivery
  35. FOREWORD Documentation is not a way of tommunication
  36. : IT'S SAD, BUT HAVE TO ADMIT H No one reads our documentation , » i; Even we do not read what we write A , i! Information becomes obsolete too fast Reading analysis is too booooring!
  37. Few paragraphs Tables and flow diagrams Screenshots and wireframes FOLLOW BEST PRADTICES : :;: ::$f: :;': ;*i: ::: 'ds Document review Delete the obsolete
  38. READABLE TO READ Documentation should be as visual as it can be. It should make you feel like reading comic strips. Alper Tonga from his talk about “Documentation in Agile Transformation" at PHI-TR Summit’l4 tttttt Iwwu sldcshare netlscrumturkeglpmI-tr-summ| t—ZDl-1-alper-Conga
  39. Just enough documentation LEAN DOCUMENTATION §. f:. ‘.'. ‘.f; ‘", :.': L°. ,?,1‘; ',, Z“"" Let it evolve
  40. in H1 4' 1:: HI '4» 3:: H"! 4’ 5«'-. PTl 4*
  41. um lawn . ... ... ... mm. nut! !! in. in am»- vu -um nu. ma. o—- —- umum an-av»-u 7 W _ Dunn hum: nay Nnvmmm Imam u. .». m.r m me- u. .. pm. .. Iknp-ml-w p. ..‘ locum: mu on-mm-v- ». .. um. -m m. .m :4. ins om nu- run-.1 nu. ma“. .. nun sslv um-a. vlvnuu swiv S¢m ; . rah-mu a. ..= .. u_. .. up- . ... ..-n Vim-1 u. .. >- . ..’u, Vin. mm. -y Sm-an -. .. .. ... m. in soc-I-1 ». n . ..». ..-u. to! luau Inca ». than ; .»---»n-- urmnnlvitllv-Mush-nu e -. --. n.. ».e. .. um . . mm Inlnmnm -no. ldnum nan Ina-<1 M: .. .n. Dunc u. ll-Idiot“ I-can mun mu . . m an». .. .1 um» I om. man. .. we may nun am he -.4 lhlw-Ml -. ».. ... .x. cu-vmu you Im- uum um In Run a. .. an. .. In two a Cd-I-vv nun . -u. ..-m can run- nun: r-an -. ..m. .. 1-. ... .l. .. .1.. . am uh. .. . . in mm now an- -. .. mm mm. .. Onsrl-tutu cu--mu. ~. . I-vv-en: a. --nu. -.. m.m. . -u. u.. .—u-nun. ..‘ uuu. —, -sun-ma. Eon-vb-auxin awn. .. has-It-uh-union
  42. WIP IS AN ILLUSION It hides problems and makes you feel safe for a while
  45. EAT THE ELEPHANT ONE BITE AT A TIME Consume most important tasks at first Detect biggest issues at first Deliver max amount of value even if you fail to complete all
  47. It takes 28% more time to go back to work after the switch Dave Erenshaw Time Management Expert
  48. Duality decreases and stress level increases Dave Crenshaw Time Management Expert
  49. It makes people feel unimportant and damages relationships Dave trenshaw Time Management Expert
  50. START IMPROVING YOURSELF TODAY focus on people lDD% Reserve time to getting things done could use Pomodoro Technique
  51. I . i ‘.1
  52. WAITINO FOREVER Waiting dependencies Waiting decisions Waiting IID Waiting threadsl processes Waiting releases 53%}
  53. TASKS ARE WAITINO flow efficiency is normally as low as 5-15%. It means most of the tasks are not proceeding, simply waiting. David J. Anderson Thought leader in managing effective technology development
  54. I need a ciianye in does Iive anti one line of code ready iii produ; c‘tieia
  55. WE AIM TO HAVE SHORT LEAD TIMES LEAD TIME feature Priority ['10 requested set Hardened UAT Live —i—i-i—i-—i-i— Development Development started completed REACTION TIME OYOLE TIME
  56. USE KANBAN Kanban is something you do to your existing processes
  57. USE KANBAN See life of your tasks Detect efficiency-killers in your flow Manage your flows Improve continuously
  58. Estimations Management practices Performance appriasals Status Tracking Time Tracking Control of viorking hours Working at office Dvertimes Meetings Dress codes Clean desk policy Tools and DS Turnovers Motivation Micro management Office space
  59. Visualize the flows and observe Detect waste and the root causes Take action to improve Inspect and Adapt
  60. “f| ood removal service” by dachalan https: IIwww. flickr. comI photosl 54945394@NDDI 810968613 “Hoover Dam - Explored : -l” by Airwolfhound https: I Iwww. flickr. comI photosl Z4D145Z8@ND4I 14044173428 All funny pictures by You Had Dne Job http: IIhadonejob. com and httpszlItwitter. comI_youhadone]ob All icons and drawings by freepik http: IIwww. flaticon. com MAOES
  61. x @LEM|0RHAN l _‘ _‘ J https: //www. linkedin. com/ in/ lemiorhan 7 @LElVl| [lRHAN ; https: //twittercom/ Iemiorhan . l .5.’ his @LEM|0RHAN ' _[_ l http: //www. s|idesharenet/ lemiorhan x‘ L @LEMl0RHAN ‘Jul https: //github. com/ lemiorhan if M AG| L|STANBUL. C0lill ~ ‘ )_ _ Turkish blog about agile development . I ' h @ ‘l't b l. 7: > Founggl: rA? J|tho: gg<§: :iTis: artfbiicom ' Official site having personal information