# data[].attributes.headline
Planificación de la gestión de interesados. Javier Hernandez.

# data[].attributes.subject
Planificación de la gestión de interesados. Javier Hernandez.

# data[].attributes.body
El Involucramiento de los Interesados es el proceso de desarrollar enfoques con base en las necesidades, expectativas, intereses y el posible impacto de los interesados.

Directamente relacionado con la planificación de comunicación este proyecto toma este plan como entrada, en conjunto con otros documentos de la fase inicial como el Acta de constitución del proyecto y otorga como salida el plan de involucramiento de interesados.

# data[].attributes.headline
Planificación de la gestión de riesgos. Javier Hernandez.

# data[].attributes.subject
Planificación de la gestión de riesgos. Javier Hernandez.

# data[].attributes.body
Es el conjunto de procesos que definen las actividades necesarias para la gestión de riesgos.

Identificar los riesgos, realizar análisis cuantitativos y cualitativos de estos riesgos y planificar una estrategia para responder a los mismos, son procesos que forman parte de este conjunto.

Los riesgos están vinculados con cada uno de los aspectos de la gerencia de proyectos y por ende la salida de este proceso se manifiesta en actualizaciones a los otros documentos de los procesos de gestión.

# data[].attributes.headline
Planificación de las Adquisiciones Javier Hernandez.

# data[].attributes.subject
Planificación de las Adquisiciones Javier Hernandez.

# data[].attributes.body
Es el proceso de documentar y especificar las adquisiciones del proyecto. El beneficio clave de este proceso es que determina si es preciso adquirir bienes y servicios desde fuera del proyecto y, si fuera el caso, qué adquirir, de qué manera y cuándo hacerlo.

Este proceso, utilizando como entrada los documentos de la fase de inicio del proyecto otorga varias salidas como el plan de gestión de adquisiciones , la estrategia de adquisiciones, documentos para licitaciones, criterios de selección de proveedores y otros.

# data[].attributes.headline
Planificación de la gestión de comunicaciones Javier Hernandez.

# data[].attributes.subject
Planificación de la gestión de comunicaciones Javier Hernandez.

# data[].attributes.body
Es el proceso de desarrollar un enfoque y plan apropiado para las actividades de comunicación del proyecto, enfocando en las necesidades de información de cada interesado o grupo, en los activos de la organización disponibles y en las necesidades del proyecto.

Este proceso otorga como salida el plan para la gestión de las comunicaciones.

# data[].attributes.headline
Planificación de la gestión de recursos Javier Hernandez.

# data[].attributes.subject
Planificación de la gestión de recursos Javier Hernandez.

# data[].attributes.body
Es el proceso de realizar una estrategia para estimar, adquirir gestionar y utilizar los recursos físicos de la empresa.

Este proceso está relacionado con las actividades del proyecto, ya que es necesario estimar los recursos a utilizar en cada una de ellas.

Como entrada este proceso utiliza el Acta de constitución del proyecto. la línea base de actividades, la línea base del cronograma y obtenemos como salida el plan de gestión de recursos, el acta de constitución del equipo, los requisitos de recursos y la estructura de desglose de recursos.

# data[].attributes.headline
Planificación de la gestión de Calidad - Javier Hernandez.

# data[].attributes.subject
Planificación de la gestión de Calidad - Javier Hernandez.

# data[].attributes.body
Es el proceso de identificar los requisitos y estándares de calidad y definir la estrategia con la que el proyecto va a cumplirlos.

Utilizando como entrada el plan para la dirección del proyecto, el acta de constitución, los factores ambientales y procesos activos de la empresa, obtenemos como salida los estándares de calidad del proyecto y el plan para la gestión de calidad.

# data[].attributes.headline
Planificación de la gestión de Costos - Javier Hernandez.

# data[].attributes.subject
Planificación de la gestión de Costos - Javier Hernandez.

# data[].attributes.body
Es el proceso de definir la manera en la que se va a presupuestar, gestionar, monitorear y controlar los costos del proyecto.

Este proceso toma como entrada el plan para la dirección del proyecto, los documentos relacionados a factores que están relacionados a un costo, los factores ambientales de la empresa y procesos activos de la organización, como salida obtenemos el plan de gestión de costos, estimaciones de costos y la base de estimaciones.

# data[].attributes.headline
Planificación del Cronograma del proyecto - Javier Hernandez.

# data[].attributes.subject
Planificación del Cronograma del proyecto - Javier Hernandez.

# data[].attributes.body
Es el proceso de definir las políticas, procedimientos y la documentación necesaria para la definición y gestión del cronograma.

Este proceso comprende la definición,  estimación y secuenciación de actividades, para luego desarrollar un cronograma y un plan para gestionar el mismo.

Las entradas de este proceso comprende el plan para la dirección del proyecto, el plan de requisitos y alcance, los factores ambientales y procesos activos de la empresa, como salida obtenemos la lista de actividades, línea base del cronograma, el cronograma del proyecto y el plan de gestión del cronograma.

# data[].attributes.headline
Planificación de la gestión del Alcance. Javier Hernandez

# data[].attributes.subject
Planificación de la gestión del Alcance. Javier Hernandez

