9 Pasos para un buen y efectivo manejo de un proyecto de desarrollo de software

Con una detallada propuesta y un competente jefe de proyecto para guiar la iniciación del desarrollo del software, existe otro importante elemento dentro de una organización que puede ser muy útil cuando se comienza con un proyecto como estableciendo pasos específicos. Existe una colección de normas prácticas para aprovechar un proyecto de desarrollo de software, establecido por dos profesores universitarios y consultores de negocio con destreza especializada en computación, ingeniería, y ambientes generales de negocio. El Dr. Gordon Scott Gehrs y el Dr. Dorota Huizinga establecen nueve pasos claves para considerar llevar a cabo en un proyecto de desarrollo de software.

Paso1: Descubrir las necesidades de los stakeholders

Entrevistar a los stakeholders con el propósito de descubrir si sus necesidades específicas existen, identificar su necesidad exacta, y determinar si el proyecto propuesto puede factiblemente entregar el desarrollo del software esperado.

Paso2: Analizar y determinar los requerimientos

Un apropiado análisis debería consistir de las entrevistas con los usuarios finales y otras personas quienes estén asociados con el nuevo sistema. Un repaso minucioso y entendimiento de los documentos de los usuarios, roles del negocio, y procesos son claves para la determinación apropiada y necesaria de las características y funcionalidades.

Paso3: Considerar las mejores prácticas

En el momento de definir los procesos de desarrollo del software se debe considerar las mejores prácticas. El Dr. Huizinga recomienda los procesos ágiles con énfasis en la documentación en imágenes, ambos para la documentación técnica y de requerimientos. Es importante seguir plantillas estándares, utilizar una herramienta de gestión de requerimientos y del tiempo.

Paso4: Diseño

Durante la fase de diseño, el arquitecto del software y el desarrollador puede poner junto un documento de diseño detallado resumiendo exactamente como el software satisfacerá los requerimientos específicos. El Dr. Gehrs recomienda el uso de mock-ups para acompañar el documento de diseño como una opción de elementos ilustrativos de la interfaz del usuario.

Paso5: Medición y rastreo de los progresos

Sin la infraestructura de la tecnología apropiada en el lugar, es difícil coleccionar y medir los datos claves del proyecto. Los indicadores del proyecto pueden ayudar asegurar la identificación rápida de los potenciales problemas, que permite que sean reconocidos y corregidos a tiempo. Cuando son observados fuera del periodo, el Dr. Huizinga remarca que los indicadores pueden ser usados para determinar la calidad del producto y despliegue deseado.

Paso6: Desarrollo

La fase de desarrollo, donde el documento de diseño es trasladado a una pieza real de software. Cuando el planeamiento cuidadoso ha sido ejecutado, el software marcará los requerimientos del manejo del negocio que inició la necesidad para el proyecto. El Dr. Gehrs menciona que los ciclos de desarrollo pueden producir varias versiones del software:

-> Alpha: característica preliminar/solamente funcionalidad
-> Beta: usada para el testeo interno o testeo de usabilidad
-> Candidatos de Release: usualmente una construcción estable puede necesitar algunas correcciones.
-> Construcción de producción o Gold Master: listo para el release

Los jefes de proyecto necesitan retroalimentarse con la experiencia de los usuarios, tiempos para completar las tareas, facilidad de uso, y otra información relacionada a la interfaz del usuario y los elementos céntricos del usuario.

Paso7: Automatización

Otro paso clave es asegurar la automatización de tareas repetitivas:

-> Construcción de códigos
-> Escaneo del análisis del código estático
-> Test regresivos

Dr. Huizinga cree que tomar medidas reduce el error propenso de la influencia humana cuando el software es implementado. Esto también facilita el uso de las mejores prácticas y colección de los datos relacionados al proyecto. Ella menciona que “todas las tareas repetitivas y mundanas deberían ser automatizadas cuando sea posible en cualquier parte del ciclo de vida del software”.

Paso8: Testeo

Ahora el siguiente paso es el testeo, Dr. Gehrs menciona que el testeo también puede variar bastante dependiendo de los procedimientos de testeos individuales adoptados por la organización. El testeo puede consistir de varias sub-etapas, como el aseguramiento de la calidad y la realización de las pruebas. Una vez que el software está en uso general, cualquier error encontrado es direccionado a una escala crítica: arreglos urgentes son programados para ser llevados tanto pronto sea posible. Los cambios característicos pueden ser elegidos para futuras versiones de actualizaciones.

Paso9: Prácticas graduales de implementación

El Dr. Huizinga menciona que “la implementación incremental de las prácticas por encima es crítico para poder sobresalir. La aproximación gradualmente a la introducción al cambio grupo por grupo y la práctica por práctica es esencial para alcanzar el cambio de la cultura organizacional, como cambio no es deseado, y siempre hay resistencia al cambio”. Porque la naturaleza compleja de los proyectos del software y la tecnología involucrada, el desarrollo del nuevo software justifica la propuesta sistemática. Entender el rol del líder del proyecto y la importancia de tener planeado un camino efectivo al desarrollo de los procesos puede ser una ventaja competitiva de una compañía dentro de un mercado competitivo.

Herramientas para la integración de Gestión de Cambios y Release (II)

Paso4: El QAE realiza el testeo de actividades.

El Ingeniero de Aseguramiento de Calidad recibe un e-mail de notificación del Rational ClearQuest que el software se encuentra listo para el testeo. Entonces se procede a revisar la información del defecto en el Rational ClearQuest y el cambio asociado (los archivos que fueron cambiados para arreglar el defecto) para planificar las actividades de testeo. Para verificar la etiqueta correcta de construcción y entender el entorno específico requerido para el testeo, se tiene que hacer referencia al BOM del Rational Build Forge.

Después, usar las características de gestión de testeo del Rational ClearQuest para la planificación del testeo. Generar casos de testeo en el Rational ClearQuest para asegurar que la corrección del programador ha corregido el defecto y luego acceder a los archivos modificados dentro del Rational ClearCase para empezar el testeo. Basándonos en los resultados construidos exitosamente Rational Build Forge puede empezar adicionalmente actividades automatizadas de testeo.

Una vez que el testeo ha sido completado, verificar los resultados de la capacidad de gestión del testeo en el Rational ClearQuest. Los resultados expuestos muestran que todos los casos de testeo han pasado. El BOM del Rational Build Forge es actualizado con los últimos resultados de testeo relacionados a la construcción. Las características de gestión de testeo en el Rational ClearQuest unifica el defecto con las actividades de testeo. El registro de un defecto contiene información sobre el defecto, como ¿qué archivos fueron cambiados para arreglar el defecto?, la información construida, ¿qué casos de testeo fueron creados para verificar el arreglo? y los resultados del testeo de aseguramiento de calidad.

Con el testeo concluido exitosamente, Rational ClearQuest continúa para administrar el flujo de trabajo del desarrollo del software con actualizaciones automáticas para el siguiente y último paso, el cuál es la “entrega”.

Paso5: El Ingeniero de Desarrollo entrega el software.

Después del testeo, Rational ClearQuest notifica al Ingeniero de Desarrollo que el software está listo para la construcción final y entrega. A través del Rational Build Forge, se puede acceder a los registros de construcción en el Rational ClearQuest para identificar todos los cambios (defectos, mejora de calidad, etc.) direccionados para ésta construcción en particular y los archivos asociados fuente almacenados dentro del Rational ClearCase. Los tres archivos que fueron modificados para arreglar el defecto actual son incluidos en la construcción del software.

Usando los procesos construidos consistentes y repetibles en el Rational Build Forge, se puede completar exitosamente y rápidamente la construcción, y los resultados de la construcción son automáticamente generados. Rational Build Forge ejecutará procesos adicionales que el equipo ha especificado para la entrega final del software.

