GERENCIA DE PROYECTOS INFORMÁTICOS

Mirada en el Software Comercial

─

Karen Teran
Jalasoft

Descripción General
La asignatura se encargará de mostrar una visión general en la gerencia de proyectos a través de una mirada
a los conceptos de manejo de proyectos relacionados con las metodologías de desarrollo de software
comercial sus aplicaciones , su estructura y su organización
 1

Unidades de aprendizaje ( Taller)

La unidades de aprendizaje del taller tendrán como objetivo posicionar al alumno en situación de ejecución
y manejo de un proyecto de software comercial, que refuerce lo aprendido en el semestre regular (ver anexo
unidades de aprendizaje (semestre regular)), para tales objetivos los siguientes puntos serán desarrollados

I. Iniciar un proyecto en software comercial

II. Planificación/Ejecución de un proyecto en software comercial

III. Comunicación/Colaboración y buenas prácticas

 2

Especificaciones y desarrollo de las

unidades de aprendizaje del taller
Conociendo la gestión de proyectos

Que es un proyecto ?

Un proyecto es un trabajo temporal que tiene un objetivo específico y único, y generalmente un

presupuesto
Porque seria trabajo temporal?
Porque un proyecto tiene un inicio y un fin
Que pasa si el proyecto pareciera nunca acabar?
Eso significa que el objetivo principal no está bien definido, para definir el objetivo
Cual es el objetivo del proyecto?
Un proyecto genera un resultado único , que puede ser un servicio un producto u otro
resultado
Que es el budget de un proyecto?
Cuando se escucha de presupuesto se piensa en dinero , pero en en un proyecto se puede
existir limitantes como el tiempo que el proyecto tiene

Que es el manejo de proyectos?

El manejo de proyectos se puede resumir en las siguientes preguntas
Cual es el problema que queremos resolver?
Definir claramente qué es lo que el proyecto debe cumplir o alcanzar es el primer paso
para el éxito del proyecto
Como vas a solucionar el problema?
Sea que se solucione un problema o se persiga una oportunidad, para esto se definen el
enfoque que se le va a dar eligiendo una estrategia, identificado el enfoque se procede a
la solución que busca:
- Reunir requerimientos
- Definir entregables
- Alcance del proyecto
 3

Cual es tu plan?
Se debe identificar
El trabajo que se tiene que hacer
Los recursos
El tiempo de ejecución, cronograma ( schedule)
Procesos ( e.j. comunicación, manejo de cambios etc.)
Como sabes cuando terminas?
Para definir cuando se termina podemos determinar:
Success Criteria ( criterio de exito)
Resultados cuantificables y medibles que muestran que el proyecto está completo
Como le fue al proyecto?
Que funciona bien?, que podíamos haber hecho mejor?
En este paso por lo general se pasa por alto pero es importante y necesario tomarse un
tiempo para analizar cómo se ejecutó el proyecto

Qué es lo que se necesita para ser un project manager ( gerente de

proyectos)?
Project manager usan una gran variedad de habilidades y conocimiento para completar los proyectos con
éxito
Habilidades
Tecnicas
Que se pone un el plan, hacer un schedule, elaborar reportes , medir el rendimiento
Experiencia en el Negocio
Debe asegurarse que el proyecto entregue el producto que agregue valor al negocio, que es el
negocio que hace y que se considera importante
Resolución de problemas
Cómo manejar los problemas y cómo trabajar con ellos para que el proyecto continúe
Habilidades interpersonales
Los proyectos pueden ser ejecutados con personas de diferentes departamentos inclusive
empresas diferentes, siendo el líder del grupo es importante alinear al equipo y fomentar el
trabajo en equipo para que el proyecto se culmine con éxito
 4

Liderazgo
Una de los más importantes Inspirar al a las personas ayudar que que conformen un verdadero
equipo y motivar a dar lo mejor de sí mismos

Ciclo de vida de un proyecto

Project management , puede categorizarse en 5 grupos:

Inicialización: Empieza por :
Definir el proyecto:
Qué es lo que proyecto lograra , cual es el alcance
Qué recursos se necesitan y los costos
Identificar los stakeholders, y asegurarse que ellos estén de acuerdo en lo que el proyecto hara
Pedir la aprobación para iniciar el proyecto

Planificación
Qué es lo que vamos a hacer?
Cómo lo vamos a hacer ?
Como sabemos cuando hemos terminado?
Cuando el plan a sido completado se busca la aprobación para ejecutar el proyecto

Ejecución

Poner el plan en acción, se reúne a los recursos y se comparte las reglas que se están usando para
la ejecución del proyecto,y después de eso todos empiezan a poner el plan en marcha

Monitorear y controlar

Significa verificar que está pasando con el proyecto y cómo está yendo con respecto al plan, y si
ocurriese que el plan no está yendo por el camino correcto se debe tomar acción para que el
proyecto vuelva a su curso
 5

