Lucas Ontivero : Project Management

Deberían los testers arreglar bugs–Parte I

Lucas Ontivero — Thu, 15 Nov 2012 03:23:00 GMT

Esa es la pregunta que lanzé en el sitio Software Quality Assurance and Testing de StackExchange.com en cuyas respuestas pude ver que existe cierto desacuerdo entre la comunidad de testers sobre ese tema y si bien yo tengo una idea clara al respecto, lo que en verdad quería conocer eran las argumentaciones de aquellos que piensan que sí deberían arreglar defectos (algunos defectos) y aquellos que piensan que no deberían para así hacer una síntesis.

No obstante, al poco tiempo otro usuario inicia otro hilo en el que pregunta cuales son las principales responsabilidades de un tester en las que expone una pequeña lista de responsabilidades:

1) Analyzing the Requirements from the client
2) Participating in preparing Test Plans
3) Preparing Test Scenarios,test cases
4) Defect Tracking
5) Preparing Suggestion Documents to improve the quality of the application
6) Communication with the Test Lead / Test Manager
7) Conducting Review Meetings within the Team

Hay tantas cosas con las que no estoy de acuerdo con lo que leo en ese foro que voy a dejar plasmado aquí mi pensamiento. Para comenzar tengo que decir que para mi, la responsabilidad de todos los miembros de un equipo es exactamente la misma: contribuir tanto como sea posible al éxito del proyecto. Entonces, si bien las actividades, especialidades y orientaciones pueden ser distintas, la responsabilidad es la misma.

Ahora bien, si aceptamos esto como válido deberíamos entonces definir qué es un proyecto exitoso y qué no lo es. Para todos aquellos medio entrado en años (de profesión) como yo de seguro les sonará el cuentito llamado OTOBOS que dice que un proyecto exitoso es un proyecto “on time, on budget, on scope” y la verdad es que en los tiempos del los modelos predictivos, en los que el SDLC era por lo general en cascada, mantener al proyecto a lo largo del tiempo on time, on budget y on scope era cosa de magos, se creía que la clave estaba en el *control*. Pues bien, puede que me equivoque pero voy a darles *mi* definición de lo que es un proyecto exitoso:

“Un proyecto exitoso es aquel que nos otorga un alto retorno sobre la inversión a la vez que nos permite crear una relación de confianza con el cliente”

La segunda parte de esta definición habla de la satisfacción del cliente, y puesto que lo que este recibe no es otra cosa que software, deberíamos aclarar qué es un software exitoso para el cliente. Veamos, nuestros clientes no nos encargan el desarrollo de una solución porque no se les ocurran mejores cosas en que despilfarrar el dinero, sino que lo invierten en una herramienta que les permita cumplir con sus metas de negocio. Ya sea optimizando o agilizando la gestión de la compañia, diferenciandose de la competencia, fidelizando clientes, brindando nuevos servicios online o alguna otra ventaja, las empresas *invierten* en software y esperan un retorno de esa inversión. Entonces:

“Un software exitoso (para el cliente) es aquel que le permite cumplir con sus metas de negocios y por tal, le otorga el esperado retorno sobre la inversión”

Y es que de eso se trata y siempre se ha tratado, de dinero. Por lo tanto, la responsabilidad de *todos los miembros del equipo* (sí, testers incluidos) es contribuir a este éxito. Y para esto hace falta mucho más que control y responsabilidades estrictas y predeterminadas.

Continuará…

del.icio.us Tags: software testing,bug fixing,testers roles

Code Freeze–Explicando esta MALA práctica

Lucas Ontivero — Mon, 23 Jan 2012 06:05:26 GMT

Hace un par de días una amigo preguntó por esta práctica en twitter por lo que decidí dar una brevísima explicación en este video.

NOTA: a sugerencia de Rodrigo Corral he cambiado el título para que quede claro de entrada que en la inmensa mayoría de los casos esta es una mala práctica, cosa que entiendo he dejado bien claro en el video; aunque nunca se sabe. Creo además que la malas prácticas también necesitan ser explicadas ya que forman parte del vocabulario común y uno debe conocerlas.

Programar no es tan complicado

Lucas Ontivero — Sun, 08 Jan 2012 05:23:23 GMT

