No cuentes el tiempo que usas en generar el entorno de testing y prepárate para explicar por que aún el testing no finaliza.
Si por cada vez que debes iniciar una actividad de testing, debes preparar ambientes nuevos o actualizar los existentes, configurando, modificando o cambiando tu juego de dato para hacerlo significativo, entre otras tantas acciones previas al testing efectivo, entonces será mejor que incluyas ese tiempo en tus estimaciones o te verás acorralado contra la línea de tiempo final.
Inclusive si tu actividad de ejecución de las pruebas en si mismo, es corta, es decir si tus casos de pruebas son simples y de un corto tiempo de ejecución, es absolutamente posible que la preparación del entorno para tales ejecuciones pueda consumirte el doble o más tiempo del que usas para hacer las pruebas.
Esto es algo que posiblemente un manager no lo comprenda y suele ocurrir muy seguido. Un síntoma muy claro es cuando se espera que la actividad de testing finalice en tiempo y en forma, aún cuando los desarrollos no finalizaron en término y se consumieron una franja del tiempo de testing.

Agile en los procesos de selección RRHH. Nuevos paradigmas contra nuevos paradigmas?

 

Durante 5 meses y medios participe en más de 10 entrevistas de trabajo en las consultoras, más de 5 en las empresas en su área de RRHH, tuve más de 15 entrevistas vía telefónica. Me llamaron hasta 7 veces distintas consultoras a nombre de la misma empresa. Me dijeron “solo falta un trámite” en más del 70% de las veces, “la semana que viene te llamamos por que te fue muy bien en los técnicos” en más del 50% y puedo seguir con la lista de “casis” hasta hartarnos.
En las distintas entrevistas en su primera fase, normalmente realizada por las especialistas en RRH, tuve un éxito importante, en las técnicas superé la mayoría de ellas y en otras fracasé hasta por falta de entusiasmo. Pero aún así, la decisión final de darme trabajo siempre fue resuelta por una suspicacia, una duda intrínsica, o una “intuición”, quizás sobre mi perfil, quizás sobre mi personalidad. Entiendo que esta suspicacia podría haber sido solo mis pretenciones económicas, pero jamás negociamos.
Aparentemente todo lo previo a esta etapa no tuvo peso significativo o lo que es peor, siempre hubo un recurso más barato.
Solo en dos oportunidades llegué a conversar con el gerente general. En una nos miramos y no congeniamos. Demás está explicar el resultado. En la otra me quedé esperando su llamado para “comenzar el lunes”. Finalmente muy amablemente pude “hacer mi descargo.”
Recientemente me integré a una empresa norteamericana radicada en la provincia de Córdoba. Estoy muy contento no solo por el grupo que la conforma, sino por el proceso de selección directo asumido por su líder al frente de la organización.
Este proceso directo me pareció especial y bien dirigido, asumiéndose todas las responsabilidades, desde la búsqueda y selección, hasta las entrevistas iniciales, técnicas y negociaciones de salarios y otros términos. Pude observar que fue un proceso libre de vicios, prejuicios, suspicacias y otros metodologías aburridas, perenes e ineficaces. En esto SOS o NO SOS.
Mi actual jefe una tarde terminó su entrevista técnica conmigo, ayudado por su líder técnico y lejos de indicarme que todo estaba a mi favor, dejó que me marchara hasta una nueva oportunidad. Al final de la tarde me pidió que me acercara a la oficina (no su secretaria ni la “chica RRHH”), conversamos unos minutos más e hizo su propuesta laboral, clara, precisa, sin rodeos y cerramos el trato.
De pronto sentí nuevamente tener mucha suerte. Haber pasado por tanto manoseo de pasamano y de pronto estar negociando mi futuro con el “dueño del circo” y cerrar trato muy favorablemente.
Esta no es una empresa pequeña ni mediana, es una gran empresa con un montón de cosas bien aceitadas, un montón de gente trabajando en conceptos absolutamente de puntas, entre los que menciono Agile.
¿Será que Agile ya está embebido en su proceso de selección de recursos? por que los principios del cara-a-cara fueron excelentemente aplicados aquí, no por que yo haya quedado, sino por que me tocó vivirlo y ahora lo estoy disfrutando desde adentro.
Por favor las empresas de Argentina y del resto del mundo, revean sus procesos de selección. Dejen de poner en manos de consultoras externas la definición de sus relaciones con sus colaboradores. No digo que no pidan su participación, pero selecciónenlas a ella previamente, expliquen quien toma la decisión y quienes deben llegar hasta los escritorios de los manager para entablar una relación duradera y de confianza.

Instalación de IIS en Windows XP Profesional

Tienes que instalar y administrar Internet Information Server y no sabes como hacerlo? Bueno, aqui tienes una guía muy sencilla para al menos los primeros pasos.

Internet Information Server (IIS) es el servidor de páginas web avanzado de la plataforma Windows. Se distribuye gratuitamente junto con las versiones de Windows basadas en NT, como pueden ser Windows 2000 Profesional o Windows 2000 Server, así como Windows XP, también en sus versiones Profesional y Server.

Nota: Windows 95, 98, las versiones Home, de Windows XP, y ME, de Windows 2000, no se admite la instalación de IIS. En su lugar podemos probar a instalar el Personal Web Server, que se explica en el artículo Instalación de Personal Web Server.

Agregar componentes adicionales de Windows

IIS se puede encontrar en el propio CD de instalación de Windows XP Profesional. Hay que acceder a la opción de "Instalar componentes opcionales de Windows" para poder cargarlo en nuestro sistema. Para ello tenemos dos opciones:

1) Insertar el CD de instalación de Windows y en la ventana de autoarranque que se muestra, seleccionar la opción que pone "Instalar componentes opcionales de Windows"

2) En el Panel de control, seleccionar la opción de "Agregar o quitar programas" y en la ventana que sale, pulsar sobre el icono de la izquierda marcado como "Seleccionar o quitar componentes de Windows".

Ahora nos muestra la ventana para seleccionar los componentes adicionales de Windows que hay disponibles. En la lista, marcamos la opción "Servicios de Internet Information Server (IIS)". Por defecto se seleccionan unos cuantos componentes, dentro de los que ofrece la instalación de IIS. Nosotros podemos elegir qué componentes deseamos instalar apretando el botón marcado como "Detalles". Entre los componentes posibles se encuentran las extensiones de Frontpage, documentación, servicios adicionales de IIS, un servidor de FTP (para la transferencia de ficheros con el servidor por FTP), incluso uno de SMTP (para el envío de correos electrónicos).

Si no sabemos qué componentes instalar podemos dejar las opciones como aparecen en un principio, pues para la mayoría de los casos serán válidas. Sólo un detalle: puede ser adecuado no instalar las extensiones de Frontpage en caso de que no pensemos que se vayan a utilizar.

Una vez hemos instalado los componentes deseados, podemos y apretar el botón de "Siguiente" para comenzar la instalación, que se alargará unos minutos.

Acceder al servidor web

Podemos acceder al servidor web para comprobar si se ha instalado correctamente IIS. Para ello simplemente debemos escribir http://localhost en Internet Explorer y debería aparecer una página web informando que IIS está correctamente instalado. Además, aparecerá la documentación de IIS en una ventana emergente, si es que fue instalada.

La verdad es más sencillo de lo que parece. Espero les sea útil.

Recurso original: Primeros pasos para la instalación de IIS en WinXP-Professional Edition.

También podría serte útil "IIS Admin Service -> Configuración de la Recuperación de Servicios"

Software Testing Advice for Novice Testers

Algunos me han preguntado que cosas tener en cuenta cuando se es un principiante en materia de Testing del Software. Mis respuestas particulares ya las di­, pero en viajes por Internet encontre un interesante sitio y un arti­culo muy bueno para tener en cuenta, aun cuando se es un experto.
Algunos conceptos solo son posibles de entender cuando los has vivido.

Software Testing Advice for Novice Testers

Próxima compra de servicios de desarrollo. El tamaño no importa…

Según tu experiencia como comprador de servicios de desarrollo de software, ¿te sientes satisfecho o aún estás intentando decidir con cual otro proveedor reemplazar los servicios actuales?

Pero en esta oportunidad ¿indagarás sobre aspectos internos del proveedor o volverás a limitarte a las cuestiones contractuales y de costos?

Algunos de los profesionales con los que he conversado en este sentido me han indicado que en el 90% de los casos basta con entregar las funcionalidades principales dentro de unos límites de tiempo, costos y calidad. Inclusive dejando una gran deuda de funcionalidad, los clientes desean evitar confrontaciones y amplian sobradamente los tiempos, habilitan un incremento del presupuesto y son los que por lo general absorven los costos.

Esto quizás solo es la consecuencia de los síntomas enquistados en la mayoría de los proveedores de desarrollo de software, normalmente PyMEs.

