Cursos de Scrum Master y DevOps en Barcelona

Quería destacar dos cursos de gestión de proyectos y desarrollo ágil que se harán en Barcelona en 2013 y 2014.

• Curso de Certificación Professional Scrum Master (PSM I) en Cynertia Consulting, de 12h en Noviembre, las tardes (de 18h a 21h) de los días 11, 13, 18 y 20. http://www.cynertiaconsulting.com/es/curso-de-professional-scrum-master-psm-en-barcelona
• Curso de Scrum Master, DevOps y Lean IT en UPC School,  de 58h que se realizará entre marzo y mayo de 2014.

Saludos,
Àlex

Cuidado con la privacidad en Linkedin

Linkedin es una herramienta fantástica. Yo la uso frecuentemente, pero tiene unos "tics" de poco respeto a la privacidad que son para desconfiar. La prueba más evidente son las personas que te sugiere para contactar. Típicamente deberían ser "contactos de contactos", pero en ocasiones son gente con la que has contactado con otras cuentas de correo personales que nada tienen que ver con la cuenta de Linkedin (habitualmente la "profesional).

Sin querer entrar en profundidad, hay foros como este donde se trata el tema exhaustivamente, hay que vigilar un par de aspectos importantes a cuidar:

• Cuentas importadas sin tu control.
• Páginas a las que accedes y dan tus datos a Linkedin, o viceversa.

Voy a tratar el primer tema, que parece bastante más peligroso que el segundo. Atención a los contactos de otras cuentas de correo que "mágicamente" añade Linkedin a tus contactos importados. Aunque no son conexiones hasta que tú no lo decides, Linkedin sugiere a estos contactos que te conocen con otra dirección (p.e. un pseudónimo) que seas su próxima conexión con tu correo (identidad) oficial. Puede ser bastante inconveniente mezclar contactos profesionales, personales, actuales o muy antiguos.

Si usas Gmail, ten en cuenta que los contactos de tu correo de recuperación (el que te pide cuando te das de alta en Gmail) serán leídos también por Linkedin.

Algunos puntos a revisar:

1. Revisa tus contactos importados (!aunque no recuerdes haber autorizado a Linkedin a importarlos!) en Network > Contacts > Imported contacts. Puedes borrarlos todos, aunque por partes.
2. Accede a tus ajustes de privacidad
3. Controla p.e. quien puede ver tu foto (público, red, conexiones).
4. Deshabilita el intercambio de datos con otras aplicaciones
5. Y en tu cuenta (asumo que es de Gmail), "revoca" el acceso a Linkedin. Verás que con el tiempo habrás acumulado permisos para muchas aplicaciones y webs.

¡ Espero que os sea útil !

Managing Technical Debt

El concepto de deuda técnica no es nuevo, ha existido desde hace mucho tiempo con otros nombres (p.e. coste de la no-calidad, entre otros). Lo interesante de éste es que, según mi experiencia, capta mucho mejor la atención de los directores, jefes y otras figuras no técnicas que toman decisiones sobre los proyectos de software.

El concepto consiste a las eventuales consecuencias de usar arquitecturas deficientes (decisiones técnicamente incorrectas) o seguir malas prácticas de desarrollo de software ("trabajar mal"), usualmente materializadas en trabajo sumergido en un momento dado pero que tarde o temprano tendrá que afrontarse (pagarse) para poder acabar el proyecto. El fin del proyecto no significa el fin de la deuda, pues el mantenimiento de cualquier producto con deuda técnica se encarecerá notablemente, además de dejar una mala imagen del equipo o empresa que lo desarrolló.

Por un lado, las consecuencias más típicas de tener un proyecto con deuda técnica son:

• Retrasos en las entregas (la planificación deja de cumplirse en cuanto emerge la deuda técnica).
• Productos con mala calidad para el usuario (visible) y para aquellos que lo mantienen (invisible).
• Mayor coste de mantenimiento y coste total de la propiedad (TCO).
• Desmoralización del equipo y excesiva rotación del personal.

Por otro lado, los motivos más habituales de la deuda técnica suelen ser:

• Mala planificación o presiones por avanzar en el proyecto sin atender a criterios técnicos.
• Falta de metodología o comunicación en el equipo (o entre equipos).
• Malas prácticas como el "hardcoding" o los componentes altamente cohesionados.
• Falta de pruebas unitarias y pruebas automáticas de regresión.
• Falta de documentación
• Muchos otros

También hay que tener en cuenta que la deuda técnica puede tener otras características:

• consciente: p.e. no hacer pruebas unitarias para poder hacer una demo interna a tiempo (pero se harán inmediatamente después).
• inconsciente: p.e. no hacer pruebas unitarias porque retrasa el proyecto (hasta que aparezcan los errores que serán probablemente más caros de solucionar).
• a corto plazo: p.e. no documentar para llegar a un hito urgente (reunión con otro equipo), pero liquidar la deuda en breve.
• a largo plazo: p.e. desarrollar la capa de persistencia para Oracle 11g porque no se espera usar otra BD en producción.

El tema da para mucho y mejor no eternizarse. Podéis consultar una presentación del clásico Steve McConell.

Espero poder presentar sobre este tema en la Barcelona Developers Conference 2013. Si os parece interesante... ¡votadme por favor! :-)

