Chess - antoniomartel.com

Archivos de Autor: Antonio Martel

Error número 15: La pila del producto no está lista

Tenemos que empezar a trabajar y la Lista del Producto no está bien detallada o especificada. Esto va a hacer que cuando pasemos cada tarjeta a desarrollo surjan dudas y preguntas o, lo que es peor, se desarrollen las cosas sin estar bien definidas y requiriendo de cambios posteriores. Trabajaremos a la mitad de la velocidad de lo que podríamos hacerlo y para colmo podríamos hacer doble trabajo. Mal trato.

El trabajo del Dueño del Producto es por tanto muy importante y si es un Dueño del Producto nuevo en estas lides difícilmente podrá ser productivo desde el inicio y tener todo el trabajo listo antes del comienzo de cada Sprint. El Equipo de Trabajo podría quedarse sin cosas que hacer si el Sprint Backlog no está bien definido antes de comenzar el Sprint.

Necesitaremos darle todo el apoyo y formación necesarios para que pueda hacer su trabajo. Ayudarle para que sepa cuáles son las cosas más importantes sobre las que debe trabajar de forma que las tenga listas para cada Sprint.

Error nº 14: Objetivos del Sprint inalcanzables

Lo que cabe dentro de un Sprint y lo que no es algo que decide el Equipo de Trabajo. Ellos son quienes mejor pueden calcular hasta dónde pueden llegar en esas semanas que dura el Sprint porque son ellos quienes saben hacer el trabajo. Si se les obliga a aceptar un alcance mínimo para entregar en ese tiempo lo que podríamos estar haciendo es forzarles a que disminuyan la calidad.

En todo proyecto hay siempre tres variables que están ligadas unas a otras. Es el llamado triángulo de hierro. Estas variables son:

  • Alcance: El conjunto de funcionalidades o tareas a realizar.
  • Coste: El presupuesto o el número de personas empleadas para desarrollar esas funcionalidades.
  • Tiempo: Lo que durará el proyecto.

 

Triángulo de Hierro en el desarrollo del software

Esto es, si tienes un alcance muy grande tendrás un proyecto muy grande con un coste alto y que durará bastante tiempo. Si por ejemplo, en un proyecto empleas a pocas personas para el mismo alcance tendrás un proyecto que se alargará en el tiempo. Estas variables están interconectadas por lo que si intentas reducir alguna de estas variables manteniendo fijas las otras será la calidad la que se resienta.

Si en cambio, como dice el título de este apartado, alguien externo al proyecto obliga a aceptar un alcance muy elevado en sólo un Sprint, estaremos ampliando el alcance pero dejando inmutables el coste (número de desarrolladores) y el tiempo. Con esto sólo conseguiremos que no lleguemos a cumplir el objetivo del Sprint o que lo hagamos con unos niveles de calidad inaceptables.

No pasará nada en un principio, todo irá aparentemente bien aparte del estrés para poder cumplir el Sprint, pero si la calidad ha bajado esto se terminará notando. Lo hará más adelante en forma de bugs o incidencias que irán apareciendo o de funcionalidades que no están bien pensadas o resultas y que son usables. Funcionalidades poco prácticas o incómodas de usar por los usuarios y que requieren más clics de los necesarios.

Si tenemos un objetivo del Sprint demasiado ambicioso, que ha sido impuesto desde fuera y que es inasumible corremos el riesgo de emplear el doble de trabajo que si lo hubiésemos repartido mejor entre más Sprints. Veamos por qué:

  • Los programadores tendrán que hacer multitarea para intentar acometer el alto número de tareas que tienen en ese Sprint. Lamentablemente nunca tenemos en cuenta la bajada de productividad que la multitarea supone.
  • Tendremos que dedicar tiempo a la corrección de bugs. No habrá tiempo ni para pensar y todas las tareas se acometerán a toda prisa: No hay tests, no se hacen pruebas, no se revisa la aplicación una vez está todo integrado y no hay tiempo de comprobar que todas las funcionalidades pedidas realmente se han hecho.
  • Debido a esto último, muchos bugs aparecerán más tarde, cuando se hagan las pruebas de aceptación por el cliente o cuando se ponga en uso la aplicación. Puede que algunos aparezcan meses o años después de entregado el código ¿Quién se acuerda ahora de por qué el código se hizo así? ¿Para qué eran esas funcionalidades? Se tardará mucho más tiempo en resolver esos bugs que si se hubiesen corregido en el mismo Sprint cuando se tenía aún fresco en la memoria el trabajo hecho. Se sobresaturó el trabajo en el Sprint y no quedó tiempo para hacer buen código y revisarlo después (o a la vez que se escribe). En el futuro pagaremos más por cada bug detectado, es mejor pagar la deuda técnica ahora que hacerlo luego con muchos más intereses.

Mi libro de nuevo bestseller en la categoría Programación y Desarrollo de Software

Hoy, domingo 4 por la tarde, ha vuelto a colocarse mi libro Gestión Práctica de Proyectos con Scrum como libro más vendido en la categoría de Programación y Desarrollo de Software de libros electrónicos en Amazon España. El número 2 en ventas en la misma categoría pero para libros en papel también.