Pero “no hay peor ciego que el que no quiere ver” y si tu gestión de proveedores es buena, no puedes evitar indagar profundamente sobre algunos aspectos que influyen no solo en la calidad de tus productos solicitados, sino en la calidad de los proyectos que compras. Ten en cuenta que en definitiva, lo que compras es un proceso de desarrollo y una gestión que afecta a personas y sería muy bueno que tu proveedor pudiera acreditar calidad en la vida de las personas al ejecutar proyectos para tus productos.

Estas son algunas de mis sugerencias sobre ítems a exigir a tus proveedores:

• Metodologías de desarrollo
• Existencia de técnicas de integración continua
• Patrones de desarrollo
• Procedimientos de pruebas unitarias
• Repositorio, seguridad de datos y respaldo
• Procedimientos de Testing por terceros (Independencia de QA)
• Pruebas de rendimiento
• Pruebas de funcionalidad
• Pruebas de usabilidad
• Pruebas de aceptación
• Gestión de defectos y métricas
• Gestión de proyectos
• Gestión de documentación en entornos colaborativos
• Entorno de trabajo y estilos de liderazgo

Parece exagerado? solo piensa que una empresa que no invierte en estos aspectos, no invierte en la calidad de sus servicios y si logras un producto de calidad, seguramente el proyecto habrá sido de una calidad dudosa o pésima y quienes sufren el impacto son los recursos humanos.

La proxima compra de servicios de desarrollo de software, hazlo con una empresa seria. No importa su tamaño.

Testing Unitario y Automatizado (lecturas recomendadas)

A pedido tuyo amigo mío (Jorge Luís Giménez) ahora que el testing te está exigiendo más conocimientos y reconoces que la calidad del software no es un aspecto que deba ser atendida solo por programadores.
Estos enlaces que te paso son solo el principio. Que bueno sería que pronto nos expliques cosas que aprendiste.
En el mundo somos muchos que buscamos algún tipo de soporte y esto suele no estar al alcance de la mano o no es muy barato que digamos.

Lectura recomendada:
Unit Test Patterns
Advanced Unit Testing, Part I – Overview
Advanced Unit Testing, Part II – Core Implementation
Advanced Unit Testing, Part III – Testing Processes
Advanced Unit Testing, Part IV – Fixture Setup/Teardown, Test Repetition, And Performance Tests
Advanced Unit Testing, Part V – Unit Test Patterns
http://mbunit.tigris.org

Aplicaciones recomendadas para Unit Test Automation :
CSUnit, NUnit, JUnit

Herramienta de diseño de Pruebas Unitarias
MbUnit

Al rescate del 60%

Recientemente leí un artículo interesante en la versión digital de La Nación, el cual en su marco principal trata sobre “qué hacer y cómo tratar a las nuevas generaciones de empleados que nacieron entre 1981 y 2000, y que traen en su ADN una nueva manera de insertarse en el mundo del trabajo”. En este artículo me interesó un concepto particular y es que según estudios recientes, se determinó que el 60% de la fuerza laboral estaría representado por empleados desmotivados cuyo aporte es el mínimo indispensable para la organización y que en lugar de hacer un aporte efectivo estarían generando pérdidas.

Esto me llevó a reflexionar sobre mi participación en distintas empresas de Argentinas y de las cuales finalmente me desvinculé, principalmente por cuestiones de motivación y una falta de misión y compromiso de tales empresas con su empleados, o por el parcialismo que representó su accionar.

Más de una vez me pregunté que ocurre con aquellas personas que por sus características personales y capacidades profesionales o adecuaciones realizadas de su aprendizaje, fueron seleccionadas para pertenecer a un equipo de trabajo para el cual se le brinda inicialmente una apertura y participación amplia, pero con el correr del tiempo, proyecto a proyecto la resultante es un un aporte operativo básico, carente de participación en opinión analítica, crítica constructiva y pensamiento diferenciado.

Creo que las insistentes “conversaciones en pasillos” entre empleados, sobre las malas políticas de RRHH, sueldos bajos, falta de capacitación o el exceso de las mismas, más la poca o nada de relación esfuerzo/compensación, en realidad tienen mucho más que ver con la falta de participación y opinión que se le ofrece a los empleados, que con los ítems negativos.

Es allí donde veo la falta de preparación de las diferentes líneas gerenciales y jefaturas, quienes manifiestan a las claras su falta de liderazgo al no saber declarar una misión, transmitir la visión, conseguir el compromiso y motivar para el cumplimiento de los objetivos.

Creo que gran parte de ese 60% de empleados desmotivados fueron finalmente empujados a esa actitud nociva y destructiva. Es posible que de alguna manera su accionar sea un acto de ajusticiamiento y revancha.

No se debe “tirar a la hoguera” a un soldado que aún vivo huye, sino rescatarlo, curarlo, re reclutarlo y aliarlo bajo un nuevo compromiso. Es importante considerar que, si como líderes y organización no estamos listo para “el rescate”, nuestra vida laboral también será complicada y en camino hacia un valle de desánimo, con un tendal de gente que “no trabaja motivada” y otros que poco a poco planifican su huida.

“Exploratory testing is simultaneous learning, test design, and test execution”

Esta hermosa frase me leventó el ánimo luego de haber ejecutado en forma manual una secuencia de TestCases diseñados en Testlink (una buena herramienta open source). Durante la ejecución no hice más que salirme de los caminos planificados e intentar alternativas que por mi intuición, sabía generarían un fallo.
Lo gracioso del asunto es que ciertamente, cada vez que me salía del plan, detectaba alguna anomalía y comencé a dudar del diseño de TestCases.
Esto tiene cierta lógica, ya que quien diseña un plan de prueba, naturalmente tiende al enfoque conservador orientado a la comprobación del correcto funcionamiento del software, similar a la postura del desarrollador y poco orientado a la “destrucción creativa” que propone un buen testing. Esta actitud nos propone diseñar pruebas en las cercanías de “el camino feliz” y respondiendo al juego de datos que normalmente haría que la aplicación tuviera un desempeño natural y eficiente.
Un enfoque de “destrucción creativa” basado en técnicas exploratorias, podría incluir un juego de datos poco convencional y alternativas de uso no contempladas, ni aún en los planes de testing más abultados.
La debilidad se centra en la mentalidad del diseñador y no en las técnicas formales de registración, que en definitiva solo son un soporte para un proceso repetitivo.
A su vez surgen otros problemas cuando un incorrecto diseño rige el proceso de testing:

. Uno podría ser la merma de creatividad en el acto de ejecución, con su consecuente pérdida de enfoque para la detección de fallos y aumento del enfoque que busca la confirmación del funcionamiento del sistema o aplicación. Aunque garantizo la posibilidad de repetir los casos tantas veces como se desee y aún teniendo la facultad de ampliar el diseño original, si el diseño original es trivial, mal enfocado o demasiado restrictivo, las ampliaciones solo serán una ampliación del error.
. Otro surge cuando se manifiestan los desvío en las ejecuciones de modo tal que una técnica aleatoria se presentan sin consenso y aumenta el riesgo de desviación de los tiempos de ejecución del plan. Aunque pueda detectar mayor cantidad de defectos, se pone en riesgo la naturaleza de los objetivos centrales del plan, la repetitividad y la rastreabilidad. Adiciono también la aparición de la necesidad de análisis por cada defectos detectado, por el solo hecho de explicar el contexto de detección donde se manifiesta el fallo.
En ambos casos la cobertura corre el mayor de los riesgos.
Este enfoque se presenta con tanta frecuencia en planes convencionales que aquí es donde propongo la creación de planes que permitan la aplicación de técnicas exploratorias.
Antes que nada tengamos en cuenta que las técnicas exploratorias, se caracterizan por ser unscripted e improvisadas, por lo que no es posible que cualquiera de los recursos afectados al testing pueda beneficiarse de este contexto, sino aquellos que tienen amplia experiencia en el aprendizaje, una gran intuición y gobiernan el contexto general del sistema y los negocios afectados.
Particularmente, solo me he permitido utilizar testing exploratorio en casos donde tengo la garantía de otros colaboradores ejecutando “testing tradicional” y me asigno tiempo en los planes, para actuar como un satélite que ejecuta “pruebas libres” como motor de ampliación de los caminos diseñados en los planes.
Muchos me han dicho que la ejecución del testing de manera exploratoria la puede ejecutar cualquiera, pero lo interesante es cuando se puede explicar el contexto y el modo de ejecución lo más detalladamente posible. Conseguir que lo intangible se transforme en tangible con solo la explicación verbal, excluye a la mayoría de los testers y managers.
Por esto mismo pienso que lo ideal es cuando se logra pasar a un punto donde las técnicas de diseño tradicional se mezclan con las bases del testing exploratorio y aun cuando ambas parezcan contradictorias, en realidad lo que se establece es un “juego de expectativas” que solo nos indica que tipo de trabajo debemos hacer y como se debe registrar, pero no da más detalles que solo aquellos que proveen la garantía de un excelente marco para el diseño.
Como manager de testing, siempre he querido ser quien más conoce de cada producto, sus características y sus comportamientos, pero no estár restringido a caminos normales y alternativos diseñados en base a otra documentación. Como tester, siempre tuve la intención de ser limpio en mis ejecuciones y facilitar la registración de nuevos caminos posibles. La ambiguedad esta presente en todo pero hay que saber lidiar con ella.
Creo que esta metodología es ideal, pues propone agilidad y creatividad, sin la pérdida de exactitud, repetición y rastreo.