Es fácil entender por qué los hombres de negocio prefieren cantidad de desarrolladores sobre calidad de desarrolladores, es por lo que yo llamo el pensamiento lineal en la administración y que no voy a discutir nuevamente aquí pero solo diré que esa tendencia lleva implícita la idea de que programar no es tan complicado y por lo tanto cualquier programador podrá hacerlo bien.

Lo que cuesta entender es el por qué Ivar Jacobson dice que el 80% del trabajo de programación es algo mecánico (“it is not brain work” - según él). Ivar Jacobson es uno de esos personajes que todo el mundo debe conocer y cuyos aportes han sido grandiosos (salvo este) y por lo tanto se merece el mayor de nuestro respeto aunque sinceramente lo primero que pensé cuando lo escuché por primera vez fue: “ojalá hubiese estado presente un programador iraquí para que le tirara un zapatazo”

Si a la tendencia de “los hombres de negocio” de preferir cantidad sobre calidad se le suman las opiniones de verdaderos gigantes de nuestro medio como Ivar Jacobson, la idea de que programar es relativamente sencillo toma todavía mucha más fuerza y nos hace un flaco favor. Sumado a esto tenemos una realidad difícil de falta de talentos debido a la gran demanda de desarrolladores en la industria que lleva a que conseguir buenos desarrolladores sea una tarea complicada.

Por estos motivos es que muchas empresas completan sus puestos con lo que muchas veces llaman “programadores promedio” que hace referencia a aquellos programadores cuya principal destreza es la fuerza bruta. (Si como dijo Lampson: todo problema en computación puede ser resuelto añadiendo un nivel de indirección; según el “programador promedio”: todo problema en computación puede ser resuelto añadiendo un IF)

Lo interesante del caso es que las expectativas que se tienen sobre el desempeño de estos programadores son muchas veces demasiado altas y así se pretende lograr software de calidad superior con desarrolladores de calidad promedio desviando el foco hacia las metodologías, QA, auditorías y herramientas entre otras cosas.

Está claro que para muchas tareas de desarrollo no se necesitan genios, también es cierto que las tareas que requieren mayores destrezas las deben realizar aquellos con mayor experiencia y conocimientos, es claro además que todo el mundo es distinto y que no se pueden contratar todos rock stars pero una cosa es decir esto y otra mucho más delicada es decir que programar no es tan complicado.

Management deficiente (I)

Lucas Ontivero — Fri, 09 Dec 2011 08:58:49 GMT

Introducción

La historia del software está plagada de ejemplos de proyectos que fracasaron estrepitosamente, estos por lo general han excedido el presupuesto estimado, el esfuerzo estimado y el tiempo estimado en muchas veces y si bien parece que la industria viene haciendo avances importantes en estos problemas, aún hoy es común ver u oír de proyectos que fallan de manera espectacular.

Voy a introducir solo algunas de las razones de por qué esto sigue sucediendo, de cómo puede solucionarse y de cómo afecta a los equipos. Pero el foco voy a centrarme en la gente, en cómo los afecta, en sus reacciones y motivaciones (o desmotivaciones) y para ello voy a usar un ejemplo real de un proyecto en el que participé.

Costos

Todos los proyectos que fracasan tienen una característica en común: superan los costos. Sea porque se renegocian o porque pierden dinero o porque no ganan lo esperado, o porque se extienden en el tiempo (también representa un costo) o por el motivo que fuera, los costos están siempre relacionados al fracaso de un proyecto.

Uno de estos costos, y probablemente uno de los que más afectan a la moral de los equipos es el llamado costo de calidad probre, costo de mala calidad o costo de no calidad, esto es, cuanto cuesta (dinero) desarrollar software con defectos (bugs) y luego tener que arreglarlos. Mientras más alto es este costo, más probabilidades existen de que un proyecto fracase.

Una introducción a La Historia

La historia con la que quiero ejemplificar se basa en el desarrollo de una aplicación gubernamental en la que trabajé y a la cual me referiré con el nombre ficticio de “pyjs”. En este proyecto, el costo de calidad pobre era una aberración, cada caso de uso requería un esfuerzo de entre 2,5 y 4 días-hombre de desarrollo y se le hallaban un promedio de 12 bugs. Así, el equipo, formado por alrededor de 13 desarrolladores desarrollaba algo así como 40 casos de uso por sprint de 2 semanas.

Lo interesante de esto es que con esos 40 casos de uso, venían también unos 480 bugs! Digamos que si arreglar cada uno de eso bugs costara tan solo una hora de desarrollo, esa bolsa de bugs costaría 480 horas-hombre, a digamos algo así como 10 u$/hs serían u$ 4.800 tirados por la ventana cada 2 semanas.