Está actualmente en el puesto 935 entre todos los ebooks vendidos por Amazon en España lo que no está mal para ser un libro de informática o de gestión de proyectos después de 4 años a la venta.

Reuniones de demo que no están listas

Es frecuente que el equipo, metido en las prisas por entregar lo comprometido en el Sprint, olvidé que al final del mismo tiene que demostrar lo que ha hecho y que esas demos tienen un coste de preparación. Normalmente es necesario:

  • Montar el entorno de demo donde se va a enseñar la aplicación
  • Asegurarse de que funciona en el equipo donde se va a enseñar
  • Tener preparado un usuario y unos registros pre-insertados para que se vean en la demo
  • Guionizar las pruebas que se van a enseñar y ensayar brevemente la demo para asegurarse de que todo irá sobre ruedas.

Cuando estamos en los primeros sprints y aún no estamos muy acostumbrados a hacer las demos, no sabemos bien dónde está el entorno de demo ni estamos acostumbrados a mostrar la aplicación es frecuente que todo falle: El usuario que escogimos no loguea, no tiene todos los permisos para entrar en las áreas de la aplicación que vamos a mostrar hoy y es necesario que alguien salga de la reunión para darle esos permisos. Necesitamos estar creando registros para poder probar delante del Dueño del Producto y los Interesados alguna de las funcionalidades.

Por esta razón, unos dos días antes de la reunión de demo suelo hacer una reunión que he dado en llamar de pre-demo. En ella, de forma informal y breve, los desarrolladores hacen una mini-demo de las funcionalidades que les ha tocado hacer y que se les ha pedido que preparen primero. En esta pre-demo suelen surgir muchas incidencias y dudas para las que todavía quedan dos días a resolver antes de entregarlas al cliente. Para entonces ya estarán más rodadas cuando se vayan a mostrar de forma algo más oficial.

Cómo aprobar la certificación Professional Scrum Master (PSM I)

La certificación Professional Scrum Master (PSM I) es sólo un examen online que podría parecer fácil de pasar pero es una de las certificaciones más duras que existen en el mercado.

Son 80 preguntas a resolver en 60 minutos por lo que sólo tendrás 45 segundos de media para resolver cada una de ellas. No es mucho tiempo para pensar y mucho menos para buscar la respuesta en la guía de Scrum o en Internet. Debes ser capaz de responder muy rápido a las preguntas más sencillas para que te dé tiempo a pararte unos segundos más en las preguntas más complejas.

Debes conocer muy bien la guía de Scrum. Ahí están directamente el 80% de las respuestas pero está muy resumida como para entender todos los conceptos a la primera. Te conviene ampliarla con otras perspectivas como el libro Scrum from the Trenches de Henrik Kniberg. Quizás no te haga falta leerte todos los capítulos del libro pero la mayoría te ayudarán a poner en contexto la aplicación de Scrum.

Léete la guía en inglés. Léetela primero en español si quieres, pero acostúmbrate a los términos y expresiones en inglés. El examen es en ese idioma y necesitarás estar acostumbrado a ese vocabulario. No tendrás tiempo de buscar lo que significa una palabra durante el examen. El glosario de Scrum.org es también muy útil. Léetelo porque en muy poco texto tienes una gran cantidad de definiciones muy útiles.

Repite y repite los tests gratuitos que te pone Scrum.org en su Open Assessment. Algunas de las preguntas que te encuentres ahí te las encontrarás en el examen real por lo que ya tienes un 10% más de preguntas acertadas. Asegurate de entender cada respuesta que das y repite el examen hasta que puedas dar un 90% de respuestas acertadas de forma consistente. Si lo haces así dificilmente suspenderás luego el examen de certificación.

Haz también test de práctica como los que puedes encontrar en mi web con tests de preparación. Algunas de las preguntas están pensadas para hacerte caer en los errores comunes. Por lo que, repito de nuevo, asegúrate de entender todas las preguntas hasta acertar en un 90% de forma reiterada. Te habrás asegurado de entender el concepto y si te lo encuentras más adelante, formulado de otra manera, serás capaz de acertar cuál es la respuesta correcta. Tienes más test de práctica por jassergarcia en Classmarker. Lo dicho, asegúrate de entender las respuestas correctas (y por qué las otras no lo son).

Tienes más recursos también en mi blog:

 

O puedes ayudarte con mi curso online de preparación para el examen Professional Scrum Master (PSM I). Allí encontrarás no sólo más tests de preparación, recursos o consejos para pasar la certificación sino también un completo curso de Scrum en español. Te explicará en palabras sencillas la guía de Scrum y te pondrá ejemplos prácticos en situaciones reales. Tienes también un bono de 5 emails para consultas que puedes hacerme directamente sobre el curso o la propia certificación en sí. Espero que te sea de ayuda.

Diploma Certificación Professional Scrum Master PSM I

Esta web utiliza cookies propias y de terceros para su correcto funcionamiento y para fines analíticos. Contiene enlaces a sitios web de terceros con políticas de privacidad ajenas que podrás aceptar o no cuando accedas a ellos. Al hacer clic en el botón Aceptar, acepta el uso de estas tecnologías y el procesamiento de tus datos para estos propósitos. Más información
Privacidad