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

La definición de hecho (2): ¿Evitemos el culto?

Discutiendo con compañeros de Agile-Spain.org sobre la Definición de hecho en Scrum (DoD para los amigos) surgieron puntos de duda y debate, como p.e.:

1. ¿Hasta que punto debe ser detallada la DoD?
2. ¿Se puede consensuar una DoD común o compatible entre varios equipos?
3. ¿Existe una variante técnica del Scrum of Scrums donde los "líderes técnicos" de los equipos puedan trabajar en consensuar DoD o intercambiar elementos de esta? ¿Se llamaría Retrospectiva de retrospectivas?
4. ¿Se puede convertir este ejercicio de consensuar DoD en una "maligna" Oficina de arquitectura, también conocida como "Torre de cristal"?

Durante esta discusión, el compañero Harald Messemer nos ha enviado un enlace muy interesante al post del The Cult of Done Manifesto. A pesar que me defino agilista pero fugitivo de las ortodoxias (aunque sean ágiles y guays) lo recomiendo. Contiene muchas verdades. :-)

SCRUM: La definición de hecho

Una visión superficial de Scrum puede dar a pensar que es una metodología sencilla y desestructurada, prácticamente lo mismo que mantener una lista de tareas en una pizarra. Es cierto que Scrum es un marco de trabajo sencillo, con 4 eventos, 3 roles y 2 artefactos estándar, pero a pesar de eso los proyectos suelen salir con un alto grado de calidad y uniformidad, tanto a nivel técnicos como de la documentación generada. ¿No parece contradictorio? Un aspecto importante a tener en cuenta es La Definición de hecho (Definition of Done).

¿Qué es la Definición de hecho?

La Definición de hecho es un acuerdo del equipo que contiene todas condiciones que deben cumplir los ítems del Product Backlog que se aceptan en el Sprint para considerarlos completados. Incluye los aspectos técnicos, de documentación, de pruebas y otros, de manera común para todo el equipo.

Cada equipo crea y mantiene su propia Definición de hecho, que suele evolucionar y refinarse conforme el equipo integra, perfecciona y automatiza sus prácticas de desarrollo. El momento habitual para revisar el cumplimiento de la Definición de hecho y refinar ésta, es la reunión de retrospectiva. Scrum no tiene auditorías, es el equipo quien autogestiona su calidad.

¿Cuál es el valor de la Definición de hecho?

El verdadero valor de la Definición de hecho es garantizar que el trabajo se realiza con un nivel de calidad uniforme, independientemente del miembro del equipo que participe. Es el equivalente al aseguramiento de la calidad en la gestión de proyectos tradicional.

La Definición de hecho aumentar su exigencia en todo momento según las posibilidades y capacidades del equipo. No tiene sentido marcar definiciones ambiciosas que no se pueden cumplir. Lo más importante es la uniformidad y la regularidad.

¿Cuál puede ser un ejemplo de Definición de hecho?

Un ejemplo sencillo e inventado de Definición de hecho es:

1. Cada historia de usuario hecha debe cumplir lo siguiente,
2. Diseño de pantallas (wireframe) actualizado en la wiki
3. Test unitario Junit integrado en montaje (Jenkins) y superado
4. Peer-review de las pruebas funcionales superado
5. Código fuente documentado
6. Wiki de diseño actualizada
7. Diseño explicado en la reunión técnica semanal

Como se puede comprobar, la sencillez de Scrum no tiene relación con la cantidad ni calidad de buenas prácticas de desarrollo que un equipo pueda realizar.

Curso Scrum Master en Barcelona: marzo y abril de 2013

Cynertia organiza periódicamente cursos de scrum master en Barcelona, en 2013 se quieren realizar cursos cada dos meses. En marzo se realizará los días 18, 20, 25 y 27 de 18h a 21h.

Se puede consultar más información sobre Scrum en www.scrum.cat.

Mobile World Congress 2013 Barcelona - Apps y tecnologías emergentes

El Mobile World Congress 2013 comenzó este lunes y, entre sus 70.000 visitantes estimados, hay un fantástico intercambio de ideas, oportunidades y colaboraciones. Esta es la parte más interesante del MWC, más allá de los nuevos terminales y las cifras de ingresos para la ciudad.