El proceso de cierre
Es corto pero importante, se obtiene del cliente la aprobación de que el proyecto está completado
Se genera documentación del desempeño del proyecto
Se cierran contratos
Se ayuda a los recursos a moverse a sus siguientes tareas

Gerente de proyectos Opciones de programas (Project Manager

Software options)
Tenemos los siguientes tipos y los podemos usar en la gestión de proyectos.
Scheduling software (calendarizar organizar en función a tareas y tiempos) ,
para muchos de los proyectos se requiere un un software management
program que ayude a construir y manejar el schedule del proyecto

Algunos de los los tools (herramientas) de software que exiting son:

Microsoft Project

Oracle Primavera

JIRA

Smart Sheet

Etc.

La mayoría de estas herramientas trabajan en la nube, lo que hace que la

colaboración sea más fluida y fácil
Cuando se piensa en todos los documentos que se producen en el manejo de
proyecto también se debe pensar en que un programa para documentar ser
requerido estos pueden ser:
Microsoft Word
Google Docs
 6

Y como los documentos de procesos en un proyecto pueden ser similares

entre los procesos se puede construir , templates de los proyectos
Spreadsheet
Es otro que se debe tener para cálculos y análisis, los spreadsheets pueden
ayudar a analizar riesgos en el proyecto y priorizar cuales se deben hacer
seguimiento
Microsoft Excel
Google docs
Presentation program
Es útil para comunicar información del proyecto
Power point
Keynote
Prezi
Colaboracion
Cuando se trabaja en equipo se necesita un lugar donde compartir y
colaborar que sea accesible para todos
Basecamp
Asana
Microsoft share point
Enterprise
Si se trabaja en una compañía que maneja :
Proyectos complejos o grandes
Recursos a ser asignados
Hacer seguimiento
Generación de librerías de documentación
 7

I. Inician un proyecto en software comercial:

Esta unidad estará de encargada de repasar y reforzar conceptos aprendidos,

orientados a su ejecución en un proyecto real

Roles/Actores :
Cuando un proyecto se encuentra en la etapa inicial es primordial
conocer los roles del equipo de trabajo que irá conformándose, todos
estos roles y miembros del equipo son importantes y es necesario
conocerlos, para que el proyecto avance adecuadamente, a
continuación desarrollaremos roles que involucran el manejo y la
ejecución del proyecto

Patrocinador Ejecutivo (Executive Sponsor):

Contribuye al manejo del presupuesto para el proyecto,
alineandolo en función a la priorización del negocio y estrategias.
Es el que tienen la última palabra en relación a ubicación de
recursos , los resultados del proyecto y los entregables

Patrocinador del proyecto (Project Sponsor) :

Cuando este rol existe, trabaja en conjunto con el patrocinador
ejecutivo , siendo delegado de el algunas responsabilidades ,tiene
el mismo nivel de interés que el patrocinador ejecutivo, y tiene
una interacción con el gerente del proyecto ( project manager)
para poder ayudar a guiar el proyecto respecto al plan.

Customers:
Quien tiene una necesidad para su negocio y nuestro producto
o servicio entregado satisfará sus necesidades de su negocio.
Ellos son quienes pagan por nuestros servicios.

Serán los que adquieran el producto para poder ser usado por
 8

ellos ( como usuarios finales) u otros usuarios finales

Analista de Negocio (Business Analyst):

Es un intermediario entre el customer y el equipo de desarrollo,
uno de sus roles es analizar las necesidades del Customer , para
asegurarse de que el producto se cree con el valor requerido del
cliente

Product Owner:
El product owner, se encarga de participar en la creación, de
historias de usuario ( user stories), creación de tareas específicas
( tasks). Está en contacto con el customer para poder realizar el
plan de trabajo junto al equipo de desarrollo en base a las
necesidades del cliente

Gerente de Proyecto (Project Manager):

El gerente del proyecto desempeña un papel principal en el

proyecto y es responsable de su finalización exitosa. El trabajo
del gerente es garantizar que el proyecto se desarrolle dentro del
marco de tiempo especificado y bajo el presupuesto establecido,
mientras se logran sus objetivos. Los gerentes de proyecto se
aseguran de que los proyectos reciban suficientes recursos,
mientras gestionan las relaciones con los patrocinadores y las
partes interesadas.

Deberes del gerente de proyecto:

Desarrollar un plan de proyecto.

Gestionar los entregables de acuerdo con el plan.

Reclutar personal del proyecto

Gestionar el equipo del proyecto.

 9

Determinar la metodología utilizada en el proyecto.

Establecer un cronograma del proyecto y determinar cada

fase.

Asignar tareas a los miembros del equipo del proyecto.

Proporcionar actualizaciones periódicas a la alta gerencia

Miembros del equipo de desarrollo:

El equipo de desarrollo se encarga de de ejecutar el proyecto en

base a los requerimientos del cliente, el equipo de desarrollo
está conformado por , Líderes de equipo, diseñadores,
desarrolladores, ingenieros de calidad, principalmente, pueden
de ser necesario o por el tamaño del proyecto existir control de
calidad usando automatización, y por el manejo y
mantenimiento de ambientes el equipo de devops