Un poco más sobre este costo

Una de las razones por la que deben atacarse rápidamente las causas de este costo es porque este crece de manera exponencial a medida que la detección de los defectos se aleja de la fase de desarrollo. Así, llevándolo a lo cotidiano, cuesta mucho menos (menos dinero) encontrar un defecto en una revisión de código antes de subirlo al repositorio que encontrarlo durante la etapa de pruebas ya que aquí se debió utilizar tiempo del equipo de pruebas, hay más reportos, más administración, etc. Ni que hablar si en lugar de encontrarlo el equipo, lo encuentra el cliente.

Volvamos a La Historia

En el pyjs la relación testers/desarrolladores era muy baja, no por algún número teórico sino por la simple razón que el equipo de pruebas no daba a basto y por ende se retrasaba cada vez más hasta llegar el punto de que probaban funcionalidad que se había terminado más de un mes atrás. Así las cosas, para cuando reportaban los defectos, el equipo ya estaba desarrollando otras funcionalidades (muchas que dependían del correcto funcionamiento de las anteriores) y una vez acumulados estos bugs se repartían muchas veces a “el equipo de los bugs”, esto es, a miembros del equipo que no habían estado involucrados en el desarrollo de esos casos de uso y que por lo tanto no los conocían, no sabían qué debía hacer esos casos de uso, cómo se relacionaban con otros casos de uso ni nada en lo absoluto. Esto convertía a estos desarrolladores en los “mártires de turno” (digo “de turno” porque alguna vez los cambiaban).

Una cosa curiosa es que la líder de proyecto comentaba que se requería el mismo esfuerzo para desarrollar los casos de uso que para arreglarlos y por esta razón en algunas ocasiones se alternó un sprint para desarrollo y el siguiente para corrección de bugs. Esto quiere decir que a menos que al cliente se le presupuestara 3 o más veces el costo de desarrollo, el proyecto era inviable.

Otra cosa a tener en cuanta es que si los casos de uso no tuvieran defectos, el proyecto podría haberse terminado en quizás en la mitad del tiempo.

Reacciones del management

Ante semejante situación, las reacciones del management fueron las siguientes:

Remover a aquellos desarrolladores que habían participado en el desarrollo de las funcionalidades con mayor número de defectos.
Incrementar el número de desarrolladores e incrementar el “seniority” del equipo incorporando personas con mayor experiencia (incrementando los costos). Esto llevó a la necesidad de “distribuir” al equipo ya que estos nuevos desarrolladores estaban en otras ciudades.
Asignar más presupuesto al proyecto para posibilitar que desarrolladores “externos” al equipo participaran en la creación de casos de uso de manera independiente (desde sus casas y en horarios extralabolares)
Pedir a los desarrolladores que por favor entendieran la situación del proyecto y que no generaran más defectos.
Pedírselo de nuevo
… y de nuevo…. y otra vez más.

Reunión de retrospectiva tras reunión de retrospectiva los líderes de proyecto (digo los porque en realidad eran 2!) repetían que el mismo sermón a los desarrolladores: “Entindan! Les pedimos que por favor entiendan que tienen que generar menos bugs a la vez que necesitamos que incrementen la velocidad!”, “A esta situación llegamos por la falta de compromiso de los desarrolladores”, “Necesitaban más memoria y se las dimos, pidieron cursos y se los estamos gestionando, ahora recapaciten!”

Cómo afectó al equipo

Si esto no bastaba para bajarle la moral a alguien, si alguno con una psiquis de acero todavía permanecía en pie, los reportes de estado del proyecto realizados por teléfono a los superiores argumentando que el proyecto estaba como estaba por una “falta de compromiso”, “por los descuidos”, “por no leer la documentación correctamente” más otras actitudes desmotivantes como los mails pidiendo al equipo que “piensen en las cosas que están haciendo mal”, acabaron con las fuerzas del equipo.

El mismo equipo que reunión de retrospectiva tras reunión de retrospectiva decía que los tiempos estaban muy comprimidos, que los bugs se detectaban muy tarde y que se sentían presionados a entregar aun a sabiendas de que estaban entregando con baja calidad.

