 | | |
| | |
|
Spaces home  Pablo AbianPhotosProfileFriendsMore |  Tools   |
Pablo AbianDesarrollo de Software y temas afines
|
|||||||||||||||
|
June 23 Gestion de Proyectos - Estimaciones...La semana pasada, uno de los desarrolladores con los que trabajo, me pregunto inocentemente: "¿Como hacen las estimaciones los Lideres de Proyecto?"
Por un momento pense en responderle algo como: "Los lideres de proyecto se dirigen al Oraculo y luego de arrojar las runas y leer en la borra del cafe, plasman en algo que llaman estimación de tamaño y esfuerzo, los valores obtenidos de la aplicacion de estas tecnicas diversas..."
Finalmente, le termine explicando algo mas aburrido, pero un poco (solo un poco) mas real:
1) TECNICAS DE ESTIMACION
En general, los lideres de proyecto terminan aplicando, junto con el equipo de desarrollo (esto si es importante), una o varias tecnicas de estimación (ver post de Lucas Ontivero: Metodos de Estimacion - Resumen). Es muy probable que, dependiendo de las caracteristicas de la organizacion, se deba aplicar obligatoriamente mas de una tecnica de estimacion y se exija contrastar los resultados obtenidos en cada caso a fin de "afinar" los resultados obtenidos. El exito en la aplicacion de una u otra tecnica de estimacion siempre debe analizarse en funcion de las caracteristicas particulares de cada proyecto y cada organizacion, ya que lo que funciono correctamente para otro proyecto de otra empresa no necesariamente debe funcionar para nosotros.
A titulo de ejemplo, les adjunto a continuacion el resumen de un informe de estimacion que me toco realizar hace unos años, para la cual se aplicaron distintas tecnicas combinadas:
- Aplicamos un template de estimación para estimar el tamaño y esfuerzo (sobre la muestra del punto 1).-
B) Actividades (Procedimiento)
En base a estos 4 elementos realizamos las siguientes actividades:
1) Definicion de la muestra de Casos de Uso
2) Analisis de los Casos de la muestra
3) Categorizacion de los Casos por complejidad
4) Cálculo del esfuerzo correspondiente a la muestra en base a valores historicos por caso de uso y complejidad
5) Extrapolacion del esfuerzo total del proyecto a partir de la muestra
6) Analisis de Riesgos Grales del Proyecto
7) Ajuste de los valores totales de la muestra y el proyecto completo en base a:
- Disminución del peso de las actividades de Gestión de Requerimientos y Analisis y Diseño (-10% del esfuerzo total) (Modalidad Software Factory).-
- Ajuste por riesgos inherentes al proyecto (+20%):
- Escaso Nivel de conocimiento del negocio del cliente
- Requerimientos de Software incorrectamente definidos (los ya existentes)
- Volatilidad de los requerimientos de Software (50 casos que aparecieron a ultimo momento...)
- Falta de Definicion de la plataforma (Framework)
8) Se realizo una segunda estimación de la muestra (técnica alternativa), basada en herramientas estándares de estimación de la organizacion, la cual fue contrastada con la obtenida a partir de datos históricos; pero la misma fue descartada por arrojar valores que consideramos demasiado "pesimistas" según nuestra experiencia.
9) Finalmente se sometieron los valores obtenidos en el punto 7 al Juicio Experto de:
- Desarrollador Senior (1)
- Lider de Proyecto Senior (1)
10) Se modifico el valor de ajuste por riesgo del punto 7 - valor final: (+30%)
C) Valores Obtenidos
MUESTRA
1) Valor Total de la muestra de 40 Casos de Uso: 1400hs
2) Ajuste -10% por disminucion del peso de los workflows (RM y AyD): -140hs
3) Ajuste +30% por riesgos del proyecto: 420hs
4) Valor Final de la muestra: 1680hs
PROYECTO
1) Valor Total Aproximado (400 Casos de Uso): 16.800hs"
2) SIGNIFICADO DE LAS ESTIMACIONES
Las estimaciones son ESTIMACIONES, no dictamenes u ordenes que DEBAN verificarse inexorablemente en la practica (sobre todo si uno no hace nada al respecto durante la ejecucion de los proyectos).
2.a) Segun la RAE (Real Academia Española) el termino "estimacion" significa:
estimación.
1. f. Aprecio y valor que se da y en que se tasa y considera algo. 2. f. Aprecio, consideración, afecto. Ha merecido la estimación del público. Es objeto de mi estimación. 3. f. ant. Instinto de los animales. Esta claro que en este contexto la acepcion nro 2 no aplica, pero la 1 y la 3 si (ojo al tema del instinto). 2.b) La WIKIPEDIA dice al respecto de "Estimation"
"Estimation is the calculated approximation of a result which is usable even if input data may be incomplete, uncertain, or noisy." Aca vemos el termino "aproximacion" y, lo que es muy interesante, se citan "DATOS DE ENTRADA incompletos, inciertos o con ruido".- Es clara la necesidad del cliente de dimensionar, durante el inicio de un proyecto, el esfuerzo total o la inversion asociada a la ejecucion del mismo. Pero no debemos perder de vista que la bondad de la estimacion esta en relación directa con la calidad y claridad de la informacion con que se cuente al momento de estimar. O sea, nuevamente estamos hablando de una estimacion y no de un dictamen exacto que si o si deba verificarse sin esfuerzo por parte de todos los involucrados.
3) ESTIMACIONES Y GESTION DEL PROYECTO
Independientemente de la bondad de las estimaciones hay un elemento relacionado que me parece importante destacar aunque parezca OBVIO. Es claro que los proyectos deben ser planificados y en el marco de dicha planificacion, deben ser estimados para poder cuantificar la VISION que tienen el lider y el equipo y en base a eso tomar algun tipo de compromiso. Pero a veces NO es tan claro que para que dichas estimaciones puedan cumplirse es necesario gestionar permanentemente el proyecto, teniendo en cuenta la realimentacion que el propio equipo y los clientes van generando.
Este punto es muy importante y tiene que ver con la participacion de todos los integrantes del equipo. Si un desarrollador acuerda con el Lider de Proyecto que una determinada tarea puede ser realizada en XX horas, es muy importante que al primer inconveniente o desfase respecto de la estimacion, dicha novedad sea comunicada inmediatemente al Lider de Proyecto y el resto del equipo, para poder tomar medidas al respecto y eventualmente plantear una reestimación. No sirve que nos enteremos una semana mas tarde. En otras palabras, si bien el cumplimiento de las estimaciones es responsabilidad fundamental del Lider de Proyecto, se requiere de una permanente y fluida comunicacion entre todos los integrantes del equipo para alcanzar dicho objetivo.
May 27 Sotaneitors - La Banda de Desarrollo (H+A)Desde hace un año, los muchachos del area de Desarrollo tienen una banda de rock: "Los Sotaneitors". Aca les paso un link a un video donde estos audaces desarrolladores hacen un cover de un conocido tema de Leon Gieco. Cita Pensar en nada Sotaneitors#ml=o%3d7%26fk%3dPensar%2520en%2520Nada%26fx%3d May 11 Evento - Interoperabilidad en Salud en ArgentinaEl 21 de Abril pasado tuve la suerte de participar en el evento "Interoperabilidad en Salud en Argentina", organizado por la SADIO, SAIS y AMA (Asociacion Medica Argentina), llevado a cabo en las instalaciones de esta ultima. Desarrollo del evento 1) La presentación inicial del evento estuvo a cargo de los Dres. Alan March (Presidente SADIO), Ricardo Herrero y Martín Díaz, quienes informaron sobre el convenio firmado entre SADIO y AMA para el desarrollo de actividades conjuntas en el campo de la Informática en Salud que comienzan con la presente jornada. 3) Luego, el orador principal, Mead Walker, del HL7 Review Board (USA), brindo dos conferencias: "HL7 Versión 3: ¿Cuál es el grado real de adopción en el mundo?" y "Etiquetado estructurado de productos: una norma CDA para insumos médicos". Fue muy interesante ver la presentacion de la estructura del RIM (Reference Information Model) de HL7 v3 basada en diagramas UML. 4) La siguiente charla: "Conectividad entre prestadores y financiadores basada en HL7. Experiencia después de 5 años", a cargo de Eduardo Del Piano (Swiss Medical Group), trato sobre un caso concreto de integracion de procesos de negocios basada en HL7. Lo aspectos que me parecieron mas destacables de esta presentacion fueron el caracter asociativo del proyecto, que fue llevado adelante por un grupo de varias empresas de medicina prepaga, competidoras entre si, las cuales aunaron esfuerzos tras un objetivo comun y la aplicacion concreta de un estandar como HL7. 5) "Conectividad para la gestión de medicamentos mediante HL7" - Presentacion a cargo de Pablo Giraud (Farmalink). Otro caso de negocios concreto basado parcialmente en la implementacion de HL7. La guia de implementacion resultado de este proyecto puede encontrarse en http://www.sais.org.ar/Biblioteca/Estandares/tabid/118/Default.aspx 6) Finalmente, la ultima presentacion, brindada por Roberto Schatz (Microsoft Argentina): "Interoperabilidad para la Salud en Microsoft de Argentina", describio brevemente la vision de Microsoft acerca de la interoperabilidad no solamente a nivel del mercado de la salud, sino tambien de foma mas amplia en el ambito del estado (e-gov) y el ambito privado. Todas las presentaciones de los oradores las pueden encontrar en la página de la SAIS o haciendo click aquí: http://www.sais.org.ar/Eventos/InteroperabilidadOto%C3%B1o08/tabid/132/Default.aspx
May 10 Modelado de Negocios - La búsqueda de la simplicidadEsta semana participe de una charla en la cual se discutieron distintas metodologias y tecnicas de relevamiento y modelado de negocios. Los desarrolladores proponian utilizar modelado con UML para describir el "negocio" del cliente y justificaban esta eleccion en los siguientes aspectos: 1) UML es un estandar universal 2) En caso de trabajar con Orientacion a Objetos se pueden disminuir las "brechas" entre el modelo de negocios y las especificaciones funcionales y de diseño del Software. En la actualidad, incluso pueden aplicarse transformaciones que permiten pasar de un modelo a otro de forma bastante simple. 3) La notacion en general es lo bastante sencilla como para ser interpretada por los usuarios. Si bien los casos de uso de negocio pueden resultar un poco complicados de leer al comienzo, con un poco de capacitacion y un uso inteligente de los mismos, pueden volverse una herramienta de comunicacion y validacion importante. Algunos de los gerentes con mas experiencia, luego de escuchar la propuesta de los desarrolladores la objetaron porque consideraban que los casos de uso NO son utiles para trabajar en las instancias de relevamiento y modelado con los usuarios. En su experiencia, las etapas de modelado de negocios y especificacion de requerimientos son las mas criticas del proyecto, ya que alli se deberian construir los acuerdos y compromisos sobre lo que debe construirse en las etapas posteriores del desarrollo, y los casos de uso (UML en general) no son lo suficientemente sencillos para ser utilizados directamente con los usuarios. Finalmente, propusieron que se buscara alguna otra notacion o lenguaje mas simple para trabajar con un usuario que normalmente no tiene tiempo ni ganas de participar en el relevamiento o la validacion de requerimientos (!). En ese punto, me di cuenta de una cosa: el problema no tiene que ver solamente con la "simplicidad" de la notacion o lenguaje utilizado, sino también y en gran parte con las expectativas del usuario / cliente. 1) Simplicidad Si bien me parece razonable buscar la simplicidad de las cosas y soy una persona que promueve la busqueda de lo simple en todas las etapas del proceso de desarrollo de software (ver El Famoso Cartelito: "Lo simple es bello"), hay casos en los cuales la problematica bajo analisis NO es simple. Ante un dominio complejo, pueden buscarse aproximaciones Top - down que permitan partir de una vision inicial simple del mismo y permitan progresivamente ir aumentando el nivel de detalle de las partes bajo analisis, pero finalmente se va a terminar obteniendo un modelo / software tan complejo como el dominio del que partimos. 2) Expectativas de los usuarios / clientes Si los usuarios esperen poder describir (o descubrir) sus procesos de negocios y sus requerimientos en una o dos reuniones de una hora, para luego en base a dicha definicion construir un software que va a brindar soporte a dichos procesos durante años, empezamos mal. Tanto las metodologias agiles como las ingenieriles son muy claras respecto de la participacion y compromiso por parte de los usuarios / clientes. Ambas visiones establecen como factor de exito de cualquier proyecto de desarrollo la participacion y compromiso de los usuarios. Es mas, en el caso de las metodologias agiles, como por ejemplo XP, incluso se requiere la participacion permanente del usuario en caracter de miembro del equipo, contribuyendo a generar y validar las historias de usuario, validar las versiones del soft que se van generando, etc. Para ir terminando, recomiendo primero no abusar de la busqueda de la simplicidad, como supo decir Einstein: "las cosas deben ser simples, pero no mas de lo que deberian". En segunda instancia, independientemente de la metodologia aplicada, es muy importante comprometer a los usuarios / clientes desde el comienzo del proyecto, aclarando de entrada que VAN a tener que participar permanentemente de las instancias de relevamiento, especificacion y validacion de requerimientos y prototipos, pruebas UAT, etc. Prometer el exito del proyecto sin esfuerzo y compromiso, es poco realista y generalmente solo termina frustrando las expectativas de todos los involucrados.- April 15 MUG - Córdoba. Seminario Gratuito: La Evolución en el Desarrollo de SoftwareCharla interesante del MUG: El Grupo de Usuarios Microsoft le invita al seminario gratuito que se realizará el jueves 24 de abril de 2008, de 18:30 a 21:30 hs en el Aula Magna UTN Facultad Regional CORDOBA - Maestro M. López esq. Cruz Roja Argentina, Córdoba Por su contenido, este seminario interesará a profesionales y estudiantes que deseen reflexionar sobre arquitecturas y metodologías actuales. Quienes desarrollan software, encontrarán muy interesantes los ejemplos que se expondrán durante la conferencia los cuales reunirán gran parte de las prácticas recomendadas.
Estarán a cargo de la presentación Eugenio Serrano y Daniel Calvin. dos profesionales de rica trayectoria, integrentes del Grupo de Usuarios MIcrosoft. Eugenio es MVP en ASP.Net. Posee gran experiencia en proyectos transaccionales, herramientas de desarrollo y soft de gestión usando distintas tecnologías y es orador habitual para MSDN, TechNet y MUG. Por su parte, Daniel aquilata mas de 26 años creando soft de comunicaciones, compiladores, desensambladores, aplicaciones distribuidas y web, en vs plataformas y tecnologías. También publicó proyectos opensource para persistencia de datos y debug en tiempo de ejecución.
La forma de escribir aplicaciones ha recorrido un largo camino desde sus inicios. Desde la programación monolítica hasta la computación distribuida de nuestros tiempos, han surgido cantidad de nuevos escenarios que han planteado distintos desafíos. En respuesta a esos retos, se acuñaron nuevos conceptos y estilos, dando lugar a otras formas de encarar los problemas. Sin duda, el software ha evolucionado. Es mas, esa evolución es constante.
Hoy día, la construcción de software ha alcanzado un nivel de complejidad nunca antes visto, y nos encontramos con distintos paradigmas, los que a su vez promueven distintas modalidades de trabajo. Por otro lado, clientes y usuarios exigen aplicaciones cada vez más ricas y con mas funcionalidad, mientras que los gerentes presionan para que se cumpla con el presupuesto y con los tiempos. Este escenario en constante evolución, provocó a su vez la evolución de herramientas y metodologías. Arquitectura, diseño, metodologías, frameworks, generadores de código, ORMs, etc se han convertido, prácticamente, en nuevas especialidades que integran el bagaje conceptual del profesional del desarrollo de software. Durante esta presentación, se hará un recorrido siguiendo la evolución de las "formas de encarar el problema". Partiendo de un esquema monolítico se avanzará hasta llegar a una aplicación orientada a servicios, pasando por el esquema datacentrico y la programación orientada a objetos. Esto dará oportunidad de presentar los problemas que debe afrontar el desarrollador y los medios con los que cuenta para sortearlos Mas información e isncripción en linea: http://www.mug.org.ar/Eventos/2973.aspx
El evento es gratuito. Se requiere registración previa.
--
¡Gracias por tu visita!
|
||||||||||||||
|
|
Invite as friend