Usuario Final ( End User) :

Es la audiencia y/o grupo a que apunta el proyecto aquellos que
usaran el programa (desarrollado en el proyecto) y para los cuales
se deben satisfacer los requerimientos de uso.

Estructura del equipo :

Una vez conocidos los roles/actores de un proyecto vamos a definir la
estructura del equipo en base a los roles que cada actor tendrá, el flujo
de trabajo que se sigue a través de un diagrama , en este diagrama
mostraremos los stakeholders de un equipo agile

Project stakeholders:
De acuerdo con el Project Management Institute (PMI), project
stakeholders se refiere a, "un individuo, grupo u organización que
 10

puede afectar, verse afectado o percibirse afectado por una decisión,

actividad o resultado de un proyecto"
Es así que vamos a revisar el siguiente diagrama mostrando los
stakeholders basados en los actores/roles revisados en el punto
anterior

★ Quienes conformarán el proyecto? who will be doing the project

(resources),

Equipos Agile (Agile Teams) ,Cantidad óptima para un equipo

agile?

La guías de scrum sugieren equipos entre 3 a 9 miembros, que

van a trabajar activamente en la implementación en el sprint
backlog, en estos equipos no se incluyen a los product owners,
scrum masters u otros stakeholders
Jeff Bezos, el fundador de la compañía Amazon, a estado
usando “two-pizza rule” para reuniones y equipos. Esta regla
dice que la cantidad de personas en una reunión o en un equipo
debe ser la cantidad de personas que pueden comer 2 pizzas en
el almuerzo
 11

Los beneficios de pequeños equipo, los que ayudan a la

eficiencia

La auto-organización es más fácil para un equipo

pequeño

Los equipos pequeños pueden colaborar en comunicación

personal que en documentación

En un equipo pequeño, la contribución de cada persona

se vuelve más importante

Metodologías/Framework de desarrollo de Software, ciclo de vida:

Waterfall :
Metodología tradicional , con enfoque lineal se basa en una secuencia
de eventos:

1. Requerimientos
2. Diseño
3. Implementation
4. Verificacion
5. Mantenimiento
Cada uno de los mencionados arriba representan una etapa del
desarrollo de software y cada uno debe terminarse antes de que
el otro comience
 12

Agile :
Del agile manifesto
Individuos e interacciones sobre procesos y herramientas
Software funcionando sobre documentación extensiva
Colaboración con el cliente sobre negociación contractual
Respuesta ante el cambio sobre seguir un plan
Entonces podemos decir que agile se refiere a métodos de ingeniería
del software basados en el desarrollo iterativo e incremental, donde
los requisitos y soluciones evolucionan con el tiempo según la
necesidad del proyecto
 13

Donde sera desarrollo El proyecto?:

○ Web
○ Mobile
○ Desktop

Tiempo de vida de un proyecto de desarrollo de software (Systems

development life cycle-SDLC)
En el modelo agile que vimos anteriormente, veamos el ciclo de vida
de software orientado al modelo agile

Flujo de trabajo en agile:

● Concept - El proyecto es visualizado y priorizado

● Inception - Se identifican a los miembros del equipo , se
definen los ambientes de trabajo y los requerimientos son
analizados
● Iteration/Construction - El equipo de desarrollo entrega el
software en el que está trabajando , en los requerimientos de la
iteración y recibe retroalimentación
 14

● Release - Pruebas y control de calidad han sido realizadas, toda

la documentación entregada, el producto es puesto en
producción ( deploy into production)
● Production - Soporte continuo de del producto
● Retirement - End-of-life activities, including customer
notification and migration

Flujo de las iteraciones en agile

● Requirements - Se definen los requerimientos de la iteración,

estos se obtienen del product backlog on del sprint backlog ,
que son resultado de la retroalimentación provista por el
customer y stakeholders
● Development - Diseño y desarrollo de software basado en los
requerimientos definidos
● Testing - QA (Control de calidad) Pruebas y control de calidad ,
se realiza la documentación
● Delivery - Integrar y entregar lo trabajado en la iteración para
ser puesto en producción
● Feedback (retroalimentación)- Accept customer and stakeholder
feedback and work it into the requirements of the next iteration

Se obtiene retroalimentación (feedback) del customer y los

stakeholders , esta retroalimentación se trabaja en los
requerimientos de la siguiente iteración
 15

Duración -Iteraciones Agile :

las iteraciones en agile no son están marcadas o definidas en un
número exacto , pero por lo general se sugiere entre 3-4 semanas, uh
en otros casos de 1-2 semanas
En cuanto tiempo se requiere la culminación del proyecto? how
much time it will require to complete the project (Schedule)

Dependiendo de los requerimientos y el backlog se deberá proyectar ,

lo cual puede ser meses, trimestres, o años, La decisión en base a la
definición del proyecto pondrá una fecha de entregables y releases (
lanzamiento del producto)