Por otro lado, la remoción de prácticamente la mitad del equipo de un plumazo, personas que quizás se desempeñaban algo por debajo del resto pero que hacían valiosos aportes al proyecto (recuerdo que muchos de ellos trabajaban muchas horas de más e incluso cuando se les pidió trabajar un fin de semana lo hicieron de buena gana), no ayudó a mejorar en lo absoluto sino todo lo contrario. De hecho esta fue la primera acción que se tomó.

La moral de un equipo es algo que debe cuidarse celosamente y protegerla porque marca una diferencia enorme en los resultados. Por eso, luego de que la moral bajara al nivel más bajo que recuerdo, el equipo comenzó a realmente desempeñarse por debajo de sus posibilidades, a importarle menos sus resultados, a ser lo que todos los días se les decía que eran: descuidados y poco comprometidos.

Costos de calidad

Existen otros costos de calidad divididos según las tareas específicas que requieren como costo de inspección, costos de prevención y así, pero básicamente lo que se busca es invertir (dinero) en actividades claves que reduzcan el número y severidad de los defectos, idealmente identificándolos en las etapas más tempranas posibles donde el costo de un defecto es menor.

Costos de calidad en esta Historia

En el pyjs la inversión en actividades de “prevención” era prácticamente $ 0,00. La justificación era que no había tiempo, que las entregas al cliente requerían que se utilizara todo el tiempo disponible en el desarrollo de las funcionalidades pactadas. Por esa razón, cuando se pidió al TL que no se siguieran desarrollando las pruebas unitaria y luego cuando propuso volver a realizar las revisiones de código obtuvo un “no hay tiempo para esas cosas”.

Por fortuna, digo que la inversión fue de “prácticamente” $ 0,00 porque se autorizó que el arquitecto desarrollase un generador de código y un set de componentes reutilizables en 4 días, lo que ayudó al proyecto a salir solo un poco de apuros. Esto se autorizó gracias al poder seductor del pensamiento mágico que todo “generador de código” despierta en algunas mentes.

Mi reacción

Como esto estaba muy claro para mi, retrospectiva tras retrospectiva planteaba la necesidad de incorporar aquellas prácticas que todo el mundo sabe que dan resultado: revisiones de código, pruebas unitarias (aunque sea en aquellas funcionalidades más delicadas), reuniones técnicas para aunar criterios o despejar dudas (el equipo se dividía entre 4 ciudades distintas).

Por otro lado, con el fin de obtener feedback más rápido por parte de testing, propuse incrementar el equipo de testing y agilizar las pruebas, filtrar aquellos defectos que no eran realmente defectos o que no se querían o podían arreglar en ese momento (los reportes de defectos en crudo a los desarrolladores es una perdida de tiempo descomunal), no enviar funcionalidades sin probar al cliente (una práctica habitual que encarecía el proyecto y le causaba muchísimo daño).

Por último, no desmotivar al equipo!

Fin de la Historia

Mis recomendaciones cayeron en oídos sordos todas la veces, ni siquiera formaban parte de las minutas de las reuniones de retrospectiva ya que la razón de los problemas no eran ningunas de esas estupideces que yo decía sino que era un tema de falta de compromiso, descuidos y falta de profesionalidad.

A todo esto, la pregunta obvia era: ¿si existe falta de compromiso en algunos miembros entonces por qué no se los remueve?. Y la respuesta fue que no se iba a modificar más el equipo porque la falta de compromiso era general! Yo creo que la razón era otra: si luego de cambiar a la mitad del equipo se cambia a la otra mitad y todo sigue igual…. ¿que se le reporta a los jefes? ¿que los 13 nuevos desarrolladores son tan indolentes como los anteriores?

Conclusión

Yo tenía una hipótesis de que los proyectos sí fallaban la mayoría de las veces por cuestiones técnicas, esto era porque he visto algunos pocos proyectos fallar por problemas técnicos pero ahora está claro que los grandes y monumentales fracasos son en verdad por un management deficiente.

De Oráculos y MSProject

Lucas Ontivero — Thu, 02 Jun 2011 15:18:00 GMT

Hoy he recibido un cronograma en un archivo .mpp que no tenía una aplicación asociada para abrirlo así que busco en Google “.mpp file extension” ¡Y claro!!! Es un project!

Juro que no lo recordaba. Creo que hace 6 o 7 años que no veo uno así que me puso nostálgico. Lo que más me gusta del project es que tiene información muy útil como que el 24 de Enero del 2012 vamos a estar todos festejando la culminación exitosa del proyecto o que el módulo XXXX va a comenzar el 10 de Octubre y que luego de 4,3 semanas el cliente nos va a dar el Ok.