http://www.satisfice.com/sbtm/

Office development Software more adecuate than Software Factory

Mientras que los procesos manufactureros se concentran en los procesos, los procesos de desarrollo de software suelen estar centradas en las personas. Es por eso que tal vez  los ahorros y los beneficios que se producen en la industria del software debido a la mejora del proceso de actividades, no son realmente importantes.
Por ejemplo, parte del proceso SIX-SIGMA consiste en identificar la causa raíz de los problemas y luego encontrar y aplicar una solución. Un requisito para lograr la mayor efectividad del proceso, es que las operaciones sean repetitivas.
Procesos como SIX-SIGMA son principalmente aplicables a industrias donde las operaciones y las actividades son prácticamente idénticos y repetitivas, mientras que quizás esta característica no existente en los procesos de desarrollo de software.
No hay que ser drásticos ni decir que SIX-SIGMA no es aplicable a los procesos de desarrollo de software, pero si es posible decir y comprobar que su aplicación no mejorará sustancialmente los beneficios como lo puede hacer en la industria manufacturera.

Algunas diferencias entre estas dos industrias son:

1 – en Manufacturing, cada producto de la serie tiende a ser idéntico a un modelo específico. En el desarrollo de software cada producto es personalizado (de otra manera no hay nada que desarrollar)
2 – en Manufacturing, para cada operación el proceso es idéntico, mientras que en el desarrollo del software varían en términos de contenidos.
3 -  en Manufacturing, los trabajadores ejecutan su trabajo en niveles muy parejo de efectividad, mientras que en desarrollo de software las habilidades varían ampliamente, como también los niveles de calidad y efectividad.

De esta manera es facil observar que las actividades implementadas para mejorar un proceso específico o resolver un problema de desarrollo de software, pueden no ser válidos para otro de la misma empresa. También el grado de éxito cada proyecto es siempre diferente.

Se puede concluir que en el proceso de desarrollo de software existe una variabilidad por la componente humana, que introduce grandes cantidades de errores que necesariamente escaparán a cualquier control. Esto evita en gran medida la obtención de procesos de consistencia hermética.

Entonces tal vez deberíamos modificar el término Software Factory evitando hacer un parangón con los procesos de fabricación manufacturera y pasar a un término más acorde, como puede ser “Office Software”. De esta forma también se delimita la forma en que cada una de estas industrias utiliza sus recursos y habilidades.

Twiter y el spam nuestro de cada día.

Twiter spam!!! así es cada día tengo en mi cuenta Twiter una lluvia de followers que finalmente son cuentas que redireccionan a alguna página comercial. Muchas veces ni puedo bloquearlas y pronto, como me sucedión con hotmail en alguna oportunidad, tendré que clausurar mi cuenta y abrir otra, o dejar de usar el servicio.
Espero que Twiter haga algo en contra de esto.

Maldito MySpace. Gasté una hora de mi tiempo en editar lo que considero un “post inspirado” y al intentar insertar una imagen de mis archivos, la ventana de edición refrescó y perdí todo lo que escribí sin una posibilidad de recuperación.
MySpace incorporó algunas funciones de vinculación con Skype y también es posible utilizar email, juegos, twiter y otras aplicaciones más, simil facebook. Pero no controla una maldita ventana de edición para que uno pueda bloguear.

Las aplicaciones Open Source están en la mira de las empresas emergente de todo el mundo. Son potentes, no implican un esfuerzo de construcción, hay una gran comunidad que soporta a los distintos proyectos, son relativamente fáciles de instalar y progresan rápidamente. Pueden ser integradas a otras aplicaciones tanto open source como propietarias y también es posible contar con su código para modificarlo de acuerdo a las necesidades.
Actualmente cuentan con una gran aceptación y en muchos casos, sirve para orientar mejor a los gerentes y propietarios de las organizaciones al respecto de sus verdaderas necesidades, las cuales en realidad podrían estar poco claras.
Así mismo, es posible que una o varias personas investiguen las mejores herramientas bajo los requerimientos de la gerencia y dado la facilidad de obtención y uso de esas herramientas, “saltar” de una aplicación a otra para compararlas.
Es posible que la mejor solución Open Source no sea gratuita, pero los costos son irrisorios en comparación con soluciones propietarias y el respaldo sigue siendo potente, eficiente y barato.

E-books. Recuros gratuitos de lectura técnica.

Excelente sitio con recursos gratuitos para lectura técnica.

El lado oscuro (reglas básicas para hacer fracasar tu proyecto)

Rescaté este interesante hilo de discución existente en XING.
Lo traigo a mi blog más que nada para poder recordar en cualquier momento, todo aquello que pensé y aún hoy sostengo. También para disfrutar del sarcazmo de mis colegas:

Juan Carlos
Esta resumen detalla las malas practicas que se pueden aplicar a un proyecto de manera que ni el coste ni la calidad sean aceptables. Obviamente la lectura debe hacerse con tono sarcastico.

La garantía es completa. Siguiendo minuciosamente mi plan será imposible que vuestro proyecto se ajuste a las necesidades de presupuesto, calidad o plazos. Este manual de malas prácticas consta de los siguientes apartados:
- Relación con el cliente. Tenemos dos alternativas de trato para fracasar estrepitosamente. La primera es tratar al cliente de ESTUPIDO y la segunda creer que es DIOS y poseedor de la verdad absoluta. Ambas nos harán profundamente desgraciados y nuestros proyectos subirán en coste.
- Especificaciones funcionales. Tenemos tres alternativas: No escribirlas nunca, escribirlas al final o en el otro extremo detallar hasta el último detalle más insignificante.
- Planificación del proyecto. Para cumplir nuestros objetivos es mejor no planificar. Es más, cuando alguien pregunte sobre el tema disimilemos y hablemos de otra cosa. Como si no hubiera dicho nada. Cuando alguien de la tenga prisa ya correremos.
- Arquitectura y diseño. ¡!Que nadie pierda su tiempo con esto por dios!! Esta actividad puede generar grandes beneficios que revertirán en el coste, no solo del proyecto en curso si también de otros. Una actividad a evitar siempre que sea posible.
- Revisiones. Cuantas menos mejor. Todo el mundo debe ser capaz de hacer las cosas mal a la primera. No necesitamos que nadie empeore nuestro trabajo.
- Análisis Estático y Estándares de codificación. Esta actividad la podemos realizar completamente automatizada, siempre que no asignemos ningún responsable de supervisarlos ni ninguna actividad asociada. Así gastaremos dinero en una herramienta que no aportará beneficios.
- Pruebas unitarias. Aquí surgen otra vez dos opciones. Una es no hacerlas, claro, pero otra mejor es hacer development driven testing, es decir, escribir el código y luego los test unitarios que NO fallen.
- Integración continua. No hacerlo bajo ningún concepto. Es una actividad muy rentable. Mejor esperar al final del proyecto, juntarlo todo y disfrutar de los fuegos artificiales (pum, pom, plas, runtime,…)
- Test funcional. Solo hay una cosa mejor que no hacerlo. Hacerlo después de entregar la versión y luego ignorar los defectos que se encuentren ya que el cliente no los ha visto (aún). A ser posible no decirle nunca al equipo del test las nuevas funcionalidades y en caso de que nos fuercen a ello hacerlo en las relase notes (o lo más tarde posible).
- Mantenimiento. Poner a un becario a mantener todo el código si es que después de todo conseguimos llegar hasta aquí.

Esta presentación tiene como objetivo defender las buenas practicas desde la perspectiva del absurdo. Algunas de las exageraciones comentadas nos parecerán un disparate, pero nos harán reflexionar sobre nuestras actuaciones, decisiones o planificación de los proyectos y sobre todo incidir en los costes que resultan de aplicar las malas prácticas y como la calidad ayuda a reducirlos.

José
Enhorabuena Juan Carlos, se lo pasaré a mi jefe de proyecto, a ver si lo aplica del todo (le faltan sólo un par de puntos para conseguir aplicarlo enteramente)
P.S.
Especialmente bueno el término “development driven testing”. ¡¡¡Como la vida misma!!!

