20.11.2008

Tipos de tareas en MS Project

Os dejo un documento word, que ha creado nuestro querido compañero Jorge Aranzabal y donde se explica los diferentes tipos de tareas que tiene MS Project y sus relaciones entre sí.

Tipos%20de%20tareas.docx

Yes we can!!

03.11.2008

Métodos extensores en VB9

Una de las novedades que trae la nueva versión de VB9 son los métodos extensores.
Los métodos extensores son métodos que nos permiten extender la funcionalidad de cualquier clase, ya sea de nuestro proyecto, del mismo .net framework, o de terceros. Esto nos puede venir bien en ocasiones para aumentar la funcionalidad de clases cerradas sobre las que no tenemos control al código fuente.
Definir un método extensor es sencillo. Se definen a nivel de módulo, ya que no necesitan de una instancia en concreto (en C# se definen en clases státicas). Además del módulo, hay que incluir el atributo Extension() al método extensor. El atributo extensión, pertenece al namespace System.Runtime.CompilerServices. El primer parámetro de nuestro método, será la clase sobre la que estamos extendiendo su funcionalidad.
Vamos a ver esto con un sencillo ejemplo donde extendemos la clase String de .Net y le añadiremos un método ToTitle que formatea el string con la primera letra en mayúsculas y el resto en minúsculas (fácil, rápido y para toda la familia!)

”’ Para indicar que es un metodo extensor, debe llevar el atributo Extension
_
Public Function ToTittle(ByVal str As String) As String
Try
‘ Saca la primera letra y la convierte a mays
Dim primeraLetra As Char
primeraLetra = str.Chars(0)
primeraLetra = Char.ToUpper(primeraLetra)

‘ Saca el resto de la frase y la pasa a mins
Dim restoFrase As String
restoFrase = str.Substring(1).ToLower

Return String.Format(“{0}{1}”, primeraLetra, restoFrase)

Catch ex As Exception
Throw ex
End Try
End Function

Una vez hecho esto, podemos utilizarlo desde:

Console.WriteLine(titulo.ToTittle())

En la siguiente imagen se puede ver como el Intelisense, detecta el método extensor y lo marca con un icono concreto:

Fijaros como incluso aparece la descripción del método que le di en la cabecera de la función:

”’ Metodo Extensor de la clase string, que formatea una cadena
”’ donde la primera letra la convierte a mays y el resto a mins

Invocar método sin extender

Si queremos invocar al método como un método “normal”, simplemente lo indicamos anteponiendo el nombre del módulo:

ExtensionesString.ToTittle(titulo)

Sobrecarga de métodos extensores

Sí, se puede!!, vamos a sobrecargar nuestro método extendido para que formatee el título como si fuera de un índice: “1.- Titulo de la sección”

_
Public Function ToTittle(ByVal str As String, ByVal orden As Integer, ByVal espacios As Integer) As String

Lo mismo para usarlo, pero pasando los parámetros requeridos para esa sobrecarga:

titulo.ToTittle(3, 5)

Pero, aquí quien manda???

Si tenemos un método extensor, que coincide con el mismo nombre y firma que un método interno, siempre se ejecutará el método interno a la clase.

Distribuyendo métodos extensores

Si distribuimos nuestro proyecto con método extensores, debemos tener en cuenta que en VB, cuando no se declara el alcance de un módulo, éste se asume como Friend, por lo que al distribuirlo y usarlo desde otro proyecto, no funcionará. Simplemente debemos definir nuestro módulo como Public para que pueda ser usado desde otros proyectos.

Si queréis saber más sobre el tema, os recomiendo:

Extension Methods: http://msdn.microsoft.com/en-us/magazine/cc163317.aspx
DotNetMania nº 50 (artículo de “El Guille”)

Os dejo el código fuente con el proyecto que he usado para el ar´ticulo y donde podéis ver todo esto funcionando: MetodosExtensores.zip

Nos vemos en la siguiente parada!!

30.10.2008

La importancia de gestionar el CAMBIO

A ver si os suena!
Día 29 de Octubre, llueve, pero eso no viene al caso! El director de mi área me está metiendo un paquete porque mi último proyecto lleva un retraso en la entrega, y con un avance del 80%, ya hemos consumido todo el presupuesto del proyecto! tierra trágame!!
Pero esto no ha pasado de la noche a la mañana, así que hagamos un flashback al más puro estilo de “perdidos”!

1 de Marzo (curiosamente hace sol), he tomado los requisitos del cliente, están por escrito en un documento que él mismo ha validado y construyo mi Project plan! me han asignado un equipo estupendo y tengo una línea base que me garantiza una rentabilidad alta y una fecha de entrega acorde a las necesidades del cliente! preparados, listos, ya!! Arrancamos el proyecto!

Los días pasan, el proyecto avanza, y de repente, suena el teléfono! Es el cliente, tras nuestro primer prototipo de la aplicación, ha decidido que el titulo de ésta debe estar más a la izquierda y en un color más “atractivo”! fácil, no? Tú traduces “atractivo=rojo”, lo haces y lo presentas! vaya, parece que el rojo no es atractivo para el cliente, seguimos buscando hasta que finalmente, acepta un verde azabache que tú ni si quiera conocías. Bien!! Ya lo tengo, seguimos con el proyecto!

Bueno, como ya habréis adivinado, el cliente hizo alguna que otra llamada más, el proyecto inicial poco tuvo que ver con el final y como consecuencia, pérdidas. El proyecto cambió en varias ocasiones, pero esos cambios no estuvieron gestionados. Por favor, no nos sorprendamos, como dice un gran sabio, “lo único que no cambia, es que todo cambia”. Simplemente asumamos que esto pasará y aprendamos a gestionarlo adecuadamente.

Como Jefes de proyecto, debemos gestionar el cambio. Una vez que se nos presenta un cambio, que puede venir no sólo del cliente, sino también de un usuario, de un técnico, de otros responsables! Lo primero que debe hacerse, es un análisis de la solicitud, estudiando cómo va a impactar dicho cambio en nuestro proyecto, no sólo en la triple restricción (alcance, tiempo y coste), sino también en la calidad del proyecto y un factor muy importante que solemos olvidar, el impacto en otras áreas: cambiar de azul a rojo puede que no haya mucho problema, pero si eliminas un campo de la BD, asegúrate que no estás rompiendo nada que otras aplicaciones o áreas estén utilizando. Una vez analizado el cambio, se lo presentamos al patrocinador. El PMI (Project Management Institute), distingue entre el patrocinador, que sería la figura que financia el proyecto (pone la pasta) y el cliente, que es la figura que usará el producto o proyecto (lo que nosotros solemos denominar “usuario final”). Esta distinción es importante, ya que presentar el cambio al patrocinador, nos ayudará a que nuestro cambio se gestione correctamente, puesto que es él y no el usuario (fuente de la mayoría de cambios), quien lo va a pagar. Una vez presentado el cambio al patrocinador, solicitamos aprobación. Si el patrocinador rechaza el cambio, seguimos con la línea base inicial, si se aprueba, debemos actualizar la línea base y si lo tenemos, actualizar también el cuaderno de bitácoras del proyecto, para tener así todo un registro de los cambios producidos. Es vital actualizar la línea base!!! El proyecto está vivo y ya no es el proyecto inicial. Tras esto, sólo queda desarrollar el cambio e informar del mismo a otras áreas que puedan estar afectadas de alguna forma.
Al final es un sencillo flujograma que hace la vida más fácil al JP:

El no gestionar los cambios, es una de las principales causas de desvíos en el proyecto, gestionemos el cambio y tendremos mucho ganado!!

Un saludo!!

27.10.2008

Algo que contar

Hola!!

Mi nombre es Luis Mañez y trabajo en ENCAMINA como Responsable de Arquitectura y Tecnología, después de 7 años en el mundillo, me siento con fuerzas para sacar un blog adelante… Qué podréis encontrar por aquí, pues un poco de todo, de ahí el título de este post, pero sobretodo, temas relacionados con la arquitectura SW, desarrollo en .NET, dirección de proyectos, liderazgo, gestión del tiempo y casi cualquier cosa que me parezca interesante y que quiero que no se me olvide :)

Nada más, espero que algún post les parezca interesante.

Muchas gracias por la visita.
Hasta pronto!!

Luis.