Rational ClearCase almacena las unidades de despliegue mientras que el Rational ClearQuest almacena los registros de despliegue. Rational Build Forge soporta una colección diversa de tareas de despliegue, incluyendo mover archivos a la localización deseada, restaurar servidores web, automatización de notificaciones, etc.

Finalmente, Rational ClearQuest completa su gestión de los flujos de trabajo del desarrollo del software con la automatización y actualización del flujo de trabajo hacia el cierre.

Conclusiones

La gestión del cambio, configuración y despliegue son puntos críticos en los procesos de desarrollo y entrega de software de calidad. La integración del software Rational ClearCase, Rational ClearQuest y del Rational Build Forge provee un ambiente de desarrollo de alta integridad con la finalidad de mejorar la entrega del software y la trazabilidad del ciclo de vida de desarrollo del software.

Herramientas para la integración de Gestión de Cambios y Release (I)

El escenario de casos de uso descrito en el paper de IBM que he encontrado, trae la solución de un efecto hacia el desarrollo y entrega del ciclo de vida del proyecto usando la integración de la gestión de cambio y lanzamiento de IBM, cabe mencionar que está orientado a los proyectos de desarrollo de software.

El software IBM Rational ClearCase, IBM Rational ClearQuest e IBM Rational Build Forge pueden apoyar al equipo durante el flujo de trabajo del desarrollo del software y entrega del sistema mediante los siguientes pasos:

Paso1: El QAE identifica y agrega un defecto

Se puede expresar que durante el testeo del sistema, el Ingeniero de Aseguramiento de Calidad (QAE) identifica el defecto, dicho defecto es ingresado al IBM Rational ClearQuest, para que después el equipo del proyecto reciba una notificación del nuevo defecto y poder identificar la prioridad de arreglar éste. Rational ClearQuest permite una configuración flexible y estandarización de los procesos del flujo de trabajo de un proyecto. El líder del equipo después de asignar la actividad a un miembro del equipo de desarrollo, el estado del defecto se convierte en “asignado”; y después puede generar reportes y gráficos sobre la información del proyecto, como por ejemplo: una lista de los defectos con alta prioridad, un gráfico de distribución de defectos en cada estado y un gráfico de defectos a lo largo del tiempo.

Paso2: El programador trabaja en el defecto

Como se ha mencionado anteriormente, el defecto es asignado a cualquier programador del equipo y será notificado por el Rational ClearQuest. El programador necesitará la información sobre el defecto, el cual se encuentra almacenada en el Rational ClearQuest, después se tendrá que agregar notas y acceder al registro construido directamente desde tu IDE usando el Rational Build Forge IDE plug-in, ya que permitirá que se vea fácilmente los archivos log, el entorno de los datos y las versiones del código fuente que ha sido utilizada en la construcción para que se pueda rápidamente aislar la causa del error. Luego conectar el Rational ClearCase directamente de tu IDE para acceder a los archivos del sistema de tu proyecto, para arreglar el defecto en particular se necesita el cambio de tres archivos después de revisarlos se marca algunas actividades al Rational ClearQuest, ya que ayudará ha asegurar que conoces cual de los defectos se debe estar trabajando y su prioridad, luego seleccionar el defecto actual de la lista. Después de haber realizado los pasos, el defecto estará ahora asociado con los tres archivos y el Rational ClearQuest automáticamente actualizará el defecto en el estado “open”, que significa que todos los miembros del equipo conocen que estás trabajando en el defecto. Después se modifica el código para arreglar el defecto.

Paso3: El programador realiza una construcción para verificar la solución

Después de haber realizado los cambios en el código, se necesita saber si las modificaciones realizadas han corregido el error. Normalmente, se debería entregar al equipo de desarrollo y esperar los resultados, pero en el siguiente ejemplo se realizará la construcción porque el Rational ClearQuest y los procesos estandarizados de construcción del auto-servicio en Rational Build Forge están integrados, y se puede ejecutar el proceso de construcción estandarizado y obtener la retro-alimentación en tiempo real para confirmar que tus cambios han corregido el defecto. El Rational Build Forge incluye un adaptador del Rational ClearCase y del Rational ClearQuest para que se pueda automatizar acciones comunes relacionadas a los procesos de construcción. Por ejemplo, el Rational Build Forge puede realizar que las operaciones del Rational ClearCase “file check-out”, “file check-in” y “apply a label” pueda ingresar un registro de construcción en el Rational ClearQuest.

La parte final del paper lo mostraré en el siguiente post…. Hasta pronto!

La Gestión del Riesgo Innovadora

A continuación hablaré sobre un tema muy importante en la actualidad, “la gestión de riesgos”. Una buena gestión de riesgos comprende la identificación de los riesgos, el análisis cualitativo y cuantitativo para saber cual es la probabilidad de ocurrencia y el impacto en nuestro proyecto, el plan de respuesta también llamado el plan de contingencia o mitigación para contrarrestar que el riesgo se convierta en problema, y la supervisión y control de los riesgos del proyecto, según el PMBOK, 2004.

Buscando algún artículo sobre la gestión de riesgos encontré uno sobre la Gestión de Riesgo Innovadora publicado por el Dr. David Hillson PMP FAPM que a continuación compartiré con ustedes.

Si Ud. piensa que “la gestión de proyectos tiene que ver con procesos y gestión de riesgos, y eso es todo el contrario de la innovación”…. Entonces Ud. está equivocado.

El propósito de la gestión del riesgo en proyectos y comercios es buscar incertidumbres significativas y abordarlas de manera proactiva. Es más eficaz cuando la gestión del riesgo considera tanto amenazas como oportunidades, como recomiendan las normas de mejor práctica.

¿Lograr este objetivo requiere mucha innovación?

1. El primer campo donde la creatividad es indispensable es la identificación de riesgos. Esto requiere que uno piense lo impensable, que uno se libere del “plan” y considere otras opciones y alternativas; realizar preguntas como “¿Y si… Por qué no… Si solo...?”

Para la identificación de problemas potenciales (amenazas) y beneficios inesperados (oportunidades) se requiere el uso de una gama de técnicas creativas tales como el brainstorming (la lluvia de ideas), assumptions-busting (poner suposiciones en duda), análisis causa raíz, visualización, análisis de escenarios, o pensar en el futuro.

De hecho probablemente no es posible identificar riesgos sin ser innovador y/o tener nuevos pensamientos.

2. Pero una segunda parte del proceso de riesgo también requiere una nueva manera de pensar, es decir el desarrollo de respuestas a riesgos eficaces.

Según Einstein, “No es posible solucionar un problema usando las mismas ideas que lo crearon.” No es suficiente simplemente identificar riesgos, si la acción apropiada no se toma, ya que luego uno quedará expuesto al riesgo hasta el mismo grado. Sin embargo decidir qué es apropiado para cada riesgo requiere cierta innovación, estar dispuesto a considerar y tomar acciones que antes uno no consideraba necesarias.

Einstein también definió la locura como “hacer lo mismo sin cesar y esperar resultados diferentes”, lo que se podría decir de otra manera así “‘¡Si sigues haciendo lo que siempre hiciste, siempre recibirás lo que siempre recibiste!”

Como dice el proverbio chino, “Si no cambiamos de dirección, es probable que llegamos adonde íbamos.”

Pero la gestión del riesgo moderna es muy diferente. Acoge y aprovecha del cambio activamente, reconociendo que algunos riesgos ofrecen la oportunidad de mejorar el plan original al trabajar “más eficaz, más rápido, más barato” – hay algo positivo tanto como negativo.

“La gestión del riesgo no creativa” es un oxímoron que no puede existir, y la gestión del riesgo sin la innovación sólo repite y documenta lo inevitable.

Conclusiones

