Requerimientos en SCRUM

Otro buen post de Navegapolis es este en el cual se describe una rutina para la obtención de requerimientos con SCRUM, esto caera de perlas a los agilistas. !Muy bién Navegapolis!.

Documentación de Proyectos

Ervin Sarkisov propone un índice para el orden de almacenamiento de documentos de un proyecto, pareciera una cosa tan trivial pero tan importante en la administración del conocimiento.

Evaluando herramientas de requerimientos

Forrester Research a través de Methods and Tools pública un estudio de varias herramientas de requerimientos muy interesante para aquellas áreas  o empresas que están convencidas de que el principal problema de los desarrollos de software son debido a un mal trabajo de requerimientos.

Dedicado a Navegapolis

Hace algun tiempo que no leía a Juan Palacio pero al ver mi bloglines me encuentro con varios post por demás interesantes, son los siguientes:

Observatorios de innovación, recuerden que pronto vendrán los capitales intelectuales y uno de ellos es la innovación.

Dilbert, programación ágil, simplemente genial.

Herramientas Case para determinar cuando acabará un proyecto.

Enfrentarse a cambios

Me ha parecido interesante el post Enfrentarse a cambios desde un blog de management tema del cual leo mucho, y por que me ha sido interesante? porque definitivamente va de la mano con la administración de proyectos, el post habla de las fases o como lo comenta el autor de las "habitaciones" por las que se pasa en situaciones de la vida real o bién en el ámbito profesional, sin duda muy interesante para los administradores de proyectos.

El viaje de 1000 millas comienza con un simple paso

Y que mejor paso que hacer un buen trabajo de requerimientos, Catalyze presenta 10 small steps to better requirements, definitivamente debe de estar dentro de nuestros favoritos.

Business Intelligence - SAP

Otro post interesante de Innova es el de Business Intelligence y Data Warehouse en SAP en el cual se presenta algunas herramientas de BI así como interesantes links con respecto a SAP-BI.

Algo de MS SQL Server 2008

Innova Desarrollos presenta este post sobre MS SQL Server 2008 en el que se presentan interesantes links de la nueva versión de SQL Server.

Negocios o Empresas?

Considero que como profesionales también nos debe interesar el tipo de empresa en la que trabajamos o tal ves trabajamos en un negocio, pero cuales son las diferencias?, este es un gran post que menciona precisamente las diferencias entre negocios y empresas o como decimos aquí en México Changarrotes vs Empresas.

Humor en la Administración de proyectos

No cabe duda que es mejor la vida con humor y que mejor que tomar con humor la situaciones que se dan en los proyectos de software, El cafe de Joe nos presenta una página donde podrás crear tu propia versión de los proyectos de software su nombre Project Cartoon. (gracias Joe no conocía la página).

y como andamos en sueldos?

Para retomar las entradas, Software Guru presenta un estudio de los sueldos en TI, resalto lo siguiente:

Los arquitectos de software ya ganan mas que los Project Manager
Ya gana mas un experto en .NET que el especialista en JAVA (el año pasado era al reves)
Me llama la atención que no este el rol de Developer o de Ingeniero de Requerimientos (por que lo habran omitido?)

Sin duda un estudio para analizar y para ver como van las tendencias.

Estudio de Salarios

¿Por que es tan importante la fase de requerimientos? Requirement Engineering: A Roadmap

Si no convencen las estadísticas de por que los proyectos de desarrollo de software fallan, pues vayamos a los números que es donde mas duele, y para eso este post nos servira mucho.

Ojala las empresas Mexicanas se convenzan de la importancia de prepararnos para afrontar esta fase, invertir en tiempo en software para controlar esta etapa, en la contratación de gente preparada en el área de requerimientos cuando suceda esto y en conjunto con el dominio de las tecnologias de desarrollo (entiendase arquitectura y programación) pasaremos a otro nivel en el ámbito mundial de desarrollo de software.

Estimando Proyectos

Desdel el blog de Ervin Sarkisov encuentro esta entrada la cual puede ser de mucha utilidad para empresas de desarrollo y en especial para aquellas áreas que hacen la estimación de un proyecto, ya que esta es una de las partes mas dificiles dentro de la ingeniería de software ya que a diferencia de otras industrias donde los productos o servicios son mas tangibles el desarrollo de software se torna dificultoso la estimacion dadas las características de este tipo de proyectos.

La ambigüedad, durmiendo con el enemigo

