UNIversity Day

El evento UNIversity Day Project Management será todo un día dedicado a la gerencia de proyectos para universitarios, se realizarán conferencias y talleres de los conceptos básicos del estándar PMI con el auspicio del PMI capitulo Lima.

CONEGP UNI-2011

pronto más información

fotos: IX Curso de Gerencia de Proyectos

Todas las fotos del IX Curso de Gerencia de Proyectos, donde se observa el dinamismo y el trabjo grupaln en que se desarrolla el curso...Muy Pronto el X curso de Gerencia de Proyectos.

martes, 27 de mayo de 2008

III CURSO TALLER DE GERENCIA DE PROYECTOS Y LIDERAZGO

III Curso Taller de Gerencia de Proyectos y Liderazgo

Para Estudiantes

III CURSO TALLER DE GERENCIA DE PROYECTOS Y LIDERAZGO


Objetivos:
  • Proporcionar los conocimientos, herramientas y técnicas básicos para gerenciar proyectos siguiendo el estándar expuesta en la Guía del PMBOK (Guía de los Fundamentos de la Gestión de Proyectos).

  • Proveer el marco conceptual básico y práctico para una comprensión de la naturaleza de los proyectos, el entorno en el que se originan y la función que cumplen dentro del plan estratégico de las organizaciones.

  • Promover el liderazgo en cada estudiante, como parte de su desarrollo en la gerencia de proyectos.

Dirigido a:

Estudiantes de Ingeniería interesados en manejar un estándar reconocido mundialmente como buena práctica y aplicarlo al campo laboral.

Temática:

  • Procesos de Gestión
  • Gestión de Integración
  • Gestión del alcance
  • Gestión del Tiempo
  • Gestión de Costos
  • Gestión de Riesgos
  • Gestión de Calidad
  • Gestión de Recursos Humanos
  • Gestión de Comunicaciones
  • Gestión de Adquisiciones

Talleres

  • CHARTER
  • WBS
  • VALOR GANADO
  • RIESGOS
  • LIDERAZGO

Expositores:

Carlos Barragán Chumpitaz

Ing. Industrial de la UNI. Profesional en Gerencia de Proyectos (PMP®) certificado por el PMI®. Egresado del Programa de Alta Especialización en Gestión de Hidrocarburos CENTRUM. Ha liderado proyectos importantes de TI en diferentes instituciones tales como Consultoría Gestor Osmos, Financiera CMR, Ministerio de Vivienda UTE FONAVI. Coordinador Informático Senior de PERUPETRO S.A. Magíster en Administración de ESAN.

Juan Carlos Pacheco Pacheco

Ingeniero Electrónico de la UNI. Profesional en Gerencia de Proyectos (PMP®) certificado por el PMI®. Consultor independiente en Tecnología y Seguridad Informática. Ha sido profesor del Diplomado de Especialización en Gerencia de Proyectos de la Universidad Peruana de Ciencias Aplicadas.

Isaac Ortiz Samanamud

Ingeniero Civil, Universidad Nacional de Ingeniería. Presidente Fundador de la sección PMI-UNI. Ha brindado asesoramiento en gerencia de proyectos a diversas empresas en el rubro de construcción.

David Carbajal Luciano

Ingeniero Civil de la UNI ,
Past - Director del PMI-UNI

Egresado de programas de especialización en Gestión de Proyectos y de Empresas en la UPC Y ESAN

Especialista en Gerencia de Proyectos y Construcción,
Lean Thinking, Team Building & Leadership.
Experto en técnicas de Outdoor Training.

Ex miembro de las Fuerzas Especiales del Ejercito del Perú

Ex miembro del SUPERA Team; con operaciones en Perú, México, Venezuela y Ecuador.


Información General:

  • Inicio del Curso:
Viernes 06 de Junio del 2008
  • Horario de clases:
Viernes de 6 - 10pm y
Sábado de 2 - 6pm
  • Duración del Curso:
32 horas de 8 sesiones presenciales de 4 horas cada una
  • Lugar:
Facultad de Ingeniería Civil (FIC).
Salón G2 272
Av. Túpac Amaru 210 – Rimac

