Ir al contenido principal

Scrum Product Owner

El Scrum Product Owner es un rol central en la metodología Scrum. La mayoria  de las responsabilidades del un clásico product manager y de un project manager  están combinadas en este único rol.

El representa al usuario final y/o  algún otro interesado  y sus responsabilidad  es maximizar el valor del producto asegurándose que el trabajo correcto este hecho en el tiempo correcto.

Como consecuencia esto significa obviamente que el Scrum Product Owner  tiene que trabajar muy cerca del Scrum Team  y coordinar sus actividades durante toda la vida del proyecto.  A ningún otro se debería permitir decir al equipo sobre las prioridades.

El Scrum Product Owner tiene las siguientes responsabilidades.


  • Administrar la Scrum Product Backlog
  • Administrar la forma de liberación de funcionalidad
  • Administración de interesados
  • Trabajar de cerca con el Scrum Team
El scrum Product Owner puede delegar ciertas actividades (por ejemplo el mantenimiento fisico del Scrum Product Backlog), pero al final el sera el unico responsable

Administrar la Scrum Product Backlog

El Scrum Product Owner es el único encargado de administrar el contenido del  Scrum Product Backlog. esto significa que

  • Crea, mantiene y clarifica cada una de las descripciones de los elementos en la Scrum Product Backlog.
  • Prioriza los elementos para lograr la mejor forma de lograr las metas y la misión
  • Se asegura que el Scrum Team  entienda todos los elementos del Scrum Product Backlog
Administrar los lanzamientos

El Scrum Product Owner  es responsable de alcanzar los objetivos del poryectos, el crea y mantiene el plan de lanzamientos  y decide acerca de los entregables, funcionalidades y lo relacionado con costos del proyecto.

El administra al Scrum Team por creacion y priorizacion de un elementos apropiados del Scrum Backlog 

Administrar a los interesados

Los interesados externos al poryecto no se comunican directamente con el equipo. Es el Product Owner quien colecta y discute las funcionalidades requeridas con los distintos Interesados, por ejemplo clientes, marketin, servicios, etc.  ehsos requerimientos son entonces combinados  y filtrados  antes de ser entregados al equipo  en forma de una priorizados elementos del  Scrum Backlog.

Trabajar de cerca con el Scrum Team

Para un proyecto exitoso  es importante que el Scrum Product Owner  y el Scrum Team trabajen muy de cerca. el es responsable que todos en el Scrum Team entiendan que es requerido.

El Scrum Product Owner  es tambien responsable de revisar y acepar los resultados del Sprint durante la Sprint Review Session

Comentarios

Entradas populares de este blog

DISEÑO AL NIVEL DE COMPONENTES

El diseño a nivel de componentes se presenta a menudo despues que se ha terminado la primera iteracion del diseño arquitectonico. y  el objetivo de esta fase es traducir el diseño en software operaciona. El diseño a nivel de componentes define las estructuras de datos, los algoritmos, las caracteristicas de la interfaz  y los mecanismos de comunicacion asignados a cada componente de software. esta fase permite revisar si los detalles de diseño son correctos y consistentes con las representaciones iniciales de diseño ¿QUE ES UN COMPONENTE? Es un bloque de construccion modular par el software de computo. una parte modular desplegable y reemplazable de un sistema que encapsula implementacion y expone un conjunto de interfaces. desde el punto de vista orientado a objetos un componente es un conjunto de clases ques se interrelacionan entre si. en el contexto convencional de ingenieria de software  un componente es un elemento funcional que incorpora  la logica del procesamiento y

ESTRATEGIAS DE PRUEBAS DE SOFTWARE

La estrategia de pruebas de software proporciona un mapa que describe los pasos que se daran como parte de la prueba indica cuando se planea y cuando se daran dichos pasos ademas cuanto tiempo, esfuerzo y recursos consumiran. un software se prueba para descubrir los errores cometidos, si se realiza sin ningun plan seguramente se desperdiciara tiempo, se dedicara un esfuerzo innecesario y lo que es peor puede que no se detecten los errores. Las pruebas se deben planificar con anticipacion y realizarlas de manera sistematica por lo que es importante tener una plantilla existen diferentes y en general tienen los siguientes pasos. 1. Revisiones tecnicas formales y efectivas 2. Se inicia a nivel de componentes y se trabaja hacia afuera hacia la integracion del sistema 3. Diferentes tecnicas en diferentes momentos 4. las pruebas las dirige el desarrollador 5. la prueba y la depuracion son actividades diferentes, pero la segunda debe incluirse en cualquier estrategia de pruebas. l

Múltiples Botones de Submit en MVC 5

Hace unos días me tope con un inconveniente debía colocar varios botones de submit en una vista de MVC, la solución que implementé es muy sencilla 1. En el controlador añadí un parámetro llamado "boton" de tipo string, el cual recibe el valor del botón que se esta accionando en la vista, en el ejemplo colocó una condición que indica que si el botón que se esta accionando es el de cancelar, regresamos al index de lo contrario ejecutamos otra acción [HttpPost] public ActionResult Carga(string boton) {         if(boton.CompareTo("Cancelar")==0)                 return RedirectToAction("Index"); } 2. En la vista tengo dos botones "Cargar" y  "Cancelar" de tipo submit, acá es importante que la propiedad "name" del botón tenga el mismo nombre que la variable del controlador, ya que es por este medio por el cual el controlador identifica de donde tomar el valor para la variable en este caso la variable del controlador