Nueva Guía Scrum, edición 2013

El 1 de agosto apareció la revisión de la guía Scrum en inglés, cuya última versión era de 2011. Las guías se van traduciendo progresivamente en la web: http://www.scrumguides.org/

Los cambios son poco significativos, básicamente:

1. Se refuerza el concepto de transparencia en los artefactos del proyecto y del Sprint, como base para la comunicación y predictibilidad.
2. La planificación del Sprint de considera un evento formal, con las mismas partes de definición funcional (requisitos) y técnica (tareas).
3. Se cambia el verbo de la definición progresiva del Sprint de "grooming" a "defining". Cuando un ítem del Backlog está preparado para pasar al Sprint se le considera "Ready".
4. Se refuerza el concepto de "Timebox" como tiempo máximo recomendable para las reuniones del Sprint, pero se puede superar si "razonablemente" es necesario para cumplir sus objetivos.
5. Las preguntas del Daily Scrum incorporan el concepto de "meta". ¿Qué hice ayer / haré hoy para alcanzar la meta del Sprint? ¿Qué impedimentos veo para cumplir la meta del Sprint?
6. Durante la revisión del Sprint, se refuerza la intención de identificar el valor del trabajo hecho o pendiente con respecto a los objetivos del producto.

También se informará en Scrum.cat cuando la guía esté traducida al castellano y catalán.

¡Feliz verano!
Àlex

3 modelos de contratación ágil

La contratación de proyectos tiene dos extremos:

1. El proveedor asume (casi) todo el riesgo, aceptando un alcance "cerrado" por un precio pactado y que frecuentemente es causa de problemas e insatisfacción tanto para cliente como para proveedor.
2. El cliente asume todo el riesgo, aceptando un proyecto "abierto", sin precio ni alcance pactados (time & materials). Este sería el modelo ideal para los proyectos ágiles, pero plantea lógicos recelos en el cliente.

Bien, parece pues que una opción intermedia sería deseable, que permita acotar el riesgo que corren ambas partes y a la vez facilitar que los clientes puedan confiar en los proyectos basados en Scrum y los beneficios que esto aporta.

El artículo 3 modelos de contratación ágil  propone otras tantas fórmulas que permiten realizar un contrato con un nivel razonable de seguridad jurídica para ambas partes a la vez que permiten compartir el riesgo. Como resumen, estas son:

1. Cambios gratis (Jeff Shuterland). Los cambios son gratis mientras se compense el volumen que éste añadide con otro eliminado equivalente.
2. Dinero para nada (Jeff Shuterland). El cliente puede cancelar anticipadamente el proyecto y pagará como compensación el 20% del valor restante.
3. Variaciones y cambios (Mitch Lacey). El proyecto se parte en dos subproyectos, uno pequeño que sirve para construir el backlog y estimar el proyecto de construcción.

Esto es sólo una simplificación, os recomiendo que leáis el artículo (en catalán o el original en inglés).

Àlex Ballarin

www.cynertiaconsulting.com/scrum

Técnica ágil: CodingDojo

Los CodingDojo son una técnica ágil destinada a aprender e intercambiar conocimientos entre programadores.

Sus características son: 1) Entorno no competitivo sino colaborativo y para pasarlo bien, 2) todos los niveles de participantes son bienvenidos y 3) se aceptan nuevas ideas, aunque salgan mal!

Tienen requisitos muy asequibles, básicamente una sala para los asistentes con almenos un portátil y un proyector.

El proceso (variante ParisDojo) es el siguiente:

• 2 minutos para decidir cuando se hará la siguiente sesión
• 25-30 minutos para analizar en una retrospectiva la última sesión: que funcionó y que fue frustrante
• 10 minutos para decidir que hacer en la sesión actual (el protocolo "siguiente - última - actual").
• 40 minutos o así para programar! (según las variantes PreparedKata -dirigida- o RandorKata -todos lideran-)
• 5 o 10 minutos de pausa para comentar como va la sesión
• 40 minutos para la segunda ronda de programación!

Podéis encontrar más información en la fuente original (codingdojo.org) y en una traducción mía en scrum.cat/2013/04/17/el-codingdojo/.

La guía de Scrum en 1 página

He creado una guía muy resumida de Scrum, que pueda utilizarse para recordar los aspectos más importantes de Scrum al principi de su uso.

Como es una "chuleta", no esperéis un alto nivel de exactitud. Está lo más importante, pero sirve para iniciarse en Scrum. ¡ Espero que os sea útil !

scribd.com/doc/134880180/SCRUM-La-guia-de-1-pagina