Que lo disfruten!
Fuente: http://gedpro.com/Comunidad/Blogs/tabid/69/EntryId/431/Todos-podemos-y-debemos-emprender.aspx
Otros videos de excelza en http://excelza.blogspot.com/search/label/videos.
viernes, 16 de abril de 2010
domingo, 11 de abril de 2010
Algo esencial
Anteriormente he comentado sobre nuestra misión como testers, y en relación a cómo evaluar el producto, he escrito sobre cómo podemos pensar qué probar http://excelza.blogspot.com/2009/11/pensando-que-probar.html.
Recientemente he leído un libro muy interesante de Greg Fournier, sobre lo que el autor denomina Essential Testing, que está en línea en gran medida con muchos de los conceptos expresados en los dos artículos mencionados. Creo útil hacer un breve resumen de las principales ideas presentadas, y compartirlo en este blog.
“Essential Testing says test the right things
to the right level of detail
at the right time,
providing results in the proper context
to prove the system under test with the most efficient amount of effort.”
O sea:
Hacer lo necesario para probar lo que se debe,
al nivel adecuado de detalle,
en el momento adecuado,
proveyendo resultados en función al contexto,
de la manera más eficiente posible.
Sobre lo ágil y lo esencial
Fournier parte de la premisa de que se requiere ser “ágiles” para hacer “testing esencial”, definiendo “agile” como “lean & mean”, o sea, magro y escueto.
Ser ágiles es importante; ser eficientes implica ir más allá de lo ágil, ejecutando sólo las actividades que no malgastan esfuerzo. Para los testers, esto significa asegurar que el producto final satisface ciertos estándares de calidad, y presentar los resultados en una forma aceptable y entendible por todos los interesados del proyecto.
Probar en una forma ágil, implica:
· Entender qué se tiene que hacer (expectativas sobre el producto y sobre el proyecto).
· Entender qué significa probar al nivel adecuado de detalle, lo que en general estará en línea con la misión de los testers, y con los riesgos identificados, en función al tiempo disponible.
· Identificar las fronteras del proyecto y su contexto.
· Comunicarse y comunicarse y comunicarse con todos los interesados… para entender bien esas fronteras y límites.
· Anticipar los cambios, estar preparado para cuando ocurran, pero no planificar para cada cambio posible… algunos ocurrirán, otros no.
· Ser minimalista, si no se está seguro de incluir alguna actividad en el plan, en principio eliminarla; siempre habrá tiempo de volver a incluirla si es necesario.
· Estar preparado para explicar. Hacerse entender; ser persuasivo.
· No concluir que un proyecto es igual a otro porque tiene algunas similitudes; siempre considerar qué cambios puede requerir un proceso ya conocido en un proyecto nuevo.
· Ser proactivo, alertar sobre problemas tempranamente si se detectan; estar dispuesto a replanificar.
· Fomentar la retroalimentación de los distintos interesados y otros miembros del proyecto, acerca de las pruebas.
· Respetar a los demás y su trabajo. Esperar y lograr respeto de los demás hacia los testers y su trabajo.
Y todo esto, independientemente de los tipos de proyectos y de las metodologías de construcción de software en que nuestro proceso de testing esté desarrollándose (iterativos ágiles, iterativos pesados (orientados al plan), waterfall pesados, altamente regulados).
El proceso de testing esencial
Fournier propone aplicar siempre “la regla de oro”: construir el proceso de testing para cada proyecto en particular, siendo tan eficiente como sea posible, y focalizando lo que se debe testear.
Para ello:
1. Entender las necesidades y percepciones de los interesados.
2. Entender el tamaño y alcance del proyecto.
3. Identificar los “artefactos” del proyecto que el equipo de testing va a recibir (qué especificaciones y cuándo), y cuáles se espera que genere (plan de pruebas, casos de prueba automatizados y/o manuales, reportes, otros). Procesos más “pesados” implican en general más artefactos y eventualmente diferentes clases de inspecciones o revisiones para que los mismos sean aprobados.
4. Identificar las actividades del proyecto que hay que cumplir para generar esos artefactos.
5. Lograr sinergia con el resto del equipo de proyecto, tanto a nivel personas como a nivel artefactos y herramientas. Colaborar con el bienestar de todo el equipo.
6. Minimizar los artefactos a generar, tanto por el equipo de testing como por el resto del equipo de proyecto. Siempre considerar cuál es el conjunto mínimo de entregables que hará felices a los interesados, y cuáles aquéllos sin los que el proyecto no será exitoso. Considerar cuáles son intermedios y no se justifica mantener, y cuáles de largo plazo, por lo que deberán ser actualizados y mantenidos.
7. Entender cuándo y cómo se harán las entregas de software para las pruebas. Esto depende en gran medida de la metodología aplicada en el proyecto.
Algunos conceptos básicos
Fournier detalla como conceptos fundamentales que son herramientas esenciales para el tester:
1. Pruebas de caja negra, basadas en requerimientos.
2. Pruebas de caja blanca, basadas en estructura interna y diseño.
3. Pruebas unitarias, que están en el ámbito del desarrollador (es esencial que se hagan).
4. Requerimientos, que son la base del trabajo del tester, expresan las condiciones o restricciones que el software tiene que cumplir, y se dividen en funcionales y no funcionales.
5. Expectativas de los interesados que el tester tiene que poder relevar o conocer, y que en general son de más alto nivel que los requerimientos.
6. Trazabilidad desde los requerimientos hasta los componentes y casos de prueba, en especial cuando los productos tienen condiciones regulatorias que cumplir (por ejemplo, productos que deban ser certificados por organismos relacionados con la Fuerza Aérea, la Sanidad Pública, etc.).
7. Cobertura, en particular cuando hay que demostrar que se ha cumplido cierta cantidad o tipo de pruebas (cobertura de pruebas respecto a requerimientos, cobertura de pruebas respecto a líneas de código).
8. Casos de uso, esenciales para testear correctamente: si no están disponibles, el tester tiene que poder / saber escribirlos, lo que aportará mucho valor al proyecto.
9. Escenarios y/o User Stories.
Otros conceptos y técnicas igualmente importantes
1. Planes de prueba. Los mínimos necesarios y suficientes para entender qué se debe hacer y cuándo. Sin demasiado nivel de detalle, seguramente van a cambiar sobre la marcha.
2. Casos de prueba. Condiciones y resultados esperados que permitan probar los requerimientos, expresados típicamente como casos de uso.
3. Scripts de prueba. Qué hace el testar para probar; pueden formar parte de los procedimientos de prueba, y ser armados para pruebas manuales o automáticas.
4. Procedimientos de prueba. Que permitan al tester preparar, ejecutar y analizar los resultados de los casos de prueba. Sólo se requiere escribirlos expresamente si son complejos.
Las cualidades deseables en los testers
1. Comunicación para poder interactuar eficientemente con los distintos niveles de interesados.
2. “Arrojo”, tener el valor de ser proactivo y tomar el toro por las astas en muchos momentos del proyecto.
3. “Agilidad”, entender qué cosas son las mínimas a hacer, para lograr liberar un producto con suficiente calidad para los diferentes interesados, y nada más.
Cómo seguir un proceso exitoso
1. Planificar las pruebas, sólo lo necesario para entender y arrancar.
2. Utilizar los requerimientos para comandar las pruebas.
Aprovechar y completar la documentación que exista.
Escribir casos de uso si no existen, eventualmente completarlos.
3. Extender los casos de uso para facilitar la prueba, identificando las variables que alteran el comportamiento del sistema, y los diferentes estados y respuestas del sistema. Darán lugar a las variaciones, precondiciones y resultados esperados de los casos de prueba a generar.
(En el libro puede encontrarse bastante detalle y ejemplos sobre cómo extender los casos de uso y cómo crear los casos de prueba a partir de los casos de uso extendidos).
4. Generar los casos de prueba esenciales, positivos, negativos e inesperados, a alto nivel.
5. Mapear requerimientos <-> casos de uso extendidos <-> casos de prueba. Esto permitirá proveer trazabilidad, que es un requisito en general en proyectos que deben cumplir regulaciones.
6. Diseñar los casos de prueba detallados, lo que implica definir las necesidades de ambiente, los participantes o actores, y los procedimientos de prueba que permitirán ejecutarlos y analizar su resultado.
7. Ejecutar los casos de prueba. Lo que implica: disponer de una entrega del producto que funcione mínimamente y de un ambiente donde ejecutarlo; saber cómo ejecutar los casos y evaluar sus resultados; entender si aplica hacer alguna prueba de regresión; entender qué puede automatizarse y qué requiere pruebas manuales.
8. Registrar los resultados de las pruebas; evaluar cuándo finalizar; reportar estado de las pruebas.
Los resultados pueden expresarse en cantidades de defectos, relaciones de sus severidades, cómo y cuándo se resuelven, etc.
Respecto a finalización, tener en cuenta que “una pintura nunca está terminada”, y las pruebas tampoco. El criterio de finalización tiene que estar relacionado con las expectativas y necesidades de los interesados, y habitualmente se expresa como una combinación de defectos bajo un cierto nivel + cobertura sobre un cierto nivel.
Qué reportar y cómo depende de a quién se informa. Básicamente se informa sobre estado del producto (resolución de los defectos detectados) y estado de la prueba.
El estado de la prueba puede mostrarse vía trazabilidad (desde las necesidades o requerimientos a los casos probados y los defectos encontrados) y cobertura (respecto a los requerimientos o cobertura de diseño, y respecto al código ejecutado, o cobertura de código).
Mis opiniones
El libro describe de manera amena y siguiendo tres ejemplos, lo que el autor define como testing esencial y ágil, y cómo puede aplicarse en diferentes contextos y tipos de proyectos.
Particularmente me resultaron muy interesantes a nivel conceptos generales los capítulos 1, 4, 5, 6 y 8.
Considero que los capítulos 9 a 19 pueden leerse independientemente, en función al tema que nos interese profundizar en un momento dado; por otra parte, creo que es valioso y útil lo descripto en capítulos 13 (cómo extender los casos de uso), 14 y 15 (cómo identificar y describir los casos de prueba), pero no siempre es posible hacerlo en los proyectos al nivel de detalle planteado por el autor. Seguramente se pueden tomar ideas y adaptar a las restricciones de cada proyecto en particular, y enfocar más el análisis de riesgos de lo que propone Fournier (que pone foco en muchos aspectos de cómo hacer más ágil el testing para productos altamente regulados).
El capítulo 20 es un buen resumen del proceso esencial de testing propuesto, mostrado vía un ejemplo.
Coincido totalmente con lo expresado por Fournier en el final del capítulo 21 de su libro:
“I was going to start the concluding chapter with a story about
a group of testers that were proactive in everything they did,
saved projects, and were highly regarded by everyone.
Then I figure, why lie?
Much of the premise of this book relates to being proactive
and taking our destiny in our own hands as much as possible.
That means that, when we test, we will step on toes.
Although we can try to minimize the number of toes we step on, there
will always be some animosity generated and our efforts will
never be fully appreciated.
Accepting that takes courage.”
"Yo iba a empezar el último capítulo con una historia sobre
un grupo de testers proactivos en todo lo que hicieron,
que salvaron proyectos, y que fueron considerados muy positivamente por todos.
Luego pensé, ¿Por qué mentir?
Gran parte de la premisa de este libro se refiere a ser proactivo
y tomar el destino en nuestras propias manos tanto como sea posible.
Eso significa que, cuando se prueba, pisaremos muchos dedos.
A pesar de que podamos tratar de reducir al mínimo el número de dedos que pisamos,
siempre se generará cierta animosidad y nuestros esfuerzos nunca se apreciarán plenamente.
Aceptar esto requiere valor. "
Espero este resumen les resulte de utilidad, y los invito a discutir el tema, si les interesa, en el Grupo de Linkedin “Mejora de Procesos de TI” http://www.linkedin.com/groups?home=&gid=2603073&trk=anet_ug_hm
¡Que lo disfruten!
martes, 6 de abril de 2010
Administración de la Cartera de Proyectos - Microsoft Project Server 2010
Introducción
En este artículo pretendo mostrar en forma resumida la propuesta de manejo de Cartera de Proyectos del producto Project Server en su versión 2010.
Para quienes estén interesados en ver las diferencias entre el manejo de la versión 2007 y 2010, agregué en la sección de Referencias un enlace a la página de Microsoft donde se explican. Para aquellos que estén interesados en la arquitectura y descripción del producto, agregué otros enlaces sobre el tema.
Nos concentraremos entonces en la propuesta de gobernanza de la Cartera de Proyectos que propone el producto.
Este gráfico resume los puntos que siguen:
Ciclo de Vida
La estrategia de la empresa da lugar a una serie de iniciativas que deben encararse para ejecutarla. Estas iniciativas a su vez, sirven como guía para la recepción de propuestas e ideas alrededor de ellas.
La recepción, registración, selección, evaluación, priorización, planificación y seguimiento de todas estas propuestas es el objetivo de la herramienta.
Estas actividades propone cumplirlas a través de cuatro grupos de procesos o fases:
1. Creación – Atiende la Gestión de la demanda.
2. Selección – Aplica las restricciones de objetivos, presupuestos, riesgos y recursos entre otras a las propuestas registradas y prioriza las propuestas seleccionadas.
3. Planificación – Las propuestas seleccionadas y priorizadas, requieren ahora una planificación detallada y tiempo y recursos.
4. Administración – Ve el comportamiento de los proyectos en cuanto a sus compromisos de entregas, tiempo y recursos, las posibles desviaciones y su impacto en la Cartera.
Roles intervinientes
Estos son posibles roles que intervienen en los procesos anteriores:
Creación:
· Cualquier persona de la Organización autorizada a enviar propuestas o ideas
· El sector en la Organización que conociendo las restricciones a aplicar, tenga autoridad para aceptar o postergar propuestas presentadas.
Selección:
· El sector en la Organización que conociendo los objetivos y las restricciones a aplicar, intenta componer la Cartera más óptima que los satisfaga.
Planificación:
· Aquella persona que presentó una idea aceptada, o a la que se le asignó una idea aceptada y que pueda desarrollar un Plan de Proyecto.
· El sector encargado de controlar que el detalle agregado a los proyectos no haya variado su elegibilidad
Administración:
· El Equipo de Trabajo
· El sector que tenga autoridad y responsabilidad para evaluar el desempeño de los proyectos y tomar o proponer las acciones necesarias en caso de desvíos.
Creación y manejo de la Cartera
Los siguientes puntos son interesantes de tener en cuenta acerca de la forma en que el producto propone lograr el objetivo arriba mencionado.
Fase de Creación
Gestión de la Demanda
La propuesta para la captura de ideas es amplia. Al estar sobre un entorno colaborativo, esta captura puede extenderse prácticamente a toda la Organización.
La información necesaria para ingresar una idea y que esta idea sea evaluada es mínima, evitando de este modo que no se presenten propuestas interesantes por falta de información al momento de ingresarlas.
La lista de ideas y propuestas no debe ceñirse sólo a aquellas propuestas que tengamos capacidad de ejecutar, de este modo estaríamos limitando nuestra capacidad de elegir, siendo esta elección la base de la estrategia.
Las limitaciones y filtros aparecerán más adelante y no en este momento.
Si bien se genera un mayor trabajo de análisis de propuestas, también permite obtener un mayor número de ellas.
Hecho este primer ingreso por el interesado, dependiendo del tipo de propuesta, esta se dirigirá automáticamente al primer proceso de evaluación.
Primera Evaluación
Esta primera evaluación acepta aquellas propuestas de interés y deja en suspenso, pero registradas, las restantes de modo tal de retomarlas en otro momento.
Agregado de Detalle
Para aquellas propuestas seleccionadas en esta primera ronda, se requiere ahora un completar el Caso de Negocio, incorporando información sobre beneficios, riesgos, tipo de personal requerido y periodo por el cual se lo requerirá, y costos.
Tambien puede aclararse el marco de tiempo en el cual la ejecución de este proyecto tiene sentido si se trata, por ejemplo, de aprovechar una oportunidad.
Toda esta información permitirá en los próximos pasos evaluar el proyecto con más precisión y priorizarlo.
Fase de Selección
Creación de la Cartera de Proyectos
Los procesos que componen la fase anterior dejaron un conjunto de propuestas que están alineadas con los objetivos estratégicos de la Organización, por ello fueron elegidas.
Los objetivos estratégicos a su vez pueden tener también distinta prioridad entre sí, otra actividad de esta fase, previa a la búsqueda de la cartera óptima es lograr ese ordenamiento.
Si ahora eligiéramos las cinco propuestas de menor costo por ejemplo, tomando sólo el costo como parámetro, quedaría una cartera posible, pero no podemos asegurar que sea la óptima.
La Cartera debe ser priorizada entonces en función de todas las variables intervinientes: prioridad de los objetivos entre sí, costos, disponibilidad de recursos, ventana de oportunidad para su realización.
Deben además contemplarse proyectos que, independientemente de su conveniencia estratégica deban realizarse en forma obligatoria, por ser regulatorios por ejemplo.
Este procesos dará entonces diversas posibilidades de Cartera (what-if), que cumplen en mayor o menor grado los objetivos, a un mayor o menor costo, por ejemplo.
Por último, las nuevas propuestas aceptadas difícilmente ingresen en una Cartera sin otros proyectos en ejecución de períodos anteriores. Estas competirán entonces con las que están en curso y surgirán decisiones acerca de mantener o no aquello que está en ejecución, si se mantienen las premisas que los hicieron elegibles en su momento o caso contrario deben ser abandonados y reemplazados por otros nuevos. Decisiones no sencillas.
Elegida aquella Cartera que cumple con las restricciones y rinde el mejor beneficio, se procederá a la siguiente Fase.
Fase de Planificación
Creación del Plan Detallado del Proyecto
Los proyectos que ahora conforman la Cartera a ejecutar deben ser bajados a detalle en su planificación. Recordemos que el plan contenido en el caso de negocio era tentativo y a nivel de recursos genéricos. Ahora esos recursos deben nominarse y asignarse.
El Jefe de Proyecto asignado creará el Equipo de Trabajo, el calendario y actualizará el costo- beneficio con la planificación real. Para ello tendrá la información de la disponibilidad de recursos determinando así a quien puede asignar a un perfil dado.
Aprobación final de proyecto
El plan detallado, registrado como línea de base cero o inicial, se remite a aprobación.
El plan es entonces revisado y aprobado o devuelto para su corrección, en caso de existir problemas, y la cartera puede en ese momento volver a recalcularse para detectar si aún se cumple con los objetivos inicialmente propuestos.
Fase de Administración
Ejecución del Proyecto
Los proyectos aprobados, planificados y con recursos asignados comienzan su etapa de Ejecución. En ella el Equipo de Proyecto efectúa las tareas organizativas típicas de registrar el esfuerzo, reportar el avance, registrar y controlar los riesgos e informar los temas del Proyecto que puedan requerir atención. El Jefe de Proyecto podrá controlar así el reporte de consumos y avance y tomar las acciones correctivas necesarias si se requirieran.
Control de la Cartera de Proyectos
La Organización encargada del control de la ejecución de la Cartera, dispone ahora de la información necesaria para determinar el estado de situación de cada proyecto y tomar acciones correctivas si lo requirieran.
Cierre del Proyecto
En el momento adecuado el Proyecto llegará a su fin y se verificará el estado de cierre, cumplimiento de costos, objetivos y calendarios para proceder a la baja del mismo de la Cartera.
Comentarios
1. Todo lo arriba mencionado describe un proceso relativamente sencillo y claro para la creación y administración de una Cartera de Proyectos.
2. Obviamente que el proceso será tan preciso como los datos que se le proporcionen. Una ventaja que presenta el enfoque del producto es que estos datos se ingresan en forma progresiva y cuando se los requiere. El no requerir información detallada desde el inicio permite:
· Evitar trabajo inútil en proyectos que finalmente serán descartados.
· Evitar momentos traumáticos para el proponente, ya que no invertió demasiado tiempo en ella y luego esta fue rechazada.
· Alentar a proponer nuevas ideas.
3. La plataforma colaborativa sobre la que está desarrollado el producto, ayuda a la facilidad de masificar la propuesta de ideas, aunque esto como dijimos más arriba recargue el análisis.
4. Deben estar formalizados algunos temas que no siempre lo están: Objetivos Estratégicos a lograr, costos, beneficios, riegos realistas, la disciplina de Caso de Negocio.
5. La variedad fomenta la innovación y el producto permite implementar una forma sencilla de capturar esa variedad y analizarla contra objetivos y restricciones conocidos.
6. Los flujos de trabajo conocidos y formalizados transparentan el proceso de evaluación y selección, disminuyendo las frustraciones y arbitrariedades.
7. La Cartera de Proyectos tiene que ser visto como algo necesario. La cantidad y variedad de proyectos debe justificar la instalación de la solución, de otro modo una lista ordenada y controlada cumpliría, aunque en forma acotada, la misma función mucho más sencillamente.
8. No hay nada más frustrante que la información desactualizada. Si la presentación de la Cartera no muestra información actual, perderá la confianza, el interés y de allí su razón de mantenerla.
Lo mencionado no pretende ser una descripción del producto Project Server. Simplemente comentarios acerca del proceso que implementa y algunas consideraciones, no técnicas, a tener en cuenta si se piensa en su implementación.
Espero les resulte de utilidad y los invitamos a discutir el tema, si les interesa, en el Grupo de Linkedin “Mejora de Procesos de TI” http://www.linkedin.com/groups?home=&gid=2603073&trk=anet_ug_hm
Saludos,
Raúl
Referencias:
1. Las novedades Project Server 2010-2007 en:
2. La arquitectura técnica del producto en:
http://msdn.microsoft.com/en-us/library/ee767687(office.14).aspx
3. Una descripción comercial sencilla pero bastante completa, no especifica de Project Server 2010 en:
http://www.microsoft.com/project/en/us/project-portfolio-management.aspx
4. Una descripción del producto Project Server 2010, se puede ver en este mismo blog en:
http://excelza.blogspot.com/2010/02/microsoft-project-2010-introduccion.html
5. Sobre Oficina de Proyectos (PMO), que contiene algunos temas de Administración de Cartera.
Running the Successful Hi-Tech Project Office. Eduardo Miranda, Artech House 2003.
En general los libros que tratan de la Oficina de proyectos (PMO) tratan en tema con mayor o menor profundidad.
martes, 23 de marzo de 2010
Microsoft Office Project Server 2007: The Complete Reference
Estuve re-leyendo algunos libros de Project Server 2007 y me pareció interesante recomendar alguno para aquellos que se están embarcando en las aventuras del EPM (mientras esperamos los libros de la versión 2010).
El libro que recomiendo en este artículo es "Microsoft Office Project Server 2007: The Complete Reference", escrito por Dave Gochberg y Rob Stewart. Las razones son:
- Es bastante sencillo de leer, teniendo en cuenta que el tema es algo "duro".
- Explica en forma conceptual la arquitectura técnica y de desarrollo.
- Lo que más me gustó: los capítulos que muestran como interactúan los diferentes roles con Project Server: el líder de proyecto, el miembro del equipo, el jefe funcional y los ejecutivos. En mi opinión, la sección más lograda de este libro (llamada Project Server en acción).
Les dejo una imagen con el mapa mental del libro que espero les sea útil:
Además pueden navegar parte del libro en Google Books. Aquí el link:
Hasta la próxima!
lunes, 22 de marzo de 2010
Anécdotas de la vida real… o por qué debe probarse el software
Además de todo lo que dice la teoría y lo que podamos pensar los que llevamos adelante la práctica, esto es un aporte personal de un amigo que sufrió recientemente un defecto durante una compra “por Internet”. En su caso terminó bien, pero el escenario pudo haber sido totalmente diferente… y ésta es sólo una de tantas historias parecidas…
-------------------------------------------------------------------------------------------------------------------------
Esto es algo que me pasó la semana pasada haciendo una compra por Internet, que creo que ejemplifica bien los riesgos de no probar adecuadamente el software.
Hice una compra en un sitio de Internet, y una vez elegido el artículo que quería marqué Check Out para concretar la operación y comencé a seguir los 4-5 pasos: forma de pago (tarjeta), dirección para el envío, método de envío, etc.
Eventualmente llegué a lo que debía ser la última pantalla, que ya no era del sitio de comercio electrónico sino del banco (cargó desde otro servidor). La página ya la había visto antes y es un pedido de autorización de operaciones de comercio electrónico, que pide simplemente una contraseña. El problema es que no tenía conmigo dicha contraseña, ya que inexplicablemente esta página sólo me la encuentro de cuando en cuando.
Por eso, preferí abortar la operación (había dos botones: Aceptar y Cancelar) y volver a hacer el pedido más tarde cuando tuviese todo conmigo. Entonces, le di a Cancelar.
'Muchas gracias por su pedido! En breve recibirá un correo con los detalles del mismo.'
Mh?
Pensé 'bueno, será un error de interface entre ambos sitios, seguramente el banco habrá cancelado, pero el sitio habrá pensado que salió por OK y por eso me muestra esto' (lo cual de todos modos habría sido un error, pero hasta aquí sin heridos).
Me distraje con alguna otra cosa y como a la media hora oí un mensaje en el teléfono móvil. Fui a ver qué era y... 'Su pedido ha sido despachado! Muchas gracias por su compra.'
Eehh?!
Ahora sí que no entendía nada. Yo nunca había autorizado la operación (más allá de que había querido hacer la compra, y seguía interesándome, con lo cual esto es sólo una anécdota). Pensé 'bueno, irá a rechazarla el banco, les hago una transferencia luego a los vendedores, y todos felices'.
Les puse un correo a los vendedores, diciendo exactamente esto y me olvidé. Llegó la respuesta: 'No se preocupe, si enviamos el artículo es porque hemos podido cobrarlo'. ¿Aparecerá el rechazo en un par de días entonces? ¿Es imposible que todo termine bien, no? Si después de todo yo nunca puse la contraseña...
Pues el final de esto es que hoy me encuentro con el débito en la cuenta del banco, o sea, en efecto, dándole a Cancelar, la operación siguió su curso normal y llegó a término.
Nuevamente, en mi caso es sólo una anécdota porque la compra la habría hecho de todos modos, pero no pude evitar quedarme pensando... ¿y si hubiese sido otra persona con mi número de tarjeta?! ¿Y si realmente me hubiera interesado cancelar la compra…?
martes, 9 de marzo de 2010
Cosas simples, impactos complejos… en la estimación de las pruebas
Queremos acercar algunas ideas a tener en cuenta al planificar el esfuerzo y el tiempo que implicará una prueba. No nos centraremos en estimar, por ejemplo cuánto llevará probar cada caso de uso, sino en supuestos y riesgos a tener en cuenta.
Proceso de estimación
El esfuerzo, y si es una contratación, el monto del servicio de prueba, se estima en función a un cálculo que puede tomar como base:
- La experiencia o seniority de los perfiles requeridos en el Equipo de Prueba y del resto de los equipos de trabajo intervinientes.
- El Alcance que determina la cantidad de trabajo a hacer, en función a la cantidad de requerimientos funcionales y no funcionales y entorno de prueba.
- El proceso que seguirá el Productor, Desarrollador u otro equipo de trabajo, para producir los entregables objeto de la prueba.
- La calidad esperada de los entregables a recibir.
Factores que alteran el presupuesto original
Errores propios de la estimación del Equipo de Prueba
El Equipo introduce errores en su propia estimación provenientes de:
- Diferencias entre los estimadores.
- Interpretaciones equivocadas de la complejidad de las tareas, producto de la poca información disponible al momento de la estimación.
Estos desvíos no deberían incidir en más de un porcentaje relativamente bajo, 5% a 10% por ejemplo, del esfuerzo y/o calendario original, y si nos referimos a una contratación, no alterarán hacia el Cliente el presupuesto original. En otras palabras, si a este nivel nos equivocamos, lo tendremos que asumir.
Otras fuentes de desvíos
Los siguientes puntos, identifican otras posibles fuentes de desvíos, ya no imputables al Equipo de Prueba.
| Fuentes de Desvío | Desvío que puede generar | Comentarios | |||||
| Entregas fuera de fecha | Esfuerzo no productivo incurrido por entrega tardía por parte del Productor (Desarrollador u otro equipo de trabajo), o bien entrega de menos productos que los planificados, estando el personal de prueba ya asignado. | El Equipo de Prueba deberá tratar de utilizar estos tiempos muertos en tareas que puedan adelantarse, si bien esto no siempre es posible. | |||||
| Desvíos por cambio de Alcance y/o cambio de Requerimientos | Esfuerzo y/o tiempo adicional por cambio o extensión de los requerimientos funcionales y/o no funcionales, en cantidad y/o complejidad. | ||||||
| Desvíos por re-trabajo o baja calidad de los entregables | Esfuerzo y/o tiempo adicional por productos entregados al Equipo de Prueba con calidad inaceptable, o incompletos. La columna siguiente muestra los parámetros y supuestos que se toman en cuenta para la planificación. |
| |||||
| Desvíos por incremento de horas de supervisión | Esfuerzo adicional debido al crecimiento no planificado de la cantidad de recursos del Equipo de Prueba, que causa aumento en la supervisión requerida. | ||||||
| Desvíos por supuestos incorrectos de otros equipos de trabajo | La estimación de esfuerzo del Equipo de Prueba, además de lo detallado, toma en cuenta un porcentual del esfuerzo del Productor (Desarrollador u otro equipo de trabajo) como base para sus calcular sus horas. | Una estimación del esfuerzo de los productores errónea, arrastra un error también en la estimación de la prueba. Ejemplo: el esfuerzo de prueba es el 40% del esfuerzo de desarrollo | |||||
| Otros desvíos con motivo de extensiones desconocidas en la planificación original | El desplazamiento del calendario se impacta con eventos no previsibles o existentes al momento de la planificación original. | -Por ejemplo, licencia del personal por vacaciones o enfermedad -Requerimientos al personal por otros proyectos |
Como dijimos al principio, estas son pequeñas ayudas a tener en cuenta al desarrollar la estimación y posterior planificación del trabajo de prueba. No pretende ser exhaustiva y Uds. pueden seguir completándola con su experiencia. Algunos temas podrán expresarse como riesgos, otros como supuestos, pero lo importante es recordarlos.
Esperamos les resulte de utilidad.
Y los invitamos a discutir el tema, si les interesa, en el Grupo de Linkedin “Mejora de Procesos de TI” (http://www.linkedin.com/groups?home=&gid=2603073&trk=anet_ug_hm)
Saludos,
Pilar Barrio
Raúl Martínez
Arriesgamos o no arriesgamos?
Según la Real Academia Española, arriesgar es “poner a riesgo”.
Y un riesgo es una “contingencia o proximidad de un daño” que puede ocurrir.
Como testers en un proyecto, y más aún si nos toca liderar las pruebas, lo que ponemos a riesgo o arriesgamos en nuestra tarea, tiene que ver con la calidad del producto que se liberará, y también con nuestra “imagen” profesional.
Si bien lo segundo es importante (para nosotros o nuestras áreas), para nuestro cliente será más importante lo primero, por lo que no deberíamos arriesgar el éxito de nuestra misión como testers, que en definitiva pasa por cumplir los objetivos del cliente.
Qué tipo de testing tenemos que ejecutar, en qué contexto, en qué momento del proyecto / ciclo de vida del producto, con qué restricciones y recursos, con qué objetivos.
Y dado que el testing es un servicio, queremos ejecutarlo “con calidad”, para que nuestro cliente (interno o externo) nos siga contratando ese servicio, al entender él que colaboramos a obtener un mejor producto, lo que preserva su inversión.
Y como la calidad es un concepto relativamente subjetivo, y el testing nunca puede ser completo, en cada proyecto de testing estamos “arriesgando”.
¿Cuánto queremos arriesgar? ¿Cuánto quiere arriesgar el cliente que contrata el servicio? Dependerá del daño posible, de cuán “cerca” se vea ese daño y de la gravedad de sus consecuencias.
En el artículo anterior http://excelza.blogspot.com/2010/02/probamos-pero-evolucionamos.html comenté sobre las fases en el proceso mental de evolución de los testers.
En ese proceso, uno de los estadíos que es deseable que alcancemos tiene que ver con entender que no probamos para mostrar que la aplicación tiene defectos o que no los tiene, sino para reducir los riesgos percibidos a un valor aceptable.
Y el siguiente lo alcanzamos al entender que el testing no es un acto, sino una disciplina mental que resulta en software de bajo riesgo, sin excedernos en el esfuerzo (y costos) incurrido en hacer las pruebas.
En definitiva, nuestro objetivo estará relacionado con gestionar los riesgos del software de la mejor forma posible, minimizando la utilización de recursos y tiempo, y previniendo o encontrando los problemas antes de que los encuentren los usuarios o clientes y se conviertan en usuarios o clientes disconformes. Lo que implica poner todo nuestro foco sobre los riesgos, para arriesgar menos al momento de liberar un producto.
Y en estos breves párrafos que acabo de escribir, aparece varias veces la palabra RIESGO.
Y la necesidad de reducir los riesgos percibidos a un nivel aceptable.
En esto se basa el Risk Based Testing (RBT): el software nos expone a un conjunto de riesgos; el testing nos da información sobre el estado de esos riesgos y si se han controlado o limitado, a efectos de lograr una liberación (suficientemente) exitosa, o bajar la probabilidad de que ocurran problemas graves al liberar.
RBT comprende tanto la estrategia de planificación de las pruebas, como la técnica de diseño propiamente dicha.
Quienes hacemos testing, intuitivamente aplicamos algunas de estas estrategias y técnicas, aunque no las llamemos RBT… No dejan de ser cosas de sentido común, aún siendo éste el menos común de los sentidos… ¿Qué tester no ha pensado cuáles son las funcionalidades o características más riesgosas del producto que tiene entre manos, o qué situaciones se han dado en el proyecto de construcción que puedan significar riesgos para la estabilidad del producto?
Risk Based Testing, gráficamente…
Básicamente, muy similar a un proceso planificado de prueba:
Planificar, diseñar, ejecutar, evaluar e informar resultados.
¿En qué residen las grandes diferencias, a nuestro entender?
En:
1) La forma de determinar el alcance inicial.
2) La forma de realimentar el diseño o el plan, en la medida en que aparecen nuevos riesgos o algunos se reevalúan.
3) La forma de diseñar los casos, a partir de los riesgos identificados, las fallas potenciales, y la manera de tratar de provocarlas.
¡Hasta la próxima!
jueves, 4 de marzo de 2010
El Jefe de Proyecto y la Organización no orientada a proyectos. ¿Encajar una pieza cuadrada en un hueco redondo?
Varios de Uds. se habrán encontrado con este tema. Yo también.
¿Es posible desarrollar la Administración por Proyecto y el rol de Jefe de Proyecto, en una Organización no orientada a proyectos?
¿La típica matriz es viable en estas organizaciones?
¿Se puede asignar responsabilidad sin dar autoridad?
Organizaciones no orientadas a proyecto
Las organizaciones funcionales típicas, no orientadas a proyecto, y presentes en empresas que privilegian la operación, parecen presentar a primera vista, como explica Kerzner(1), un desafío para desarrollar la Administración por Proyectos y el rol del Jefe de Proyecto.
Los recursos se asignan con prioridad a áreas funcionales de mayor rendimiento económico, y los proyectos son para generar o cambiar productos de estas áreas funcionales.
¿Qué problemas se presentan con los proyectos?
· La inexistencia de la visión del proyecto, o la visión del mismo a través de los silos funcionales.
· La consiguiente demora de las tareas del proyecto en estos silos, debido a prioridades sobre los recursos, en conflicto respecto a tareas funcionales (2).
¿Qué problemas se presentan con el rol de Jefe de Proyecto?
· El rol del Jefe de Proyecto es muchas veces informal.
· Es un trabajo de tiempo compartido.
· Tiene escaso o nulo control del presupuesto del proyecto.
· Tiene poca o ninguna autoridad sobre la asignación de recursos (el típico “el equipo ya me llega armado”).
· Tiene en general poca autoridad debido a su posición en la estructura, muchas veces subordinada a los mismos jefes funcionales que deben provee los recursos.
· Los responsables de las áreas funcionales tienen poca voluntad para aceptar la autoridad del Jefe de Proyecto.
Pero… ¿En qué casos una Organización no orientada a proyectos necesita trabajar por proyecto?
Un buen resumen (3) confirmado por la práctica es el siguiente:
· Cuando para desarrollar un nuevo tema, debe intervenir más de un área de la Organización, siendo crítico que trabajen coordinadas, por ejemplo, el desarrollo de nuevos procesos, la instalación de un ERP que cambiará la forma de operar de la Compañía, u otros casos similares.
· Cuando hay dudas acerca de la conveniencia de una tecnología y conviene probar en un ambiente controlado (el del proyecto).
· Cuando hay restricciones económicas o de recursos importantes para desarrollar una nueva idea, que exigen un estricto control de estas variables.
Como vemos, estas pueden no ser tareas rutinarias en organizaciones de este tipo.
Finalmente… ¿Podremos hacer encajar las piezas?
Las siguientes ideas tratan de ayudar a resolver algunos de estos problemas, a evitar que el rol esté “pintado” en la Organización y a que se comprenda el sentido de un proyecto:
1. Aceptar que no todo emprendimiento es un proyecto ni puede organizarse como tal.
2. Formalizar el rol a través de definir sus roles y responsabilidades, e incluirlo en el Plan de Carrera o su equivalente.
3. Ubicar el rol de Jefe de Proyecto en la estructura de modo tal que acceda a los mismos niveles de decisión que los Jefes Funcionales, ya sea en forma directa o a través de una organización que los agrupe.
4. Capacitar en la práctica de Administración de Proyectos.
5. Comunicar, comunicar y comunicar a todos los interesados sobre el rol del Jefe de Proyecto y la Administración de Proyectos
6. Evitar en todo lo posible la continua injerencia de los Jefes Funcionales en los trabajos del Proyecto y sobre los recursos.
7. Asignar la responsabilidad completa del Proyecto al jefe de Proyecto y la correspondiente autoridad.
Espero sea de utilidad y los invito a discutir el tema en el Grupo Mejora de Procesos de TI en LinkedIn.
Saludos,
Raúl
Bibliografía
1. Project Management, H. Kerzner
2. PMBOK 4th Edition, PMI
3. Problems of Matrix Organizations, Davis and Lawrence, HBR
Suscribirse a:
Entradas (Atom)