Lo urgente y lo importante en la Gestión de Proyectos

Uno de los principales retos para todo Gerente de Proyecto, especialmente para los recién promovidos que se están iniciando como supervisores, es el poder manejar la cantidad de actividades, cosas por hacer, alertas y asuntos que conlleva un día de trabajo normal para este tipo de trabajo. En este artículo describimos como diferenciando entre asuntos urgentes e importantes se puede hacer una gestión efectiva de los proyectos. También se describen las consecuencias negativas de no hacerlo.

La diferenciación entre asuntos urgentes e importantes como método en la Gerencia fue descrito por Stephen Covey en su obra "Los siete hábitos de la gente altamente efectiva", es una herramienta útil para el Gerente de Proyectos para organizar su propio trabajo de día a día durante la fase de ejecución, pero también se puede aplicar a áreas especificas como por ejemplo la Gestión de Riesgos.

Presentamos a continuación el artículo de "Lo urgente y lo importante en la Gestión de Proyectos":

Los 5 valores de la programación extrema (XP)

La Programación Extrema “Extreme Programming” (XP) no es un conjunto de reglas a seguir, sino una forma de trabajar en armonía con los valores personales y organizacionales, que tiene su punto de partida en cinco valores fundamentales.

En este artículo, se describen los cinco valores de XP, que son: Comunicación, Simplicidad, Retroalimentación, Coraje y Respeto. Estos valores no son un simple ardid de mercadeo sino que realmente son parte integral de la metodología.

Los valores XP representan un excelente punto de partida para entender los cambios de paradigmas que implica trabajar bajo la filosofía ágil.

Les invitamos a leer y a contarnos, ¿Han aplicado los valores de XP en su trabajo?, ¿Que opinan del resultado?, ¿Cuales ventajas y desventajas han visto?. Les invitamos a dejar sus mensajes y preguntas en la sección de comentarios del artículo.

Presentamos a continuación los 5 valores de XP:

Errores comunes en el desarrollo de Bases de datos: Segunda Parte

Imagen de: Picasa Web Albums

En la semana anterior, publicamos un artículo titulado “Errores comunes en el desarrollo de bases de datos”, en el cual se exponían una serie de errores comunes y sus alternativas. Presentamos a continuación la segunda parte de esa serie, presentando errores comunes adicionales, como lo son: Hacer caso omiso de los índices a la hora de escribir consultas que relacionen tablas, no utilizar sentencias preparadas, usar instrucciones DISTINCT para no mostrar filas duplicadas, utilizar GROUP BY y HAVING para filtrar filas (en lugar de WHERE), colocar un cursor o consulta dentro de un ciclo y no utilizar herramientas para analizar el desempeño de consultas y procedimientos.

Este artículo fue elaborado con base a los comentarios recibidos de la comunidad y fuentes de información consultadas. Esta lista no es limitativa, seguramente el lector podrá pensar en muchos más errores comunes, ¿Considera que existe algún error que deba agregarse a la lista?, les invitamos a opinar en el foro de discusión del artículo (Tome en cuenta que los comentarios son moderados por lo que pueden tardar en ser publicados).

Los cambios de alcance en los proyectos de informática

Imagen de: Picasa Web Albums

En un entorno tan dinámico como el de los tiempos actuales, todo proyecto está expuesto a la posibilidad que ocurran cambios de alcance durante su desarrollo.

En proyectos de informática está prácticamente asegurado que una vez que el cliente vea el producto se requerirán “ajustes” respecto al diseño original, además, la necesidad del área de negocio podría variar desde el inicio del proyecto hasta su entrega.

En este artículo se discute los distintos tipos de cambios de alcance que puede enfrentar un proyecto de informática, los posibles impedimentos para negociarlos con el cliente y los peligros representados en los mismos.

Además se expresan una serie de pasos que se pueden seguir para gestionarlos con el cliente.

5 Preguntas y respuestas sobre el Feature Driven Development (FDD)

Imagen de: Picasa Web Albums

El Feature Driven Development (FDD) o “Desarrollo Enfocado por Funcionalidades”, es un método de desarrollo de software iterativo e incremental, que cuenta con comunidades de seguidores al igual que otros métodos como RUP, Scrum, XP, entre otros. En este artículo, describimos el método FDD, incluyendo Que es, cuáles son sus orígenes, si es considerado un método ágil de software, en que se diferencia de otros métodos y en qué actividades consiste.