Oscar
Una aportación al “manual del buen desarrollador” de Juan:
Los requerimientos:
Al igual que los clientes, los requerimientos son casi una leyenda. Pocos los han visto, y quienes los han visto o han resultado con una sicosis post traumática por ello o no los han entendido. Preventivamente, usted evítelos todo lo que sea posible.
Recuerde siempre que el único requerimiento que siempre se cumple es el que no se escribe (a esto los matemáticos le llaman prueba por vacuidad).
Si su cliente es uno de esos necios que insiste en escribir requerimientos, no se espante, igual puede conjurar a esas quimeras.
Primero, léase un par de leyes para que entienda lo que quiere decir “decir mucho sin decir nada”. Ya con el estilo jurídico en la cabeza, póngase a escribir un tratado kilométrico sobre la funcionalidad del software poniendo mucho cuidado en que no quede claro ni de qué software está hablando ni cuál es la tan mencionada funcionalidad. Use palabras técnicas, términos en inglés, nombres de archivos y bibliotecas, palabras inventadas y uno que otro periplo en pseudocódigo.
Haga uso de diagramas complicados en un UML muy personalizado, así, si el cliente tiene la desgracia de entender UML, usted puede presentarse como un reformador y modernizador del UML.

Un tip básico es:
Nunca use términos de dominio, son confusos. Por ejemplo, a los usuarios puede llamarles “userEntity”, o mejor aún, desaparézcalos y hable de “userName” y “userModuleAPermision”. Puede decir algo como:
[...]
Un userName especificado puede estar linkeado con un userModuleAPermision que indicará de manera especializada un comportamiento del sistema en cuanto al usuario asociado al userName en cierto módulo del mismo.
[...]
Escribir requerimientos de este modo es casi un arte, por eso existe gente que presta sus servicios como analistas de requerimientos, tanto para interpretarlos a conveniencia como para escribirlos.

Javier
Cuan importante es valorizar nuestra actividad individual para reconocer el esfuerzo grupal y sentir orgullo de lo que hacemos. Tan simple como entender que no se puede improvisar o mejor dicho, no se debe, pues de poder siempre se pudo y se hizo:

“La garantía es completa” y “Relación con el cliente”Esta frase me recuerda a cuando fui vendedor de seguros de retiro. La muletilla era “te lo pudo garantizar, decime a donde firmo. Pero mi firma va con la tuya”. Fantásitica técnica de venta agresiva, donde lo único que no va es la firma del vendedor.
¿El cliente esta interesado realmente en las garantías o en los problemas que provocan los incumplimientos de las garantías? Personalmente opino que lo segundo. Si estuviera interesado en las garantías, sería el principal conocedor de nuestro proceso y el mejor crítico. Y pensar que desde un principio los proyectos tienen una alta garantía de fracaso!!!.
Recuerdo que algunos expresaron una envidia sana cuando en un hilo de Neurona expuse “Capacitar al cliente para …” . Algunos dijeron que era imposible contar con un cliente maduro. Solo expreso hoy que si tenemos un cliente al que podemo tildar de ignorante, estúpido, o simplemente inmaduro, quiere decir que nuestro proceso tiene muchos elementos que alimentan esa condición especial de nuestro cliente y la sostienen. También sugiero que estos tildes son puestos por los sectores operativos que se contraponen a la visión del cliente como un dios.
Por otro lado si nuestro cliente es “dios”, estoy seguro de que estamos hablando de una condición impuesta por nuestros superiores, nuestros comerciales o ambos y suelen ser un factor de presión al nivel operativo, principalmente a los Líderes de Proyectos y/o Analístas de Requerimientos o Funcionales, quienes expondrán las limitaciones de los requerimientos, del dominio del sistema y del negocio y en primeras instancias mostrarán las dificultades que serán inmediatamente tildadas de “visionarios de incendios y muertos en la puerta de un hospital” o de “solicitantes del postre cuando no se sabe ni comer”.
La mayoría de las veces puede darse que los costes ya están definidos y las variaciones sean mínimas o no significativas, pero el esfuerzo de comunicación, entendimiento y satisfacción serán absolutamente diferentes, según la madurés del cliente.

>”Especificaciones funcionales”
Este punto es casi para discutir de procesos y metodologías. Agile o RUP, RUP Agile, algún pseudo proceso a modo de proceso propio basado en….
No escribirlas me parece la peor opción. Sucede? si, todo el tiempo en mayor o menor escala, en proyectos, en defectos o incidentes, en mesa de ayuda o soporte. Siempre algo falta y en algún momento se necesita esa información.
Lo interesante de cualquiero proceso o metodología o combinación, es como construimos y administramos nuestra base de conocimientos.

>”Arquitectura y diseño”
Realmente dificil provocar la existencia de estos artefactos. Lo prácticamete imposible es hacer entender a La Gerencia lo importante de esta actividad y demostrar los beneficios fuera del proyecto, cuando estamos en fases de Garantías, justo cuando el cliente comienza a solicitar cambios significativos. Cómo explicarle a los niveles superiores que esos artefactos se deben considerar si o si en la presupuestación pues restarle arquitectura y/o diseño a un sistema es restarle FLEXIBILIDAD, ESTABILIDAD, ESCALABILIDAD y también merman los CRITERIOS DE SATISFACCIÓN AL CLIENTE.

>”Revisiones” (Evitar revisiones, “nunca lo hice ni lo volveré a hacer”)
En mi vida como profesional SQA, he sido partícipe necesario de los recortes de procesos por demanda de La Gerencia y me he sentido víctima, victimario e indiferente ante esta situación.
Al principio sentí la impotencia de la víctima de quien debe cumplir un rol, una función y no tiene el marco necesario. Este mismo modo me vinculó con el rol de Victimario, pues así me he sentido al ser complice sin otras chances más que la de expresar con cierta peligrosidad mi desacuerdo. Hasta sentí el impulso de renunciar. Y finalmente mi instinto de supervivencia me hizo volverme indiferente aunque más no fuera de manera temporal, pues mi naturaleza me impide cambiar la vista a otro lugar cuando tengo una importante obligación.
Hacer las cosas bien a la primera. Bueno, no es una locura y mucha gente pionera en Ágile explica el por qué. Pero sin ser Ágilista, siguiendo un modelo en V, cuanto antes se haga mejor, doblemente mejor para las fases de revisión, exponencialmente mejor para el proceso, el producto, la empresa.

>”Pruebas unitarias”
Como lo explicaron en otro hilo de discución, debe existir un justo balance entre Testing Unitario, Testing de Integración y Pruebas de Sistemas. Lo que le hace mal a todas estas actividades es la falta de planificación, no contar con el tiempo de dedicación necesario y no atesorar la experiencia dejándo de lado las métricas, lecciones aprendidas y otros elementos que puedan ayudarnos a mejorar para próximos proyectos.

>”Integración continua”.
Integrar los componentes en iteraciones cortas suele dar resultados muy favorable para ejecutar testing en ciclos más contínuos, aún sin haber logrado efectivizar técnicas formales de Integración contínua.

>”Test funcional”
Quien no ha sufrido la entrega forzada de un producto no ha conocido la presión de esta industria particular.
En algunas ocaciones la estrategía ha sido no notificar a Calidad del despliegue del sistema en producción, luego de meses el cliente encuentra fallos de gravedad importante y “se tira la bomba a Calidad con una mecha encendida”, situación ante la cual solo sirve tener una gran conciencia o rastreabildad de lo que sufrió el proceso de calidad o morir callado asumiendo que el estallido puede costar muy caro.
Yo prefiero rastreabilidad antes que conciencia, pero necesito de las dos cosas.

>”Mantenimiento”.
No opino sobre este concepto pues al considerarlo de gran importancia y relacionarlo con los acuerdos de servicios, entonces prefiero que se abra un nuevo hilo de discusión al respecto.

En un nuevo posteo me uniré al sarcazmo.

Juan Carlos
¿El cliente esta interesado realmente en las garantías o en los problemas que provocan los incumplimientos de las garantías?
Supongo que dependerá del cliente, pero me cuesta imaginar un cliente que quiera que su proyecto se ponga en riesgo a no ser que tenga algún tipo de razón maliciosa. Normalmente el cliente lo que quiere es pagar menos por más y eso es común a todos los compradores. Otra cosa es que la cesión comercial sea siempre a costa de la calidad o falta de funcionalidad encubierta (se le dice al cliente que si cuando sobradamente se sabe que no va a ser a si).

…nuestro proceso tiene muchos elementos que alimentan esa condición especial de nuestro cliente y la sostienen…
Más que nuestro proceso yo diría que se alimentan desde una posición de competencia feroz y a veces poco profesional que hace difícil competir diciendo la verdad (y si, ya se lo del largo plazo, pero dilo cuando presentas la cuenta de resultados….)