Inversión:

CONDICION INVERSIÓN(Por participante)
Estudiante UNI S/. 300.00
Estudiante EXTERNO S/. 400.00

La inversión incluye:

  • Certificado a nombre de la Facultad de Ingeniería Civil de la UNI (Valido para certificación CAPM)

  • Materiales de trabajo por sesión

  • Coffee break por cada sesión

Inscripciones:

  • Cancelar en el Local del PMI UNI (sótano de la FIC) en horario de oficina

- Lunes a Viernes

9:00am a 5:30pm

- Sábados

9:00am a 1:00pm

  • Llenar Ficha de Inscripción, entregada en el PMIUNI

Informes:

SECCION ESTUDIANTIL PMI UNI,

Sotano Facultad de Ingenieria Civil, Campus UNI, Av. Tupac Amaru 210, PE-LIMA25, Lima, PERU,

e-mail: pmiuni@gmail.com


web:
http://www.pmiuni.blogspot.com, http://www.pmi.uni.edu.pe/


ORGANIZA

Sección Estudiantil PMI - UNI

lunes, 12 de mayo de 2008

Método Scrum en Administración de proyectos de Software


¿Qué es SCRUM?

Scrum es una metodología para el desarrollo ágil de productos, expuesta por Hirotaka Takeuchi e Ikujiro Nonaka, en el artículo The New New Product Development Game [Harvard Business Review Ene-Feb 1986] en el que ponen de manifiesto que:

- El mercado competitivo de los productos tecnológicos, además de los conceptos básicos de calidad, coste y diferenciación, exige también rapidez y flexibilidad.
- Los nuevos productos representan cada vez un porcentaje más importante en el volumen de negocio de las empresas.
- El mercado exige ciclos de desarrollo más cortos.

El artículo compara al desarrollo tradicional de ciclo de vida formado por fases separadas y equipos especializados con las carreras de relevos, donde un equipo pasa el testigo al siguiente hasta finalizar el desarrollo del producto. Siguiendo el símil deportivo, se compara al nuevo modelo de desarrollo, basado en el solapamiento de las fases y en un único equipo multi-disciplinar, con la evolución del juego del rugby; y de él se toma el término scrum.
Nonaka y Takeuchi extraen las bases de scrum de las prácticas que observan en las empresas con buenos resultados de rapidez y flexibilidad en la producción: Xerox, Canon, Honda, NEC, Epson, Brother, 3M o Hewlett-Packard; y son:

• Inestabilidad consustancial al entorno de desarrollo.
• Equipos auto-organizados.
• Solapamiento de las fases del desarrollo.
• Multi-aprendizaje.
• Control sutil.
• Transferencia de aprendizaje a nivel organizacional.

Aunque surgió como modelo para el desarrollo de productos tecnológicos, también se emplea en entornos que trabajan con requisitos inestables y que requieren rapidez y flexibilidad; situaciones frecuentes en el desarrollo de determinados sistemas de software.
Jeff Sutherland aplicó el modelo Scrum al desarrollo de software en 1993 en Easel Corporation (Empresa que en los macro-juegos de compras y fusiones se integraría en VMARK, luego en Informix y finalmente en Ascential Software Corporation). En 1996 lo presentó junto con Ken Schwaber como proceso formal, también para gestión del desarrollo de software en OOPSLA 96. Más tarde, en 2001 serían dos de los promulgadores del Manifiesto_ágil. En el desarrollo de software scrum está considerado como modelo ágil por la Agile Alliance.
La ficha adjunta incluye una descripción sinóptica del proceso y sus elementos que son:

Roles: Propietario del producto, Gestor o Manager del Scrum, Equipo e Interesados.
Componentes del proceso: Pila del producto (Product Backlog), Pila del sprint (Sprint Backlog), Incremento.
Reuniones
Planificación del sprint, Revisión diaria, Revisión del sprint.
Sprint