Y definir el tiempo de iteraciones, para alcanzar las metas a corto y

largo plazo

Requerimientos Cliente :
Para poder empezar el desarrollo de un proyecto debemos tener
un punto de partida que en colaboración con el product owner,
customer, business analysts y project manager se generen las
bases del software a desarrollar
 16

Existen documentos que pueden ayudar a este propósito, entre

ellos:
Documentos de requerimientos del producto
Product requirements document PRD

Especificación de requerimientos de Software

Software Requirements Specification document

De ambos documentos antes mencionados, vamos a resumir los

puntos principales en los que los requerimientos se van a recabar:
Propósito del proyecto de software:
Para qué y dónde queremos que alcance el producto basado en
los objetivos, metas y beneficios del producto , y por último al
grupo de personas al que llegue el proyecto

Features (Características del producto):

Historias de usuario definidas en al función propósito del

proyecto , estos features deberán ser analizados por el equipo de
desarrollo y los product owners, business analyst , project
manager

Organización de los requerimientos del cliente traducido en producto

Product Backlog :
El product backlog es una lista de nuevos features, cambios en
features existentes, o bugs fixes ( arreglos en el código de los
bichos encontrados)
Release( lanzamiento del producto):
 17

Una vez definidas las metas y planteadas las historias de usuario,

en función al alcance del producto se generar el compromiso para
poder tener entregables en un marco de tiempo definido, en otras
palabras sponsors y customer plantean una fecha para la entrega
del producto

Estimaciones:
Para poder iniciar estimaciones debemos responder a las siguientes
preguntas:

El proceso de estimación es importante para determinar el esfuerzo

requerido para el proyecto de software, por ejemplo cuantos meses se
necesitará para desarrollar y cuantas personas se requerirán
 18

★ Cuánto trabajo se requiere estimar ? how much work is to be

estimated (scope)

Para poder iniciar el proceso de desarrollo el scope definido en

el backlog, que lista los features que van a ser desarrollados

★ Qué son los requerimientos?

Los requerimientos serán definidos en base a los

features(características) lo que se requiere del producto y que es
lo que se necesita para para lograr desarrollar esas
características

★ Complejidad de los features?

Una vez revisados los features en el backlog , se genera un

análisis entre los product owners ( pudiendo ser también los
customers o analistas del negocio) y el equipo de desarrollo

○ Priorizacion? Agile MoSCoW

Una vez definido el proyecto y definidas las iteraciones y el

alcance del proyecto

Es una técnica usada por los proyectos para identificar qué

requerimientos tienen mayor valor que otros, esta técnica es
usada ampliamente en proyectos agile, donde el tiempo el costo
y la calidad son considerados

Must have

Fundamental requirements

Por ejemplo desarrollamos un sitio web, debemos tener

manejo de pagos seguro y encriptado

Should have

Importantes pero no vitales

 19

E.g. multiples metodos de pago

Could have

Los nice to have, los que queremos pero no son tan

importantes y tendrán el menor impacto si no se realizan

Podemos tener un chat, no es necesario pero le agrega

valor a la experiencia de usuario

Won’t have

No se tendrá por ahora, significa que no se entregarán en

el sprint o en el proyecto

Puede ser multi language , pero por ahora el

requerimiento principal es

★ Cómo estimar el proyecto ? how to estimate the project (techniques)

Técnicas de estimación agile :

Las técnicas de estimación ágil nos ayudar a medir el esfuerzo

que se hará en el desarrollo para las distintas historias de
usuario , estas no estarán determinadas por tiempo sino por una
medición en tamaños definidos por el equipo entre pequeñas
(small), medianas (medium), grandes (large)
 20

Algunos tecnicas de estimacion usadas en agile son las

siguientes:

Poker planning: Todos los participantes reciben cartas

numeradas generalmente usando la serie fibonacci , el product
owner( al igual que el customer, business analyst dependiendo
a lo que el proyecto requiera) explica la historia y una vez
hechas las preguntas necesarias, cada miembro del equipo
muestra su carta con los puntos que va a darle, se inicia un
debate cuando las diferencia entre los puntos son grandes ,
donde los participantes deben explican los puntos que elegido

T-Shirt sizes: Esta técnica es comúnmente usada con backlogs

que contienen user stories grandes, cuando muchos equipos
están trabajan en el proyecto los tamaños usados serán XS, S,
M, L, XL. La decisión del tamaño es un trabajo colaborativo
entre todos los participantes

Dot Voting: Cuando se tienen una cantidad reducida en el

backlog , cada participante obtiene stickers que serán colocados
en los user stories , los mas votados seran los mas grandes en
effort
 21

The bucket System: otra alternativa para grandes cantidades del

backlog se generan buckets con los mismos valores de poker
planning , y se van colocando los stories en cada uno de los
buckets numerados

Una vez que las iteraciones vayan progresando y los equipos

