Cómo dirigir un equipo de desarrollo… ¡Y quedar como un Jefe! - … · 2016-03-02 · • En...

#SemINF @miryamgsm @plasticscm

Cómo dirigir un equipo de desarrollo…

¡Y quedar como un Jefe! ;‐)

Marzo 2016 UBU

#SemINFMíryam Gómez San Martín

@miryamgsm


DE QUÉ TRATA LA SESIÓN…


¿De qué trata la sesión de hoy?

• Has estudiado ingeniería del software• Sabes de análisis, de diseño, programación…

• ¿Sabrías desenvolverte si mañana mismo tuvieras que dirigir un proyecto?

• ¿Cómo coordinas a tu equipo para que no se queden con los brazos cruzados mientras se te ocurre qué hacer?

• Eso es lo que vamos a solucionar hoy ;‐)


QUIÉNES SOMOS Y QUÉ HACEMOS…Pero antes…


¿Quiénes somos y qué hacemos?

• Desarrollamos

• Es un control de versiones – es como el “sistema operativo” del desarrollo – como no funcione, nadie trabaja

• Os sonarán sistemas como Git, Subversion… Perforce, TFS…


¿Quiénes somos y qué hacemos?

• Somos 16 personas en el equipo (ingenieros en informática, de la UVA, USAL y UBU) – los puedes conocer a todos aquí https://www.plasticscm.com/company/team.html

• Y competimos contra gigantes:– Git (USA + internacional)

• GitHub +300 developers• Atlassian +50 developers en Git (Bitbucket, SourceTree, etc)• Collabnet ‐> exSVN ‐> +200!!• GitTower…

– Perforce (USA) ‐> +300– TFS ‐> MICROSOFT ‐> +100– IBM ‐> su producto es RationalTeamConcert


Y muchas veces… les ganamos!!


¿Cómo es nuestro desarrollo?

• + 1 millón de líneas de código (90% C#, mucho Java, algo de C, JS, etc)• Código de servidor (+ ahora servidor cloud) ‐> implica algoritmos, bases de datos (7)• Protocolos de red (incluso WAN optimized)• Clientes GUI – nativos para Mac, otro Linux y otro Windows• Interfaz web• Integraciones: Visual Studio, Eclipse, IntelliJ, todo tipo de sistemas de continuous delivery, JIRAs, etc• Algoritmos de merge! Incluyendo semantic merge!!• Diff tools…

• Echad un vistazo a https://www.plasticscm.com/gallery.html

En definitiva… no nos aburrimos mucho ;‐)


LEAD A PROJECT… LIKE A BOSS!!!Y ahora pasamos al tema de hoy


¿Qué vais a aprender?

• Las prácticas que nosotros aplicamos y que nos funcionan• Cómo es el día a día de un equipo de desarrollo• Técnicas y herramientas que usamos


Nuestro ciclo de trabajo


Nuestro ciclo de trabajo… explicado


Conceptos que salen de aquí

• Iteración, sprint, backlog ‐> métodos ágiles ‐> SCRUM• Gestión de tareas / issue tracking• Branch per task ‐> nuestro patrón de trabajo• TDD ‐> test driven development• Code review ‐> revisar cáda tarea!• Validation + exploratory testing• CI – continuous integration (+ continuous delivery!!)• Integración ‐> merges!!• Crear releases MUY frecuentes!! ‐> core de agile


SCRUM en 3 minutos!


• ¿Cómo se alimenta?– servicio vs producto– feedback, uservoice, featuresadicionales requeridas por un nuevo cliente, ideas propias.

– + lista de bugs: detectados por el cliente e internamente.

• ¿Dónde se registra?– excel, wiki, etc…

• ¿Cómo se prioriza? – objetivo: entrega temprana y continua de valor al cliente.

Backlog


Estimación

• Nosotros usamos PERT para estimar:• Para cada tarea, en horas:

– Mejor caso ‐> si todo te va bien– Peor caso– Caso más probable

• Ejemplo: 4h, 10h, 6h ‐> con esto se calcula la estimación• OBJETIVO: controlar el optimismo exagerado.

Para saber más


¿Cómo gestionamos las tareas?

• Issue tracker – nosotros tenemos el nuestro propio TTS, pero hay muchos: JIRA, Bugzilla, Mantis, OnTime, etc, etc. Lo importante es tener uno.

• En el issue tracker metemos todo lo que se hace (ojo, no cajón de sastre de ideas, eso no funciona): bugs, nuevas features, refactors, etc


¿Qué es una tarea? ‐TTS


TTS


TDD en 1 minuto!!! :‐O

• TDD – test driven development ‐> escribe tests unitarios antes que el código.

• En nuestro caso: escribe tests antes de terminar la tarea al menos, que TODO vaya probado

• Cambio de mentalidad: probar es probar con testsautomáticos, probar a mano es jugar al software, los pros no lo hacen así!!!


Code Review

