Your SlideShare is downloading. ×
Scrum y craftsmanship
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Scrum y craftsmanship

529

Published on

Presentacion sobre Software Craftsmanship para el Scrum Bolivia Day 2013

Presentacion sobre Software Craftsmanship para el Scrum Bolivia Day 2013

Published in: Technology
2 Comments
2 Likes
Statistics
Notes
No Downloads
Views
Total Views
529
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
13
Comments
2
Likes
2
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide
  • Mi Presentación – Kleer - Twitter
  • CC y Slide
  • Transcript

    • 1. Craftsmanship y Scrum Desarrolladoreságiles, profesionales y responsables. Carlos Peix carlos.peix@kleer.la - @carlospeix
    • 2. Agenda• Craftsmanship y Scrum• Simplicidad, comunicación, realimentación, re speto y coraje• Condiciones de trabajo• Estado de flow• Mejorando habilidades• Codificando ágilmente• El camino hacia software craftsmanship
    • 3. Craftsmanship y ScrumAntes que procesos y herramientas buscamos individuos e interacciones y nos comportamos como profesionales
    • 4. Craftsmanship y ScrumAntes que documentación extensiva preferimos software funcionando y del cual estemos orgullosos
    • 5. Craftsmanship y ScrumAntes que negociación contractual preferimos colaborar con el cliente y buscamos alianzas productivas
    • 6. Craftsmanship y ScrumAntes que seguir un plan respondemos al cambio y agregamos valor continuamente
    • 7. SimplicidadCon código simple mantenemos controlados los costos de mantenimientoTDD como camino a la simplicidadSin refactoring no hay código simple Sin buenas pruebas no ha refactoring Sin TDD no hay buenas pruebas¿Qué otra manera propones para lograrlo?
    • 8. ComunicaciónDebemos mejorar nuestra comunicación – Verbal - Precisión en el lenguaje – Escrita - Riqueza, puntuación, eficiencia – Visual - Facilitación y documentación gráficaSi no nos entienden o nos entienden mal ¿Cómo lograremos comunicarnos?
    • 9. RealimentaciónNingún profesional del desarrollo de software puede permitirse el lujo de no validar internamente y externamente su trabajo.Queremos hacer lo que el cliente necesita, que no siempre es lo que nos pide…
    • 10. RespetoDebemos romper el círculo vicioso del engaño mutuoPara romper ese círculo, debemos entender el punto de vista del que pagaAntes que pedir respeto debemos ganárnoslo, comportándonos como profesionales
    • 11. CorajePara decir “No”Para aceptar erroresPara sostener nuestras estimacionesPara tomar control de nuestro softwarePara cambiar de entorno si no puedo cambiarloNadie mejor que nosotros mismos para defender nuestros intereses
    • 12. ¿Cómo lohacemos?
    • 13. Condiciones de trabajoNingún médico operaría a un paciente si el anestesista o el quirófano no fuera confiableNingún notario permitiría una operación si no nos pudiese identificar según las reglasComo profesionales, debemos exigir condiciones seguras de trabajo(TDD, IC, pair programming, refactoring, entorno apropiado, sin interrupciones, cliente accesible, deploy automatizado, etc.)
    • 14. Estado de “flow”El estado de flow se logra por acciones “secundarias”Si estoy bloqueado o me distraigo fácilmente Pair programmingSi quiero ir rápido y sostenido Prolijo, ordenado, pequeños pasosSi el trabajo parece demasiado Entregas pequeñas y frecuentes (cadencia)
    • 15. Mejorando habilidadesDuras – Un lenguajes y paradigma nuevo cada año – Participar en un proyecto open sourceBlandas – Entender explicando – Aprender enseñando – Presentar en eventos – Participar en la comunidad
    • 16. Codificando ágilmenteSimplicidadTest Driven DevelopmentLa regla del boy scoutCadencia de corto plazo (Pomodoro)Principios de diseño e ingenieríaProgramamos para el usuario/clienteOptimizamos velocidad solo si se justificaMantener la calma en la crisisDebugger driven development -> ¡FAIL!Mal humor o desmotivación -> ¡FAIL!Horas extra -> ¡FAIL!Atajos del IDE o editorZona de flowPair programmingArquitectura ágil
    • 17. El camino hacia software craftsmanship• Lenguajes y paradigmas – Ruby, Io, Java, Scala, Prolog, Erlang, Clojure, etc.• Herramientas – Editores: Vim, Sublime, IDEs (aprender atajos) – Git, Heroku, Travis – VM con Linux (mucho mas fácil todo)• Libros – Clean Code – The Clean Coder – Pragmatic Programmer
    • 18. El camino hacia software craftsmanship• Herramientas – TDD con JUnit, NUnit, RSpec, QUnit – ATDD (Fitnesse, Cucumber, JBehave, SpecFlow)• Tutoriales – Koans sobre distintos lenguajes – Git, Subversion, políticas de branching y commit – Diseño con objetos (sigan a @HernanWilkinson) – Principios SOLID – Patrones de diseño (solo después de 5 años) – Katas y Dojos, muchos, en diferentes entornos
    • 19. El camino hacia software craftsmanship• Videos – TDD con James Shore, Robert Martin – http://holatdd.com/ – Agile Planning de Mike Cohn – http://www.cleancoders.com/ – ¡Comparte tus propios videos!
    • 20. “The trouble with quick and dirty is that dirty remains long after quick has been forgotten.”“El problema con rápido y feo es que lo feo se mantiene mucho después de que nos olvidamos que fué rápido.”Steve McConnell(Code Complete, Rapid Development, Software Estimation, etc)
    • 21. “Make it run, make it right, make it fast.”“Primero que funcione, luego que sea limpio, por último que sea rápido.”Lampsonhttp://c2.com/cgi/wiki?MakeItWorkMakeItRightMakeItFast
    • 22. “Premature optimization is the root of all evil.”“La optimización prematura es la causa de todos los males.”Knuthhttp://c2.com/cgi/wiki?PrematureOptimization
    • 23. Referencias• On line – http://agilemanifesto.org/ – http://manifesto.softwarecraftsmanship.org/• Libros – Clean Code - 2009 - (Robert Martin) – The Clean Code - 2011 - (Robert Martin) – The Pragmatic Programmer - 1999 - (Andrew Hunt, David Thomas)• Videos – http://www.jamesshore.com/Blog/Lets-Play/Lets-Play-Test-Driven- Development.html – http://holatdd.com/ – http://www.cleancoders.com/
    • 24. ¡Muchas Gracias!carlos.peix@kleer.la - @carlospeix http//www.kleer.la/
    • 25. http://www.slideshare.net/kleer_la

    ×