¡Esta información SÍ que es valiosa!

Nota: Sí, estás en lo correcto, es una sobredosis de sarcasmo.

Ruidos y señales en nuestra industria

Lucas Ontivero — Wed, 30 Mar 2011 17:50:00 GMT

Voy a tomar prestado las palabras señal y ruido del campo de las telecomunicaciones para explicar una situación que nos afecta de cerca. Entendamos la palabra señal, en el contexto de esta entrada, como el mensaje, lo importante, lo esencial y como ruido lo indeseable, lo molesto, lo que encarece y entorpece al mensaje.

La señal, o el mensaje en este caso, que deseamos transmitir, por lo general todos los que hemos estado en esto durante algún tiempo (y que nos hemos equivocado terriblemente una infinidad de veces y lo vamos a seguir haciendo), es que educación (léase como entrenamiento o capacitación), trabajo en equipo, orden (o método), comunicación, simplicidad, motivación, experiencia, más experiencia, buen management y buenas prácticas son los puntos claves para el éxito en la empresa de desarrollar software.

El ruido, por otro lado, lo constituyen los maremotos de frameworks que se ponen de moda y cuya vigencia no supera el año o dos, las tendencias y sus variantes (TDD y BDD) y sus productos forzados (Isolation Frameworks, IoC containers/DI) que a su vez son más frameworks o requieren agregar complejidad al código, Patrones y más patrones (alguno de ellos requeridos, utilizados, o introducidos por algunas prácticas o frameworks), nuevos lenguajes con ideas antiquísimas (funcionales y dinámicos), otros lenguajes resucitados (Lisp) y sus mil variantes o dialectos (clojure, scheme y otros), application blocks, ORMs y la lista puede seguir ad infinitum.

Podríamos discutir un año completo el por qué ninguna de estas cosas incrementa el éxito de los proyectos de desarrollo en una forma sustancial. Pero como evidencia podemos recurrir a la realidad cotidiana. ¡Cuidado! No estoy diciendo que todos los frameworks son puro ruido, no estoy diciendo que algunos lenguajes no introducen mejoras, no afirmo que la inyección de dependencia no tiene excelentes usos ni que los patrones, que nos han elevado al grado de que hoy somos más diseñadores que programadores, sean inútiles; NO. No nada de eso, lo que digo es que su contribución al éxito de los proyectos (léase si se quiere como: costos, tiempo, presupuesto y calidad) y en lo que entregamos a los clientes es sencillamente marginal.

En software como en telecomunicaciones, el ruido puede transportar señal también. Esto quiere decir que de todo eso que hoy está de moda, pero que mañana solo servirá para reírnos un rato, algo queda y mucho se aprende.

Mi preocupación va por el lado de la desproporción en la relación señal/ruido. Creo que la señal es débil mientras que el ruido es muy fuerte. Muchas veces por la necesidad de vender productos las compañías introducen gran parte del ruido. Otras veces, somos nosotros cuando resaltamos el ruido cuando buscamos gente “Perfil: deberá conocer WCF, Mockito (conocimiento de Moles se tomará en cuenta), Prism, MVVM, Unity, Linq, JQuery y controles de Tellerik”. Esto amplifica el ruido tremendamente. Al cliente por otra parte seguramente le entregaremos una solución bastante parecida a lo que le hubiésemos entregado hace 3 años cuando ningunas de esas cosas existía.

Horas extras y las cadenas psíquicas

Lucas Ontivero — Mon, 21 Mar 2011 20:31:18 GMT

Siempre veo y escucho de gente que trabaja 2, 3, 4 y hasta 5 horas de más, personas que deberían salir de sus lugares de trabajo a las 18hs se quedan hasta las 22hs o 23hs sin ninguna compensación. Es cierto que algunas veces uno debe terminar un trabajo y ello puede requerir quedarse algunas horas extras por unos días. No hay nada malo en ello, el problema surge cuando esa situación no se da de manera excepcional sino que es una constante, cuando las personas se quedan a hacer sobre turnos por semanas o incluso meses.

Por lo general, las respuestas que dan aquellos que así lo hacen cuando se les pregunta el por qué de quedarse hasta esas horas son algunas de estas:

porque el proyecto lo necesitaba,
porque ellos se comprometieron a tenerlo en esa fecha y/o,
porque ellos son muy responsables.

