Lucas Ontivero : Gestion de Proyectos

¿Quién quiere ser líder de proyectos?

Lucas Ontivero — Fri, 25 Nov 2011 02:59:05 GMT

Hace un par de semanas atrás estábamos reunidos todos los líderes de proyectos y líderes técnicos del sitio de Córdoba porque nos visitaba uno de los mandos altos de la empresa, luego de tratar una serie de asuntos, este preguntó a los TLs ¿Alguno de Uds. piensa ser líder de proyectos y seguir la carrera de management?. De los 15 o 20 TLs ninguno levantó la mano.

Están bien frescas en mi memoria las incontables veces que he presenciado el intento de muchos desarrolladores por “escapar” hacia el paraíso del management. Muchas veces por tener un mejor salario, otras porque no les gusta programar pero quizás la mayoría de la veces es por una combinación de mal salario, poca satisfacción por lo que hacen y poco valor social de la especialidad; entre otras cosas.

Pero, ¿por qué ninguno de estos TLs quiere seguir la carrera de dirección de proyecto?, ¿no saben que $20.000* es mayor que $10.000**?, ¿acaso nunca escucharon eso de que dirigir es mejor que ser dirigido? Creo que la respuesta no viene por ese lado, la explicación es que existe una carrera técnica paralela a la de administración, que sus conocimientos técnicos son valorados de igual manera que los de aquellos que administran los proyectos, que tener la responsabilidad técnica de un proyecto contribuye al éxito del mismo de igual manera que la responsabilidad de aquellos que administran los recursos.

No sé lo que pensaré en 10 años pero si lo que pienso hoy: así debe ser.

* y ** son solo números inventados.

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.

Resultados con TDD en Microsoft, IBM, HP y Ericsson

Lucas Ontivero — Sat, 21 Aug 2010 13:08:52 GMT

Las recientes experiencias en la industria confirman que para obtener mejoras sustanciales mediante pruebas unitarias es necesario incorporar TDD (Test-Driven Development) como práctica integral del desarrollo. Aunque TDD no es una práctica nueva, solo experiencias recientes en Microsoft, IBM, HP y Ericsson comprueban la efectividad y factibilidad de ésta en proyectos reales y de reputación mundial. Los números de los resultados en realmente asombrosos. Les recomiendo leer las siguientes publicaciones...(read more)

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)

[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)

[PM] Métodos de Estimación - Resumen

Lucas Ontivero — Tue, 18 Mar 2008 01:16:18 GMT

Quiero compartir con vos un mapa conceptual sobre los distintos métodos de estimación de los que disponemos a la hora de afrontar una estimación de un proyecto de software. Este mapa muestra, entre otras cosas, los pros y contras de las distintas alternativas como así también las entradas requeridas por cada uno de los métodos. Esta entrada es parte de la entrada anterior sobre Estimaciones y Scheduling Avanzado y que seguramente se conertirá en una serie. (Hay que hacer click sobre la imagen para...(read more)