Si el objetivo de la gestión del riesgo se percibe como impedir que uno diverja del plan a todo costo, agarrarse desesperadamente al método original y rechazar el cambio, pues es verdad que se ahogarán la creatividad y la innovación.

Para ser eficaz el proceso de riesgo debe abordar ideas innovadoras y creativas tanto en la identificación del riesgo como en el desarrollo de respuestas, buscando de manera proactiva incertidumbres con la potencialidad de ser significativas y abordándolas apropiadamente. Algo menos no merece el nombre de la gestión del riesgo.

Comparando las Metodologías Guiadas y Ágiles

A continuación hablaré sobre un extracto de un paper que he encontrado sobre las ventajas y desventajas en el uso de las metodologías guiadas y ágiles.

Algunas diferencias entre Metodologías

1. SDM vs. PMBOK

Conociendo que el SDM es la metodología de desarrollo de sistemas que ofrece procesos, herramientas y técnicas para el desarrollo de software basado en otros sistemas; mencionaré algunas diferencias con el PMBOK.

-> El PMBOK se enfoca en la gestión de un proyecto cualquiera, mientras que el SDM se enfoca en la producción de un software.
-> El PMBOK responde a las preguntas de ¿Quién?, ¿Qué? y ¿Cuándo? para la gestión de un proyecto, mientras que el SDM ¿Qué producir? y ¿Cómo producir?.

2. Metodologías Guiadas vs. SDM

-> Ambos proveen procesos, herramientas y técnicas.
-> Ambos requieren un enfoque disciplinado al desarrollo del software.
-> Cada uno tiene fortalezas y debilidades.

3. Metodologías Guiadas vs Metodologías Ágiles

-> Las metodologías ágiles dirigen muchas situaciones cuando las metodologías dirigidas no están bien definidas.
-> Las metodologías guiadas enfatiza en las comunicaciones formales y en el control, con la finalidad de ser más predictivo, mientras que las metodologías ágiles enfatiza en las comunicaciones informales continuas y a la reacción en los cambios, con la finalidad de ser mas adaptivo.

Ejemplos de Metodologías Guiadas

-> RUP de IBM
-> Gestión de Proyectos Tradicionales

Ejemplos de Metodologías Ágiles

-> XP (eXtreme Programming)
-> SCRUM
-> FDD (Feature Driven Development)
-> LD (Lean Development)
-> Crystal

¿Cómo elegir la herramienta correcta?

Seleccionando una metodología dependiendo de la situación, ya que la metodología guiada trabaja mejor bajo algunas circunstancias, y la metodología ágil trabaja mejor bajo otras, o tomando componentes y/o técnicas de cada uno, para construir los procesos que trabajen mejor para la situación.

Pero en realidad eso no me define que herramientas escoger ¿?, por eso se debe tomar en cuenta los siguientes factores:

1. Experiencia

Cuando el equipo tiene experiencia con el dominio de problemas, usa la metodología ágil, pero si el equipo tiene poca experiencia, puede utilizar la metodología ágil junto a la metodología guiada. Se debe tener en consideración el uso de:

-> R&D
-> Desarrollo iterativo mientras se está ganando experiencia con factores de realización.
-> Uso de nuevas tecnologías que impacte al equipo, por ejemplo la aplicación de grupos pequeños de trabajo.

2. Madurez del equipo de trabajo

-> Los equipos con poca madurez requieren una estructura adicional de una metodología guiada.
-> Los equipos con alta madurez fácilmente pueden tomar una ventaja ágil.

3. Localización y Tamaño del Proyecto

Si el equipo de trabajo es grande y geográficamente disperso requieren una comunicación formal de la metodología guiada, pero si el equipo es pequeño y localizado debe utilizar una comunicación informal. Es recomendable que los equipos no excedan de 6 a 8 miembros.

4. Cultura Organizacional

Algunas culturas organizacionales y equipos de gestión pueden ser más receptivos de un enfoque de otro.

5. Escalabilidad y Portabilidad

Para la construcción de un robusto sistema para la extrema escalabilidad a lo largo de una variedad de arquitecturas e infraestructuras podrían ser mejor direccionado con los controles de una Metodología Guiada.

6. Producto Comercial

La creación de un producto comercial requiere coordinación con Marketing y Departamentos de Venta, para la preparación de guías de usuario, el desarrollo de programas, y el establecimiento de equipos de producción; el cuál puede ser muy beneficioso utilizando un enfoque de una Metodología Guiada.

7. Combinando Metodologías

Combinando prácticas de ambos tipos de metodologías podría ser beneficial en algunas situaciones. Algunos enfoques son los siguientes:

-> Usar la metodología guiada para un proyecto o programa complejo y después utilizar la metodología ágil para sub-proyectos o sub-componentes.
-> Usar la metodología guiada para cualquier proyecto en general pero usar las técnicas ágiles como la programación en pareja para el esfuerzo de desarrollo.

Conclusiones

Un proceso definido no necesariamente debe ser formal o documentado, solamente debería ser consistente y ajustado.

El término ágil es un enfoque disciplinado al desarrollo de software pero con un énfasis en diferentes aspectos de los procesos.

Los equipos de gestión que trabajan bien con un enfoque de la metodología guiada también tienden a trabajar bien con un enfoque ágil.

Integrando el PMBOK al Proceso Unificado de Desarrollo de Software en Proyectos de TI

El siguiente tema que tocaré a continuación ha sido una ponencia en el Congreso Nacional de Gerencia de Proyectos PMI 2007 dictado por el PMP Guillermo Villavicencio. Los principales tópicos fueron: el problema con los proyectos TI de desarrollo de software, el RUP, integración del PMBOK al RUP (Mapeo de los principales entregables y actividades entre el PMBOK y el RUP) y un caso de aplicación práctica en el sector financiero en Perú.

Según un reporte Chaos realizado por la Standish Group identificó las siguientes causas del problema con los proyectos TI de desarrollo de software son:

-> Falta de involucramiento del usuario.
-> Falta de apoyo de la alta gerencia.
-> Objetivo de negocios difusos.
-> Gerente de proyecto inexperto.
-> Hitos de larga duración.
-> Requerimientos no administrativos.
-> Personal inexperto.
-> Planeamiento insuficiente.

Los dos grandes factores de éxito que pueden ayudar en la mejora de los proyectos de desarrollo de software a un 100% en 10 años son: proceso iterativo y manejo de proyectos profesional.

RUP es un proceso de desarrollo de software cuyas características son: iterativo, conducido por casos de uso, centrado en la arquitectura y gestión temprana de riesgos. Es un proceso bidimensional eso quiere decir que está compuesta por fases y disciplinas. Como ya sabemos RUP tiene 4 fases: iniciación, elaboración, construcción y transición; y cada una de esas fases tiene sus objetivos principales y su periodo de ejecución. Las disciplinas de gestión permiten: balancear y cumplir los objetivos de negocio, administrar los riesgos involucrados en los proyectos y entregar con éxito un producto que satisfaga las necesidades del cliente y de los usuarios.

El PMBOK posee un framework para gestión de proyectos, posee procesos principales que son agrupados en nueve áreas de conocimientos y muestra el nivel de actividad de cada proceso basado en el tiempo.

Ahora con respecto a la Integración del PMBOK al RUP, cabe recalcar lo siguiente: El RUP no cubre por completo todos los procesos de gerenciamiento de proyectos descritos en el PMBOK, con respecto al gerenciamiento de costos, recursos humanos y adquisiciones. Por otro lado, el PMBOK no está orientado a Proyectos de Desarrollo de Software.

Principales Características:

Propuesta de Solución: “Buscar en el PMBOK las mejoras prácticas de gestión de proyectos e integrarlas al RUP”


Mapeo de Áreas de Conocimientos del PMBOK con disciplinas del RUP

Conclusiones