madurando en las técnicas de estimación , se podrá determinar
la velocidad del equipo y el esfuerzo que se puede poner en
cada iteración

Esto dependerá de los compromisos hechos con los

patrocinadores y/o customers

Riesgos/Dependencias que puedan impactar a la culminación del

proyecto?
Any intermediary dependencies that may delay or impact the project (Risks).

Si bien los riesgos técnicos, como el software de terceros o las

dependencias externas, generalmente se observan, a veces los
riesgos que realmente amenazan el éxito del proyecto, aunque
son conocidos por el equipo, no se han documentado ni
reconocido formalmente. Estos pueden incluir el impacto de
problemas ambientales como requisitos poco claros o
inestables, falta de autoridad del gerente del proyecto, objetivos
organizacionales conflictivos, recursos limitados o inexpertos, y
más. Es muy probable los equipos son reacios a plantear estos
problemas, por temor a que estos riesgos sean vistos como
"quejas", y no esperan ningún margen para abordarlos de todos
modos. Pero estos son riesgos muy reales y deben ser
reconocidos por las partes interesadas, siendo estos los project
managers, sponsors, y customers
 22

Ciclo de vida de un release ( lanzamiento)

Pre-Alfa

Pre-alfa se refiere a todas las actividades realizadas durante el

proyecto de software antes de las pruebas formales. Estas
actividades pueden incluir análisis de requisitos, diseño de
software, desarrollo de software y pruebas unitarias. En el
desarrollo típico de código abierto, hay varios tipos de
versiones pre-alfa. Las versiones de Milestone incluyen
conjuntos específicos de funciones y se lanzan tan pronto como
se completa la funcionalidad.
Alfa

Es la primera versión completa del programa, la cual es enviada

a los verificadores para probarla.

Algunos equipos de desarrollo utilizan el término alfa

informalmente para referirse a una fase donde un producto
todavía es inestable, aguarda todavía a que se eliminen los
errores o a la puesta en práctica completa de toda su
funcionalidad, pero satisface la mayoría de los requisitos.

El nombre se deriva de alfa, la primera letra en el alfabeto

griego.
Beta

Una beta representa generalmente la primera versión completa

de un programa informático o de otro producto, que es posible
que sea inestable pero útil para que sea considerada como una
versión preliminar (preview) o como una preliminar técnica
 23

(technical preview [TP]). Esta etapa comienza a menudo

cuando los desarrolladores anuncian una congelación de las
características del producto, indicando que no serán agregadas
más características a esta versión y que solamente se harán
pequeñas ediciones o se corregirán errores. Las versiones beta
están en un paso intermedio en el ciclo de desarrollo completo.
Los desarrolladores las lanzan a un grupo de probadores de
betas o beta testers (a veces el público en general) para una
prueba de usuario. Los probadores divulgan cualquier error que
encuentran y características, a veces de menor importancia, que
quisieran ver en la versión final.

Cuando una versión beta llega a estar disponible para el público

en general, a menudo es extensamente probada por los
tecnológicamente expertos o familiarizados con versiones
anteriores, como si el producto estuviera acabado.
Generalmente los desarrolladores de las versiones betas del
software gratuito o de código abierto los lanzan al público en
general, mientras que las versiones beta propietarias van a un
grupo relativamente pequeño de probadores. En febrero de
2005, ZDNet publicó un artículo acerca del fenómeno reciente
de las versiones beta que permanecían a menudo por años y que
eran utilizada como si estuvieran en nivel de producción.
Gmail, igual que las Google Noticias, por ejemplo, estuvieron
en beta por un período de tiempo muy largo (cinco años). Esta
técnica puede también permitir a un desarrollador retrasar el
ofrecimiento de apoyo total o la responsabilidad de ediciones
restantes. Los receptores de betas altamente propietarias pueden
tener que firmar un acuerdo de no revelación. Como esta es la
segunda etapa en el ciclo de desarrollo que sigue la etapa de
alfa, esta se nombra como la siguiente letra griega beta.
Versión candidata a definitiva (RC)
 24

Una versión candidata a definitiva, candidata a versión final o

candidata para el lanzamiento (del inglés release candidate),
comprende un producto preparado para publicarse como
versión definitiva a menos que aparezcan errores que lo
impidan. En esta fase el producto implementa todas las
funciones del diseño y se encuentra libre de cualquier error que
suponga un punto muerto en el desarrollo. Muchas empresas de
desarrollo utilizan frecuentemente este término. Otros términos
relacionados incluyen gamma, delta (y tal vez más letras
griegas) para versiones que están prácticamente completas pero
todavía en pruebas; y omega para versiones que se creen libres
de errores y se hallan en el proceso final de pruebas. Gamma,
delta y omega son, respectivamente, la tercera, cuarta y última
letras del alfabeto griego.

Considerada muy estable y relativamente libre de errores con