En nuestra web hemos recogido una lista de las innovaciones, tecnologías y apps emergentes más interesantes que hemos visto allí.

Editoriales y prensa: del papel al digital

Desde la aparición de Internet, el sector editorial de la prensa pasa por una crisis económica y de modelo de negocio creciente que se ha agravado de manera dramática con la situación económica actual. La brutal caída de ingresos por publicidad y el cambio de hábitos de los lectores han hecho insostenibles las finanzas de muchas empresas del sector, desde editoriales hasta la distribución y los puntos de venta (kioskos).

La evolución del sector a los soportes de Internet como la Web, las tabletas y otros dispositivos se ha hecho sin una estrategia clara y sostenible.
Cynertia ha analizado este contexto para un cliente y presenta el siguiente resumen:

1. El contexto actual: una transición de 360º
2. El Internet social y comercial: el model ZMOT
3. Estrategia empresarial, editoria y digital
4. Evolución tecnológica

Puede accederse al artículo Editoriales y prensa: del papel al digital en la web de Cynertia.

CMMI, Scrum, mitos y desinformación

Desde hace unos pocos años las metodologías ágiles han pasado a ocupar el “main stream”, probablemente aún no son mayoritarias en las empresas pero están casi omnipresentes en el “circuito blogero” de expertos y consultores.

Si tenemos en cuenta el Ciclo de Hype, que explica un patrón común al incorporar socialmente nuevas tecnologías (y metodologías) , vemos que es casi inevitable que se produzcan “burbujas” con expectativas exageradas a las que siguen desilusiones y una estabilización conseguida cuando la nueva tecnología ya no es una novedad pero la mayoría de sus usuarios obtienen de ésta una efectividad sostenible y económica. ¿Por qué se producten las burbujas? En el prólogo del excelente libro Workflow Modeling se da un conjunto de razones muy convincentes, centradas en la actividad de profesores, fabricantes y consultores que, usualmente llevados por sus propios intereses y excitación, alaban las posibilidades de las nuevas tecnologías, pero raramente hablan de las experiencias negativas.

Esto está pasando ahora mismo con Agile, especialmente con Scrum. De los muchos artículos que se publican continuamente, algunos son exageraciones alabando las maravillas de Scrum en aspectos como la menor documentación o su mayor comunicación y eficiencia. No es que Scrum no tenga muchas ventajas, pero no destacar igualmente los riesgos y malas experiencias no me parece inocente sinó tristemente interesado.

Una derivada de esta publicidad de Agile consiste en criticar las metodologías tradicionales y modelos de calidad como CMMI. Hay que uir de éstos para adoptar entusiastamente Scrum. Esto se dice sin explicar que Scrum funciona muy bien en ciertos contextos (p.e. desarrollo interno de producto) pero no se puede aplicar en otros (p.e. donde se requieren inversiones y decisiones iniciales fuertes, o existen transformaciones organizativas complejas).

Sin hacer ningún juicio de valor, un ejemplo es el artículo “Cómo pasar de CMMI y su incomunicación a la colaboración con Scrum, Agile y Lean”. Este blog me encanta, su autor es muy competente, pero en esta ocasión se debería explicar bien que se da un ejemplo de una implementación muy arriesgada de CMMI (una empresa que se certifica en nivel 3 en un plazo agresivo de 18 meses y que incorpora un outsourcing con muchas diferencias culturales). En primer lugar CMMI puede implementarse de manera ágil, como se explica en el libro Integrating CMMI and Agile Development, pero además un proyecto de outsourcing siempre tiene riesgos y desventajas que deben cuidarse mucho para que resulte compensador el menor coste de subcontratar partes de la producción en otro país. En 2010, otro estupendo blogger como Javier Garzás, hizo un muy buen artículo que analiza con detalle los conceptos y diferencias relacionados con las discusiones de la conveniencia de adoptar CMMI o Scrum.

Para finalizar, debo decir de mi experiencia de profesor en postgrados y másters, que veo como algunos alumnos más jóvenes tienen asumido que Scrum es la metodología aplicar y ni siquiera conocen lo que es el PMBOK. Es un error no conocer las diferentes opciones a la hora de solucionar un problema para aplicar la combinación de éstas adecuadas. Lo digo como consultor con experiencia aplicando diferentes metodologías en muchas empresas y estando certificado tanto en Scrum Master como PMP.