Podemos utilizar la metodología iterativa incremental de RUP con gestión de proyectos PMBOK para proyectos medianos y grandes, y proyectos exitosos.

Es importante que el cliente entienda las ventajas del proceso iterativo incremental y las ventajas de una metodología formal de gestión de proyectos, al igual que las personas que practican la gerencia de proyectos comprendan la importancia de utilizar una metodología iterativa incremental de gestión de proyectos.

Todavía el mapeo tiene algunos vacíos en la disciplina de la Gestión de Proyectos:

-> Gerenciamiento de Recursos Humanos.
-> Gerenciamiento de Costos.
-> Gerenciamiento de las Adquisiciones y contrataciones.
-> Gerenciamiento del Alcance del Proyecto (el RUP se enfoca más en el alcance del producto o del software).
-> Análisis cuantitativo de riesgos y el planeamiento e ubicación de recursos para su tratamiento.
-> Otras técnicas que si se abordan en el PMBOK.

Ocho Tendencias a combatir cuestiones claves en Proyectos CRM

Muchos proyectos de CRM no son exitosos debido a que el gran problema es tratado de resolver todas las necesidades a la vez. Otros no tienen éxito debido a la política entre la TI y los interesados del negocio. Sin embargo, existen proyectos de éxito de CRM que han demostrado afrontar términos de tiempo, dinero y recursos. Estos proyectos siguen 8 tendencias importantes para luchar contra las cuestiones claves que a menudo se encuentran en proyectos de CRM, incrementando así el éxito de la entrega de una sólida visión de CRM.

Entonces, ¿Cuáles son dichas tendencias?

1. La correcta solución es seleccionada para un uso razonable de tiempo de ejecución

Si la solución no encaja en el modelo de negocio o procesos de negocio revisados con la funcionalidad out-of-the-box, no debería ser considerada sino se puede implementar con un mínimo de personalizaciones o integraciones con sistemas externos. En lugar de depender únicamente de las aportaciones a largo plazo de los empleados, la dirección ejecutiva usualmente contrata un proveedor independiente comprometido para trabajar con negocios y la administración de TI para determinar la solución que mejor satisfaga las necesidades empresariales.

2. Selecciona el proveedor correcto para la implementación que haga la diferencia

Está bien elegir una de los cinco empresas de Consultorías de spin-off para la implementación de la solución CRM, los más exitosos proyectos de CRM optan por empresas reconocidas de consultoría basada en la retroalimentación “antes de” y en los clientes existentes. Pequeñas empresas de consultoría proporcionan resultados mas eficientes (por lo general tres veces más calidad de los productos proporcionados por las 5 mejores empresas de consultoría), desde el diseño de las fases de producción y meticulosamente la toma de la propiedad en el éxito de la implementación del CRM.

3. Las personas negativas nunca deben estar en el equipo

Siempre habrá personas con energía negativa con el afán de destruir los proyectos de CRM. Los empleados perezosos y descontentos estarán mejor servidos si son expulsados del proyecto o participando en la fase del testeo del sistema donde la negatividad les forzará a ellos a tratar de malograr el sistema, identificando potenciales errores y funcionalidad perdidas que pueden ser resueltas antes de la aceptación del usuario.

4. Equipos híbridos proporcionan mejores resultados

Siempre hay un equipo híbrido que siempre se está basando de un complemento en el lado del cliente al lado del líder desarrollador, líder del testeo, líder de la integración, y un líder del negocio que entiende los procesos del negocio para cada función del sistema. Si los equipos de desarrollo se encuentran en el lugar, dos empleados y/o consultores del cliente estarán disponibles para la explicación de la lógica del negocio que normalmente se pierde en la traducción - un administrador señor de proyecto que comprende el desarrollo de los análisis de control, tableros, y los planes de proyecto detallados y un jefe técnico (consultor con años de experiencia en la entrega de la solución CRM).

5. Malos procesos son eliminados como parte de la preparación de CRM

El éxito de proyectos CRM tienen stakeholders ejecutivos que entienden que los malos procesos implementados en una solución CRM no es más que un mal proceso de negocio automatizado que requiere una mayor personalización, en última instancia utilizando mas tiempo, recursos y presupuesto.

6. La calidad de los datos y la fiabilidad está planificada en fases tempranas

Reconociendo que la conversión de datos deben ser planificados y desarrollados en el mismo tiempo de desarrollo es clave para una visión CRM exitosa. La migración de datos e integración de datos son planificados con las iniciativas de calidad de datos en las etapas de diseño no después del desarrollo de la funcionalidad del sistema.

7. Presentación de informes no es al final

El éxito de los proyectos CRM es mantener el propósito de la gestión de la visibilidad en la planificación y diseño. Dado que ésta es siempre una prioridad y la razón superior para la implementación, la presentación de informes es planificado tempranamente en las etapas de diseño por la ODS y expertos del Data Warehousing.

8. El tiempo de prueba es por lo menos el doble del tiempo de desarrollo

La norma estándar de la asignación de dos veces el tiempo de desarrollo de la prueba exacta sigue siendo válida. El éxito de los proyectos CRM tiene 5 fases que involucra el testeo unitario y funcional, el testeo del sistema, el testeo de la aceptación del usuario, el testeo de prueba de errores del testeo que son resueltos por el equipo de desarrollo. En resumen, los proyectos CRM pueden ser exitosos si estas tendencias se cumplen desde el comienzo del proyecto. A raíz de estas tendencias comunes aumentará la probabilidad de éxito de una visión CRM puesta en acción.

Source: http://ezinearticles.com/?8-Trends-to-Combat-Key-Issues-of-CRM-Projects&id=1261220

Las herramientas top10 para la Gestión de Proyectos para oficinas virtuales

Saliendo un poco del tema de las metodologías para la gestión de proyectos, comienzo a buscar algún artículo sobre de alguna novedad que se esté orientada a las herramientas de software para la gestión de proyectos, es así que encuentro un artículo muy interesante que explicaré a continuación. Pero antes quisiera explicar un término que en el artículo se repite en muchas ocasiones, la definición de un asistente virtual ¿? se denomina a “un profesional independiente que brinda servicios administrativos, creativos y/o técnicos. Utilizando medios de comunicación de tecnología avanzada, una VA profesional asiste a clientes en su área de expertise desde su propia oficina, enmarcando los servicios en un acuerdo contractual”.

Ahora que las oficinas remotas, teletrabajo, el trabajo desde el hogar y asistentes virtuales están cobrando impulso, es imprescindible que lleguemos a un modelo general que mejor se adapte a nuestras necesidades para la gestión de proyectos dentro del equipo de trabajo, y con los clientes.

Para una organización de gran tamaño, que aprueba el teletrabajo y el framework de oficina remota, entonces no hay nada de que preocuparse. La oficina remota se ocupará de las herramientas de gestión personalizada y le informará acerca de ello. Por otro lado, si es un asistente virtual independiente, entonces mi hipótesis es que si está confiando en los hilos de su correo para hacer un seguimiento de las conversaciones y el uso de hojas de cálculo para realizar un seguimiento de la situación del proyecto. Si usted es un poco más inteligente, usted va a usar etiquetas (como en Gmail) o carpetas (como en Yahoo y Hotmail) para ordenar los hilos de correo para facilitar el acceso. Archivos adjuntos de correo se pueden guardar en su escritorio. De nuevo, si usted es inteligente, se comparten los documentos en lugar de enviarlos por correo. Ser un Asistente virtual, se entiende al conjunto de trabajo que se encontrará en línea (online). Se puede hacer el manejo de más de un proyecto para el mismo cliente, o tener más de un cliente en cualquier punto dado del tiempo.

La mayoría de las herramientas online para la gestión de proyectos son libres (con algunas características para un único usuario), y viene a un precio razonable (si quieres funciones avanzadas). La lista que figura a continuación muestra las 10 principales herramientas online para la gestión de proyectos:

1. ProjectInsight:

Tiene todas las características necesarias de un sistema de gestión de proyectos. No es tan básico ni tan avanzado. Por lo tanto, si usted es un asistente virtual con conocimientos regulares de trabajo de cómo un sistema de gestión de proyectos trabaja, entonces tiene las posibilidades de probar el siguiente programa.

2. AceProject:

Según lo que considera el autor el AceProject es el mejor sistema de gestión de proyectos. Tienen alrededor de 22 características como un foro de debate, dependencias de tareas y proyectos múltiples, y gestión de tareas considerada como la mejor. Ofrecen una web alojada y una opción auto-organizada si desea que se encuentre de un negocio intralink. Podría ser abrumado inicialmente, pero una vez que llegue a conocerlo, las cosas son mas fáciles. El autor menciona que es un sistema completo para un único usuario y multi-usuarios, por ejemplo: Agencias personales virtuales.

3. CoMindWork:

El autor considera que es el segundo mejor sistema de gestión de proyectos en la web basado en las características como wiki y blog de proyectos específicos que son ofrececidos. Ellos permiten la integración con otras PMS como BaseCamp y Salesforce, y también la integración con Gmail y OpenID. La razón por la que está como el segundo es porque para los usuarios libres solamente pueden tener un proyecto. Tal vez pagando el servicio se ajusten a las necesidades de su negocio.

4. MyClientSpot:

El siguiente sistema de gestión de proyectos ha sido diseñado para asistentes virtuales independientes que operan independientemente. Es sencillo y pequeño. Se trata de un interfaz muy intuitiva y hasta 5 usuarios les permite compartir e interactuar con el equipo de trabajo o cliente. Si maneja 2 proyectos al mismo tiempo (con 20 MB de espacio), entonces esta es, sin duda, la que se ajusta a sus necesidades.

5. BaseCamp:

Dá una visión general de las cosas del proyecto sin adornos. La interfaz tiene pestañas como el tablón de mensajes, archivos de zona, hitos y listas son sólo un clic de distancia. Pruebe la cuenta gratuita para obtener el sentir de las cosas.

6. VirtuaAssistantManager:

La demo da una buena idea sobre de lo que esperamos cuando nos registramos. La lista está alineada según los clientes existentes, dándole una imagen de estado del proyecto en relación con un cliente específico. Este es un servicio de pago a partir de 39 $ / mes por 1 Asistente virtual. Sus clientes incluyen a Pepsi, Time Warner y Comcast, entre otros.

7. EasyProjects:

Esto es especialmente bueno si usted tiene un equipo, y quiere un único centro de mando para todos los proyectos del cliente y también para proyectos in-house delegados al equipo de trabajo. El empleado de tiempo y papel jerárquico basado en permisos son características dignas de mención. Una vez más, este es un servicio de pago.

8. Project.net:

Esta es una edición completa de un sistema de gestión de proyectos. La demo ofrece una visión general de las características de Project Manager del punto de vista. Sin embargo, queda por ver cómo esto puede ser modificado para adaptarse a un único usuario, con múltiples clientes. Ellos ofrecen la personalización de las pestañas y campos de formulario. Pero nunca se sabe hasta que lo intenta.

9. IdidWork:

El autor no llama a este proyecto una herramienta de gestión, pero si son parte de un equipo que te obliga a presentar actualizaciones periódicas de trabajo a largo como correos electrónicos o las hojas de cálculo compartida, puede hacer uso de su interfaz como Twitter, para comunicar su situación laboral. Además, todos acumulados "mensajes de estado" puede ser por correo electrónico al administrador del equipo. Esto también permite una visión general de rendimiento durante un período de tiempo. Vale la pena intentarlo, aunque las preferencias individuales puede diferir.

10. SmartSheet:

Si son muy cómodos con el uso de hojas de cálculo y, a continuación, este sistema de gestión de proyectos es definitivamente para ti. El concepto de trabajo se utiliza para agregar las hojas para el mismo proyecto y le gusta la de ella. Usted puede colaborar con los clientes y cargar archivos para el debate. Toma un poco de tiempo para acostumbrarse al sistema. Esta es gratuita y tienen la versión beta en marcha. http://outsorcerer.com es un proveedor líder de bajo coste, pero fiable asistentes virtuales para ayudar a los empresarios ocupados a ampliar sus esfuerzos.

Espero que les haya gustado! Hasta la próxima...

Source: http://EzineArticles.com/?expert=Ishani_Mitra

Procesos Unificados y AUP

En el anterior post me enfoqué sobre el OpenUp sus beneficios, principios y ciclo de vida; pero me olvidé de mencionar algo muy importante de que el OpenUp se encuentra dentro de un grupo de mejoras y variaciones del Proceso Unificado. Ahora comenzaré a dar una introducción sobre el proceso unificado para después comenzar a hablar sobre el Proceso Unificado Ágil (AUP) .

¿Qué es Proceso Unificado?

El proceso unificado o también llamado proceso unificado de desarrollo de software es un framework de procesos de desarrollo de software iterativo e incremental. La variación más conocida y extensivamente documentada de los Procesos Unificados es el RUP (Proceso Unificado Racional). También el proceso unificado es generalmente usado para describir procesos generales incluyendo aquellos elementos que son comunes en la mayoría de las variaciones.

Características del Proceso Unificado

- Iterativo e incremental
- Manejo de los Casos de Uso
- Centrado en la Arquitectura
- Enfocado en los Riesgos

Ciclo de Vida del Proyecto

Este punto ya ha sido mencionado en el anterior post en detalle, pero quiero recalcar que todas las variaciones del Proceso Unificado tienen las mismas 4 fases en común: Iniciación, Elaboración, Construcción y Transición.

Refinamientos y Variaciones del PU

Los refinamientos del Proceso Unificado varían de uno del otro en la forma que se categorizan sus disciplinas o flujos de trabajo. Por ejemplo, RUP define 9 disciplinas: Modelamiento del Negocio, Requerimientos, Análisis y Diseño, Implementación, Prueba, Despliegue, Configuración y Gestión del Cambio, Gestión del Proyecto y Ambiente. El EUP (Proceso Unificado Empresarial) adiciona ocho disciplinas empresariales y mientras las variaciones ágiles del Proceso Unificado tal como OpenUp/Basic y AUP (Proceso Unificado Ágil) simplifican el RUP reduciendo el número de disciplinas.

Los refinamientos también varían en el énfasis puesto en los diferentes artefactos. Los refinamientos ágiles racionalizan el RUP simplificando los flujos de trabajo y reduciendo el número de artefactos; además pueden variar en las especificaciones después de la etapa de transición como por ejemplo en el RUP después de su fase de transición es usualmente seguida por la fase de iniciación mientras que en el EUP es la fase de Producción.

Las organizaciones utilizan los procesos unificados invariablemente incorporando sus propias modificaciones y extensiones. El siguiente listado es sobre los refinamientos y variaciones más conocidos:

- Proceso Unificado Ágil (AUP): variación ligera desarrollada por Scott W. Ambler
- Proceso Unificado Básico (BUP): variación ligera desarrollada por IBM y el precursor del OpenUp.
- Proceso Unificado Empresarial (EUP): extensión del RUP
- Proceso Unificado Esencial (EssUP): variación ligera desarrollada por Ivar Jacobson.
- Proceso Unificado Racional (RUP): proceso de desarrollo de software racional propuesto por IBM.
- Método Unificado de Oracle (OUM): proceso de desarrollo e implementación de Oracle.

AUP – Disciplinas, Principios y Ciclo de Vida

Como ya lo había mencionado antes el Proceso Unificado Ágil es una versión simplificada del RUP, la cual describe en una forma simple, fácil de entender y brinda un enfoque de desarrollo de software utilizando técnicas ágiles y conceptos del RUP.