Scrum por sus características no es válido para cualquier proyecto ni para cualquier persona o equipo de personas. Es más, Scrum según muchos especialistas de esta metodología, es óptima para equipos de trabajo de hasta 8 personas, aunque hay empresas que han utilizado Scrum con éxito con equipos más grandes.
Se puede decir que para el 90% de los proyectos y empresas, es una metodología válida, pero no es una metodología válida al 100%. Es más, no hay metodología mejor que otra ni válida al 100% para todas las personas y empresas.
Scrum es por lo tanto, una metodología más de las muchas que hay, y ésta en concreto, se basa en la filosofía del desarrollo ágil que fue expuesto por dos japoneses alrededor del año 1986.
Scrum no es ni la mejor metodología ni la única, pero es una metodología que está empujando muy fuerte por la facilidad de implantación y por su agilidad en cuanto a cambios y lo que propiamente aporta en comparación con otras metodologías.
Por un lado, Scrum evita la burocracia y la generación documental. No es que con Scrum no se deba o no se pueda documentar, si no que con Scrum no se exige documentar nada para iniciar un proyecto, algo que en otras metodologías es impensable.
Con Scrum por otro lado, la idea principal es la de ponerse a trabajar prácticamente desde el primer momento y empezar a sacar frutos de ese trabajo para que el cliente vaya viendo los avances y se quede satisfecho con lo que se está haciendo y cómo se está haciendo.

¿Como se Aplica?

El scrum es simple en su composición, lo podemos ver como 3 grandes bloques principales

• Las personas
• Las ceremonias
• Los documentos o artefactos

Las personas

Scrum introduce simplificaciones sobre algunas estructuras tradicionales de la administración de proyectos; todos tienen su lugar en un Scrum, solo que su función ha sido redefinida de forma que los equipos sean más funcionales y menos burocráticos.

Las principales personas alrededor de un scrum son:

• El dueño del producto
• El scrum master
• El equipo


El dueño del producto

El dueño del producto representa a la empresa, a los usuarios y en general a todas las personas que intervienen en la empresa.
Por un lado tiene la responsabilidad de hacer que el producto dé un beneficio para los intereses económicos y estratégicos del negocio. Por otro lado tiene la responsabilidad de asegurarse que todos los requerimientos de los diferentes grupos de usuarios del sistema sean contemplados.

Sus funciones y responsabilidades más importantes son:
• Define los requerimientos y funciones del sistema.
• Prioriza las funciones a desarrollar de acuerdo al valor que aporten al negocio o mercado.
• Decide cuando liberar el producto del proyecto.
• Es el responsable directo sobre la recuperación de la inversión (RoI).
• Acepta o rechaza el resultado del trabajo del equipo.


El scrum master

La figura de líder de proyecto, como persona que tiene la responsabilidad del éxito o fracaso del proyecto; quien determina que tareas se deben hacer, quien debe hacerlas, cuando y durante cuanto tiempo y cuanto costarían esas tareas; se transforma de un administrador del proyecto a un coordinador de actividades cuya principal responsabilidad es mantener la efectividad y productividad del equipo protegiéndolo de fuerzas externas que distraigan el esfuerzo de desarrollo. Los equipos en scrum son auto-administrados por lo que no se requiere alguien sirviendo de gerente o manager.

Sus funciones y responsabilidades esenciales son:
• Que el esfuerzo de desarrollo sea exitoso.
• Protege al equipo de interferencias externas.
• Mantiene el enfoque y efectividad del equipo.
• Evangeliza los principios, valores y prácticas de scrum en toda la organización.
• Es un facilitador.
• Elimina los impedimentos que el equipo de desarrollo tenga para hacer su trabajo.


El equipo de desarrollo

Esta compuesto por las personas que diseñan, programan, prueban e implementan el sistema o producto de software.

Sus características y funciones son:
• Típicamente de 5 a 9 personas.
• Multifuncional (todos diseñan, programan, prueban).
• De tiempo completo.
• Auto‑administrados. No se les asigna trabajo, cada quien selecciona tareas de la lista de tareas por hacer conocida como el sprint backlog.
• La composición del equipo no puede cambiar durante la iteración.