Presentamos a continuación las 5 preguntas y respuestas sobre el FDD:

Errores comunes en el desarrollo de Bases de datos

Imagen de: Picasa Web Albums

Continuando con nuestra serie de artículos de errores comunes en el desarrollo de software, en este artículo presentamos 5 errores comunes en el desarrollo de bases de datos. Consisten en: uso excesivo de claves primarias (Primary Key), normalización inadecuada, uso excesivo de procedimientos almacenados (Stored Procedures), no usar claves primarias y usar “hard delete” en lugar de “soft delete”.

El siguiente es un extracto del artículo “Five common database development mistakes”, publicado en el blog “Software Engineer” de Techrepublic.com, de fecha 30 agosto 2012. Su autor (Justin James) describe algunos errores comunes en el desarrollo de bases de datos y como no cometerlos. Estos errores son independientes del manejador de bases de datos utilizado.

Sin más preámbulo, presentamos a continuación 5 errores comunes en el desarrollo de bases de datos. 

Gestión de Proyectos: 5 tareas clave para dirigir la fase de ejecución

Imagen de: Picasa Web Albums

Independientemente del enfoque de gestión de proyectos adoptado, bien sea el predictivo tradicional, o los nuevos enfoques ágiles, el llevar a feliz término un proyecto implica más que hacer una buena planificación y medición de los avances.

En este artículo exploramos algunas tareas clave que deben convertirse en hábitos para el Jefe de Proyectos durante la fase de ejecución, abarcando aspectos como asegurar que todas las partes tengan el mismo entendimiento, guiar y apoyar al equipo, eliminación de impedimentos, resolución rápida de problemas, saber reconocer las señales de alerta y tomar acciones en función a ellas.

Podría pensarse que la alta tasa de proyectos fallidos hoy en día es un factor de desmotivación de las empresas, quienes podrían conformarse con al menos lograr terminar sus proyectos, sin embargo, este no es el caso, a pesar de las adversidades, se observa que las exigencias para terminar los proyectos más rápido, a menor costo y con mejor calidad son cada vez mayores.

Presentamos a continuación las tareas claves para gestionar la fase de ejecución con éxito.

5 Herramientas para la automatización de pruebas de software

¿Quieres aprender cómo utilizar Selenium para automatizar tus pruebas de software? Inscríbete en el curso: Automatiza tu navegador. Selenium WebDriver con Python

iStockPhoto/p_scout

Con el auge que está tomando el desarrollo ágil de software, representado en marcos de trabajo como Scrum, la Programación extrema (XP) y el Agile Testing, cada vez es más crítico contar con la posibilidad de realizar constantes refactorizaciones e integraciones de código.

En este artículo presentamos una lista de 5 herramientas para la automatización de pruebas de software.

Cada vez es más crítico ir a la par de los exigentes tiempos de entrega y cambios demandados por las áreas de negocio.

Para lograr esto, es necesario automatizar las pruebas funcionales y de regresión, con la finalidad que estas pruebas se puedan ejecutar de forma rápida y repetitiva.

PMOInformatica presenta: 5 Herramientas para la automatización de pruebas de software.

Test Driven Development (TDD): 9 retos para su implementación y cómo hacerles frente

Imagen de: Picasa Web

La técnica del Test Driven Development (TDD) es bastante prometedora y ha demostrado dar resultados, sin embargo presenta importantes cambios de paradigmas y retos para su implementación exitosa. En este artículo se abordan 9 retos en la implementación del TDD y algunas ideas de cómo hacerles frente: curva de aprendizaje, cambio del enfoque de desarrollo a las pruebas, apoyo de la gerencia y dirección, dificultades con sistemas legados (Legacy), dependencias de aplicaciones externas, sesgo del desarrollador, relajarse cuando no se identificar muchos errores inicialmente, constantes iteraciones, refactorizaciones y alto costo de errores no identificados.

El Test Driven Development (TDD), es una técnica de desarrollo de software invierte el orden tradicional de las actividades de desarrollo y pruebas, de tal forma que primero se diseñan y ejecutan las pruebas, para luego a partir de los resultados desarrollar la funcionalidad. Se caracteriza por la ejecución constante de: Pruebas, definición de nuevos casos, refactorizaciones, iteraciones, integraciones y pruebas de regresión. Implica cambios de paradigmas importantes, desde el equipo de desarrollo (los programadores), hasta la gerencia y dirección de la organización.