…Arquitectura y diseño
Realmente difícil provocar la existencia de estos artefactos
No es necesario un detalle impresionante, pero un mínimo de planteamiento se debe hacer, al menos si el proyecto tiene un tamaño considerable y sobre todo si es una plataforma nueva o un desarrollo nuevo completamente.

…Pero sin ser Ágilista, siguiendo un modelo en V, cuanto antes se haga mejor, doblemente mejor para las fases de revisión, exponencialmente mejor para el proceso, el producto, la empresa.
Completamente de acuerdo. Cuanto antes se detecte el problema mejor.

…Yo prefiero rastreabilidad antes que conciencia, pero necesito de las dos cosas
La trazabilidad es mi seguro de vida. El avisar de los riesgos de la no ejecución de determinados procesos es nuestro deber, pero la decisión de asumirlos no. Puedo entender que si el producto no está disponible hoy, se llega tarde al mercado. No somos los guardianes de la calidad, sino que ayudamos a tomar decisiones respecto a calidad del producto.

El sarcasmo ayuda a digerir y tomarse con humor las situaciones más complejas.

Javier
¿El cliente esta interesado realmente en las garantías o en los problemas que provocan los incumplimientos de las garantías?
Supongo que dependerá del cliente, pero me cuesta imaginar un cliente que quiera que su proyecto se ponga en riesgo a no ser que tenga algún tipo de razón maliciosa. Normalmente el cliente lo que quiere es pagar menos por más y eso es común a todos los compradores. Otra cosa es que la cesión comercial sea siempre a costa de la calidad o falta de funcionalidad encubierta (se le dice al cliente que si cuando sobradamente se sabe que no va a ser a si).

Juan Carlos, ¿El cliente puede expresar que quiere evitar todos los riesgos posibles en su proyecto y no interesarse en tu proceso? ¿o evitar su involucramiento tan solo para sentarse a esperar desde una postura rigurosa de “ya pactamos los términos del contrato ahora quiero que cumplas en tiempo y forma”?.
Siendo esta situación posible, como proveedores ¿no adoptaremos todos los recuados necesarios para controlar todos los riesgos posibles y cumplir en tiempo y en forma? si respondemos que si a esta última pregunta, ¿podemos hablar de proyectos con pocos elementos de control en los procesos o en los que se sacrifique alguna parte de el, por ejemplo la calidad? ¿Podemos realmente ser rentables para nuestra organización y para el cliente si entregamos “encubiertamente” funcionalidad recortada? ¿Podemos seguir adoptando proyectos mal definidos y trabajar contra End_Lines mentirosos?

…nuestro proceso tiene muchos elementos que alimentan esa condición especial de nuestro cliente y la sostienen…
Más que nuestro proceso yo diría que se alimentan desde una posición de competencia feroz y a veces poco profesional que hace difícil competir diciendo la verdad (y si, ya se lo del largo plazo, pero dilo cuando presentas la cuenta de resultados….)
Juan Carlos, yo sugiero que busquemos clientes mejores, no los que solo pretenden el engaño de “pagar menos por más”.
Un cliente que aprecie la calidad será el que nos haga ganar dinero a grandes escalas, no solo por que nos pagará lo que valemos, sino que nos recomendará, nunca nos abandonará y será nuestro aliado para mejorar nuestros procesos y nos hará verdaderamente competitivos. Si somos fieles a nosotros mismos y trabajamos con lealtad, permaneceremos y trascenderemos.

Arquitectura y diseño
Realmente difícil provocar la existencia de estos artefactos
Juan Carlos, los procesos agilistas no desdeñan estos artefactos y cuando más agilista pretenden ser, más lo incorporan, aunque a su modo. Lo interesante es generarlos en el momento en que deben aparecer. Son la base para nuestros SLA y la garantía para lo que el mercado exige tan competitivamente, la evolución.

Pero sin ser Ágilista, siguiendo un modelo en V, cuanto antes se haga mejor, doblemente mejor para las fases de revisión, exponencialmente mejor para el proceso, el producto, la empresa.
Completamente de acuerdo. Cuanto antes se detecte el problema mejor.
Juan Carlos, estoy plenamente de acuerdo con vos en estos puntos.

El sarcasmo ayuda a digerir y tomarse con humor las situaciones más complejas.
Juan Carlos, también me pongo de acuerdo con vos en tomarse las cosas con humor.

Extraido de XING

Oportunidad en Córdoba – búsqueda de perfiles Líderes de Proyecto, Arquitecto de Sistemas, Analistas Funcionales, Developers, QA y Testers

Empresa de servicios Off-Shore radicada en Córdoba invita a Líderes de Proyecto, Arquitecto de Sistemas, Analistas Funcionales, Developers, QA y Testers a enviarnos su CV como primera medida de contacto.

Por favor indiquen en el asunto del email la referencia correspondiente:

• LP (Líder de Proyecto)
• ARS (Arquitecto de Sistemas)
• AF (Analista Funcional)
• DEV (Developers)
• QA (Aseguramiento de Calidad y Mejora de Procesos)
• TST (Tester de aplicaciones)

Se admiten postulaciones a otros cargos relacionados con TI, Servicios Informáticos y Desarrollo de Software, que no hayan sido mencionados aquí mismo.

Consultoras de Servicios IT en Latinoamércia: “prestadores de verdaderas soluciones para clientes reales?

En esta época de globalización generalizada, donde las barreras geográficas y tecnológicas no son un impedimento, los prestadores de servicios profesionales latinoamericano estamos iniciando un nuevo camino en el que debemos aprender a posicionarnos.

Las potencias económicas que antes consumían los servicios y recursos humanos de países como India e Israel, casi en forma exclusiva, han comenzado a mirar hacia Latinoamérica con mayor énfasis que nunca.

Argentina es uno de los países que dice estar a la vanguardia de prestación de servicios Offshore y Nearshore (nuevos término post Out Sourcing), quizás por algunos factores externos, más que por sus reales capacidades.

India presentó un modelo interesante de trabajo para los norteamericanos y los europeos, al demostrar que por años se han estado preparando para dar servicios exclusivamente a ese mercado demandante. Los niños son educados en el idioma inglés y las especializaciones técnicas son dictadas en forma gratuita en prácticamente todo el país.

Bajos costos en la mano de obra y respuestas aceptable con habilidades técnicas probadas, convierten al mercado indio en un atractivo singular para las empresas del primer mundo.
El soporte de este modelo esta garantizado por una situación coyuntural, donde la población India supera los 90 millones de personas donde la mayoría intenta emerger de la pobreza, más el adicional de los aspectos mencionados antes.

Otro modelo presente en el mundo, pero a mi entender diametralmente distinto, es el isralelita, el cual pareciera ser una suerte de clonación del modelo norteamericano.
Este mercado de prestación de servicios se expande a todo el abanico posible, logrando ser más amplio que el conjunto de servicios hindú.
Las capacidades técnicas y de resolución de problemas de los israelitas en distintos ámbitos (no solo IT y servicios informáticos), es bien muy conocida en todo el mundo.
La cara de estas empresas está escondida detrás de las marquesinas que promueven sus servicios en los sitios con formatos totalmente “yankizados”. No hay forma de detectar una diferencia entre un proveedor norteamericano y uno israelita, sobre todo si no es necesario mencionar el origen de la prestadora.

Argentina se encuentra en la disyuntiva de definir un modelo útil de prestación de servicios al exterior, desde hace varios años ya, encontrándose en discusiones y comparaciones, justamente estos dos modelos mencionados.

Al igual que años atrás desde el noviciado, los hindúes e Israelitas comenzaron a dar servicios a los mercados del primer mundo, hoy nos toca “en carne propia” incursionar en esa empréstito y arrancar desde una posición demasiado poco madura y con capacidades más que limitadas para hacerlo con buenos grados de garantías internas.

Una enorme cantidad de individuos  y grupos de Argentina se han asociado en pos de esta “ola de servicios” (Outsourcing, Offshore, Nearshore), con la promesa de generar trabajo, ganar dinero y establecer relaciones duraderas con clientes del exterior.

Sin embargo hay factores que favorecen a una enorme volatilidad en dichas relaciones. Un  grupo de factores son de índole interna y tienen que ver con la falta de un verdadero apoyo por parte de los gobiernos, notándose la falta de capital destinado a este tipo de empresas, falta de asesoría y formación específica para entender y generar relaciones con el exterior y el establecimiento de un formato específico para ser competitivos “sin relegar precio” y generando valor en forma bilateral. Por supuesto los mecanismos de protección a los operarios empleados, pueden ser fácilmente sorteados.