Falta de análisis, obviar las cosas, subestimar ciertas etapas del proyecto son grandes razones por las que los proyectos fallan, en mi experiencia puedo decir que estos factores me dieron muchos dolores de cabeza en algunos proyectos, para solucionarlo pueden haber muchos tips desde la redacción del documento de requerimientos pero sin lugar a dudas la experiencia cuenta mucho, el saber tratar al cliente, el obtener del cliente lo que se busca sin desesperarlo y tener una visión de lo que puede suceder son grandes armas para evitar dormir con el enemigo.

 

Gran post desde el catalizador.

SEI - ITESM

Apenas me entero de esta noticia de colaboración entre el SEI y el ITESM (una de las escuelas mas prestigiadas en México) donde el objetivo es la adopción de PSP (Personal Software Process) y TSP (Team Software Process) metodologías creadas por Watts Humphrey, me da mucho gusto la noticia ya que he visto los beneficios en específico de PSP, espero esto detone mas la industria de software en mi querido país México así como en el estado que radico.

Aquí la noticia

Defining IT Projects

En RNQ se pública un estudio de Scott Ambler acerca de lo que es el éxito del proyecto el cual resulta interesante porque a decir del autor no coincide con lo que Standish Group da como definición, y en este aspecto dare mi opinión considero que el éxito del proyecto se puede ver desde varios enfoques en específico 2 desde el punto de vista del cliente y desde el punto de vista de la empresa que desarrolla el proyecto (hablando de proyectos de TI). Hay clientes que por ejemplo el tiempo no es tanto problema (claro esta con un margen razonable de desvío) con tal de que se entregue lo pactado en funcionalidades y costo, esto quiere decir que los retrasos los absorverá la empresa que desarrolla pero para esta  es vital que el proyecto se termine en el tiempo establecido por que sino se corre el riesgo de perder rentabilidad en el proyecto.

Comentarios de JAVA

Había escuchado hablar y constatado en mi poca experiencia de que JAVA es muy pesado y que es su talón de aquiles, mas alla de eso todo lo demas eran buenos comentarios, pero me encuentro en este post algunos otros inconvenientes de JAVA. Cabe resaltar que ese mismo problema lo encuentro en Microsoft software por aqui, software por aca, bajar esto, bajar esto otro, creo que las complicaciones serían menos si todo se pudiera integrar o clasificar de una manera mas sencilla, alguna vez escuche a alguién decir Lo que no es facil o práctico esta mal hecho, sera cierto??? creo que algo hay de eso.

Inventing Requirements

Como me hizo recordar experiencias con clientes este artículo, se comenta en el artículo lo siguiente 'The system does not sort the list alphabetically' when nothing in any requirement specified any particular sort order' Que opinan? hasta que punto es problema de una empresa de desarrollo el que se omitan este tipo de funcionalidades y hasta que punto es culpa del cliente que no nos dijo que se debe ordenar una lista alfabeticamente?, desde mi punto de vista el Ingeniero de requerimientos debe ahondar mas en estos puntos porque dificilmente un cliente te los dira, es por eso que ahora esta tomando fuerza el Analista de Negocios quien debe saber aplicar la tecnología en beneficio del negocio pero que sobre todo sepa de procesos de negocio.

Free on line Books, desde Navegapolis

Hace mucho que no resaltaba algo de Navegapolis sera porque ando enfrascado mucho en el tema de administración de proyectos, por vasta echarle un ojo cada tercer dia a Navegapolis para ver los valiosos post que presenta Juan Palacio, en este caso Free on line Books.

In Defense of UML, RUP, and Application Design

Antes que nada perdón por poner el mismo título de la fuente de informacion en muchos de mis posts, pero es para darle todo el crédito al autor.

Me ha parecido controversial lo que comenta Frank Teti acerca de UML y RUP en algunas cosas comulgo con ellas pero en otras no, desde mi punto de vista en este mundo hay cabida para las metodologías ágiles y las formales creo que estan orientadas a diversos mercados o mas bien tipos de proyectos, el criticar una u otra metodología se me hace perder el tiempo y no ayuda nada a la industria y mas alla de eso puede confundir a los clientes, es como la pelea entre .NET y Java cual es mejor??? pues yo creo que los dos tienen sus pro y sus contras. Soy un amplio defensor de RUP y UML pero no quiere decir que no deje de ver las virtudes del mundo Agil de SCRUM o de FDD etc. En fin es un artículo para disfrutar.