Presentamos a continuación los 9 retos para poner en práctica el TDD y algunas ideas de cómo enfrentarlos:

5 preguntas y respuestas sobre la identificación de riesgos

Imagen de: Picasa Web Albums

Todo proyecto siempre poseen niveles de incertidumbre sobre la actividad a realizar y el producto a entregar, son riesgos que deben ser gestionados.

En este artículo se exploran 5 preguntas y respuestas sobre la identificación de los riesgos en un proyecto, incluyendo quien debe participar, cuando debe hacerse, cuando termina (o más bien no termina) la identificación de riesgos, la importancia de la creatividad, el pensamiento innovador, herramientas y técnicas para la identificación de los riesgos.

El verdadero valor de un plan de riesgos, no reside en el cálculo de valor monetario, sino en la identificación de todos los riesgos y en la definición de planes de respuesta.

Identificar riesgos en un proyecto no se trata sólo de herramientas y técnicas, la creatividad, el pensamiento innovador y participación de todos los integrantes del equipo juegan un papel importante.

Presentamos a continuación 5 preguntas y respuestas sobre la identificación de riesgos:

Productos Amazon de la semana: 25 de Octubre de 2012

A continuación se presentan los productos de Amazon.es y Amazon.com de la semana que culmina el 24 de Octubre de 2012, que son de interés para la comunidad en los géneros de Desarrollo ágil de software, Gestión de Proyectos de Informática, Software, Tecnología y Gestión de Sistemas Informáticos, Negocios, Gerencia, Liderazgo, entre otros temas.


Novedades: Informática, Internet y Medios Digitales
Idioma: Castellano

Guía rápida  Powerpoint 2010 Autor: Miss Maribel Ramírez >> España (amazon.es) >> Latinoamérica (amazon.com) >> Latinoamérica (amazon.com). Kindle	Seguimiento y Control  de Proyectos (MS  Project 2010) Autor: Docentes Compuclub >> España (amazon.es) >> Latinoamérica (amazon.com)	27 controles críticos  de seguridad de información Autor: Sergio Castro Reynoso >> España (amazon.es) >> Latinoamérica (amazon.com)	Mi nuevo iPad Autor: Wallace Wang >> España (amazon.es)

Errores comunes de programación: Segunda Parte

Imagen de: Picasa Web Albums

Anterior a este artículo publicamos “5 errores comunes de programación”, original del blog “Software Engineer de Techrepublic.com, el cual se describían algunas prácticas de programación erróneas. Luego de los comentarios recibidos de la comunidad, hemos decidido publicar una segunda parte, tomando en consideración las sugerencias de algunos usuarios y otras fuentes de información consultadas.

En este artículo se exploran cinco prácticas de programación que pueden ser problemáticas, abarcando la codificación sin un análisis previo, estructura inadecuada de módulos, codificación directa de variables (“Hard Coding”), omitir el manejo de excepciones y no documentar los comentarios en el código.

Presentamos a continuación, la segunda parte de la serie sobre “Errores de programación comunes”.

10 actividades críticas a incluir en todo plan de desarrollo de un software

Imagen de: Picasa Web Albums

En el mundo de la informática, los clientes e inclusive nuestros Gerentes y Directores, esperan que cuando nos presenten un problema de ingeniería de software estemos en capacidad de responder de inmediato ¿para qué fecha cree usted que podría estar desarrollado y entregado?

Sin embargo, debe tenerse extremo cuidado al proporcionar fechas, pues los desarrollos de software suelen presentar muchos imponderables, que deben ser cuidadosamente analizados.

Una de las peores situaciones que se le pueden presentar a un analistas-programador de software, arquitecto, líder de equipo o Gerente de proyecto, es darse cuenta en la mitad de la ejecución, que actividades críticas no fueron consideradas cuando se planificó y comunicó una fecha de entrega.

En este artículo, se exploran una serie aspectos con frecuencia omitidos, pero que deben considerarse en la planificación de todo desarrollo de software. Van desde los tiempos para aprobaciones de los diseños, integraciones de códigos, instalación de ambientes de prueba, entre otros.

Para ayudar a los analistas-programadores, líderes de grupo y Gerentes de Proyectos de Software en esta tarea, presentamos a continuación las actividades críticas que no deben faltar en un plan de desarrollo de software.