Sin duda esta es una oportunidad de oro, pero hay que tener cuidado por que “no todo lo que brilla es oro”.
Este actor primario proveniente del exterior está comenzando a manifestar algunas restricciones importantes luego de la “crisis económica de 2009″. Un síntoma claro, es que hoy muestra su capacidad de permanecer en una puja sin cuartel para ganar a su favor un precio por una diferencia de U$D300 ó menos, quizás destinado a un recurso humano.
Otra restricción es que sus proyectos en realidad podrían no ser para satisfacer una necesidad propia, sino que ellos mismos están siendo terceros para la satisfacción de un cliente más importante en la pirámide. Entonces comienza una cadena de tercerización de tercerizaciones, la cual aprieta a los que se encuentran al final de la cadena de cobro, es decir al principio de la cadena operativa.

Es posible que estemos siendo proveedores de individuos y grupos conformados con el mismo propósito que el nuestro y que tienen la capacidad de destinar algunos capitales pequeños para tercerizar un trabajo que les ha sido confiado a ellos.

Creo también que podríamos estar siendo utilizados para pujas de precios y ya he podido ver pujas entre proveedores de Buenos Aires y Córdoba para un mismo cliente de EEUU.

Es muy fácil para nosotros desconocer a donde está “el brazo del río con la veta de oro” y cual es el que solo deja residuos.

Por otro lado aquí mismo pareciera ser mejor establecer un  “gran pasamanos  de RRHH freelance”, en lugar de conformar empresas que realmente cuenten con sus propios recursos, de infraestructura y humanos, manifestándose prestadores de verdaderas soluciones para clientes reales.
Para esto, hay que asumir riesgos, inclusive si nuestro cliente no nos habilita plenamente los recursos para proyectos en fases iniciales. Es decir que suena más serio si logramos establecer nuestra organización antes de que los proyectos la requieran.

¿No nos han dicho siempre que debemos estar listos?

Es interesante entonces que nuestra postura general tenga un modelo consensuado, que nuestro modo de relaciones cuente con garantías para la protección de nuestros negocios e involucrados, basado quizás en condiciones  que nuestros clientes comprendan y acepten.

Es cierto que “el que tiene la joya pone las reglas”, pero estoy seguro que la joya no es el dinero sino el trabajo bien administrado y definido, con el adicional de la dedicación, la pasión y la energía que cada equipo le pone.  Si esta joya no es más importante que “la oportunidad de oro”, nada podrá ser ponderado adecuadamente.

Segundas Jornadas Latinoamericanas sobre METODOLOGÌAS AGILES

Profesionales relacionados al desarrollo del software, unidos por el objetivo de crear un espacio amplio de discusión sobre las metodologías Agiles y su adopción en América Latina, han organizado para el mes octubre de 2009 en Florianópolis, Brasil, las SEGUNDAS JORNADAS LATINOAMERICANAS SOBRE METODOLOGÍAS AGILES.

Están confirmadas las presencias de importantes figuras del medio como:

- “Brian Marick” (uno de los 17 visionarios que firmaron el Manifesto for Agile Software Development en el año 2001)

- “Diana Larsen” (co-autora del libro “Agile Retrospectives: Making Good Teams Great!” y co-fundadora de la conferencia Agile Open Northwest y del evento internacional Retrospective Facilitators Gathering)

- Entre otros referentes internacionales de la comunidad ágil, se contará con la participación de Matt Gelbwaks, Naresh Jain, Dave Nicolette y Joshua Kerievsky como invitados especiales.

La información oficial del evento está aquí

Sede: Rod Admar Gonzaga, 2765

Florianópolis – SC, 88034001, Brazil

View Larger Map

desde LinkedIn: Debate: ArgenTIna – Software y Servicios Informáticos.

El aprendizaje de un nuevo lenguaje

Están convencidos de que el aprendizaje de un nuevo lenguaje de programación aporta al aprendizaje de nuevos paradigmas?

Siempre entendí que un paradigma va más allá de un lenguaje en particular; es una representación que encierra problemas y soluciones con un enfoque particular.

Entiendo la necesidad de los programadores de aprender más lenguajes de programación y es válido si lo vemos como proponentes de soluciones técnicas útiles en los proyectos.
Entiendo que un arquitecto de sistemas debe poder comprender muy bien estos lenguajes que su equipo de desarrollo opera, sin embargo deberán darse cuenta que en otras capas de las organizaciones, otros analistas tienen otro dinamismo con la lingüística relativa a los ámbitos que les competen y también debe existir un nexo con estas personas que administran otros paradigmas.

El lenguaje de los negocios tiene su propia lingüística y así ocurre con cada capa que se presenta donde deba ser gestionada la transformación de las ideas.

Por lo tanto, pienso que los lenguajes de programación son solo los medios para hacer tangible lo abstracto de las ideas analizadas y puestas en un plano distinto al de su origen, de las cuales se espera un resultado utilizable. Sostengo también, que el aprendizaje de nuevos lenguajes no tienen relación con herramienta alguna, sino con la “lingüística conductiva” que trasciende a través de todo un equipo concluyendo en soluciones óptimas.

Contratos Agile Para Tus Clientes (1)

No se puede convencer a los clientes de que utilicen metodologías Agile, ellos por si mismo deben convenserse de que Agiles les es útil. Nuestro aporte es enseñarles a traves de hechos.

Video 1 – Introducción

Aspectos que rescato de esta exposición:

• No se puede decir que los clientes hacen mal su gestión de proyectos.
• Nuestro interés debe ser mejorar los resultados de los proyectos de nuestros clientes
• Nuestro interés debe ser crear diferencias en los procesos de trabajo de nuestros clientes para darles una ventaja competitiva
• Todo se puede mejorar según las metodologías de mejora continua

¿Los programadores quieren dejar de programar? o ¡A ver cuando me ascienden para dejar de programar!

Entre las muchas ideas que pudimos comentar en la reunión … salió un tema que resulta bastante habitual: Ingenieros que quieren dejar de hacer trabajo técnico. Dejar de programar para pasar a tareas comerciales, de consultoría o de gerencia.

El año pasado en una selección de personal (para programadores) un candidato afirmaba que su objetivo era ascender en la compañía, para dejar de programar y pasar a comercial o consultoría. Según sus palabras: “a puestos con mayor proyección”.

Algunos fragmentos extraídos de la entrevista:

“Un médico de 50 años es una eminencia y un programador de 50 años es un fracasado”

“No podemos negar que el salario, además de la reputación es muy importante”

“Efectivamente, el negocio del software en España funciona así” … “Acá en México la cosa no cambia”  (y por lo que vimos en la reunión de la semana pasada, en Chile pasa lo mismo)

“No hagan líderes de proyecto a sus mejores programadores, porque pierden a su mejor programador y ganan un pésimo líder de proyecto”

“Ser (buen) programador es duro. Muy duro”

“El mérito se lo llevan los comerciales y gerentes, y dentro de las empresas solo se valora a quien tenga contacto con el cliente, ya que es el que paga”

“No entiendo como a un ingeniero informático o a un técnico informático no le parece apasionante el mundo de la Programación de ordenadores. Nunca lo entenderé”.

“Me encanta programar, me apasiona. Es mi vida. Pero sabéis qué me ha sucedido? Mis jefes y superiores me han tratado mal”

esta es una lista que se extrae e inicia de ¡A ver cuando me ascienden para dejar de programar!

Luego de leer atentamente el hilo de discusión, quise ver como se desarrollan las opiniones de los programadores y mis conjeturas son las siguientes:

Como características diferenciadoras, pude observar que algunos reconocen la importancia de los distintos roles en una organización y se expresa que la inoperancia en la ejecución de estos roles esenciales perjudica con gran dolo al programador. Al expresarse aspectos negativos de otros roles y el impacto nocivo en los resultados de los programadores, se deja evidencia de que estos roles bien ejecutados bajo un proceso sinérgico tendrían el impacto contrario en el trabajo (…el de todos), es decir positivo.

En otros casos pareciera ser que para ser programador se necesita de capacidades extraordinarias, desestimando la importancia y aporte de otros roles y peor aún, de otro modelos y/o procesos de desarrollo distintos a los Agiles. De modo tal que se teje en la figura del programador, una suerte de omnipotencia.
Algunos solo admiten el trabajo entre pares y consideran que esto les da la cobertura de pensamiento, análisis y toma de decisión suficiente y necesaria para llevar adelante un trabajo ingenieril en materia de desarrollo de software.
La sugerencia en algún comentario, es de que solo se puede acceder a cargos de liderazgo o comercial, luego de haber transcurrido una carrera como programador en los productos que en la empresa existan.