una calidad adecuada para una distribución amplia y usada por
usuarios finales. En versiones comerciales, puede estar también
firmada (usado para que los usuarios finales verifiquen que el
código no ha sido cambiado desde su salida). La expresión de
que un producto sea dorada significa que el código ha sido
completado y que está siendo producido masivamente y estará a
la venta próximamente.
Versión de disponibilidad general (RTM)

La versión de disponibilidad general (también llamada dorada)

de un producto es su versión final. Normalmente es casi
idéntica a la versión candidata final, con sólo correcciones de
última hora. Esta versión es considerada muy estable y
relativamente libre de errores con una calidad adecuada para
una distribución amplia y usada por usuarios finales. En
versiones comerciales, puede estar también firmada (usado para
 25

que los usuarios finales verifiquen que el código no ha sido

cambiado desde su salida). La expresión de que un producto sea
dorado significa que el código ha sido completado y que está
siendo producido masivamente y estará en venta próximamente.

El término dorado se refiere anecdóticamente al uso del disco

maestro de oro que fue frecuentemente usado para enviar la
versión final a los fabricantes que lo usan para producir las
copias de venta al detalle. Esto puede ser una herencia de la
producción musical. En algunos casos, sin embargo, el disco
maestro está realmente hecho de oro, tanto por apariencia
estética como por resistencia a la corrosión.

Microsoft y otros usan el término distribución a fabricantes