El tamaño del equipo puede ser tan pequeño como 2 personas y tan grande como 8; por encima de 8 son demasiadas las líneas de comunicación y los espacios físicos requeridos. Entre más pequeño el equipo menor será su velocidad y por consecuencia más largo el tiempo de entrega.
Los demás interesados en el proyecto se involucran activamente en el proyecto mediante una de las ceremonias de la metodología, el scrum diario. Adicionalmente, cualquier interesado puede hacer que sus necesidades y requerimientos sean considerados pero lo hacen exclusivamente a través del dueño del producto.


Las ceremonias

Scrum obliga unas cuantas ceremonias, todas obligatorias. Las juntas de Scrum tienen todas como característica principal que están estrictamente limitadas a los tiempos preestablecidos obligando a los involucrados a ser efectivos y hacer uso inteligente del tiempo.

Las ceremonias son:
• La junta de planeación del sprint
• El scrum diario
• La revisión del sprint
• La retrospectiva del sprint.

La junta de planeación del sprint



Scrum es un proceso cíclico de sprints donde el resultado de cada uno debe ser una pieza de software funcionando por encima de diagramas, textos de diseño, etc. Para lograrlo, la planeación es clave. Sin embargo se planea solamente el esfuerzo que se puede realizar durante la duración de un sprint. La reunión de planeación tiene dos objetivos:

• Definir el objetivo del sprint. Este objetivo es una descripción textual de una meta tipo SMART que tanto el dueño del producto, el scrum master y el resto del equipo puedan fácilmente visualizar.
• Hacer una estimación del tiempo de los requerimientos de más alta prioridad y seleccionar sobre esa base cuantos se pueden lograr terminar en el sprint. Para hacer lo anterior, el equipo y el scrum master desglosan las tareas de programación necesarias para poder considerar terminado cada uno de los requerimientos aceptados para el sprint.

El resultado de la planeación del sprint es lo siguiente:
• La meta del sprint
• El backlog del sprint

La duración de la junta de plantación del sprint debe ser suficiente para poder hacer el análisis y las estimaciones de los requerimientos de más alta prioridad. Si es necesario, el dueño del producto debe repriorizar las tareas acumuladas del producto para obtener lo que sea de más valor para la empresa. En general se puede obtener una buena plantación con un día completo de trabajo separado en 2 partes.

• Análisis, evaluación, repriorización y estimación de las tareas acumuladas del producto
• Desglose y estimación de las tareas de los requerimientos aceptados por el equipo.

No se recomienda extender esta planeación más allá de un día laboral completo, scrum depende de que las fechas y los compromisos sean respetados por todos.


El Scrum diario

Al igual que el resto de las ceremonias, el scrum diario esta estrictamente limitado en su tiempo y para este caso es de 15 minutos, no más y no menos. Ocurre todos los días laborales a la misma hora y en el mismo lugar.
Cada uno de los miembros del equipo y el maestro scrum tienen la responsabilidad y obligación de asistir todos y cada uno de los scrum diarios, por ello un equipo scrum debe estar 100% dedicado al proyecto. El dueño del producto puede asistir para informarse sobre el proyecto, pero no esta obligado a responder las 3 preguntas.
Un aspecto clave de esta reunión es que cualquier interesado en el proyecto puede asistir a los scrums diarios con la única condición que no pueden interrumpir de ninguna forma el trabajo del equipo durante esos 15 minutos. Scrum provee diversos mecanismos por medio del cual los interesados en el proyecto pueden conocer el progreso del proyecto y agregar sus propios requerimientos al backlog del producto. La junta diaria es uno de los mecanismos de transparencia de scrum y uno muy poderoso que no debe ser desaprovechado por los interesados o el dueño del producto.

Durante estos 15 minutos cada miembro del equipo responde a tres preguntas:

• ¿Que hiciste/lograste ayer?
• ¿Que vas a hacer/lograr hoy?
• ¿Que impedimentos tienes para lograrlo?

