martes, 30 de julio de 2013
lunes, 29 de julio de 2013
domingo, 28 de julio de 2013
You really love playing Russian roulette
Does the project drained the budget, you do not have change management, the customer is tired of your "quality" and delay, and you can not do testing because, is the delivery date the priority? You really love playing Russian roulette
sábado, 27 de julio de 2013
jueves, 25 de julio de 2013
miércoles, 24 de julio de 2013
martes, 23 de julio de 2013
domingo, 21 de julio de 2013
How much agile are your processes?
Some times we read opinions about the stiffness of traditional development methodologies versus agile methodologies. In many of these it is confused models with methodologies. As I understand it, a model tells you what to do, while a methodology gives guidelines on how you can do it. I see it totally complementary and necessary.
I imagine that phobias against models come because of stiff processes have been defined and phobia against agile comes because of understanding the agility as an excuse for anarchy.
As virtue is in the middle, I would like to express my opinion about what should be done, and see examples of how we can do it.
In any project we have to take special care about the expectations of our client's requirements. If we want to obtain a profit, we must keep track of the changes, as these aren't free, they can have a big impact on that we have made. We probably have to rework on something finished. Then I don't understand how somebody can say that as the agile methodology is, we do not need:
If your project is run by a team of medium size, it is bestter that your system will be a collaborative management. That all members have access to the latest information and latest known dates. Each team member must know who is doing what and in what state it is. It may be that what the person is doing on your right, it will be need by the person you have on your left.
How to implement all this effort?
What support tools are you using?
Do you have more or less established process?
When the project size rise and / or the number of simultaneous projects rise and / or when you go to pass from an informal group to a company known as serious one, or you have a model, using a methodology and defined processes or it will be very difficult to have everything under control, and sooner or later you will be in trauble.
Stories should not told by anybody. We can not improve that it is not there, so we need a process to be improved. We can not know that we do not measure or observe, then we need to measure in order to compare the previous with present.
You need a quality model. You need a methodology that is aligned with your quality model. You need a process to help you following your methodology. You need that one that fits your personality better and with your organization. To summit that one that will help you to identify how you can be more competitive.
The question should be: How much agile are your processes?
I imagine that phobias against models come because of stiff processes have been defined and phobia against agile comes because of understanding the agility as an excuse for anarchy.
As virtue is in the middle, I would like to express my opinion about what should be done, and see examples of how we can do it.
In any project we have to take special care about the expectations of our client's requirements. If we want to obtain a profit, we must keep track of the changes, as these aren't free, they can have a big impact on that we have made. We probably have to rework on something finished. Then I don't understand how somebody can say that as the agile methodology is, we do not need:
- Requirements management
- Changes management
- Project management
- Test management
- Configuration management
- ...
If your project is run by a team of medium size, it is bestter that your system will be a collaborative management. That all members have access to the latest information and latest known dates. Each team member must know who is doing what and in what state it is. It may be that what the person is doing on your right, it will be need by the person you have on your left.
How to implement all this effort?
What support tools are you using?
Do you have more or less established process?
When the project size rise and / or the number of simultaneous projects rise and / or when you go to pass from an informal group to a company known as serious one, or you have a model, using a methodology and defined processes or it will be very difficult to have everything under control, and sooner or later you will be in trauble.
Stories should not told by anybody. We can not improve that it is not there, so we need a process to be improved. We can not know that we do not measure or observe, then we need to measure in order to compare the previous with present.
You need a quality model. You need a methodology that is aligned with your quality model. You need a process to help you following your methodology. You need that one that fits your personality better and with your organization. To summit that one that will help you to identify how you can be more competitive.
The question should be: How much agile are your processes?
domingo, 14 de julio de 2013
Testing: Quality Assurance o Quality Assistance
- "A que te dedicas?"
- "A probar software"
- "Ah! trabajas como Quality Assurance?"
- "Si"
- "Entonces, modificas el código del software que pruebas?"
- "No!!!"
- "Interesante!! Y como aseguras la calidad?"
...
El otro día leyendo una entrada del blog de Michael Bolton DevelopSense, mencionaba mas o menos esa conversación. La conclusión es que uno solo puede asegurar la calidad del trabajo que uno hace. No del que hacen los demás.
La calidad es responsabilidad de todos. Y todo lo que no empieza con calidad, difícilmente termina con ella.
El trabajo de pruebas no es asegurar nada. Es ayudar a evaluar el riesgo en que incurriríamos al entregar el producto en las condiciones en que se prueba.
Excusas cuyo objeto es justificar por que no hemos hecho las pruebas lo único que indican es cuanto nos gusta el riesgo y que realmente se desconoce cual es la función de las pruebas.
Y a tu empresa? Le gusta el riesgo?
Y a tu cliente? Le gusta el riesgo?
No veamos las actividades de prueba como aseguramiento de la calidad, sino como asistencia a la calidad y asegurémonos desde el minuto cero de que todas las actividades del proyecto se realizan con calidad, ya que de lo contrario vamos a ir acumulando una deuda que resultará muy difícil de amortizar y que siempre irá en contra de nuestro prestigio y credibilidad.
- "A probar software"
- "Ah! trabajas como Quality Assurance?"
- "Si"
- "Entonces, modificas el código del software que pruebas?"
- "No!!!"
- "Interesante!! Y como aseguras la calidad?"
...
El otro día leyendo una entrada del blog de Michael Bolton DevelopSense, mencionaba mas o menos esa conversación. La conclusión es que uno solo puede asegurar la calidad del trabajo que uno hace. No del que hacen los demás.
La calidad es responsabilidad de todos. Y todo lo que no empieza con calidad, difícilmente termina con ella.
El trabajo de pruebas no es asegurar nada. Es ayudar a evaluar el riesgo en que incurriríamos al entregar el producto en las condiciones en que se prueba.
Excusas cuyo objeto es justificar por que no hemos hecho las pruebas lo único que indican es cuanto nos gusta el riesgo y que realmente se desconoce cual es la función de las pruebas.
Y a tu empresa? Le gusta el riesgo?
Y a tu cliente? Le gusta el riesgo?
No veamos las actividades de prueba como aseguramiento de la calidad, sino como asistencia a la calidad y asegurémonos desde el minuto cero de que todas las actividades del proyecto se realizan con calidad, ya que de lo contrario vamos a ir acumulando una deuda que resultará muy difícil de amortizar y que siempre irá en contra de nuestro prestigio y credibilidad.
Cueces o enriqueces
Cual es tu estilo, cual es tu forma de probar?
Piensas que cualquiera puede probar, que puedes disponer de un repositorio re utilizable de casos de prueba, que puedes construir un framework de pruebas automáticas con montones de scripts re-utilizables, ... ? Cueces
Piensas que probar es escuchar, preguntar, explorar, aprender, investigar, cuestionar... ? Enriqueces
Imaginemos el proyecto "comprar un coche usado". Nuestra principal preocupación es que no nos den "gato por liebre". Que vamos a hacer para minimizar el riesgo o al menos poder tomar la decisión?
Revisaremos los puntos que consideremos críticos y normales?. Es nuestra checklist particular. Pero es que nosotros no somos expertos en coches, así que nuestra checklist, seguro que o bien es escasa, o bien no tenemos forma de verificarla. Es barata, pero el riesgo es grande. El vendedor sabe lo que vamos a mirar.
Recurrimos a un taller de confianza? Este es experto en coches. Conoce que puntos son los críticos, en general, tiene experiencia y medios para verificar con bastante mas profundidad que mas o menos todo está en orden. Su checklist es mas completa y sistemática que la nuestra. Seguramente publicitará "Revisión de 200 puntos de tu vehículo". Esta opción ya no es gratis, pero el riesgo a equivocarnos disminuye.
Investigamos el historial del vehículo en concreto, sus dueños, el modelo. Con la información encontrada, profundizamos en la verificación de los puntos susceptibles de fallo:
Piensas que cualquiera puede probar, que puedes disponer de un repositorio re utilizable de casos de prueba, que puedes construir un framework de pruebas automáticas con montones de scripts re-utilizables, ... ? Cueces
Piensas que probar es escuchar, preguntar, explorar, aprender, investigar, cuestionar... ? Enriqueces
Imaginemos el proyecto "comprar un coche usado". Nuestra principal preocupación es que no nos den "gato por liebre". Que vamos a hacer para minimizar el riesgo o al menos poder tomar la decisión?
Revisaremos los puntos que consideremos críticos y normales?. Es nuestra checklist particular. Pero es que nosotros no somos expertos en coches, así que nuestra checklist, seguro que o bien es escasa, o bien no tenemos forma de verificarla. Es barata, pero el riesgo es grande. El vendedor sabe lo que vamos a mirar.
Recurrimos a un taller de confianza? Este es experto en coches. Conoce que puntos son los críticos, en general, tiene experiencia y medios para verificar con bastante mas profundidad que mas o menos todo está en orden. Su checklist es mas completa y sistemática que la nuestra. Seguramente publicitará "Revisión de 200 puntos de tu vehículo". Esta opción ya no es gratis, pero el riesgo a equivocarnos disminuye.
Investigamos el historial del vehículo en concreto, sus dueños, el modelo. Con la información encontrada, profundizamos en la verificación de los puntos susceptibles de fallo:
- Historial de taller (Que histórico de mantenimiento ha tenido nuestro producto)
- Tipo de conductor (Quien ha construído nuestro producto)
- Historia del modelo en busca de problemas conocidos (Que problemas comunes presenta ese domino)
- Historial de Inspecciones Técnicas de Vehículos (Que pruebas se han hecho ya en el producto)
- Historial de siniestros (Que problemas se conocen ya del producto)
Con todas estas acciones podremos poner al descubierto tanto los fallos visibles encontrados por nuestras checklists (Cueces) como los posibles fallos ocultos fruto de un mal diseño, uso o siniestro que pueda poner en riesgo el correcto funcionamiento (Enriqueces)
Y por supuesto que todas las acciones deben ser tomadas en cuenta ya que "cocer y enriquecer" deben ser complementarios.
Las checkslist, repositorios de casos de test tipo, automatizaciones, están muy bien, pero llegan donde llegan. Es mucho menos costoso, pero encuentran lo evidente.
Para escuchar, preguntar, explorar, aprender, investigar, cuestionar, necesitaremos otro perfil, seguramente mas caro, pero que aportará mucho mas valor.
Y tu? Cueces o enriqueces?
Suscribirse a:
Comentarios (Atom)