(RTM o release to manufacturing) para referirse a esta versión
(para productos comerciales como Windows 7, se referirían a
ella como "la compilación 7600 es la elegida como Windows 7
RTM"), y distribución a web (RTW o release to Web) para
productos libremente descargables.

Participación de la clase : Actividad de grupo , dividir el grupo en sub equipos ( 5

personas), para participar del Marshmallow Challenge, esta actividad ayudará al
grupo a conocer el diseño de un proyecto basado en un prototipo

Marshmallow Challenge
Marshmallow challenge winning work.
 26

The Marshmallow Challenge is an instructive design challenge. It involves the task of constructing the
highest possible free-standing structure with a marshmallow on top. The structure must be completed
within 18 minutes using only 20 sticks of spaghetti, one yard of tape, and one yard of string.[5][6]

Observation and studies of participants show that kindergartners are regularly able to build higher
structures, in comparison to groups of business school graduates. This is explained by the tendency for
children to at once stick the marshmallow on top of a simple structure, test the prototype, and continue to
improve upon it. Whereas, business school students tend to spend time vying for power, planning, and
finally producing a structure to which the marshmallow is added.[7] The challenge helps to build and
develop prototyping, teamwork, leadership and innovation skills and is a popular STEM activity. The
challenge was invented by Peter Skillman of Palm, Inc. and popularized by Tom Wujec of
Autodesk.[8][9][10][11][12]

II. Planificación/Ejecución de un proyecto en software comercial:

Desde este punto para adelante siendo agile frameworks la tendencia en
desarrollo de software , iremos avanzando en los siguientes puntos
considerando agile framework. Ejemplo con la herramienta JIRA
confluence
● Planificación del proyecto:
○ Dividir los requerimientos del customer :
Analisis de prioridades
Complejidad
○ Estimaciones
■ Medir esfuerzo ( todo el equipo involucrado) , medir el
campo de
juego y hacer al equipo consciente de las reglas
■ Negociación y toma de decisiones
○ Definir Entregables
● Herramientas de seguimiento y ejecución del proyecto :
○ Historias de usuario ( user stories)
 27

● Participación de la clase : Actividad de grupo , dividir el grupo en sub

equipos ( 6 personas), para participar en la planificación de un
proyecto

III. Comunicación/Colaboración y Buenas Prácticas

El trabajo efectivo de de un equipo comienza y termina con comunicación
(Mike Krzyzewski) , por ejemplo si pedimos al equipo que piense en una
manzana , algunos pensaran en una manzana roja, otros en una verde y
algunos en la compañía apple, si bien todas las respuestas son correctas, la
comunicación nos ayudará a alinear al equipo con los objetivos del proyecto

Establecer un team charter:

Definir el propósito del documento ( team charter)
Cuales son los objetivos del equipo ?

Qué es lo que debemos lograr como equipo ?

Establecer expectativas

Ponemos limites
Esta documento ayudara al equipo este enfocado en la meta que persigue
Establecer los roles del equipo :
Se definen los roles del equipo ( quien está en el equipo?, que aporte hacen al equipo?,
tenemos que a todos los que necesitamos?
Determinar las condiciones de satisfacción del equipo
Convener ( conciliador, coordinador) : Generalmente el líder de equipo, determinar si una
reunión es necesarias, y pondrá los puntos que se revisaran en la reunión ( agenda items)
Recorder ( toma notas): Toma nota de los detalles de la reunión, provee un lista de los
participantes, y lista de las siguientes actividades, debe enviar una copia a todos los
participantes
Monitor: Ayudará al equipo se enfoque en los puntos a ser revisados en la reunión
 28

Como se toman decisiones

Commanding
Cuando el líder del equipo toma la decisión, dependiendo del tiempo que se tiene para tomar una
decisión ( si este fuera corto) o para sí el líder tuviera más contexto en la decisión a ser tomada
Ventajas
No necesita mucho tiempo
Desventaja
Puede genera la sensación de separación y de no inclusión en el resto del equipo
Consulting approach
Permite a los miembros del equipo a aportar, pero al final una persona debe tomar la decisión
final, después de considerar todos los puntos sobre la mesa, la decisión generalmente recae el
líder del equipo
Ventajas
Provee la oportunidad a las personas del equipo a contribuir
Ayuda al encargado de la toma de decisiones para recabar información y tomar una
decisión con más información
Desventajas
Puede traer frustración para aquellos que se oponen a la decisión tomada
Puede tomar mucho tiempo
Consensus building approach ( Consulta general y con votos)
Acordar y seguir la decisión tomada por mayoría de votos, esta toma de decisión es en la cual los
miembros del equipo colaboran más , al final todos votan y el punto más votado es la decisión
que se tomara
Ventajas
Se considera que es más democrática
Todos sienten que su voto se a tomado en cuenta

Desventajas
Es ineficiente, no es necesario que todos los del equipo estén de acuerdo con la decisión

Compartir informacion
 29

Formas de compartir información a través de reuniones

Reuniones
-Regulares
-Reuniones cuando son necesarias
- Cuánto tiempo durará
- Seran en persona
- Todos deben asistir?, o solo las personas impactadas por los puntos a ser elaborados en
la reunión?
Electronic
- Puede ser mal interpretado, body language facial expression
- E-Mail
- Instant messages
- Texting
- Cuán seguido se deben enviar
- Todos necesitan estar incluidos
- Cuando se considera un buen tiempo de respuesta
- E.g. uno puede esperar respuestas en un timeframe de 1 hr y si otro no lo sabe existe un
huevo de comunicación
Por telefono:
Similares a los de electronic

Resolución de conflictos
Siempre hay posibilidades de conflictos en un equipo y de cuando en cuando es casi esperado que
podría haber desacuerdos en el equipo, los conflictos no son necesariamente malos en realidad, los
conflictos saludables pueden ayudar a generar mejores resultados en el equipo .
Cuando un conflicto existe un de nuestros primeros instintos son:
Alejarse lo más posible del conflicto
Manejar el conflicto defensivamente y apartar a todos los que están no están de acuerdo
con el manejo del conflicto
Ninguno de los anteriores es recomendado, vayamos analizando las formas y manejo de
conflictos que podemos usar.
claves para el manejo de conflictos :
Se comprensivo,
Abstiene de entrar en los chismes o la frustración
 30

Disagreement ( desacuerdos)
Reconocer que existe un conflicto u problema
Generar un espacio de comunicación con los involucrados en el problema
Mantenerse neutral
Comunicar antes de la discussion
Negociar un win win scenario
Establecer y mantener confianza

Say-Do gap ( espacio entre lo que decimos que vamos a hacer y lo que hacemos)
Cuando decimos que vamos a hacer algo, y por todas las tareas que tenemos , no lo
logramos hacer lo que hemos prometido
Por tanto los líderes deben ayudar a mejorar el comportamiento del equipo dando el
ejemplo y cumplendo lo prometido , como regla general cumplir lo prometido y entregar
aún más de lo prometido (under promise over deliver)

Si es que ocurriera que no se pudo lograr lo que se prometió es bueno admitirlo tomar
responsabilidad y evitar poner excusas, se responde mejor a aquellos que toman
responsabilidad vs a los que ponen excusas, y evitar hacer un hábito en no cumplir con las
promesas hechas

Accommodate (Acomodarse)
Cuando una persona siente fuertemente una idea acerca del equipo donde los otros miembros no
están tan preocupados.
En estos casos en bueno encontrar una solución para esa persona
Compromise ( llegar a un comun acuerdo a un compromiso)
Cuando ambas partes han cedido en algo , el resultado es que cuando haya hecho un compromiso
ambos tengan la sensación de haber cedido

Collaborate ( colaborar)
Idealmente, un equipo podría colaborar entre todos y
 31

Construir Lazos de confianza:

Abrir canales de comunicación
Hacer conocer a los miembros del equipo el valor que ellos representan para el equipo,
individualmente y en grupo
Team building , reunión en la que miembros del equipo puedan conocerse
Reconocer el éxito que ha tenido el equipo

Anexos:

Bibliografia Web links :

https://www.whizlabs.com/blog/different-roles-in-project-management-covering-various-industries/
https://www.villanovau.com/resources/project-management/project-team-roles-and-responsibilities/
https://www.pmi.org/learning/library/negotiation-analytic-approach-managing-project-8090
https://smallbusiness.chron.com/sponsors-vs-stakeholders-66944.html
https://www.planview.com/resources/articles/agile-roles-software-development/
https://keydifferences.com/difference-between-customer-and-client.html
https://www.knowledgehut.com/blog/agile/difference-agile-scrum
https://www.projecttimes.com/articles/the-five-goals-of-a-project-manager.html
https://technology.amis.nl/2016/03/23/8-agile-estimation-techniques-beyond-planning-poker/
https://en.wikipedia.org/wiki/Iterative_design
https://agilemanifesto.org/
https://agilepainrelief.com/notesfromatooluser/2016/10/choosing-the-team-size-in-
scrum.html#.XXu3j2ZReUk
https://www.simplilearn.com/project-estimation-techniques-article

https://www.smartsheet.com/blog/demystifying-5-phases-project-management
https://www.devteam.space/blog/waterfall-vs-agile-which-methodology-is-right-for-your-project/
https://www.seguetech.com/waterfall-vs-agile-methodology/
 32

https://en.wikipedia.org/wiki/Project_stakeholder

https://www.aha.io/roadmapping/guide/requirements-management/what-is-a-good-product-requirements-
document-template
https://www.atlassian.com/software/confluence/templates/product-requirements-document
https://en.wikipedia.org/wiki/Software_release_life_cycle

https://lab.getapp.com/step-by-step-project-lifecycle-methodology/

https://www.smartsheet.com/understanding-agile-software-development-lifecycle-and-process-workflow

https://www.agilealliance.org/glossary/backlog/#q=~(infinite~false~filters~(postType~(~'page~'post~'aa_b
ook~'aa_event_session~'aa_experience_report~'aa_glossary~'aa_research_paper~'aa_video)~tags~(~'b
acklog))~searchTerm~'~sort~false~sortDirection~'asc~page~1)
https://www.scrum.org/resources/what-is-a-product-backlog