• Revisamos TODAS las tareas que hacemos• Ninguna tarea va sin code review• Esto ayuda a mantener la calidad del código• Sirve de training para los nuevos (les vas tutorizando todo el rato, no te llevas la sorpresa)

• Herramientas: primero un buen control de versiones, luego un buen sistema de diff (Plastic :P, pero tbGit y otros + Gerrit óSmartBear óGitHub con sus reviews integradas, etc).


Diff the código


Code Review


Cómo vamos…



Validación

• Cada tarea la validamos: es decir, alguien prueba a mano que hace lo que debe hacer.

• NO es testing como tal, es más comprobar que el resultado tiene sentido, como producto!

• Es como un “exploratory test” pero corto.• Qué es un exploratory test?

Para saber más


Exploratory testing


CI systems

• Sistemas de Continuous Integration (ahora también conocidos como Continuous Delivery, que va más allá todavía).

• Son sistemas que están monitorizando tu control de versiones, y cuando detectan un cambio (o una nueva rama), compilan el código y pasan los tests!!

• Son muy útiles porque dejan un informe con lo que ha ido bien y mal.

• Si en una tarea fallan los tests… se reabre y no se integra!!


Issue tracker(TTS)

Task

Branch

Task validation

Merge

Atlassian Bamboo

A ne

w br

anch

for

each

tas

k

Each finished

task is tested

prior to be

merged

Code Review

Validation

Each task is code reviewed

Each task is validated

Only tasks arriving here are merged

Monitors branches. Implement branch-per-task CI.On Windows and Linux:1. Builds2. Runs nunit3. Runs CLI tests4. Runs GUI tests

A ne

w re

leas

e

ever

y 24

hou

rs

Release testing

Windows (w2k to w8), Linux (several flavors), macosx: plus all backends (oracle, sqlserver,

mysql, sqlite, postgres) + combined win/linux + mac

>24h o

f

automa

ted

testin

g run

in

parall

el

VMWare

New tests

Taskdoc

Wiki


CI systems

• Herramientas que os tienen que sonar:– Bamboo (de Atlassian)– Jenkins

• Continuous Delivery va más allá: si los testsvan bien, pone directamente el código en producción!!! (en lugar de tener que hacerlo tu a mano… a mano == desastre!)

Para saber más(aunque es un poco tocho!)


Branch per task

• Muy fácil: para cada tarea en el issue tracker, creamos una rama en el control de versiones!

• De ese modo eres libre de hacer tantos checkins como quieras


Branch per task

• De ese modo, tu desarrollo en vez de ser así:


Branch per task

• Será así: con líneas paralelas


Branch per task

• Y todas esas ramas al final se juntan, se MEZCLAN, se integran (diferentes nombres para lo mismo).

• ¿Sabes lo que es un merge? Es clave en control de versiones!!! Y por tanto en desarrollo de software!!

• Tras el merge se compila el código, se prueba, y se hace una nueva release


Release!

• En nuestro caso tenemos un ingeniero que se encarga 100% de hacer releases. Es el build master.

• Cada release pasa montones de test: 40h paralelizadas en un montón de VMWares para que tarde menos de 3h en probarse!

• Pasamos tests unitarios, smokes + tests gráficos

• Intentamos hacer una release CADA DÍA: por eso las releases son tan importantes, son el latido del proyecto!! Es lo que hace que todo funcione, que nos demos prisa con las reviews, las validaciones.

• El objetivo de todo el ciclo es lanzar software que no se rompa… que no falle!!


¿Hemos terminado?



Información interesante

• ¿Sabes qué pinta tiene un GUI tests? Mira: https://youtu.be/7mEqkUaMxJI• Todo sobre branch per task en nuestra web: https://www.plasticscm.com/branch‐per‐task‐

guide/index.html• Nuestro ciclo de trabajo explicado en nuestro blog:

– http://codicesoftware‐es.blogspot.com.es/2012/07/ciclo‐de‐trabajo‐de‐codice‐software‐i.html– http://codicesoftware‐es.blogspot.com.es/2012/07/ciclo‐de‐trabajo‐de‐codice‐software‐ii.html– http://codicesoftware‐es.blogspot.com.es/2012/08/ciclo‐de‐trabajo‐de‐codice‐software‐iii.html– http://codicesoftware‐es.blogspot.com.es/2012/08/ciclo‐de‐trabajo‐de‐codice‐software‐iv.html– http://codicesoftware‐es.blogspot.com.es/2012/08/ciclo‐de‐trabajo‐de‐codice‐software‐v.html– http://codicesoftware‐es.blogspot.com.es/2012/08/ciclo‐de‐trabajo‐de‐codice‐software‐vi.html


Y libros interesantes

• Clean Code – Robert C. Martin• Implementation Patterns – Kent Beck• Code Complete – Steve McConnell


Preguntas@miryamgsm

Cómo dirigir un equipo de desarrollo… ¡Y quedar como un Jefe! - … · 2016-03-02 · • En...

Documents

Transcript of Cómo dirigir un equipo de desarrollo… ¡Y quedar como un Jefe! - … · 2016-03-02 · • En...