Las primeras 2 preguntas son en base a tareas del backlog del sprint. Los equipos scrum son auto-administrados y cada miembro toma libremente tareas de la lista del backlog del sprint en lugar de ser asignadas por el scrum master; por lo anterior, la respuesta a las primeras 2 preguntas giran alrededor de tareas que se lograron terminar en las ultimas 24 horas y cuales se pueden lograr durante las siguientes 24.
El desglose de cada requerimiento se hace en tareas que no son mayores a 12 horas o menores a 4; de forma que los miembros del equipo pueden comprometerse a terminar una o más tareas en el tiempo entre dos scrums.
El scrum diario no debe convertirse o manejarse como el mecanismo tradicional de control y rendición de cuentas de un gerente de proyectos. Cada miembro del equipo en respuesta principalmente a la segunda pregunta asume un compromiso personal con cada uno de los miembros del equipo de terminar lo que dice que puede terminar. Si no puede terminarlo debe tener la honestidad, la integridad y el coraje de aceptar que no puede terminarlo, determinar que SI puede terminar y comprometerse a ello.
El maestro scrum tiene la responsabilidad de registrar los impedimentos que el equipo haya señalado y de eliminarlos a toda costa. Si la lista de impedimentos no se disminuye con cada scrum o si peor aún empieza a crecer, el maestro scrum no esta haciendo una de sus funciones principales. En tal caso el equipo puede sugerir que se interrumpa el sprint de forma extraordinaria.
Cada miembro del equipo debe conocer a detalle lo relacionado con los requerimientos y en base a ese conocimiento se auto-asigna tareas y se compromete a terminarlas de un scrum a otro.
La redacción de las preguntas dice que hiciste ayer y que vas a hacer hoy, sin embargo en términos prácticos significan:

• ¿Que hiciste/lograste desde el ultimo scrum y este?
• ¿Que vas a hacer/lograr entre este scrum y el siguiente?


La revisión del sprint

La revisión del sprint se programa anticipadamente como resultado de la planeación del sprint, todo el equipo esta enfocado en lograr la meta que se definió para el sprint, de ahí su nombre, scrum. Al final de los 30 días, el equipo hace una demostración de la funcionalidad de la pieza (o piezas) de software que se terminaron durante el sprint. Esta demostración se hace directamente en las computadoras del equipo de desarrollo sin mucha preparación previa. La preparación necesaria se hizo a lo largo del sprint y lo que se presenta es lo que interesa al dueño del producto y el resto de los interesados.

Los invitados a esta reunión son:
• El dueño del producto
• El maestro scrum
• Todo el equipo
• Cualquier interesado en el proyecto

La duración de esta demostración debe ser por lo menos de 4 horas y de 8 como máximo. El equipo de desarrollo hace las pruebas de funcionalidad para cada uno de los requerimientos aceptados para el sprint en la planeación que se hizo 30 días antes. Si se descubren nuevos requerimientos durante la revisión del sprint, estos se integran al backlog del producto para ser priorizados por el dueño del producto antes de la reunión de planeación del siguiente sprint.
El dueño del producto debe aprovechar esta reunión para conocer las opiniones del resto de los interesados, integrar sus propios requerimientos y adaptar el proyecto con una visión renovada. De esta manera estamos cumpliendo con el fundamento de adaptabilidad.


La retrospectiva del sprint

La retroalimentación, el aprendizaje y la experiencia son fundamentales tanto para el sprint como para cualquier otra metodología. Después de la revisión del sprint, el equipo se reúne para evaluar el desempeño durante el sprint recién terminado y como se puede aprender de lo que acaba de terminar para mejorar lo que esta por empezar.
Cada miembro del equipo se responde los siguientes interrogantes:

• Que SI funciona para seguir haciéndolo...
• Que NO funciona para dejar de hacerlo y...
• Que podemos empezar a hacer para que funcione MEJOR


Los artefactos o documentos

Scrum propone y obliga solo 3 documentos fundamentales que son usados tanto para gestionar el proyecto y sus tareas como para dar seguimiento, visibilidad y transparencia al proceso:

• El backlog del producto o bitácora priorizada de requerimientos
• El backlog del sprint o bitácora priorizada de tareas
• La grafica de burndown

También se recomiendan la grafica de Burnup, la bitácora de impedimentos y otros, sin embargo estos tres son fundamentales para el buen funcionamiento del un equipo Scrum.