https://melsatar.blog/2018/01/15/5-steps-to-software-development-effort-estimation/

https://www.knowledgehut.com/blog/agile/top-5-scrum-estimation-techniques-find-your-best-fit

https://technology.amis.nl/2016/03/23/8-agile-estimation-techniques-beyond-planning-poker/

https://agilepm.com/the-ideal-iteration-length-revealed

https://www.agilealliance.org/glossary/backlog/#q=~(infinite~false~filters~(postType~(~'page~'post~'aa_b
ook~'aa_event_session~'aa_experience_report~'aa_glossary~'aa_research_paper~'aa_video)~tags~(~'b
acklog))~searchTerm~'~sort~false~sortDirection~'asc~page~1)

https://www.toptal.com/product-managers/agile/scrum-team-size
 33

https://medium.com/@MagnusDahlgren/why-small-scrum-teams-rock-3b05a93299bc
https://www.pmi.org/learning/library/managing-software-projects-common-risk-pitfalls-7876

https://www.devteam.space/blog/waterfall-vs-agile-which-methodology-is-right-for-your-project/

https://www.linkedin.com/learning/communication-within-teams/establish-a-team-charter

Unidades de Aprendizaje (semestre regular)

1. Gerencia Estratégica.
a. Gerencia y Toma de Decisiones.
b. Herramientas para la Gerencia de Proyectos.
2. Ingeniería de requerimientos:
a. Definición de Usuarios y Grupos de Usuarios.
b. Requerimientos del usuario.
c. Requerimientos de Insumos y Fuentes Instrumentos de Recolección de Información
(Encuesta, entrevista, sondeo).
d. Requerimientos del sistema. Funcionalidad del sistema vs. Requerimientos. Criticidad de
los requerimientos (Ponderación).
e. Método Jerárquico de SAATY.
f. Matrices de Análisis.
3. Control de gestión de los sistemas de información.
a. Sistemas de Información.
b. Control de Gestión en TIC.
c. Control de Actividades en TIC.
d. Estructura organizativa del área informática.
e. Estructura y Organización del área de las TIC.
f. Estructuración y Tipos de Estructuras.
g. Funciones y Puestos de Trabajo. Jobs Description.
4. Gestión de proyectos tecnológicos.
a. Proyectos y metodología de implantación.
b. Organización y gestión de los recursos.
c. Organización del Proyecto.
d. Jefe de Proyecto y Grupos de Trabajo.
e. Gestión de Recursos.
5. Planificación y control.
 34

a. Procesos de la Gestión de Proyectos.

b. Ciclo de Vida del Proyecto.
c. Ciclo de Vida del Producto.
d. Planificación y Control de Proyectos.
e. Necesidades y Requerimientos.
f. Planificación de Proyectos.
g. Gestión de Riesgos del Proyecto.
h. Control y Seguimiento de Proyectos.
i. Herramientas y Técnicas.
6. Ejecución, documentación y herramientas.
a. Contratación de Productos y Servicios.
b. Recuperación y Terminación del Proyecto.
c. Documentación del Proyecto.
d. Herramientas de Gestión y Documentación de Proyectos.
e. Tendencias en Gestión de Proyectos.
7. PROJECTS. Introducción.
a. e-Business Projects.
b. e-Business Strategy. Projects.
c. Agile Project Management.
d. Agile Software Development.