Hola, de nuevo colaboro en el arranque de un proyecto, desde mi área de calidad. Y de nuevo, ayudo en la adaptación de las plantillas y procesos para que el proyecto se adapte a lo que el cliente necesita, cumpliendo al mismo tiempo los más altos estándares de calidad.
Acabo de recibir una felicitación porque el conjunto de plantillas y documentación para el proyecto, ha sido percibido por el cliente como excelente. Y sí, para no mentir, son las cosas que te llevas a casa tras un día de duro trabajo que te animan. Las cosas que te animan a seguir luchando por mejorar, por buscar la excelencia, por no apoltronarse sentados en la autocomplacencia.
Pero claro, como buen culo inquieto, quiero más. Y me pongo a pensar que efectivamente, las plantillas, con sus guías, ejemplos y bien pensada estructura, cubren todas las necesidades...¿o no? Pero...¿qué pasa con el contenido?
En algún momento, todas esas plantillas se convertirán en documentación real, en contenidos que reflejen la realidad del proyecto en un cierto momento y sus objetivos, suposiciones y carencias. Y sin embargo, aquí es donde realmente empieza el valor aportado al cliente. Es como si al cliente le hubiéramos dado un puente. Y sí, el puente está bien. Pero el cliente no quiere un puente. Quiere cruzar el río. Del mismo modo, lo que necesita el cliente no es las plantillas. De hecho, no quiere ni la documentación. Sino el seguro, la garantía que proporciona el tener un adecuado control del proyecto.
La documentación me recuerda al seguro de la vivienda o del coche. Los programadores no quieren oir hablar de la documentación. Esto ya lo comentaba en mi artículo "Nos gusta programar, pero no documentar". Tampoco nadie quiere un seguro de coche o vivienda. Pero es algo necesario, ya que no podemos circular por ahí, sin convertirnos en "bombas en potencia". Del mismo modo, un proyecto sin adecuada documentación se convierte en una bomba en potencia, ya que ante el más mínimo problema, empezamos todos a correr como pollos sin cabeza, apagando el fuego como si fuéramos bomberos.
Y es importante recordar, que podemos ser muy buenos creando código super-optimizado, clases y estructuras de información super-funcionales y cumpliendo los más modernos estándares...Pero sin una adecuada documentación, no sirve. Eso me recuerda a los ofuscadores de código. Conozco gente que no lo necesitaba: su código era auto-ofuscado.
En fin, espero que el equipo de los proyectos sigan trabajando bien, y sobre todo, documentando adecuadamente (evitando la "documentitis", por supuesto).
miércoles, 18 de febrero de 2015
martes, 17 de febrero de 2015
Windows 10 y la gestión de pruebas beta
Supongo que muchos ya conoceréis el concepto de Alfa y Beta en el mundo del software. Pero es importante destacar, y en ello ISTQB lo diferencia claramente:
- Pruebas Beta es un software que se da a probar al cliente en su casa. Vamos, que se lo lleva a su casa, o su oficina, y lo prueba.
- Pruebas Alfa es un software por el contrario, que se prueba en un entorno controlado por el equipo fabricante, en las instalaciones del fabricante.
Me acabo de acordar porque precisamente estos días, me he instalado Windows 10 en versión Beta, a través del Microsoft Insider Program.
Desde el punto de vista de la gestión de proyectos software, es muy interesante este concepto, ya que permitiría, bien llevado, a llevar el agilismo a extremos insospechados. Un cliente puede usar una aplicación (o en este caso, el sistema operativo), y a través del análisis de su uso del software, se podrían detectar funcionalidades mejorables, funcionalidades más usadas, etc. Por supuesto, en el caso de Windows 10, tenemos el caso del feedback tipo "esta aplicación no me ha funcionado", o "esta página web no se ha visto bien".
No digo que Microsoft esté haciendo Windows 10 añadiendo funcionalidades ad-hoc a nuestros gustos. Simplemente, que estamos cada vez más, ante una forma de trabajar adaptativa (ágil), permitiendo a posibles usuarios/clientes el ver prototipos tempranos, más o menos terminados.
Otro caso, también de Microsoft, es Windows 10 para móviles. Todos los usuarios de algunos modelos seleccionados, pueden instalarse una versión bastante avanzada (pero aún no terminada), para obtener feedback del uso, pulir defectos, detectar incompatibilidades, etc.
Por supuesto que todo esto ya existe, y tenemos aplicaciones web (recordemos que GMail ha sido una gran parte de su historia una versión Beta: más exactamente algo más de 5 años entre 2004 y 2009) que se ofrecen a los usuarios de manera muy temprana. Sin embargo, la aproximación que ha tomado este fabricante me parece valiente, y a la vez arriesgada, ya que una mala gestión del modelo de betas podría afectar gravemente a su imagen, si por ejemplo todos los ordenadores o todos los móviles dejasen de funcionar, o si los móviles comenzasen a hacer llamadas de forma autónoma y arbitraria.
Aquí desde el punto de vista de las pruebas y de la ingeniería del software, vemos como se presenta una disyuntiva, y hay que buscar un equilibrio entre la estabilidad del producto (por muy beta que sea), y la necesidad de hacerlo probar a un público lo mayor posible para obtener feedback. Desde luego, es necesario tener un gran control de las pruebas realizadas, y obtener métricas que nos permitan estimar (de forma aproximada, claro), el número de defectos y su gravedad en caso de liberar nuestro producto inacabado.
¿Y vosotros? ¿Os atreveríais a hacer público un software inacabado siguiendo un modelo de pruebas Beta? ¿Cómo gestionaríais los riesgos de hacer público un producto sin terminar?
domingo, 15 de febrero de 2015
Modelo RACI - Qué es y para qué se usa
Hola de nuevo. Hoy quiero hablaros de una técnica que es a la vez tan simple como necesaria, y que sin embargo, se tilda de teórica e inútil en muchas ocasiones...incluso cuando nos damos cuenta de que hace falta.
Es una técnica de gestión de proyectos, por lo que efectivamente, aquellos proyectos que carezcan de una adecuada gestión, son los principales candidatos a quejarse de esta técnica.
El modelo RACI es una técnica que permite identificar quién se encarga de qué en el proyecto. Pero va mucho más allá, identificando los principales roles intervinientes en cada tarea. Los roles que identifica esta técnica son cuatro, cuyas iniciales en inglés dan nombre al modelo:
A la hora de rellenar con estas letras/roles, tendremos en cuenta una serie de reglas:
Es importante hacer notar, que el rol de las distintas partes puede cambiar en el tiempo. Por ejemplo, en un mantenimiento, el proveedor anterior de mantener la aplicación puede pasar de R/A, a solamente A/C (en la fase de transición) y finalmente solo C en un período de soporte en el que el nuevo proveedor de mantenimiento tiene ya el control total del soporte.
¿Y ya está?
Pues no. Como siempre, hay variantes para todos los gustos. Por ejemplo veremos dos a continuación.
Es una técnica de gestión de proyectos, por lo que efectivamente, aquellos proyectos que carezcan de una adecuada gestión, son los principales candidatos a quejarse de esta técnica.
El modelo RACI es una técnica que permite identificar quién se encarga de qué en el proyecto. Pero va mucho más allá, identificando los principales roles intervinientes en cada tarea. Los roles que identifica esta técnica son cuatro, cuyas iniciales en inglés dan nombre al modelo:
- Responsible: responsable de ejecutar la tarea. Vamos, quien la hace físicamente, el que se pone manos a la obra, y se "mancha" las manos.
- Accountable: responsable de que la tarea se ejecute, es quien rinde cuentas. ¿Porqué separar este rol con el anterior? En muchas ocasiones, yo puedo ser el responsable de que algo se haga, pero no lo hago directamente yo. Lo subcontrato, o lo asigno a un tercero. Y es importante diferenciar las tareas que hago yo directamente, de las que encargo a otros.
- Consulted: este rol tiene información útil o valiosa para la realización de las tareas, aunque no sean responsables de las mismas ni participan activamente en su ejecución. Por ejemplo, grupos de expertos en un tema, grupo de calidad, etc. Es importante destacar, que este rol interacciona bi-direccionalmente, es decir, se le consulta, y él responde, o bien participa de forma espontánea aportando su conocimiento.
- Informed: informado. En este rol incluiremos a todos los grupos que hay que mantener informados, poner en copia de los correos, etc. La principal diferencia con otros roles es que con éste se tiene comunicación unidireccional.
¿Cómo se hace todo esto?.
Una forma simple es hacer una tabla, donde por cada fila, escribiremos en la primera columna el nombre de las tareas. De esa forma, por cada fila (por cada tarea), rellenaremos a su derecha unas columnas adicionales, una por cada persona o grupo involucrado. En esas columnas adicionales, indicaremos su rol por las iniciales antes mencionadas: R, A, C, I.A la hora de rellenar con estas letras/roles, tendremos en cuenta una serie de reglas:
- No es necesario usar todas las letras (R,A,C,I) en cada fila/actividad.
- Al menos, sí deben aparecer en cada fila/actividad, los roles R y A (es decir, responsable y encargado de ejecución). Los roles C,I, son por tanto opcionales en cada fila.
- En cada fila/actividad, debe aparecer un único R (responsable de ejecución), y un único A (responsable de la tarea).
- En cada fila/actividad, los roles C,I pueden repetirse.
- Una misma persona/grupo, puede asumir varios roles para una misma tarea. En ese caso, se anotaría algo como "R/A" si por ejemplo fuese a la vez responsable de la tarea y de su ejecución.
¿Dónde se utiliza esto?
Yo lo he usado principalmente en documentación funcional para definir el "As-Is" o el "To-Be" de los procesos de negocio, o en contratos, o propuestas, donde es fundamental dejar claro el papel de las distintas partes durante el ciclo de vida de una tarea.Es importante hacer notar, que el rol de las distintas partes puede cambiar en el tiempo. Por ejemplo, en un mantenimiento, el proveedor anterior de mantener la aplicación puede pasar de R/A, a solamente A/C (en la fase de transición) y finalmente solo C en un período de soporte en el que el nuevo proveedor de mantenimiento tiene ya el control total del soporte.
¿Y ya está?
Pues no. Como siempre, hay variantes para todos los gustos. Por ejemplo veremos dos a continuación.
RACI-S
Existe la variante RACI-S, que añade un rol adicional de Soporte ("Support"). Ésta es la variante que he visto en la práctica. EL rol Soporte, se encarga de dar soporte de todo tipo al rol "R" (que es quien hace la tarea), en todo lo que éste necesite. No confundir con el rol "C", que sería más bien un experto en la materia, y que si bien también da soporte, digamos que dicho soporte sería más "pasivo" que el del rol "S".RACI-VS
También existe la variante RACI-VS que añade dos roles:- Verify (verificador): este rol se encarga de actividades de verificación, es decir, de comprobar si el producto está conforme con los criterios de aceptación establecidos en su descripción/diseño/calidad.
- Sign (aprobador o supervisor): este rol aprueba las decisiones del rol Verificador y autoriza el producto. Lo lógico es que el trabajo de un S preceda siempre al de un A.
Microsoft porta MSN Noticias a iOS y Android
Curioso. Poco menos que curioso la política que siguen los gigantes de internet. Mientras Google se va y cierra su servicio de Google News en España, Microsoft no sólo no sigue su estela sino que saca su aplicación MSN Noticias para iOS, Kindle y Android (entre otras muchas aplicaciones).
Curioso, aunque en la línea de Google de negarse a sacar cualquiera de sus aplicaciones en los sistemas Windows, y en la línea de las acciones recientes de Microsoft de hacer justo lo contrario: facilitar sus aplicaciones en todos los demás sistemas.
Y lo está haciendo en muchas más, superando el centenar de aplicaciones que Microsoft está ofertando (principalmente gratis) a usuarios del resto de plataformas.
Curioso.
Curioso, aunque en la línea de Google de negarse a sacar cualquiera de sus aplicaciones en los sistemas Windows, y en la línea de las acciones recientes de Microsoft de hacer justo lo contrario: facilitar sus aplicaciones en todos los demás sistemas.
Y lo está haciendo en muchas más, superando el centenar de aplicaciones que Microsoft está ofertando (principalmente gratis) a usuarios del resto de plataformas.
Curioso.
Suscribirse a:
Entradas (Atom)