En comparación de las disciplinas del RUP que son 9, el AUP tiene solamente 7 las cuáles algunos son combinaciones de dos disciplinas del RUP

1. Modelo: Entender el negocio de la organización, el problema de dominio que se abordan en el proyecto, y determinar una solución viable para resolver el problema de dominio.
2. Implementación: Transformar el modelo(s) en código ejecutable y realizar un nivel básico de pruebas individuales.
3. Prueba: Realizar una evaluación objetiva para garantizar la calidad. Esto incluye la búsqueda de defectos, validar que el sistema funciona tal como está establecido, y verificar que se cumplan los requisitos.
4. Despliegue: Realizar un plan para la presentación del sistema y ejecutarlo para hacer que el sistema se encuentre a disposición de los usuarios finales.
5. Gestión de Configuración: Realizar la gestión de acceso a artefactos de su proyecto. Esto incluye no sólo el seguimiento de las versiones del artefacto en el tiempo, sino también el control y la gestión de cambios para ellos.
6. Gestión del Proyecto: Dirigir las actividades que se lleva a cabo en el proyecto. Esto incluye la gestión de los riesgos, la dirección de personas (la asignación de tareas, el seguimiento de los progresos, etc), y coordinar con las personas para garantizar que se entrega a tiempo y dentro del presupuesto.
7. Ambiente: Apoyar el resto de los esfuerzos por garantizar que el proceso adecuado, la orientación (normas y directrices), y herramientas (hardware, software, etc) están disponibles para el equipo según cuando ellos lo necesiten.

El ciclo de vida del AUP es el siguiente:

La primera cosa que es notable es que las disciplinas han cambiado. En primer lugar, la disciplina "Modelo" abarca el Modelado de Negocios, Requisitos y Análisis y Diseño del RUP. El Modelo es una parte importante del AUP, como se puede ver, no domina el proceso. En segundo lugar, las disciplinas Configuración y Gestión del Cambio es ahora la Gestión de Configuración, en su desarrollo ágil de Gestión del Cambio son parte de de los esfuerzos de gestión de requerimientos, que forma parte de la disciplina del Modelo.

Puedo mencionar algunos principios como:

1. El personal necesita saber lo que está haciendo. La gente no va a leer la documentación de los procesos en detalle, sino que quieren una orientación de alto nivel y/o formación de vez en cuando. El producto AUP proporciona enlaces a muchos de los detalles si uno está interesado pero no obliga seguir los detalles.
2. Simplicidad. Todo se describe concisamente usando unas páginas, no miles de páginas.

3. Agilidad. El AUP se ajusta a los valores y principios de la Alianza Ágil.

4. Centrarse en las actividades importantes. La atención se centra en las actividades que realmente cuentan.

5. Herramienta de la independencia. Poder usar cualquier herramienta que desee utilizar con la AUP. Es recomendable utilizar herramientas que mejor se adapten para el trabajo, que a menudo son herramientas simples o incluso herramientas de código abierto.

6. Querer adaptar este producto para satisfacer sus propias necesidades. El producto AUP es fácil de manejar a través de cualquier herramienta de edición de HTML. Usted no necesita comprar una herramienta especial, o tomar un curso, para adaptar el AUP.

Las versiones incrementales en el tiempo son las siguientes:

El primer release a menudo toma más tiempo que las demás, ya que mayormente el equipo de trabajo tiene la necesidad de obtener la mayor parte del sistema lo que permite la existencia de la colaboración del equipo. La primera producción de liberación puede tomar doce meses y la segunda nueve meses, y otras cada seis meses. Una de las primeras se centran en cuestiones de despliegue no sólo le permite evitar problemas que también le permite aprovechar de sus experiencias durante el desarrollo. Por ejemplo, cuando se está implementando el software en una área debe tomar notas de lo que funciona y lo que no.

OpenUP como alternativa metodológica para proyectos pequeños de software

Nosé si realmente alguno de ustedes haya escuchado algo sobre el OpenUp, pero la verdad yo nunca hasta hace unos días, leyendo algunos artículos sobre ésta metodología me entero que es relativamente nueva ya que en el 2006 IBM lanza al mundo del software una metodología ágil llamada “OpenUP”, diseñada para el desarrollo de proyectos y que ha tomado las mejores prácticas del RUP.

¿Cómo se define el OpenUP?

OpenUP es un marco del proceso del desarrollo del software Open Source que en un cierto plazo, se espera que cubra un amplio sistema de necesidades para los proyectos de desarrollo.

OpenUP es un proceso iterativo para el desarrollo de software que es:

- Mínimo: Solo incluye el contenido del proceso fundamental
- Completo: Puede ser manifestado como proceso entero para construir un sistema.
- Extensible: Puede ser utilizado como base para agregar o para adaptar más procesos.

¿Qué es el OpenUp/Basic?

OpenUP/Basic es un subconjunto de OpenUP que lleve un acercamiento ágil para el desarrollo del software, con solo un contenido fundamental provee un conjunto simplificado de artefactos, roles, tareas y guías de trabajo.

OpenUP/Basic es un proceso iterativo del desarrollo del software que es mínimo, completo, y extensible. Es un proceso para equipos de desarrollo pequeños y que le dan valor a la colaboración y a las necesidades de los stakeholder.

OpenUP/Basic es extensible, porque puede ser utilizada como base para agregar o adaptar según las necesidades. Es un proceso ejemplar y extensible para una gama de los procesos del desarrollo y de la gerencia del software que apoya el desarrollo iterativo, ágil, e incremental y es aplicable a un amplio sistema de plataformas y de usos del desarrollo.

Beneficios en el uso del OpenUP

- Ya que es apropiado para proyectos pequeños y de bajos recursos permite disminuir las probabilidades de fracaso en los proyectos pequeños e incrementar las probabilidades de éxito.
- Permite detectar errores tempranos a través de un ciclo iterativo.
- Evita la elaboración de documentación, diagramas e iteraciones innecesarios requeridos en la metodología RUP.
- Por ser una metodología ágil tiene un enfoque centrado al cliente y con iteraciones cortas.

Principios del OpenUP

- Colaborar para alinear intereses y para compartir conocimiento.
- Balancear las prioridades para maximizar las necesidades de los stakeholder.
- Centrado en la Arquitectura.
- Desarrollo Iterativo.

Fases del OpenUP

1. Concepción

Primera de las 4 fases en el proyecto del ciclo de vida, acerca del entendimiento del propósito y objetivos y obteniendo suficiente información para confirmar que el proyecto debe hacer. El objetivo de ésta fase es capturar las necesidades de los stakeholder en los objetivos del ciclo de vida para el proyecto.

2. Elaboración

Es el segundo de las 4 fases del ciclo de vida del OpenUP donde se trata los riesgos significativos para la arquitectura. El propósito de esta fase es establecer la base la elaboración de la arquitectura del sistema.

3. Construcción

Esta fase esta enfocada al diseño, implementación y prueba de las funcionalidades para desarrollar un sistema completo. El propósito de esta fase es completar el desarrollo del sistema basado en la Arquitectura definida.

4. Transición

Es la última fase, suyo propósito es asegurar que el sistema es entregado a los usuarios, y evalúa la funcionalidad y performance del último entregable de la fase de construcción.

Conclusiones

El OpenUp es un proceso modelo y extensible, dirigido a gestión y desarrollo de proyectos de software basados en desarrollo iterativo, ágil e incremental apropiado para proyectos pequeños y de bajos recursos; y es aplicable a un conjunto amplio de plataformas y aplicaciones de desarrollo. Espero que les haya gustado hasta la próxima.

¿Cómo crear tu propia metodología basada en un framework estándar? (II)