El backlog del producto

El estudio y la experiencia nos han demostrado que frecuentemente, el cliente no es capaz de definir puntualmente su problema y mucho menos lo que necesita y como podemos nosotros programarlo si él mismo no lo sabe. Las metodologías tradicionales enseñan que los requerimientos deben fijarse al principio del proyecto y definirse de tal forma y con tal alcance que no haya dudas, mal entendidos o cambios en los mismos; he ahí la raíz del problema, ya que las cosas cambian inesperadamente y no podemos esperar desarrollar sistemas funcionales y que den valor a nuestros clientes si exigimos que los requerimientos se congelen en el tiempo mientras nosotros desarrollamos el producto.
Es muy común que el cliente al ver el producto visualiza la solución de forma distinta, es decir, la misma solución crea nuevos requerimientos o cambia los existentes. El libre manifiesto de ideas provoca e incentiva los cambios. Scrum define el Backlog del producto para este fin.
En su forma más esencial el Backlog del producto o bitácora de requerimientos es un simple listado de requerimientos expresados en forma de Historias de Usuario (User Stories) y estimados en alguna unidad representativa del tiempo. Estas Historias de Usuario deben estar expresadas exclusivamente en el lenguaje del negocio y deben aportar un valor real al mismo que pueda ser definido y visualizado por cualquiera que conozca el problema.
El backlog del producto debe incluir el mayor numero de requerimientos (User Stories) que se puedan obtener de los usuarios y demás interesados del proyecto a través del dueño del producto y en base a las estimaciones del equipo de programación sirve para estimar el numero de sprints necesarios para terminar con el proyecto. El backlog del producto es la herramienta principal para desarrollar y estimar el plan de liberación del producto.
De este backlog el equipo selecciona los requerimientos de más alto nivel que puede completar en 30 días en base a su capacidad y velocidad de desarrollo y produce el siguiente artefacto documental del Scrum, el backlog del sprint.



El backlog del sprint

Una vez que se seleccionan los requerimientos del Backlog del producto, se definen y estiman las tareas de programación necesarias para cumplir con cada uno de los requerimientos aceptados para el sprint.
La duración de cada una de las tareas se puede estimar en horas o en las unidades que se estiman los elementos del backlog del producto. Pero no dejan de ser solo estimaciones, a medida que pase el tiempo el equipo puede volver a plantear estos tiempos si lo ve necesario.
Las tareas de programación deben ser tareas específicas para que puedan ser completadas por un miembro del equipo en un día laboral. Si es menor de 4 horas quizás sea necesario considerar esa tarea como parte de otra, si es mayor a 12 horas la tarea debe desglosarse un poco más. El objetivo es que se desglosen tareas a las que un miembro del equipo se pueda comprometer terminar de un scrum a otro.

La gráfica de burndown

Este gráfico permite conocer de manera ágil y visual el progreso o no de los trabajos del proyecto. Diariamente cada miembro del equipo de desarrollo actualiza la(s) tarea(s) en que esta trabajando y estima de nuevo el tiempo necesario para terminar la tarea. La suma de las estimaciones de las tareas pendientes por terminar de cada día es graficada como un punto en la gráfica; en el eje horizontal se determina un punto por cada uno de los días del sprint y de esta forma se obtiene una imagen casi en tiempo real del progreso del trabajo del equipo de desarrollo.



Valores

Scrum es una metodología muy simple en su composición, sin embargo sus fundamentos teóricos y los valores en los que se fundamenta es lo que hace a su complejidad. Los valores de scrum y del manifiesto ágil son la goma que une a los personajes en las ceremonias y a través de los documentos y les permite cumplir con sus compromisos día a día, sprint a sprint hasta el éxito del proyecto.