# data[].attributes.body
La gestión del alcance define, válida y controla el alcance del proyecto, el proceso de la planificación de esta gestión incluye la documentación que defina las estrategias a utilizar para realizar este objetivo.

La definición general del alcance, la recopilación de requisitos y la creación de EDT (Estructura de Desglose de Trabajo) son procesos comprendidos en la planificación del alcance.

Como entradas este proceso toma el Acta de constitución del proyecto, Las salidas de los procesos de la fase de inicio, Los factores ambientales de la empresa, los procesos activos de la organización y el plan para la dirección del proyecto. Como salida obtenemos el plan para la gestión del alcance y el plan para la gestión de requisitos.

# data[].attributes.headline
Planificación de la dirección del proyecto  - Javier Hernandez.

# data[].attributes.subject
Planificación de la dirección del proyecto  - Javier Hernandez.

# data[].attributes.body
El desarrollo del plan para la dirección del proyecto es el proceso de definir todos los componentes del proyecto y consolidarlos en un plan integral que determine la dirección. Este proceso define la base para todo el trabajo del proyecto y el método en el que se realizará.

Como entradas este proceso toma el Acta de constitución del proyecto, Las salidas de los procesos de la fase de inicio, Los factores ambientales de la empresa y los procesos activos de la organización, como salida obtenemos el plan para la dirección del proyecto.

# data[].attributes.headline
Jose Gil - Falta de Comunicación con el Cliente o los Usuarios

# data[].attributes.subject
Jose Gil - Falta de Comunicación con el Cliente o los Usuarios

# data[].attributes.body
Aunque lo ideal fuese un levantamiento total de requerimientos que permitiese contemplar todos los factores para la realización del proyecto, esto es algo irreal. Usualmente faltan detalles, estos suelen ser triviales para alguna de las partes y por consiguiente de no cumplirse son los primeros en llevar a errores de desarrollo. Por este motivo es importante llevar un control de los avances realizados por el proyecto que permita evaluar este tipo de desviaciones.

# data[].attributes.body
Pudiese surgir al momento de levantar los requerimientos del proyecto, la creación objetivos que por diversos motivos no se pueden cumplir

# data[].attributes.headline
Procesos de la planificacion (PMBOK) - Javier Hernandez.

# data[].attributes.subject
Procesos de la planificacion (PMBOK) - Javier Hernandez.

# data[].attributes.body
Es el grupo de procesos que definen los objetivos, ofreciendo una línea de acción para cumplirlos.

Usualmente este grupo de procesos son ejecutados repetidas veces durante el desarrollo del proyecto.

# data[].attributes.body
Abarca situaciones que generen perdidas de capital para la empresa, dichas situaciones pueden atribuirse a alteraciones en el mercado, empresas rivales o demandas legales.

# data[].attributes.body
Incluye el área tecnológica de la empresa, donde pueden presentarse fallas de seguridad que se relacionen a violaciones del sistema y fallas de electricidad que implican suspensión de servicios como internet.

# data[].attributes.body
En este caso hablamos de fallas de ejecución o dentro del medio, entonces eso da como consecuencia problemas en la planificación del proyecto y dificultades en la comunicación del equipo.

# data[].attributes.body
Estos riesgos implican aquellos que están fueras de nuestro alcance, como desastres naturales o caso reciente pandemias.

# data[].attributes.body
Cuando nos referimos a estos riesgos hablamos de las malas decisiones o mal rendimiento, es decir, un software no compatible que no cumpla con los requerimientos o un proveedor problemático.

# data[].attributes.body
Dentro de los riesgos contemplados es posible que coincidan con estos:

# data[].attributes.body
La gestión del tiempo comprende la planificación sobre las actividades y la cantidad de tiempo de la realización de cada una de ellas en el proyecto, todo esto con el objetivo de ganar eficiencia y productividad en la realización de las actividades.
Al realizar la planificación de estas actividades permite definir prioridades, plazos, objetivos y puntos importantes del proyecto.

# data[].attributes.body
La gestión de costos de un proyecto comprende el proceso de estimar, presupuestar y controlar los costos asociados al desarrollo del proyecto con el objetivo de mantener los gastos dentro del presupuesto disponible. Es importante realizar estos estudios ya que da pie al inicio del proyecto con los recursos que puedan entrar en el presupuesto. Sin un presupuesto definido se vuelve complicado saber si se esta progresando en el proyecto de la manera mas eficiente posible.

# data[].attributes.headline
José Di Pietro - Ventaja: Mide la eficacia

# data[].attributes.subject
José Di Pietro - Ventaja: Mide la eficacia

# data[].attributes.body
Con una gestión general de los recursos se obtiene una comprensión general de los costos y el retorno de la inversión, haciendo mas viable ejecutar algún otro proyecto parecido.

# data[].attributes.headline
José Di Pietro - Ventaja: Consigue transparencia

# data[].attributes.subject
José Di Pietro - Ventaja: Consigue transparencia

# data[].attributes.body
Gracias a la gestión de recursos otros equipo de la organización pueden ver la capacidad de tu equipo y de esta poder planificar en consecuencia si tu equipo esta al máximo de su capacidad o si tiene disponibilidad para otro proyecto.

# data[].attributes.headline
José Di Pietro - Ventaja: Proporciona una red de seguridad