En el anterior post me enfoqué en hablar sobre lo que es un framework estándar, cuales son los frameworks existentes, ventajas, y recomendaciones antes de escoger un framework estándar. Ahora explicaré sobre la adaptación y documentación de la metodología.

El autor del paper “Lucas Rodríguez” da cuatro tips para la adaptación y documentación de la metodología.

1. Entiende el framework

Una vez que el framework haya sido escogido se comienza a construir la metodología. Primero, se debe tener una interpretación general de la metodología, una vista holística de sus componentes y se recomienda tener una idea clara de su alcance y limitaciones. Podría ser útil (en el caso que se tenga algunos procesos formales en el lugar) para llevar un mapeo de tus procesos al estándar y llevar a cabo un análisis completo, y no es necesario si uno aproxima el proyecto como un proyecto de reingeniería, construyendo procesos nuevos para el desarrollo.

2. Construye un mapa de trayectoria

Una vez que se tenga una visión clara del alcance del framework estándar y tu situación actual, se tiene que definir el alcance de tu metodología, significa que tienes que tener una visión clara de tu organización una vez que la metodología esté en operación. Se debe encontrar que algunos procesos no se aplican a tu organización o son sofisticados para tus necesidades.

“Ser realista”, tomar en consideración los recursos que tienes disponibles para el proyecto y el tiempo que cuentas. Tienes que estar seguro que tu visión estratégica es conocida por todas las personas que se encuentran involucradas en el proyecto, comprendan y contribuyan en el mismo.

El siguiente paso es definir los objetivos del proyecto, pero antes se mencionará las dos formas de afrontar el proyecto:

- Única entrega, la metodología es solamente utilizada una vez que el alcance haya sido logrado.
- Entrega incremental, la metodología es utilizada en muchas iteraciones, donde cada una está compuesta de un conjunto de procesos.

Aunque la propuesta de una única entrega puede tener sentido cuando el alcance del cambio es limitado, se cree que una propuesta iterativa aumenta la probabilidad del éxito del proyecto. Elige las primeras iteraciones de aquellos procesos que agregan un valor visible o resuelvan problemas conocidos, entonces aprenderás cada lanzamiento y aplicación del conocimiento en las iteraciones posteriores.

3. Adáptate y detalla los procesos

Los frameworks estándar son propósitos generales, ya que son útiles para muchas organizaciones las cuáles ellos proveen las mejores prácticas expresadas en términos generales. Después de entender el proceso ya descrito en el framework, tendrás que determinar como esto puede ser llevado dentro del contexto de las organizaciones, determinando los roles los cuales serán responsables las personas involucradas para la ejecución, las herramientas que serán usadas para facilitar la metodología y los documentos, información, objetos, etc… que debe ser entregado.

4. Documenta los procesos

Una vez que los nuevos procesos estén claros, se deben de documentar con la finalidad de facilitar su comunicación a las personas que lo ejecutarán. El objetivo ahora es que los procesos sean ejecutados en el mundo real acorde a la nueva definición de procesos. Esto puede solamente ser logrado a través del entendimiento de los procesos y el interés de las personas que llevan a cabo los procesos, y la “buena documentación de procesos” es la palabra claves para esto.

Los procesos pueden ser documentados en una amplia variedad de formatos con varias herramientas (del MsWord al metoCube, la cual es una herramienta de documentación de procesos desarrollado en Nevant). Sea cual sea el formato y la estructura, se debe tener en cuenta para la documentación de procesos lo siguiente:

- Los documentos de los procesos deben ser fácilmente accesibles, sino lo son las personas no utilizarán tiempo en la búsqueda de ellos.
- La documentación de los procesos debe ser fácilmente navegable, si las personas no encuentran información concreta que ellos están buscando, probablemente desistirán o desperdiciarán tiempo valioso.
- Las herramientas y plantillas que se necesitan llevarse a cabo para el trabajo descrito deben ser fácilmente accesibles para la documentación.
- Complementa las descripciones de los procesos textuales con diagramas.

Espero que haya sido de mucha utilidad, el paper que he encontrado. Ya que es muy importante conocer como se puede estructurar una nueva metodología, aplicando conocimientos de otros frameworks tal como el PMBOK o ITIL y hacer nuestra propia metodología e interesante según los intereses que tengamos para lograr algún resultado específico.

¿Cómo crear tu propia metodología basada en un framework estándar? (I)

Algunas veces nos preguntamos: ¿por qué tantas metodologías existen en la actualidad?, ¿por qué ésta se puede aplicar a mi proyecto y otras no?… La respuesta es que cada una de las metodologías tiene su propia prioridad, unas orientadas solamente al desarrollo del software, otras indicadas para proyectos con un rápido cambio de requerimientos, otras al control del proceso, factor humano, etc.

Si uno tiene dificultades en escoger la metodología mas adecuada tiene la opción de crear su propia metodología tomando procesos, técnicas y herramientas de otras metodologías para así formar una metodología híbrida que tenga las características deseadas.

Después de haber dado una breve introducción, explicaré algunos tips que encontré en un paper sobre la creación de nuevas metodologías basadas en un framework estándar. Pero antes explicaré la definición y ventajas de un framework estándar.

¿Qué es un framework estándar?

Un marco estándar es una colección de buenas prácticas, normalmente expresadas como un conjunto de procesos repetitivos creados por una organización ya sea una asociación profesional, universidad, administración pública, etc. Además usualmente se refieren a las áreas de conocimiento, metodologías, etc.

Las estructuras de trabajo estándar tienen que ser aplicadas en toda la organización, no necesariamente detalladas a un nivel que puede alcanzar el estándar sino dependiendo de las necesidades que tenga la organización, es decir las mejores prácticas que te puede brindar éste tipo de estructuras de trabajo tienen que ser trasladadas a procedimientos concretos y políticas de acuerdo a las características y el ambiente de trabajo de la organización.
Por ejemplo, cuando una estructura de trabajo dice “Determina cuales son los riesgos que afectan el proyecto con sus respectivas características”, la metodología puede decir “el líder del proyecto registra los riesgos del proyecto en una lista y documenta sus características”. La metodología también provee plantillas de trabajo, y descripción del roles de los miembros de un proyecto en una organización.

Algunos de los frameworks existentes que son usados como base para una metodología son los siguientes:

- Gestión de Servicios de Tecnología de la Información: ITIL / COBIT / MOF
- Gestión de Proyectos: PMBOK / PRINCE2
- Desarrollo de Software: RUP / OPEN Process Framework

Ventajas en el uso de un framework estándar

- Tomar ventaja del trabajo producido por profesionales expertos en el campo.
- Establece una metodología estándar, con la finalidad que realce la comunicación interna y externamente.
- Facilita procesos de confrontación de resultados, para que se pueda conocer que tan bien se está llevando a cabo los procesos a comparación de otras organizaciones.
- Los empleados se encontrarán motivados, ya que adicionarán un valor agregado.
- Los frameworks principales evolucionarán todo el tiempo, para que te sientas capaz de realizar tu propia metodología.

¿Qué framework debemos escoger?

Antes de escoger una estructura se debe tomar en cuenta las siguientes recomendaciones:

- Busca e investiga: Es normal encontrar frameworks para una sola disciplina.
- Determina cual estándar se adecua mejor a tus necesidades en términos de industria, tamaño de la organización, etc.
- Determina como el estándar se integra con otros estándares de otras disciplinas.
- Evalúa la estructura de la estructura de trabajo encontrado: ¿Tiene una estructura uniforme y formato para las descripciones de todos los procesos?
- Evalúa el alcance: ¿Contiene todos los procesos que tú necesitas? ¿Hace referencia a los sistemas de soporte? ¿Contiene manuales y plantillas?
- Evalúa concordancias con las características de tu organización: De repente el estándar que has encontrado es muy pesado para tus necesidades. Nota que los procesos que parecen muy complejos en la estructura de trabajo pueden ser implementados a través de procesos simples que incrustan un valor agregado.

