modlost.net

A brand new version of Eclipse has been released!!!

This release includes ECF and Mylyn proyects!!! :D

Happy Birthday Eclipse RCP!

What is Eclipse RCP? Let's see what Eclipsepedia says about it:

"While the Eclipse platform is designed to serve as an open tools platform, it is architected so that its components could be used to build just about any client application. The minimal set of plug-ins needed to build a rich client application is collectively known as the Rich Client Platform"

IMO Eclipse RCP is an amazing way of developing rich client applications. Eclipse has a beautiful internal design that allows you to reuse and extend its functionality through plugins (bundles) so imagine that power in your rich client applications or even better in your web applications with Rich Ajax Platform or in your mobile applications with Embedded Rich Client Platform.

If you want something to read about Eclipse and Eclipse RCP I strongly recommend this books:

• Eclipse Rich Client Platform: Designing, Coding, and Packaging Java Applications
• Eclipse: Building Commercial Quality Plug-ins

The next week I'm going to give a mini-conference about Eclipse RCP and Eclipse Communication Framework (ECF) at PUCP!

En un día caluroso del verano limeño, Mr. Solis un típico jefe de proyecto y Ryan un típico arquitecto tienen esta atípica conversación:

I agree with every point of the Agile Manifesto and with almost all the agile practices. I believe that following an agile software development process is the right way to address most of the problems that we see in several projects nowadays.

So, why do I decide to take a PMI© Certification course?,.. well, I wanted to know more about PMI©, learn from it, modify it, adapt it to agile practices and write about everything I disagree/agree with. I just want challenge myself!

The course was divided in sections, one for each PMBOK© chapter. So I can read each chapter before class and prepare questions or topics for discussion in class. Yeah, that will be fun!

Well, as part of the Certification course my group has to develop all the documentation for a software development project reusing some templates that we received in the first day of class. This week, we had the first preliminary presentation of Project Charter and Preliminary Project Scope Statement documents. While I was looking the Preliminary Project Scope Statement template, I had a doubt about project phases because the template assumes sequential project phases and my partners defined them as: analisys, desing, implementatión, testing. OMG that's waterfall!!!

I asked about how can I show clearly that I'm following an iterative process in the Preliminary Project Scope Statement but I didn't receive a clear answer. Someone told me that PMBOK© assumes that project phases are sequential. Argggg!,... waterfall!!!

At night, taking a closer look in Chapter 2 - Section 2.1.2 - 3rd Paragraph, I found that PMBOK© uses as example an information technology project with iterative project life cycle!. In conclusion, PMBOK© assumes that most of the projects have sequential phases but there are exceptions like information technology projects using an iterative life cycle.

So it could be interesting to develop a template for Preliminary Project Scope Statements that assumes parallel and sequential phases and a mix of them.

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!!!! :P

Dedicado a mis amigos que en estos
momentos están en Cruch Time.