# data[].attributes.subject
José Di Pietro - Ventaja: Proporciona una red de seguridad

# data[].attributes.body
En un caso hipotético que el proyecto no haya tenido éxito debido a la falta de recursos, la planificación y gestión de los recursos establece que tienes que hacer lo que puedas con lo que tienes a disposición.

# data[].attributes.headline
José Di Pietro - Ventaja: Impide el desgaste

# data[].attributes.subject
José Di Pietro - Ventaja: Impide el desgaste

# data[].attributes.body
Realizar una buena gestión de recursos permite evitar la sobreasignación o dependencia de actividades o activos, dejando así una visión mas clara sobre la carga del equipo.

# data[].attributes.headline
José Di Pietro - Ventaja: Evitar dificultades

# data[].attributes.subject
José Di Pietro - Ventaja: Evitar dificultades

# data[].attributes.body
El conocer los recursos previamente y planificar como, donde y en que circunstancia serán requeridos nos ayuda a solucionar carencias o prever problemas antes de que aparezcan.

# data[].attributes.headline
José Di Pietro - Ventajas de Gestión de Recursos

# data[].attributes.subject
José Di Pietro - Ventajas de Gestión de Recursos

# data[].attributes.body
La gestión de recursos es indispensable para ejecutar un proyecto, y puede abarcar desde la gestión de las habilidades del personal hasta cualquier activo requerido para el avance del proyecto. La gestión de recursos trata de hacer más con menos, tratar de malgastar los recursos lo menos posible, sobre todo en el mundo empresarial.

# data[].attributes.body
Es el periodo temporal comprendido entre el inicio y el final de un proyecto, es decir, su duración, influencia todas las otras restricciones. Normalmente se ve reflejado en un cronograma.

# data[].attributes.body
Es la magnitud de un proyecto, esto se ve reflejado en los entregables que se deben realizar, los productos resultantes del proyecto y la calidad de ambas cosas.

# data[].attributes.body
Es el nivel de profundidad en el que las entregas de un proyecto, o una parte de un proyecto, empiezan a cumplir con el requerimiento propuesto. La calidad suele verse afectada a causa de fluctuaciones en las otras restricciones

# data[].attributes.body
Son representadas a través de un presupuesto que contiene todos los requisitos con el costo financiero asociado a ellos, todos los proyectos requieren de calcular un costo a su inicio pero es común que cambie a lo largo de la vida del proyecto.

# data[].attributes.body
Son los medios con los cuales contamos para poder cumplir con los objetivos planteados a lo largo de un proyecto, para asegurar que su uso sea el más óptimo es necesario estimar la necesidad de cada recurso y gestionar su uso.

# data[].attributes.body
Los riesgos son las ocurrencias inesperadas que pueden ocurrir a lo largo del ciclo de vida de un proyecto, en su mayoría tienen un efecto negativo, para esto deben ser mitigados a través de la gestión de riesgos

# data[].attributes.body
La realización de un proyecto se ve limitada por distintos factores los cuales denominamos restricciones, estas muchas veces interactúan entre si y se influencian, deben ser calculados al inicio de un proyecto y perfeccionadas a lo largo de la ejecución de él.
Según la quinta edición del PMBOK, existen 6 restricciones las cuales debemos equilibrar a lo largo del proceso de la gestión de proyectos. Les Restricciones son las siguientes:

# data[].attributes.body
La gestión organizacional es el proceso de organizar, planificar y controlar eficientemente los recursos y el personal de una empresa u organización con el fin de alcanzar un objetivo predefinido.

La gestión de la organización permite el uso óptimo de los recursos mediante una planificación y un control meticulosos en el lugar de trabajo. Para eso, la gestión organizacional de una empresa debe ser capaz de tomar decisiones y resolver problemas.

Una gestión eficaz garantiza la rentabilidad de la organización y le da un sentido de dirección a los empleados, pues provee a los individuos el conocimiento de sus funciones y responsabilidades y de lo que deben hacer en la organización.

# data[].attributes.body
La gestión de proyectos es el proceso de planeación, organización y ejecución de proyectos de manera que puedan cumplirse los objetivos específicos aun trabajando con restricciones, como presupuestos y calendarios.

Este tipo de gestión es parte de la gestión organizacional de una empresa, e incluye la ejecución, el seguimiento y el cierre de los proyectos, además de que tiene un producto final con plazo de tiempo limitado.

# data[].attributes.headline
Caracteristicas de un proyecto complejo - Jose Saad

# data[].attributes.subject
Caracteristicas de un proyecto complejo - Jose Saad

# data[].attributes.body
- Se caracterizan por la incertidumbre, la ambigüedad, las interfaces dinámicas y las influencias políticas o externas significativas.
- Por lo general, se ejecutan durante un período que excede el tiempo del ciclo tecnológico de las tecnologías involucradas.
- Se puede definir por efecto, pero no por solución.

# data[].attributes.body
Cuando se trata de proyectos y prácticas, es posible que una talla no sirva para todos. El tamaño del proyecto es un factor determinante del "alcance del proceso", definido más simplemente como el grado y la medida en que se aplican formalmente las prácticas de gestión de proyectos.
El tamaño del proyecto es un factor que debe tenerse en cuenta para la planificación del proyecto, lo que garantiza que los planes y las actividades sean relevantes y que los recursos se utilicen y asignen correctamente.
Es imprudente y poco práctico adoptar un enfoque de "talla única" para la gestión de proyectos. Las metodologías de proyectos pequeños nunca encajarían en un proyecto a gran escala, y cualquier proyecto pequeño sería superado fácilmente por el peso de procedimientos y prácticas demasiado detallados.