Seguro podríamos discutir estas respuestas desde algunos puntos de vista técnicos-metodológicos-ingenieriles pero esta vez no. Esta vez quiero analizarlo desde el punto de vista psicológico. Para esto, partamos de la base de que las personas saben que afuera hay un mundo, que tienen una novia, una esposa, unos hijos que los esperan. Se dan cuenta que, al menos en invierno y en mi provincia, entran a trabajar de noche y salen de trabajar de noche. Todo el mundo es consciente de que su tiempo es finito y que la vida se les pasa pero aún así se quedan a trabajar muchas más horas. ¿A cambio de qué? De nada.

¿Cómo es posible entonces? La verdad es que esa declamada responsabilidad es solo una excusa inconsciente, una trampa psicológica que los protege de la angustia de saber que están tirando su vida al tacho. Esto nos lleva a otra pregunta: ¿qué les impide irse a casa a las 18hs? En apariencia, nada se los impide. Es más, hasta se les podría culpar de ser adictos al trabajo. Pero si se necesita de una excusa inconsciente para justificarse por hacer algo es porque existen otras fuerzas invisibles que les impiden irse a las 18hs.

La primera y quizás más poderosa es la fuerza del grupo. Una vez que un grupo acepta trabajar más horas que aquellas inicialmente pactadas, todo nuevo integrante se someterá al comportamiento e idiosincrasia del grupo. El experimento de conformidad de Asch es una muestra clara y por demás concluyente de que la individualidad se distiende en gran medida para concordar con la visión grupo. Si todos trabajan hasta las 20hs, aún cuando no fuese necesario, aquel que se fuera a las 18hs sufriría una presión enorme. Ver el experimento del ascensor.

La segunda es el de la autoridad. El poder que la autoridad tiene para suprimir la voluntad del individuo llega a límites insospechados. El experimento de obediencia a la autoridad de Milgram, el que se recreó muchísimas veces con similares conclusiones, prueba que en el 65% de los casos, personas comunes llegan a aplicar descargas de 450 voltios a un semejante solo por obediencia, esto en algunos casos equivale a matarlos. Entonces, en las organizaciones, donde la estructura de autoridad es absolutamente vertical y se encuentra claramente establecida, la obediencia es un factor clave. Aunque las frases: “Quiero esto para mañana” y “Hasta que no esté resuelto no se va nadie de acá” son ejemplos crudos y explícitos, las ordenes no tienen por qué ser tan explicitas (la sugestión es mucho más efectiva incluso) para que sean acatadas cuando quien las imparte ha sido embestido con autoridad por la compañía. Por otro lado, la obediencia en las organizaciones se muestra más como un afán por mostrarse cooperativo que como el cumplimiento de una orden.

Son estas dos fuerzas las que, junto con otras como la de “comprometerse” (quizás con las estimaciones dichas en público), crean un malestar psíquico como producto de la disonancia entre lo que hacen, de manera forzada, y lo que realmente piensan sobre lo que hacen. La magnitud del malestar es proporcional a la magnitud de la disonancia y por ello, para disminuir la angustia, buscan mediante una excusa, estar en mayor consonancia con lo que hacen. Ver “Cognitive consequences of forced compliance”

El problema detrás de todo esto es que el malestar tiene que desaparecer de alguna manera. Por lo general, las personas que hacen sobre turnos están dispuestos a cambiar de trabajo mucho más fácilmente que aquellos que no los hacen. Es un problema real para las organizaciones que tiene costos asociados los cuales son muy difíciles de medir. ¿Cual es la ganancia asociada a una persona que trabaja durante 3 meses algo más de 2 horas extras para luego irse a la competencia? Nadie lo sabe.

Pero lo más triste es que muchas de estas personas (colegas) que se cambian a la competencia en busca de una realidad distinta, terminan en exactamente las mismas situaciones solo que en una empresa diferente. Siempre que hablo con alguien que quiere “escapar” a otra empresa para cambiar su realidad actual le pregunto: ¿Y qué vas a hacer para que en la nueva empresa no te termine pasando lo mismo? Nadie lo sabe.

Yo tampoco tengo la respuesta pero sin dudas parte de culpa pertenece a las personas que aceptan esos sobre turnos. Aún cuando puedan irse autoimponiendo de manera gradual y progresiva.

Como fracasar con las pruebas unitarias

