Scrum y craftsmanship

Craftsmanship y ScrumDesarrolladores ágiles,

profesionales y responsables.

Carlos Peixcarlos.peix@kleer.la - @carlospeix

Agenda• Craftsmanship y Scrum• Simplicidad, comunicación, realimentación,

respeto y coraje• Condiciones de trabajo• Estado de flow• Mejorando habilidades• Codificando ágilmente• El camino hacia software craftsmanship

Craftsmanship y Scrum

Antes que procesos y herramientasbuscamos individuos e interacciones

y nos comportamos como profesionales

Craftsmanship y Scrum

Antes que documentación extensivapreferimos software funcionando

y del cual estemos orgullosos

Craftsmanship y Scrum

Antes que negociación contractualpreferimos colaborar con el cliente

y buscamos alianzas productivas

Craftsmanship y Scrum

Antes que seguir un planrespondemos al cambio

y agregamos valor continuamente

SimplicidadCon código simple mantenemos controlados los costos

de mantenimiento

TDD como camino a la simplicidad

Sin refactoring no hay código simpleSin buenas pruebas no ha refactoring

Sin TDD no hay buenas pruebas

¿Qué otra manera propones para lograrlo?

Comunicación

Debemos mejorar nuestra comunicación– Verbal - Precisión en el lenguaje– Escrita - Riqueza, puntuación, eficiencia– Visual - Facilitación y documentación gráfica

Si no nos entienden o nos entienden mal¿Cómo lograremos comunicarnos?

Realimentación

Ningú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…

Respeto

Debemos romper el círculo vicioso del engaño mutuo

Para romper ese círculo, debemos entender el punto de vista del que paga

Antes que pedir respeto debemos ganárnoslo, comportándonos como profesionales

Coraje

Para decir “No”Para aceptar erroresPara sostener nuestras estimacionesPara tomar control de nuestro softwarePara cambiar de entorno si no puedo cambiarlo

Nadie mejor que nosotros mismos para defender nuestros intereses

¿Cómo lo hacemos?

Condiciones de trabajo

Ningún médico operaría a un paciente si el anestesista o el quirófano no fuera confiable

Ningún notario permitiría una operación si no nos pudiese identificar según las reglas

Como profesionales, debemos exigir condiciones seguras de trabajo

(TDD, IC, pair programming, refactoring, entorno apropiado, sin interrupciones, cliente accesible, deploy automatizado, etc.)

Estado de “flow”

El estado de flow se logra por acciones “secundarias”

Si estoy bloqueado o me distraigo fácilmentePair programming

Si quiero ir rápido y sostenidoProlijo, ordenado, pequeños pasos

Si el trabajo parece demasiadoEntregas pequeñas y frecuentes (cadencia)

Mejorando habilidades

Duras– Un lenguajes y paradigma nuevo cada año– Participar en un proyecto open source

Blandas– Entender explicando– Aprender enseñando– Presentar en eventos– Participar en la comunidad

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

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

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

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!

“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)

“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

“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

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-D

evelopment.html– http://holatdd.com/– http://www.cleancoders.com/

¡Muchas Gracias!http//www.kleer.la/

carlos.peix@kleer.la - @carlospeix

http://www.slideshare.net/kleer_la