Crunch Time: Mala practica en gestion de proyectos
2008-04-18 | Categories: Articles, Management | Tags: agile
Si no saben que es Crunch Time pueden revisen este post. Crunch Time es una de las malas practicas más generalizadas en la gestión de proyectos informáticos y consiste en exigir a los miembros del equipo a trabajar mas horas y a trabajar fines de semanas o feriados.
¿Por qué llegan la mayoría de proyectos al Crunch Time? Hay diferentes razones y entre ellas podría mencionar:
- Mala definición del alcance del proyecto: Si al definir el alcance del proyecto solo intervienen los vendedores, el cliente y el jefe de proyecto entonces todo saldrá mal. Los vendedores solo quieren vender y tienen de bajar tiempos, recursos con el fin de vender aun así sepan lo que pasará. Los clientes muchas veces no saben lo que quieren o quieren algo que es imposible realizar con el tiempo y dinero que pueden invertir. Los jefes de proyecto por lo normal tampoco saben de tecnologías y no piden un juicio experto (consultan al arquitecto de software)
- Mala estimación de tiempos: Tiene que ver mucho con lo anterior. El cliente quiere que todo sea rápido. El vendedor promete un tiempo para convencer al cliente sin consultar si es viable. El jefe de proyecto trata de cumplir con lo imposible porque ya todo esta bajo contrato, etc.
- Mala estimación de cantidad de recursos: A menos recursos más ganancia (vendedor), menos costo (cliente). El jefe de proyecto tendrá que exigir más y más al equipo.
- Over-engineering: Hacer más de lo que necesita el cliente, un ejemplo clásico es tratar de hacer un sistema extremadamente flexible. Al final el cliente nunca necesitará aprovechar esa extrema flexibilidad y peor aún esa flexibilidad no funciona correctamente.
¿Que resultado obtendremos con esto?
- Un equipo desmotivado y por ende un mal producto
- Un cliente enojado debido a que el tiempo, costo y calidad del producto no es el esperado
- Los miembros del equipo van renunciando, esto lleva a que en el siguiente proyecto se cometan los mismos errores
Y al parecer nadie aprende de estos errores, nadie trata de cambiar:
- Enseñar a los vendedores sobre tecnologías y que siempre consulten al arquitecto de software
- El arquitecto de software debe lo suficientemente fuerte para poder decir las cosas como son y no callar
- Presentar al cliente opciones factibles/reales para solucionar sus necesidades. Si quiere menos costo o tiempo disminuir las funcionalidades para mantener la calidad del producto. De que le sirve al cliente un producto que se entrego a tiempo y con los costos exactos y no es de buena calidad. Tarde o temprano el producto será más y más costoso para el cliente.
- El jefe de proyecto debe negociar y no tratar de cumplir por cumplir
- Documentar las experiencias adquiridas sean buenas o malas para tomarlas en cuenta en los siguientes proyectos
Y mi recomendación final: Digan NO al Crunch Time!!!! o cobren mucho mucho mucho mas!!!! 
Dedicado a mis amigos que en estos
momentos están en Cruch Time.
2008-04-03 | Categories: Articles, Technology | Tags: architecture
Ayer hablando con un amigo sobre realizar un podcast del rol del arquitecto de software, me sorprendió con su primera reacción:
Estas seguro que el Perú esta preparado para saber lo que realmente tiene que hacer un arquitecto de software
Wow!, nunca lo había planteado en esos términos pero si estoy convencido que hay mucho por mejorar y replantear respecto al rol del arquitecto de software en el Perú. No hay un consenso generalizado sobre este tema, en ningún lado y menos espero lo que lo haya en el Perú.
Este tema va a ser muy interesante para un podcast y mucho mejor si los participantes no comparten las mismas ideas. Pero lo primero lo primero, dentro de unas horas voy a publicar el tercer episodio de modlost.net radio, luego me concentraré en el podcast de arquitectura y haré un post preliminar para calentar la discusión.
2008-04-03 | Categories: Articles, Technology | Tags: programming
¡La programación es una parte vital de todo proyecto de desarrollo de software! Lamentablemente hay personas que creen que no es así y solo piensan en contratar mano de obra barata, dando como resultado proyectos con mas problemas de lo normales. En fin, ese es otro tema y lo trataré en otro artículo.
Hay diferentes formas de ver la programación:
- Como algo que no te gusta pero tienes que hacerlo porque esta en tu curricula.
- Como algo que no te gusta pero tienes que hacerlo para luego poder comenzar como programador pero dejarlo lo mas pronto posible para poder luego postular por un puesto de analista programador, analista, jefe de proyecto, etc.
- Como algo que no te apasiona pero que tampoco te parece terrible hacerlo.
- Como algo que te apasiona y te interesa aprender más y más.
- Como un arte.
Este artículo va orientado para todos los apasionados por la programación y mas aun para los que ven la programación como un arte.
Finding file names without dots in their names
2007-10-08 | Categories: Articles, Technology | Tags: linux, unix
Yesterday, I received an interesting question in a company where I’m a consultant. They wanted to find all file names in the source code of “XYZ” application without dots in their names so they were looking for the easiest way to do this task in GNU/LiNUX.
I’ve never needed to do that kind of search so I’ve recommended to read find command man page and use regular expressions. At home, I’ve found an nice way to do this task:
modlost@optimus:~/tmp$ mkdir -p testdir/1/2/3
modlost@optimus:~/tmp$ touch testdir/1/withoutdots
modlost@optimus:~/tmp$ touch testdir/1/2/with.dot
modlost@optimus:~/tmp$ touch testdir/1/2/3/withoutdots
modlost@optimus:~/tmp$ find testdir -type f -regex '[^.]*'
testdir/1/2/3/withoutdots
testdir/1/withoutdots
2007-08-29 | Categories: Articles, Technology | Tags: foss, java, linux
Geronimo 2.0.1 has been released! There are a lot of new features, all of them made Geronimo a fully compliant and certified Java Enterprise Edition 5.0 container. So, it’s time to play with it!
Getting binaries
First of all, we have to download JDK 1.5 or greater from here. If you prefer, you could use the default package of your favorite distribution but in my case, I usually need different versions of JDK, so, I prefer to manage the JDK by myself.
modlost:~$ ls ~/download
jdk-6-linux-i586.bin
A good question is where we will install that JDK?, well, It’s better to follow FHS and try to keep everything clean in your hard disk. It’s difficult sometimes but It’s better for maintenance. Let’s install JDK in /opt directory.
modlost:~$ mkdir -p /opt/java/sun/
modlost:~$ cp ~/download/jdk-6-linux-i586.bin /opt/java/sun
modlost:~$ cd /opt/java/sun
modlost:/opt/java/sun$ chmod 755 jdk-6-linux-i586.bin
modlost:/opt/java/sun$ ./jdk-6-linux-i586.bin
Acegi Security: Custom Authentication
2007-05-31 | Categories: Articles, Technology | Tags: foss, security, spring
I’ve been using Acegi Security in several projects with good results. It’s powerful and flexible! Sadly, sometimes, developers have problems when they want to customize it. The code is the best documentation, so, I recommend them to read the code and javadocs. Well, this time I’ll show you how to customize the authentication. I assume a good knowledge of Spring Framework and basic knowledge of Acegi Security.
1: <bean id="authenticationProcessingFilter" 2: class="org.acegisecurity.ui.webapp.AuthenticationProcessingFilter"> 3: <property name="authenticationManager" ref="authenticationManager"/> 4: <property name="authenticationFailureUrl" value="/login.htm?login_error=1"/> 5: <property name="defaultTargetUrl" value="/foobar.htm"/> 6: <property name="filterProcessesUrl" value="/j_acegi_security_check"/> 7: </bean>
You usually define a bean like authenticationProcessingFilter and add it to a chain in the FilterChainProxy bean. With this configuration, you attempt to authenticate when a request to /j_acegi_security_check has been made, delegating the authentication to the authenticationManager bean. If everything is OK, the user is redirected to /foobar.htm otherwise to /login.htm?login_error=1