Lucas Ontivero — Tue, 15 Jun 2010 23:46:58 GMT

Hace poco gravé un pequeños video en el que explicaba una realidad que he visto en muchos proyectos respecto de las pruebas unitarias. En síntesis lo que comentaba era que en esos proyectos, los beneficios de las pruebas unitarias no eran visibles mientras que los costos sí lo eran. En problema aparente era la calidad de las pruebas, pero en realidad, el problema de fondo es la estrategia de hacer las pruebas luego de terminado el código. Por lo general, los programadores escriben piezas de código...(read more)

¿Cuantas líneas de código son 9 líneas con TDD?

Lucas Ontivero — Tue, 15 Jun 2010 23:32:55 GMT

En mi último post presentaba una métrica (verdaderamente muy mala) sobre mi productividad en un proyecto realizado completamente utilizando TDD de manera estricta. Esta mostraba aproximadamente 9 LOC/Hs. Al mismo tiempo, y como las pruebas y el código los escribí interactivamente, escribía 11 LOC/Hs de pruebas. Esto hace un total de 19 LOC/Hs. Ahora bien, cada 2 o 3 pruebas el código era refactorizado para eliminar duplicaciones, del mismo modo que luego de observar un patrón común en un conjunto...(read more)

TDD y Yo

Lucas Ontivero — Sun, 13 Jun 2010 22:30:57 GMT

Hace poco comencé un nuevo desarrollo y decidí grabar algunos videos de los cuales solo publiqué los primeros tres. Sucede que el hecho de saber que alguien me estaba mirando me hacía prestar mayor atención a mis palabras que al código que debía escribir. No obstante a ello, continué grabándome para tomar el tiempo y estudiarme. La primera parte de ese desarrollo está completado y estos son los números: 66 pruebas unitarias. 15 clases. (solo 4 centrales, el resto son datacontracts, excepciones y...(read more)

¿Te ves como un verdadero profesional?

Lucas Ontivero — Mon, 31 May 2010 05:52:05 GMT

Tanto se los he dicho que ya están empezando a darse cuenta de que realmente no entienden las necesidades del negocio. Al parecer ellos se meten en la programación desde chiquitos y el mundo se les achica tanto que no comprenden que hay compromisos asumidos y que el cliente está esperando el producto. Pero bueno, yo sigo explicándoles y varios lo entienden bien pero hay un par que verdaderamente no parecen estar muy convencidos. Lo peor de todo este asunto es que cada vez trabajan más lento y cada...(read more)

[Productividad] Parálisis por Emails

Lucas Ontivero — Mon, 17 Nov 2008 13:32:00 GMT

El correo electrónico es una de las herramientas más importantes de trabajo, todos tenemos un cliente de correo que chequeamos varias veces al día ya sea en nuestro trabajo o en nuestros hogares. Es tanto un medio de comunicación como un sistema para recibir alertas y recordatorios, todos los sistemas se comunican con nosotros mediante correo electrónico, " se te ha asignado un nuevo ticket ", " quedan 3 días para renovar las licencias ", " inscríbete para el curso de seguridad...(read more)

[Software Factories] Software factory (la historia sin fin)

Lucas Ontivero — Thu, 14 Aug 2008 04:44:00 GMT

Hace una año comencé la serie Introducción a los Software Factory con 4 entradas: [Software Factories] Introducción (Parte 1) , [Software Factories] Introducción (Parte 2) , [Software Factories] Introducción (Parte 3) y [Software Factories] Introducción (Parte 4) . Hoy quiero exponer los desafios que plantea la implantación de una software factory en el mundo real. Veamos.... Al hablar hoy de software factories uno puede revivir el sentimiento de frustración que sentia 15 años atras cuando hablaba...(read more)

[PM] Estimaciones Agiles, no Extremas

Lucas Ontivero — Wed, 19 Mar 2008 04:45:19 GMT

Primero lo primero Hace poco comentaba en un post de Rodrigo Corral sobre algunas de las desventajas de un método de estimación que el mencionaba como método ágil y rápido: el Plannig Poker . Luego, Rodrigo me responde con un post en el que intenta rebatir cada una de mis afirmaciones. Una excelente noticia es que al menos el capítulo 6 del libro Agile Estimating and Planning (by Mike Cohn) que trata, entre otras cosas, sobre Plannig Poker está disponible para leerlos en pdf desde acá . Lo primero...(read more)