# data[].attributes.body
Este recurso hace referencia a donde se incorpora toda la parte de hardware y software para que trabajen en conjunto;  el hardware proporciona una plataforma que soporta las herramientas (software) requeridas para producir los productos operativos.

Ref. bibliográfica: Pressman, R. Ingeniería del software un enfoque practico. Séptima edición. México, D. F.: McGRAW-HILL INTERAMERICANA EDITORES, 2010.

# data[].attributes.headline
Fernando Silva- Recursos de software reutilizables

# data[].attributes.subject
Fernando Silva- Recursos de software reutilizables

# data[].attributes.body
Cuando en proyectos se utiliza la ingeniería de software basada en componentes, hace mucho énfasis a la reutilización, la reutilización de componentes los cuales son bloques constructores de software. Se han categorizado en cuatro principales: Comerciales, los cuales se adquieren de terceros; de Experiencia completa, los cuales se emplearon en proyectos anteriores y se sabe que funcionan, esto reduce notablemente los riesgos; de Experiencia parcial, los cuales se emplearon en proyectos anteriores pero hay que hacerles modificaciones; y por ultimo, Nuevos, los cuales se construyen desde cero.

Normalmente los componentes de software reutilizables con frecuencia se desprecian durante la planificación, para eso es mejor especificar tempranamente los requisitos de recurso del software.

Ref. bibliográfica: Pressman, R. Ingeniería del software un enfoque practico. Séptima edición. México, D. F.: McGRAW-HILL INTERAMERICANA EDITORES, 2010.

# data[].attributes.body
La cantidad de personas requeridas para un proyecto se calcula después de la estimación del esfuerzo de desarrollo del mismo. Para proyectos pequeños basta con una sola persona para realizar las tareas, y claro consultar a especialistas. Por otro lado, para proyectos mas grandes se recomienda al equipo de software ubicarse en diferentes lugares geográficos. Se recomienda especificar tanto la posición organizacional (Ejem.: Ingeniero) como la especialidad (Ejem.: Base de datos).

Ref. bibliográfica:  Pressman, R. Ingeniería del software un enfoque practico. Séptima edición. México, D. F.: McGRAW-HILL INTERAMERICANA EDITORES, 2010.

# data[].attributes.body
Según Pressman, la segunda tarea en la planificación de proyectos de software es la estimación de los recursos a utilizar, los cuales se pueden englobar en tres categorías: humanos,  componentes de software reutilizables y en torno de desarrollo.

Ref. bibliográfica:  Pressman, R. Ingeniería del software un enfoque practico. Séptima edición. México, D. F.: McGRAW-HILL INTERAMERICANA EDITORES, 2010.

# data[].attributes.headline
Ricardo Díaz - Pasos para usar la Matriz de Riesgos

# data[].attributes.subject
Ricardo Díaz - Pasos para usar la Matriz de Riesgos

# data[].attributes.body
Una vez que hayas creado una matriz de riesgos, puedes usarla como una herramienta de análisis integral. Lo mejor de la plantilla de matriz de riesgos es que no necesitas cambiarla con cada proyecto. Una vez que la tengas, puedes reutilizarla y compartirla con los demás [2].

# data[].attributes.headline
Ricardo Díaz - Nivel de Impacto de Riesgo

# data[].attributes.subject
Ricardo Díaz - Nivel de Impacto de Riesgo

# data[].attributes.body
Cuando colocas un riesgo en la matriz en función de su probabilidad y gravedad, obtendrás el nivel de impacto del riesgo. El impacto del riesgo está codificado por color de verde a rojo y clasificado en una escala de 1 a 25.

Bajo (1-6): Es probable que los eventos de bajo riesgo no sucedan y, si suceden, no tendrán consecuencias significativas para tu proyecto o empresa. Puedes etiquetarlos como de baja prioridad en tu plan de gestión de riesgos.

Medio (7-12): Los eventos de riesgo medio son una molestia y pueden causar contratiempos en el proyecto, pero si tomas las medidas correspondientes para prevenir y mitigar estos riesgos durante la planificación del proyecto, estarás allanando el camino hacia el éxito del proyecto. No debes ignorar estos riesgos, pero tampoco es necesario que sean tu principal prioridad.

Alto (13-25): Si no los tienes en cuenta durante la planificación del proyecto, los eventos de alto riesgo pueden hacer que tu proyecto descarrile. Dado que es probable que estos riesgos ocurran y tengan consecuencias graves, son lo más importante en tu plan de gestión de riesgos [2].

# data[].attributes.body
Deberás identificar la escala de probabilidad, que colocarás en las filas de tu plantilla de matriz de riesgos. La escala de probabilidad identifica que tan probable es que ocurra cada riesgo.

Muy probable (5): Puedes estar bastante seguro de que este riesgo ocurrirá en algún momento.

Probable (4): Existe una gran probabilidad de que este riesgo ocurra.