• Compromiso - Estar dispuesto para comprometerse a una meta. La metodología la da a las personas la autoridad que necesitan para cumplir con sus compromisos.
• Enfoque Haz tu trabajo - Enfoca todos tus esfuerzos y habilidades para trabajar en lo que te comprometiste a hacer. No te preocupes por nada más. Alguien lo hará por ti.
• Apertura / honestidad - SCRUM mantiene todo acerca del proyecto visible a todos.
• Respeto - Los individuos estamos formados por nuestros orígenes y nuestras experiencias. Es importante respetar las diferentes a las personas del equipo y sus formas de pensar.
• Coraje - Tener el coraje para comprometerse, actuar, ser honesto y esperar respeto.


Ventajas

• Se obtiene software lo más rápido posible y este cumple con los requerimientos más importantes.

• Se trabaja en iteraciones cortas, de alto enfoque y total transparencia.

• Se acepta que el cambio es una constante universal y se adapta el desarrollo para integrar los cambios que son importantes.

• Se incentiva la creatividad de los desarrolladores haciendo que el equipo sea auto administrado.

• Se mantiene la efectividad del equipo habilitando y protegiendo un entorno libre de interrupciones e interferencias.

• Permite producir software de una forma consistente, sostenida y competitiva.

• Las reuniones se dedican a inconvenientes recientes, evitando el estancamiento


Desventajas

• Requiere delegar responsabilidades al equipo, incluso permite fallar si es necesario.

• Es una metodología que difiere del resto, y esto causa cierta resistencia en su aplicación para algunas personas


Scrum en Argentina

Epidata Consulting

Actualmente Epidata Consulting utiliza Scrum en la mayoría de las áreas funcionales de su negocio como una manera de administrar el fuerte crecimiento que está teniendo la empresa. Las prácticas de Scrum se implementan de forma integral o parcial en la mayor parte de los proyectos de Epidata, sean éstos de desarrollo o consultoría; también se organizan a través de esta metodología las áreas no técnicas de Capital Humano y Comunicación Institucional. La metodología Scrum se alinea con la filosofía de la empresa, permitiendo el aprendizaje continuo y la comunicación entre los integrantes de cada proyecto.
Para facilitar la aplicación de prácticas de esta metodología ágil, se brindó una charla introductoria y luego un workshop de 6 horas acerca de la metodología Scrum. De esta forma, todos los integrantes pudieron conocer y acercarse lo más posible a su aplicación real, logrando que la adopción en los proyectos no fuera un factor limitante para el logro de los objetivos prefijados.
La implementación de prácticas de Scrum resultó realmente satisfactoria, poco intrusiva y, sobre todo, con un pequeño overhead en el trabajo cotidiano de los integrantes de Epidata, siendo el resultado de la misma muy positivo.


Scrum en Estados Unidos

Mountain Goat

Fundada en 1993, Mountain Goat Software es una compañía dedicada a las consultas y entrenamientos de procesos de software y administración de proyectos. El foco de esta empresa esta en ayudar a compañías a adoptar y aplicar el uso de procesos y tecnologías ágiles para desarrollar de manera eficiente su organización.
Su trabajo es ayudar a que estas compañías puedan lograr satisfactoriamente el desarrollo de sus proyectos de software.
Mountain Goat Software dispone de especialistas en Scrum que pueden ayudar a su equipo a través de nuestros respetados y popular cursos y entrenamientos, nuestra ayuda onsite, y un excelente equipo de ScrumMasters.

Esther Derby Associates, Inc.

Esther Derby Associates, Inc. es una compañía que trabaja con clientes para construir ambientes productivos de trabajo y desarrollo de software. No cuentan con la solución para todos los problemas, en cambio, están dispuestos a explorar cada situación, escuchar, y juntar información. Recomiendan acciones a la medida de cada cliente el cual es único.
Scrum se trata de sentido común. Pero si usted nunca experimento Scrum o agile project management, puede sentirse extraño al principio.
El workshop de esta compañía usa un simulador para ayudar al equipo a interrelacionarse con los fundamentos de trabajar con agilidad.
Después de haber simulado la experiencia con Scrum, el equipo se encarga de planear la primera iteración, usando los actuales requerimientos y planeamientos para el trabajo real
Se espera que todos los participantes entiendan los conceptos básicos de Scrum antes de asistir a este curso.

domingo, 4 de mayo de 2008

Conferencia Gestion de Proyectos en Construcción VIERNES 09 MAYO

