Se ha denunciado esta presentación.
Utilizamos tu perfil de LinkedIn y tus datos de actividad para personalizar los anuncios y mostrarte publicidad más relevante. Puedes cambiar tus preferencias de publicidad en cualquier momento.

How to keep calm and ship it (Juozas Kaziukėnas)

2.254 visualizaciones

Publicado el

This talk focuses on both the process improvements (short sprints, how to capture requirements) and technical (testing, continuous integration).

Publicado en: Software, Ingeniería
  • I think you need a perfect and 100% unique academic essays papers have a look once this site i hope you will get valuable papers, ⇒ www.HelpWriting.net ⇐
       Responder 
    ¿Estás seguro?    No
    Tu mensaje aparecerá aquí
  • What if you had a printing press that could spit out hundred dollar bills on demand? Do you think that would change your life? ♣♣♣ http://t.cn/AisJWzdm
       Responder 
    ¿Estás seguro?    No
    Tu mensaje aparecerá aquí
  • Get Paid On Social Media Sites? YES! View 1000s of companies hiring social media managers now! ◆◆◆ https://tinyurl.com/rbrfd6j
       Responder 
    ¿Estás seguro?    No
    Tu mensaje aparecerá aquí
  • How to Grip Her Attention - Unlock Her Legs ▲▲▲ http://ishbv.com/unlockher/pdf
       Responder 
    ¿Estás seguro?    No
    Tu mensaje aparecerá aquí
  • Nice !! Download 100 % Free Ebooks, PPts, Study Notes, Novels, etc @ https://www.ThesisScientist.com
       Responder 
    ¿Estás seguro?    No
    Tu mensaje aparecerá aquí

How to keep calm and ship it (Juozas Kaziukėnas)

  1. 1. HOW TO KEEP CALM AND SHIP IT
  2. 2. hello my name is @JUOKAZ
  3. 3. IF SOMETHING BIG HAPPENS, HOW QUICKLY CANYOU REACT?
  4. 4. MVP
  5. 5. WHY DOESTHIS MATTER?
  6. 6. ANY DAY NOT IN PRODUCTION IS LOST POTENTIAL
  7. 7. HOWTO GO FROM AN IDEA TO IMPLEMENTATION IN DAYS
  8. 8. MOVE FAST AND BREAK THINGS - Mark Zuckerberg, Facebook
  9. 9. REQUIREMENTS
  10. 10. UNCLEAR ORIGINAL SPECIFICATIONS
  11. 11. CYCLES OF CHANGES AND TESTING
  12. 12.     LACK OF UNDERSTANDING WHY KILLS PROJECTS
  13. 13. “YOU SHOULD ADD A BUTTON/CHECKBOX” 
  14. 14. IMPACT MAPPING http://www.impactmapping.org/
  15. 15. 1. why are we doing this 2. who is affected by this 3. how should the behavior change 4. what can we do as an organization
  16. 16. ALWAYS HAVE A PLAN
  17. 17. IDENTIFY WHATYOU CANNOT BREAK
  18. 18. FEATURE-CREEP KILLS PROJECTS
  19. 19. AGILE?
  20. 20. IF IT'S HARD, CUT SCOPE - Wiggins' Law
  21. 21. PROTOTYPING
  22. 22. FAMILIARTOOLSET
  23. 23. TOOLBOX • Bootstrap for all frontend work • Web framework of choice • Database of choice • ect.
  24. 24. FLASK-SKELETON https://github.com/juokaz/flask-skeleton
  25. 25. BUILD DELIVERABLE PRODUCTS
  26. 26. EVERY SUB-FEATURE SHOULD WORK
  27. 27. “WE CAN ALWAYS FIX IT LATER”
  28. 28. PRETTY APPS > WORKING APPS
  29. 29. FAKE/HACK IRRELEVANT PARTS
  30. 30. CONTINUOUS DELIVERY
  31. 31. 12-FACTOR APP http://12factor.net/
  32. 32. 1. Codebase - One codebase tracked in revision control 2. Dependencies - Explicitly declare and isolate dependencies 3. Config - Store config in the environment 4. Backing Services -Treat backing services as attached resources 5. Build, release, run - Strictly separate build and run stages 6. Processes - Execute the app as one or more stateless processes 7. Port binding - Export services via port binding 8. Concurrency - Scale out via the process model 9. Disposability - Maximize robustness with fast startup and graceful shutdown 10. Dev/prod parity - Keep development, staging, and production as similar as possible 11. Logs -Treat logs as event streams 12. Admin processes - Run admin/management tasks as one-off processes 12-FACTOR APP
  33. 33. TDD?
  34. 34. VERIFICATION
  35. 35. DOCKER http://docker.com/
  36. 36. CHECKLIST • Push to master • Build a Docker container containing the app • Runs tests, code formatting checks, database migrations validation • If all is ok, the Docker container is a stable build • Then deploy to staging and/or production
  37. 37. FEEDBACK LOOP
  38. 38. DEVELOPERS ROLE • Owners of a project/feature/system • Responsible for fixing if it’s broken • Slack operations room
  39. 39. METRICS
  40. 40. STATSD/GRAPHITE https://github.com/etsy/statsd
  41. 41. “NO ONE NOTICES A WEBSITE BROKEN FOR 2 MINUTES”
  42. 42. USERS
  43. 43. IN SHORT • Collect requirements and make aTODO list even for small projects • Prototype using familiar tools and frameworks • Continuos delivery • Feedback loop
  44. 44. THANKS! Juozas Kaziukėnas @juokaz

×