Posible (3): Este riesgo podría ocurrir o no. Las probabilidades de que suceda son 50/50.

No es probable (2): Existe una gran probabilidad de que este riesgo no ocurra.

Muy improbable (1): El hecho de que este riesgo ocurra es una posibilidad remota [2].

# data[].attributes.body
Al momento de crear la plantilla de matriz de riesgos, primero deberás identificar tu escala de gravedad, que colocarás en las columnas de tu matriz. ​​La escala de gravedad mide qué tan graves serán las consecuencias de cada riesgo. En una matriz de cinco por cinco, tendrás cinco niveles en tu escala de gravedad.

Insignificante (1): El riesgo generará pocas consecuencias si ocurriera.

Menor (2): Las consecuencias del riesgo se gestionarán con facilidad.

Moderada (3): Las consecuencias del riesgo tardarán en mitigarse.

Importante (4): Las consecuencias de este riesgo serán significativas y pueden causar daños a largo plazo.

Catastrófica (5): Las consecuencias de este riesgo serán muy perjudiciales y puede resultar difícil recuperarse [2].

# data[].attributes.body
Una matriz de riesgos es una herramienta de análisis de riesgos que sirve para evaluar la probabilidad y la gravedad del riesgo durante el proceso de planificación del proyecto [2].

# data[].attributes.body
Utilizar software u otras utilidades informáticas inadecuadas supondrá una merma en tu productividad. Si existen problemas tecnológicos, esto retrasará o dificultará la entrega de tus proyectos.

Para evitar este tipo de problemas, nosotros ponemos a tu disposición un software líder en gestión de proyectos. Así, al menos por esta parte, podrás respirar tranquilo.

Una vez conozcas las fuentes de las que pueden proceder los riesgos que se pueden presentar durante la ejecución de tu proyecto, te será más fácil identificarlos e incluirlos en tu planificación. Así podrás desarrollar planes para eliminarlos, transferirlos, mitigarlos o, si no queda otro remedio, aceptarlos. En ese caso, podrás elaborar planes de contingencia [1].

# data[].attributes.body
Los recursos de los que se dispone para realizar un proyecto también experimentan modificaciones durante el transcurso de este. Aunque inicialmente los recursos presupuestarios sean de una determinada cantidad, es posible que durante el desarrollo del proyecto se presenten cambios en la situación económica del sector al que se dedica la empresa o cambios macroeconómicos.

En estas circunstancias, el director de proyectos tendrá que hacer lo que pueda con el presupuesto que finalmente tenga asignado, eliminando aquellas tareas que aportan menos al conjunto del proyecto y tratando de garantizar un resultado que cumpla con los requisitos mínimos necesarios para considerar que el proyecto ha sido exitoso.

Por otro lado, los recursos humanos también pueden experimentar modificaciones. El personal que comienza realizar un proyecto no necesariamente será el mismo que lo termine. Además, los nuevos miembros que se incorporen al equipo cuando el proyecto ya se encuentre comenzado, deberán emplear un tiempo en adaptarse. Esto supondrá, al menos temporalmente, una menor eficiencia y productividad [1].

# data[].attributes.body
Las razones por las que es posible que el proyecto no se desarrolle de la manera en la que se había planificado inicialmente no necesariamente tienen por qué ser errores propios de nuestro equipo, sino que pueden obedecer a causas externas.

Retrasos en el suministro por parte de un proveedor externo, accidentes u otros imprevistos no controlados, pueden alterar la planificación inicial.

Por ello, una adecuada planificación debe prever todos los escenarios posibles y además cuantificarlos, tanto en la probabilidad de que se presenten, como en el grado de desviación que supondrían con respecto al escenario considerado inicialmente como idóneo.

En este caso puede ser muy útil elaborar una matriz de evaluación de riesgos [1].

# data[].attributes.headline
Ricardo Díaz - Riesgos de la planificación

# data[].attributes.subject
Ricardo Díaz - Riesgos de la planificación

# data[].attributes.headline
Ricardo Díaz - Riesgos relacionados con los recursos

# data[].attributes.subject
Ricardo Díaz - Riesgos relacionados con los recursos

# data[].attributes.body
En general se desea medir los siguientes aspectos en Ingeniería de Software:

Procesos o tareas a ejecutar (modelado, diseño, prueba).

Productos entregados durante el proceso (documentaciónde diseño, código fuente, registro de pruebas).

Recursos que permiten realizar el proceso (personal, computadoras, dinero).

# data[].attributes.headline
Grado de estructuración del proyecto - José Contreras

# data[].attributes.subject
Grado de estructuración del proyecto - José Contreras

# data[].attributes.body
En este contexto, la estructuración se refiere a la facilidad con la que las funciones pueden ser compartimentalizadas y la naturaleza jerárquica de la información que debe ser procesada.

# data[].attributes.body
A medida que aumente el tamaño o la interdependencia entre distintos elementos del software, éste tiende a crecer rápidamente.

# data[].attributes.headline
Complejidad del Proyecto - José Contreras

# data[].attributes.subject
Complejidad del Proyecto - José Contreras

# data[].attributes.body
La complejidad, sin embargo, es una medida relativa que se ve afectada por la familiaridad 53 con anteriores esfuerzos.