Como características inclusivas, pude ver que el lenguaje general es de insatisfacción y crítica para el modelo y estilo de liderazgo difundido en las distintas empresas que agrupan a estos programadores, mostrándose fuertes sensaciones de injusticia e incomprensión de los mandos gerenciales y líderes.
Estos caracteres acentúan la necesidad de cambio de rol de algunos programadores, mostrando una necesidad de ser reconocidos en su micro entorno e “impartir justicia” con quienes ellos reconocen como “los más esforzados de toda la organización”.

También se habla del aspecto económico precarizado existente y la sensación de inequidad en relación a los esfuerzos que ejecutan distintos roles.

Algunos exigen acertadamente, la necesidad de procesos de trabajo bien conducidos, principalmente en la gestión de proyectos.

Algunos relatos demuestran la importancia de roles transversales, no para aliviar la carga de los programadores o de cualquier otro, sino para ejecutar una actividad ingenieril digna.

Por lo que puedo observar, lo que realmente falla es el estilo de liderazgo organizacional y la falta de comprensión y aplicación de un verdadero proceso de ingeniería, independientemente del modelo que lo rija.
Sucede que en todas partes del mundo se ahorra en gente, se ahorra en procesos, procedimientos y mejores prácticas y los resultados finales se traducen en mala calidad laboral y de vida. El recorte es una característica que se reconoce en todos los casos de fracaso en los proyectos, pero sucede así por que se recorta sin criterio y con total arbitrariedad y luego se estandariza el proceso dejándolo estático, en lugar de adaptarlo para cada proyecto.
Por otro lado, esta sensación de insatisfacción generalizada se presenta aún en personas que aman su profesión, independientemente del rol. Puede variar la perspectiva, pero todos tenemos a la corta o a la larga, la necesidad de reconocimiento general o de nuestros pares, un salario digno, horarios laborales tan flexibles como nuestra flexibilidad horaria, beneficios e incentivos por hacer cada día más productiva nuestra labor, posibilidades de crecimiento y proyección, respeto y trato justo, entre otras cosas.
Entonces si la percepción es la misma, tal vez la solución no sea mirar de reojo y con desmedro a nuestros colaboradores de otras fases, sino demostrar que el trabajo en equipo es mucho más que una ambición utópica y lo podemos hacer.

Referencias:

¿Los programadores quieren dejar de programar? at Chile Ágil.
A ver cuando me ascienden para dejar de programar

Liderarse a uno mismo

Para poder liderar es necesario, primero, conducir la vida propia. Conocerse. Tener objetivos claros para con uno mismo. Saber de las virtudes y defectos propios.

Alex Rovira, experto en Self Management, explica las herramientas para conocerse a uno mismo, y así poder lograr altos estándares de liderazgo:

“Creo que lo importante es intentar liderar la propia vida con dignidad, con coherencia, con ética, con compromiso, con rigor y con amor. Uno sólo puede ser un buen líder para los demás si es un líder para sí mismo”.

“Esta es una cuestión de actitud”. “La buena suerte depende de cómo se aprovecha un golpe de suerte. Todo depende de cómo se lo gestione”.

El especialista resalta las diferencias entre la suerte, ese encadenamiento de hechos, lo fortuito; y la buena suerte, una actitud, la manera en que uno aprovecha un golpe de suerte o del azar.
La buena suerte dependerá de cómo se aprovechen las oportunidades que se le presente a cada individuo, esas oportunidades que, tal vez, sean producto del azar. Así, la Buena Suerte será el producto entre la preparación y el azar que, en definitiva, dependerá de uno mismo.

Alex Rovira propone “Los Siete Poderes”, que serán la guía para el liderazgo de alto rendimiento:

• Coraje: El coraje es cambiar. Es la conciencia mediante la cual uno se esfuerza y toma valor para concretar algo.

• Responsabilidad: “Debemos ser responsables de nuestra propia suerte Ser parte del problema y de la solución”.

• Propósito: “Es la voluntad y entrega para que un sueño se haga realidad”.

• Humildad: Es necesario saber comprender todos los puntos de vista y a todas las opiniones, por más desacertadas que sean. Esto lo resaltará como líder de manera positiva.

• Confianza: Es muy difícil de construir pero fácil de romper. Vale la pena confiar en sí mismos para romper problemas y cruzar las barreras. Con confianza hay compromiso y responsabilidad. Aquellas empresas que tienen un alto nivel de confianza, triplican sus resultados. La confianza se aprende tanto como la resignación.

• Amor: El amor moviliza a las personas que motivan a quienes los rodean.

• Cooperación: Es la interacción de los demás poderes.

Sobre el liderazgo, Rovira destaca la importancia de saber gestionarse a sí mismo para luego poder conducir a otras personas:

“es fácil saber si alguien es un buen líder observando simplemente los talentos de las personas que le rodean”. Líder será aquel que sepa escuchar y dar sentido, el que logre que los demás manifiesten sus propios e individuales talentos. El líder debe poseer los poderes mencionados por el experto, es decir ser humilde, saber escuchar al otro, cooperar y, por sobre todas las cosas, tener confianza en sí mismo. Quien ostente esas virtudes sabrá tratar -liderar- a su grupo si se dirige a ellos según la personalidad de cada uno.

“Lo importante es intentar liderar la propia vida con dignidad, con coherencia, con ética, con compromiso, con rigor y con amor. El resto -dijo Rovira- viene por añadidura. Un buen jefe sólo puede serlo para los demás cuando lo es para sí mismo. Esa es la clave del liderazgo”, aseguró.

Fuente Liderarse a uno mismo.

El Liderazgo de Alto Desempeño

Saber manejar conflictos y discusiones son dos de las principales prioridades que deben conocer los líderes. Poder escuchar e imponerse en el momento justo, tener sólidos conocimientos sobre negociación y principalmente, inspirar a sus seguidores.

Kohlrieser, supo expresar cuáles son los pilares sobre los que se erige un líder:

“Debemos ser centrados en todo momento, utilizar el ojo de la mente, presentar lo que nos molesta y comenzar a negociar”

“A la hora de la negociación tenemos que estar motivados e inspirados. Además, hay que estar abiertos a la pronta resolución de conflictos y crear una buena energía”.

“Algo muy importante para un líder es contar con una estrategia y tener bien en claro hacia dónde se va; aunque también debe poseer la flexibilidad para ajustarse a los cambios!”.

“Tenemos que tener la capacidad de lograr un diálogo”.

“Debemos eliminar las interferencias para llegar al desempeño pico”.

” Hay que bloquear los estados negativos y activar los estados positivos”.

“Cultivar los factores que mejoran el alto desempeño”.

Según Kohlrieser existen distintos tipos de líderes de acuerdo a los estilos que pueden existir:

“Se puede ser democrático, coercitivo, autoritario, “marca pautas” o entrenador. Cada una de estás posibilidades tiene sus características, que se ajustan a las distintas personalidades”.

Kohlrieser indica también cuales son las bases para un liderazgo de alto desempeño:

• Autoconocimiento
• Autogestión
• Habilidades sociales
• Conciencia social

Con respecto a los máximos escollos que deben saber sortear los líderes, Kohlrieser, expresa que uno de los más importantes es el conflicto, por lo que “todos deben saber qué hacer y qué no en una situación de este tipo”. El diálogo es de vital importancia en estas situaciones.

Para estos casos, lo primero que se debe hacer es plantear la diferencia entre las dos o más personas que son parte del conflicto y encontrar una salida de manera racional y efectiva para todas las partes, lo que en otras palabras no significa más que dialogar con los otros para zanjar las dificultades o diferencias que pudieran tener.

El diálogo, para Kohlrieser, es la mejor salida a los problemas, pero, desde ya, existen varios inconvenientes que pueden hacer mella a la hora de dialogar.
Según el académico, los obstáculos se dividen en primarios y secundarios:
En el primer grupo están la pasividad, la ignorancia, la redefinición y el exceso de detalles, y en el segundo demasiada racionalidad, emoción y generalización, abstracción, falta de apertura y de honestidad.

Sorteando estos impedimentos, la negociación entre el líder y quienes lo cuestionan tendrá 10 etapas diferentes:

1. Crear un vínculo
2. Separar a la persona del problema
3. Identificar las necesidades y deseos propios
4. Identificar las necesidades y los deseos del otro
5. Dialogar
6. Crear un objetivo
7. Presentar opciones y propuestas
8. Beneficios mutuos
9. Acuerdo
10. La relación continúa o finaliza en forma positiva

Por último se debe tener en cuenta que dicen las últimas investigaciones sobre el cerebro de los líderes de alto desempeño:

“El cerebro siempre puede cambiar. Ello dependerá de las relaciones con las que el individuo vaya creando. Además, la experiencia, el conocimiento, pueden reemplazar la predisposición genética, si no es propia de un líder”
“Las nuevas experiencias pueden crear circuitos que reemplacen a las experiencias pasadas”.

Referencia: El Liderazgo de Alto Desempeño.