sábado, 3 de mayo de 2008

La UNI en su hora decisiva - Parte II

¿Cuál es el papel que desempeña la UNI en las próximas cumbres mundiales?

Por: José Isaac Ortiz Samanamud - Egresado UNI

En pocos días se realizará en nuestro país la V Cumbre Mundial de los países de América Latina – El Caribe y la Unión Europea ( ALC – UE) y en noviembre la Cumbre Mundial de la APEC, ambas de gran importancia por los temas que tienen en agenda tanto en el ámbito académico, cultural y empresarial. En Lima y provincias se dan los preparativos para recibir a los invitados de dichas cumbres, y claro esta que lo que todos buscan es establecer relaciones de cooperación que les permita desarrollar proyectos de gran envergadura para beneficio de sus organizaciones. La UNI iba en ese camino y para ello se concretaron varios proyectos de índole académico como la movilización académica a los países de Europa comenzando por Francia y las relaciones con delegaciones científicas de China, India, Japón y Corea y en el ámbito de contar con modernas infraestructuras y equipamiento se llegaron a concretar el Instituto de Matemáticas y Ciencias Afines (IMCA), la transferencia del Instituto Nacional de Investigación y Capacitación de Telecomunicaciones (INICTEL), el Centro de Extensión y Proyección Social (CEPS), el Centro de Convenciones del CISMID y en pleno desarrollo el Centro de Tecnologías de la Información y Comunicaciones (CTIC) financiado con apoyo de Corea, otro de los grandes proyectos sin duda alguna para recibir a estos invitados era la construcción de una moderna Biblioteca para lo cual el Ing. Roberto Morales ya había dado pasos significativos en cuanto al financiamiento del mismo, comprometiendo al Ministerio de Economía con una partida presupuestal exclusiva para la biblioteca, también al Patronato y con los recursos propios que genera la Universidad.

Después de tres meses confirmo las sospechas que estableciera en mi artículo anterior LA UNI EN SU HORA DECISIVA I, -LA UNI ESTARIA PERDIENDO EL RUMBO-, a tal punto que prácticamente es la gran ausente en estas cumbres mundiales, donde deberíamos estar planteando temas como la asociación estratégica con los empresarios para dar soporte tecnológico a las empresas y mejorar sus niveles de competitividad que les permita competir frente a los tratados de libre comercio con empresas de otras nacionalidades, al mismo tiempo de establecer convenios internacionales con los países asiáticos para hacer investigación conjunta en alta tecnología, todo esto esta quedando de lado y lo único que aparentemente preocupa a la actual autoridad es hacer nombramientos de docentes asambleístas y otros no asambleístas en puestos remunerados de la administración central que le procuren posiblemente votos para las elecciones de nuevas autoridades del próximo año.

Espero exista una reflexión por parte de los miembros asambleístas, especialmente de los miembros estudiantiles quienes no se ven involucrados en el tema de querer conseguir un puesto en la administración central, a fin de que hagan las correcciones pertinentes para que la UNI retome su rumbo y logre contar con una moderna Biblioteca y también la creación de la Escuela de Post-Grado antes de la reunión más importante de la APEC en noviembre, y tener como invitados a personajes importantes en la toma de decisiones para visitar nuestras instalaciones y concretar convenios y acuerdos en favor de la Universidad.

Finalmente la pregunta con que inicie este escrito, seguirá en nuestras mentes, esperando que nuestras actuales autoridades y nuestros representantes de los diferentes estamentos de la universidad hagan las correcciones y retomen el liderazgo a la altura de lo que representa la UNIVERSIDAD NACIONAL DE INGENIERIA en el Siglo XXI, y que no quede solo en el pintado de un slogan en el puente denominándola, “Alma Máter de la Ciencia y Tecnología al servicio del País”, sino que sea una realidad comprobada.







Proyecto Ganador del Concurso Arquitectónico para la nueva Biblioteca, realizado por un equipo integrado por Docentes, Egresados y Alumnos de la FAUA.

Share

Twitter Delicious Facebook Digg Stumbleupon Favorites