# data[].attributes.body
La estimación es una parte importante de la etapa de planificación de un proyecto. Una forma de estimar es utilizar métricas basadas en mediciones pasadas para hacer las estimaciones. También es útil dividir el proyecto en pequeñas unidades o partes para facilitar la estimación

# data[].attributes.body
Si un riesgo se llega a hacer realidad, hay que responder. Si se cumplen correctamente los pasos anteriores, para este punto ya se debería contar con múltiples planes de acción para afrontar estos riesgos

# data[].attributes.body
Cuando el proceso de desarrollo esté en marcha, se debe hacer un monitoreo continuo del proyecto para intentar atajar los riesgos antes que ocurren o actuar lo mas rápido posible si ya ocurrieron.

Es importante que el equipo tenga una buena cultura colaborativa para que no suceda que un miembro note un problema pero le dé miedo informarlo

# data[].attributes.body
Una medición es una representación del mundo real en un lenguaje matemático, que puede servir para comparar de forma mas eficiente diferentes entidades y ocurrencias. Las mediciones nos dan una descripción cuantitativa de una situación lo que nos ayuda a poder reproducirla cuantas veces sea necesario. El reto y la meta a la hora de realizar mediciones es interpretar los resultados, juzgar sus causas y significados y emitir decisiones a partir de ellos.

# data[].attributes.body
Resulta útil designar a un miembro del equipo como el responsable de gestionar un riesgo en particular antes de que este riesgo ocurra

# data[].attributes.body
Atender todos los riesgos es caro, por lo tanto hay que decidir cuales son mas importantes, para ello, usando como base los dos pasos anteriores, se debe asignar una cierta prioridad a cada riesgo identificado y analizado.

# data[].attributes.body
Por cada riesgo identificado se debe analizar cual es su probabilidad de ocurrencia, cuál sería su impacto en caso de suceder y hacer un plan de respuesta

# data[].attributes.headline
Mediciones de Producto y Proceso - José Contreras

# data[].attributes.subject
Mediciones de Producto y Proceso - José Contreras

# data[].attributes.body
“Medimos para mejorar” Las mejoras en el proceso de desarrollo de software y sistemas de calidad no pueden ser evaluadas sin un esfuerzo efectivo de medición

Referencia Bibliográfica

# data[].attributes.body
Lo primero es identificar cuales son los posibles riesgos para el proyecto.

# data[].attributes.headline
Jorge Cróquer - Proceso para gestionar riesgos

# data[].attributes.subject
Jorge Cróquer - Proceso para gestionar riesgos

# data[].attributes.body
Según Julia Martins, el proceso para gestionar los riesgos de un proyecto consta de 6 pasos

# data[].attributes.headline
Jorge Cróquer - Posibles riesgos para un proyecto

# data[].attributes.subject
Jorge Cróquer - Posibles riesgos para un proyecto

# data[].attributes.body
Algunos de los posibles riesgos a la hora de desarrollar un proyecto

# data[].attributes.body
En cualquier desarrollo de proyecto existen riesgos para la calidad del producto final que deben ser correctamente gestionados para ser mitigados

Ver este blog de Julia Martins publicado el 5 de mayo de 2022

# data[].attributes.body
- Simple Design: El mejor diseño para el software es el más simple que funciona. Si se encuentra alguna complejidad, debe eliminarse.

- Coding Standards: Un equipo debe tener conjuntos comunes de prácticas de codificación utilizando los mismos formatos y estilos para la redacción de código.

- Collective Code Ownership: Esta práctica declara la responsabilidad de todo un equipo por el diseño de un sistema. Cada miembro del equipo puede revisar y actualizar el código.

- System Metaphor: La metáfora del sistema representa un diseño simple que tiene un conjunto de ciertas cualidades. En primer lugar, un diseño y su estructura deben ser comprensibles para la gente nueva.

# data[].attributes.body
- Code Refactoring: La refactorización consiste en eliminar la redundancia, eliminar las funciones innecesarias, aumentar la coherencia del código y, al mismo tiempo, desacoplar elementos.

- Continuous Integration: . Los programadores discuten qué partes del código pueden ser reutilizadas o compartidas y de esta manera ellos saben exactamente qué funcionalidad necesitan desarrollar.

- Small Releases: Esta práctica sugiere lanzar la primera versión rápidamente y desarrollar más el producto haciendo actualizaciones pequeñas e incrementales.

# data[].attributes.body
- Test-driven development:  Los equipos XP practican la técnica de desarrollo guiada por pruebas (TTD) que implica escribir una prueba unitaria automatizada antes del propio código.

- The Planning Game: Esta es una reunión que se produce al principio de cada sprint. El equipo de desarrollo y el cliente se reúnen para discutir y aprobar las características de un producto.

- On-site Customer: De acuerdo con XP, el cliente final debe participar plenamente en el desarrollo.

- Pair Programming: Esta práctica requiere que dos programadores trabajen conjuntamente en el mismo código.

# data[].attributes.headline
Prácticas de la programación XP - Andrea Mendoza

# data[].attributes.subject
Prácticas de la programación XP - Andrea Mendoza

# data[].attributes.body
XP sugiere usar 12 prácticas mientras desarrollamos software. Como XP está definido por valores y principios, sus prácticas también los representan y pueden agruparse en cuatro grupos:

# data[].attributes.body
La retroalimentación en las metodologías de desarrollo de software más tradicionales, tipo cascada, a menudo es «demasiado pequeña, demasiado tarde».

# data[].attributes.body
La simplicidad dice que siempre hay que esforzarse por hacer lo más sencillo que funcione. A menudo se malinterpreta y se interpreta como lo más sencillo y punto, ignorando la parte de «que funciona».

# data[].attributes.body
La falta de comunicación impide que los conocimientos fluyan dentro de un equipo. A menudo, cuando hay un problema, alguien ya sabe cómo resolverlo.

# data[].attributes.headline
Valores y principios de XP -Andrea Mendoza

# data[].attributes.subject
Valores y principios de XP -Andrea Mendoza

# data[].attributes.body
Los valores proporcionan un propósito a los equipos. Actúan como una «estrella del norte» para guiar sus decisiones en un alto nivel.

Los principios proporcionan una orientación más específica que los valores. Son directrices que iluminan los valores y los hacen más explícitos y menos ambiguos.

# data[].attributes.headline
Anamaría Chacón - Herramientas de Rentabilidad

# data[].attributes.subject
Anamaría Chacón - Herramientas de Rentabilidad

# data[].attributes.body
Cuentan con funciones para apoyar en aspectos de cálculo de las ganancias. Poder llevar el control de los costos reales de cada proyecto permite medir con exactitud cuánta ganancia deja cada proyecto [1].

# data[].attributes.headline
Anamaría Chacón - Herramientas de Colaboración

# data[].attributes.subject
Anamaría Chacón - Herramientas de Colaboración

# data[].attributes.body
Permiten compartir y actualizar el trabajo del proyecto de forma rápida y en tiempo real, proporcionando una retroalimentación instantánea entre los diferentes miembros del equipo. Este intercambio instantáneo ahorra tiempo y reduce la necesidad de largas cadenas de correo electrónico y llamadas telefónicas [1].

# data[].attributes.headline
Anamaría Chacón - Herramientas para Informes de Progreso

# data[].attributes.subject
Anamaría Chacón - Herramientas para Informes de Progreso

# data[].attributes.body
Es difícil para muchas empresas medir el progreso en un proyecto o tarea, ya que se deben tomar en cuenta muchas variables, en especial si el trabajo es inusual en tipo y alcance. Las herramientas para informes de proyecto ofrecen en tiempo real una vista actualizada de todo el progreso del proyecto [1].

# data[].attributes.headline
Anamaría Chacón - Herramientas para Gestión del Tiempo

# data[].attributes.subject
Anamaría Chacón - Herramientas para Gestión del Tiempo

# data[].attributes.body
En la gestión de proyectos, se debe hacer un buen uso del tiempo para acelerar el flujo de trabajo y aumentar la productividad. Un software de gestión de tiempo permite monitorear y registrar automáticamente el tiempo que se invierte en cada una de las tareas, así como en los diferentes proyectos de clientes. Algunas cuentan con Inteligencia Artificial, la cual puede identificar rápidamente cuánto tiempo se necesitará para terminar cada tarea, lo que permitirá ajustar deadlines de entrega y tomar previsiones [1].

# data[].attributes.headline
Anamaría Chacón - Herramientas de Planificación de Tareas

# data[].attributes.subject
Anamaría Chacón - Herramientas de Planificación de Tareas

# data[].attributes.body
Este tipo de herramienta permite agregar tareas de forma visualmente atractiva, indicando datos como fechas límites, reuniones, inicio y fin de la tarea, persona responsable de la misma, entre otros. Así se logra llevar un seguimiento de lo que se necesita hacer y se organiza con precisión la programación diaria, semanal e incluso mensual por adelantado [1].

# data[].attributes.headline
Anamaría Chacón - Clasificación de las Herramientas para la Gerencia de Proyectos

# data[].attributes.subject
Anamaría Chacón - Clasificación de las Herramientas para la Gerencia de Proyectos

# data[].attributes.body
Una herramienta de gerencia de proyectos es un software con el que se puede realizar un seguimiento a todas las actividades, tareas, recursos y demás elementos de uno o varios proyectos para lograr una gestión exitosa de proyectos. Dentro de estas hay diferentes tipos según las funciones que ofrecen [1].

# data[].attributes.headline
Miguel Yépez - Algunas Desventajas de Kanban

# data[].attributes.subject
Miguel Yépez - Algunas Desventajas de Kanban

# data[].attributes.body
Entre algunas desventajas que podemos observar en Kanban se encuentran:

-Apuesta por lo justo lo cual genera que sea altamente probable sufrir cuellos de botella
- Cuando los plazos de entrega no pueden cumplirse, se ve afectado el calendario de producción para el resto de pedidos
-Cuando hay demasiadas etiquetas y poca preparación, los miembros del equipo pueden confundirse fácilmente

Referencia Bibliografica

# data[].attributes.headline
Miguel Yépez -Algunas Ventajas de Kanban

# data[].attributes.subject
Miguel Yépez -Algunas Ventajas de Kanban

# data[].attributes.body
Entre algunas de las ventajas podemos encontrar las siguientes:

-Mayor visibilidad del flujo
-Mejorar la velocidad de entrega
-Alineación entre los objetivos empresariales y la ejecución
-Mejora de la capacidad de gestión de la escala y las dependencias

Referencias Bibliografica

# data[].attributes.headline
Roiberth Gonzalez - El Equipo de Desarrollo de Scrum

# data[].attributes.subject
Roiberth Gonzalez - El Equipo de Desarrollo de Scrum

# data[].attributes.body
Son los que más conocen las prácticas de desarrollo sostenible. Los equipos de scrum más eficaces tienen una relación estrecha, se encuentran en la misma ubicación y están compuestos por entre cinco y siete miembros.

Los miembros del equipo tienen distintas habilidades y se forman entre sí para que nadie se convierta en un cuello de botella en la entrega de trabajo. Los equipos de scrum sólidos se autoorganizan y enfocan sus proyectos con una clara actitud colectiva.

El equipo de scrum se encarga de:
1) Impulsar el plan de cada sprint
2) Prevén cuánto trabajo requieren para finalizar a lo largo de la iteración en función de su historial de velocidad.
3) Aportan al equipo de desarrollo feedback sobre su estimación y proceso de entrega, lo cual a su vez consigue que las previsiones sean cada vez más precisas.

# data[].attributes.body
Los expertos en scrum son los mayores especialistas de scrum en el equipo. Proporcionan formación a los equipos, a los propietarios de producto y a la empresa en el proceso de scrum, y buscan formas de afinar su práctica.

Un experto en scrum eficaz conoce profundamente el trabajo que realiza el equipo y puede ayudarlo a optimizar su transparencia y flujo de entrega. Como conseguidor principal, planifican los recursos necesarios (tanto humanos como logísticos) para organizar los plazos de los sprints, las reuniones rápidas, la revisión de sprints y las retrospectivas de sprints [1].

# data[].attributes.headline
Roiberth Gonzalez - El Propietario del Producto de Scrum

# data[].attributes.subject
Roiberth Gonzalez - El Propietario del Producto de Scrum

# data[].attributes.body
Los propietarios de producto son quienes más conocen el producto. Están centrados en entender los requisitos empresariales, de los clientes y del mercado, para luego priorizar el trabajo que el equipo de ingeniería debe realizar para cumplirlos. Los propietarios de producto eficaces [1]:

Crean y gestionan el backlog del producto

Se asocian estrechamente con el negocio y el equipo para asegurarse de que todo el mundo entiende los elementos de trabajo en el backlog del producto.

Aportan al equipo directrices claras sobre qué funcionalidades entregar a continuación.

Deciden cuándo lanzar el producto con predisposición hacia una entrega más frecuente.

# data[].attributes.headline
Roiberth Gonzalez - Retrospectiva de Sprint

# data[].attributes.subject
Roiberth Gonzalez - Retrospectiva de Sprint

# data[].attributes.body
La retrospectiva es donde el equipo se reúne para centrarse primordialmente en documentar lo que salió bien y lo que debe mejorarse para la próxima vez, y menos en lo que salió mal [1].

# data[].attributes.body
Al final del sprint, el equipo se reúne en una sesión informal para ver una demostración o inspeccionar el incremento. El equipo de desarrollo muestra los elementos del backlog que ahora están "finalizados" a las partes interesadas y a los compañeros de equipo para recibir comentarios [1].

# data[].attributes.headline
Roiberth Gonzalez - Busqueda de Cambios Progresivos

# data[].attributes.subject
Roiberth Gonzalez - Busqueda de Cambios Progresivos

# data[].attributes.body
Esta reocmendacion que proporciona la metodología Kanban, está definida para mitigar futuros riesgos incluyendo en el desarrollo herramientas mas completas que ayuden en la mejora del SI.

# data[].attributes.body
Se trata de una reunión diaria de muy corta duración que tiene lugar siempre a la misma hora y en el mismo sitio para facilitar las cosas con el fin de que todos los miembros del equipo estén en sintonía, se adecuen al objetivo del sprint y dispongan de un plan para las próximas 24 horas [1].

# data[].attributes.body
Es el periodo real en que el equipo de scrum trabaja de forma conjunta para finalizar un incremento. La duración de un sprint suele ser de dos semanas, aunque algunos equipos manifiestan que les resulta más fácil una semana para el alcance o un mes para entregar un incremento valioso [1].

# data[].attributes.headline
Roiberth Gonzalez - Planificación de Sprint

# data[].attributes.subject
Roiberth Gonzalez - Planificación de Sprint

# data[].attributes.body
En esta reunión, todo el equipo de desarrollo planifica el trabajo que se va a realizar (alcance) durante el sprint actual; donde en ella el equipo decide el objetivo del sprint. Posteriormente, se añaden historias de usuario específicas que se adecuan al objetivo y también son acordadas por el equipo de scrum para que sea factible implementarlas durante el sprint [1].

# data[].attributes.headline
Roiberth Gonzalez - Organización del Backlog

# data[].attributes.subject
Roiberth Gonzalez - Organización del Backlog

# data[].attributes.body
Es una lista de trabajo ordenado por prioridades para el equipo de desarrollo que se obtiene de la hoja de ruta y sus requisitos. Los elementos más importantes se muestran al principio del backlog del producto para que el equipo sepa qué hay que entregar primero [1].