Los profesionales de IT mejor pagos

Especialistas en Java, .net y Cobol son los más requeridos por las empresas.

Hays, consultora dedicada a la selección de personal especializado, realizó un estudio sobre la demanda de profesionales del sector de IT en Europa y algunos países latinoamericanos. El resultado fue que los profesionales más requeridos son los orientados a tecnologías Java, .Net y Cobol, en puestos técnicos y de desarrollo de sistemas.

En España, las retribuciones salariales para estos perfiles rondan los 30.000 euros mensuales. En Portugal, el salario aproximado de un profesional de esta área gira en torno de los 26.600 euros.

En Francia, los profesionales de Java han experimentado un notable aumento en comparación con el año pasado. El resto de los perfiles requeridos se mantiene en el mismo nivel en el que estaba y con una remuneración económica que va desde los 25.000 euros a los 40.000 euros al año.

Suecia, por su parte, paga a estos profesionales entre 30.000 euros y 48.000 euros al año. En la República Checa, estos perfiles además tienen que estar dotados de habilidades para la comunicación tanto verbal como escrita e interpersonal. Su remuneración económica oscila entre los 23.000 euros y los 50.000 euros al año.

En el caso de Hungría, los perfiles más demandados son los de Java y .Net, y los sueldos alcanzan los 32.400 euros al mes. Los perfiles más demandados en Italia son los mismos, y el salario va de los 25.000 euros hasta los 50.000 euros al año. Por otro lado, en Brasil, estos perfiles son muy requeridos, y el sueldo de un puesto intermedio al año es de 26.000 euros.

Referencia:  Los profesionales de IT mejor pagos.

TMap – Testing Management Approach for Structured Testing

TMap (Test Managment Aproach) es una framework creado por sogeti basado en Metodologías Estructurada de Testing. TMap se encuentra difundido por toda la comunidad europea en paise como Alemania, Francia, Suecia, Suiza, España, Bélgica, Reino Unido e inclusive Estados Unidos.

• El objetivo de Sogeti es proveer a las organizaciones con un proceso de testing para sistemas complejos, donde los riesgos por falta de pruebas sean eliminados, permitiendo incorporar elementos tales como detección, evaluación y comprensión de riesgos asociados a la calidad del software
• Un proceso de Tesing transparente y proactivo administrable en términos de tiempos,  costos y calidad
• Alertas por calidad insuficiente (falta de cobertura, falta de criterios, dualidad, funcionalidad ambigua, funcionalidad debil, etc.)
• Habilidad para detectar y prevenir defectos en fases tempranas
• Un periodo corto de tiempo para el testing sobre la ruta crítica de todo el ciclo de desarrollo
• Reutilización del proceso de testing (Test Case y Test Script)
• Estandarización y consistencia (un mismo lenguaje para todos los involucrados en el proceso de testing)

TMap se basa en cuatro pilares fundamentales:

1. Un ciclo de vida del testing  con actividades consistentes
2. Estructrura organizacional embebida
3. Infraestructura y herramientas correctas
4. Técnicas usables

Para TMap, el ciclo de vida es el centro del proceso puesto a que allí se desarrollan y fundamentan el resto de los pilares y es preciso que el ciclo de vida responda a los criterios organizacionales que lo sustentarán en el tiempo.
la infraestructura es fundamental para la obtención de resultados óptimos, como también el correcto uso de las herramientas. Así mismo el "entorno de testing" debe ser estable, controlable y resentativo.
Por último es importante que las técnicas utilizadas den el soporte requerido por el proceso de testing planteado por TMap, de modo que con estas se lograrán implementar las mejores estrategias para garantizar especificaiones y revisones de casos de usos y scripts de pruebas, incluyendo repetitibidad y trazabilidad.

Al tratarse TMap de un método estructurado, se reconocer cinco fases bien definidas:

1. Planificación y Control
   Especificación de "Quien", "Que", "Cuando", "Como" y "Donde" probar.
2. Preparación
   Determinación de las especificaciones de calidad del software para obtener una exitosa ejecución del testing.
3. Especificación
   Indica los Test Case involucrados y la infraestructura requerida, incluidas las configuraciones necesarias, lo cual permitirá que la ejecución del Testing comience en cuanto el "Objeto de Testing".
   En esta fase se analiza cualquier diferencia entre los resultados esperados y los obtenidos y finalmente se reportan los defectos.
4. Ejecución
   La fase de ejecución inicia cuando el "Objeto de Testing" es liberado
5. Completitud
   Esta fase consiste en el reporting de los resultados evaluación de los procesos de prueba para la mejora del mismo proceso, como también la obseravación de los "Matariales de Test" que pueden ser reutilizados para proyectos futuros o inclusive para fases de mantenimiento y/o soporte de los productos generados por el proyecto.

TMap ofrecer una manera de emprender en forma efectiva y eficiente los procesos de pruebas de software, permitiendo a las organizaciones enfocarse en los objetivos claves para sus negocios.
Lo hace de manera efectiva para que se enfoca en encontrar a tiempo los defectos importante y con una relación directa con el riego del producto.
Lo hace de manera eficiente por que es un metodo aplicable universalmente que enfatiza el re-uso, con una estrategia basada en los riesgos de los objetivos de negocios y de los productos, permitiendo hacer estrategias inteligentes sobre que testear, como testear y cuando testear, en lugar de testear todo en todo momento.

Leer TMap_Nutshell
Ver artículos, templates y checklis para Testing Estructurado

¿CMMI o AGILE? ¿Juntos es posible?

CMMI tiene una carga y una exigencia que equipos conformados AGILE (típicamente pequeños) no pueden soportar, simplemente por que no tienen la estructura de personal. Al menos eso sucede con equipos para SCRUM.

Ejemplos sencillos son las exigencias de CMMI-2 sobre las Áreas de Proceso “Planificación de Proyectos” y “Aseguramiento de Calidad”, donde están vigentes los “Procedimientos de Planificación de Proyectos” y “Procedimientos de Estimación y Presupuestación”, como los “Procedimientos de Planificación de Calidad” y “Procedimientos de Auditoria y Revisiones”.

Estas solas áreas de procesos exigidas por CMMI-2 y sus correspondientes procedimientos pueden poner "en jacke" a quienes sostienen que con un equipo pequeño es posible certificar CMMI-2 o 3, dado que para solo cumplimentar las prácticas específicas para esos dos procedimientos que mencionas, necesitas de un equipo QA completo y al menos dos niveles de gerencia para escalar las aprobaciones.
La Planificación de Proyectos para CMMI es lo que me parece crítico y no es fácilmente adaptable a equipos SCRUM, por que es necesario formar y tener aprobado el Cronograma del Proyecto, lo cual por si mismo significa haber confeccionado un Plan de Iteraciones, Plan de Participación de los Interesados y un Plan de Integración, más un Plan de Riesgos, un Plan de Decisiones Técnicas y un Plan de Capacitaciones o certificar en una matriz de capacitaciones organizacionales, que para iniciar el proyecto el equipo del proyecto tiene las habilidades requeridas.
En lo que a calidad se refiere, debe existir documentación objetiva y sólida confeccionada por el Líder de Proyecto (no Gerente de Calidad ni Líder de Testing) sobre los Objetivos de Calidad y Performance y eventualmente utilizar procedimientos de Gestión de Cambios para modificar requerimientos u objetivos de calidad cuando existen contraposiciones y Procedimientos de Análisis y Toma de Decisiones para establecer esos cambios. Finalmente se debe registrar cuales objetivos se gestionarán estadísticamente.
Si quieres podemos hablar de las revisiones por pares, las cuales no están referidas a (pair programing) sino que son prácticas específicas para un muy alto porcentaje de los productos de software generados.
Todas estas decisiones, principalmente Gestión de Cambio y Toma de Decisiones, se realizan por comité organizacional.
Si considero interesante y posible que la agilidad se puede insertar en toda la organización con prácticas como SCRUM (…muchas otras…según), pero debemos conseguir de una vez por todas que nuestras soluciones de consultoría Agile trasciendan el ámbito del área de desarrollo, por que lamentablemente hasta el día de hoy son pocas las organizaciones que lograron traspasar esa barrera en las organizaciones de envergadura mediana o grande.
Un simple ejemplo es que ni a duras penas logran unificar un criterio para establecer prácticas en Testing o sostener un circuito de auditorías de calidad, sin pretender absorber este departamento QA hasta hacerlo desaparecer para conformarse en el equipo de desarrollo.
Para acercarme a una conclusión, estoy seguro que la simplificación de los procesos debe hacerse concienzudamente, sin ofrecer a las organizaciones "recetas de menudencias" que en un principio parecen ser buenas, pero a la larga podrían dejar el sabor insípido de la pérdida de prácticas que alimentan la base del conocimiento organizacional.