Source:

http://research.ittoolbox.com/white-papers/itmgmt/pm/create-your-methodology-based-on-a-standard-framework-2054

Bueno espero que les haya gustado mi post, en el siguiente post trataré la segunda parte de éste tema que comprende la adaptación y documentación de la metodología basada en un framework.

Integrando DSDM en un ambiente existente con PRINCE2…

Buscando por Internet algún paper que sea de mi interés :) … encontré uno que se refería a como integrar un DSDM en un ambiente de una organización que está utilizando la metodología Prince2, pero ¿que es un DSDM? …. es un framework de proyectos el cuál es iterativo e incremental que tiene un control dinámico de cambios, el cuál más adelante explicaré con más detalle.

El propósito del paper es describir los beneficios de juntar Prince2 y DSDM. Pero… ¿Como integrar los dos métodos? Creo que primero se debe entender cuales son las limitaciones y fortalezas de cada uno de ellos.

Prince2 es un método genérico de administración de proyectos que puede ser empleado para cualquier tipo de proyectos dentro de cualquier tipo de organización. Algunas fortalezas son:

-> Brinda buenos canales de comunicación entre el proyecto, la gerencia del proyecto y el resto de la organización.
-> Provee revisiones regulares del progreso contra el plan y el caso de negocios.
-> Tiene un inicio, medio y fin controlados y organizados.
-> Brinda puntos de decisión flexibles.

-> Provee control administrativo automático de cualquier desviación del plan
-> Provee el compromiso de la gerencia y partes interesadas en el momento y lugar apropiado durante el proyecto

Prince2 no cubre la gestión de servicios ni la gestión del personal.

DSDM es un framework muy útil para proyectos con restricciones temporales o requerimientos cambiantes, combina el punto de vista de las metodologías ágiles (desarrollo rápido de las aplicaciones) con una especificación más rigurosa de la gestión del proyecto. Se compone de un conjunto de principios, un ciclo de vida del proyecto con flexibilidad, roles y responsabilidades claramente definidas y un conjunto de técnicas de mejores prácticas que permitan la entrega del producto.

Con la integración de Prince2 y DSDM todas las fortalezas están en un lugar y permiten un enfoque verdaderamente escalable a agilizar la entrega del proyecto.

La integración de DSDM dentro de un ambiente que utilice PRINCE2 es bastante sencilla ya que ambos enfoques se basan de una manera similar y puede ser descrita como procedente de la misma estable. Ambos usan descripciones de productos y tienen similares estructuras organizativas, por lo tanto, cuando se realiza la combinación de los dos es necesario adoptar nuevos conceptos y componentes del DSDM e instalarlos dentro de la estructura del Prince2. El DSDM adicionaría los siguientes conceptos al PRINCE2:

-> Introducir mecanismos de tolerancia del alcance.
-> Brindar un desarrollo iterativo e incremental de los productos.
-> Proporcionar estructuras de entrega del producto.
-> Permitir un carácter ágil.
-> Promover el uso de talleres de modelado.

Por conclusión, todos los proyectos son únicos pero también tienen semejanzas y utilizar PRINCE2 con DSDM permite a una organización elegir el camino en el cuál ellos desean ejecutar un proyecto en particular. En algunas ocasiones las organizaciones necesitarán ejecutar un proyecto con gerencia muy fuerte y poco lugar para la maniobra. Sin embargo, en otras situaciones un proyecto puede existir una relación más de colaboración y esto puede aprovecharse para tomar ventajas dentro de un enfoque más ágil para aproximarse a una solución exacta.

Referencia:

www.best-management-practice.com/gempdf/DSDM_White_Paper_v2.pdf

MPMM vs Prince2 vs. PMBOK

Antes de comenzar con las diferencias entre ellos, quiero hacer una breve definición de los términos.

_ Prince2 (Projects in Controlled Environments): Estándar británico que contiene las mejores prácticas en gestión de proyectos, altamente usado en el gobierno británico y sector privado británico. Metodología de gestión de proyectos que cubre la administración, control y organización de un proyecto. Ademas Prince2 consiste en dividir el plan del proyecto en numerosos niveles para un fácil planeamiento y control.

_ PMBOK (Project Management Body of Knowledge): Colección de procesos y áreas de conocimientos creado por el PMI altamente reconocido como las mejores prácticas dentro de la disciplina de la gerencia de proyectos.

_ MPMM (Method123 Project Management Methology): Ayuda a la implementación de las mejores prácticas en la gestión de proyectos ya que se encuentra alineado con los estándares PMBOK y Prince2.

Algunas Diferencias:

El PMBOK brinda las herramientas y plantillas que son necesarias para completar con éxito cada una de las fases de vida del proyecto mientras el MPMM muestra como utilizar dichas herramientas en nuestro proyecto.

Las diferencias entre el PMBOK y Prince2 son mínimas ya que ellos consideran procesos similares para la planificación de un proyecto.

--> No puedo asegurar cual de las dos metodologías es mejor sería cosa de probar Prince2 para poder afirmarlo, pero tengo mucha curiosidad sobre Prince2 no dudo en que muy pronto lo aplicaré.

Espero alguna opinión sobre éste tema :) ...

Referencias:

_ http://ezinearticles.com/?PRINCE2---Blend-of-Traditional-and-Agile-Project-Management-Training&id=1333890
_ http://www.mpmm.com/project-management-best-practices.php

Usando el OpenProj 1.3

Bueno como les comentaba en el anterior post ya está disponible el OpenProj 1.3, y ya lo probé :) ... he encontrado ventajas nomas por tal motivo no mencionaré ninguna desventaja ... asi q pruebenlo a ver si es mas fácil de manipular que el Microsoft Project, xq para mi si lo es :)

Ventajas:

--> Wiki completo y detallado en el uso de ésta herramienta.

--> Nuevos diagramas como el WBS (estructura de desglose de actividades) y RBS (estructura jerárquica de los recursos humanos).

--> Fácil uso en el desarrollo de un diagrama de Gantt con tan solo arrastrar la barra de seguimiento actualiza las fechas de inicio y fin.

--> Filtros por tareas terminadas, por prioridades, por fechas, por estado, por duración, etc.

--> Mas organizado, ya que brinda al usuario facilidad de acceso a opciones del OpenProj 1.3.

En fin, espero q encuentren alguna desventaja xq fácil debe tener!!!, ya que lo he probado a la volada! :) ... Aca les dejo el link otra ves ya que el anterior no se puede descargar :S :

http://ufpr.dl.sourceforge.net/sourceforge/openproj/openproj-1.3.1.msi

Espero q lo prueben!, el próximo post será acerca del PMBOK...

Una nueva herramienta para la Gestión de Proyectos

OpenProj 1.3, una solución real para la gestión de proyectos OpenProj es una excelente solución de código abierto para la gestión de proyecto, según sus creadores es el remplazo ideal de Microsoft Project y otras soluciones de gestión de proyectos. Tiene versiones listas para usarse en Windows, Linux y Mac. OpenProj esta programado en Java y se distribuye bajo los terminos de CPAL license. Para linux existen paquetes en .deb y .rpm para instalarlo de manera fácil en las distribuciones basadas en Red Hat y Debian. Incluso se incluye por defecto en la versión europea de StaOffice, OpenProj se ha traducido a Francés, Español, Alemán, Portugues, Sueco, Finlandés, Gallego, Persa, Ruso, Coreano y Chino.

Source:

http://somoslibres.org/modules.php?name=News&file=article&sid=2030

Será verdad que es una excelente herramienta??? Bueno eso lo tengo q ver, lo voy a probar y después comento q tal me fue! Ahí he dejado el link (source) para q lo descarguen y lo prueben.