Ir al contenido principal

Que es SCRUM


Scrum es un marco liviano de gestión de proyectos, es un acercamiento iterativo e incremental en el desarrollo del trabajo. Usado mayormente para el desarrollo de proyectos de software.


Este modelo fue identificado y definido por Ikujiro Nonaka e Hirotaka Takeuchi a principios de los 80, al analizar cómo desarrollaban los nuevos productos las principales empresas de manufactura tecnológica: Fuji-Xerox, Canon, Honda, Nec, Epson, Brother, 3M y Hewlett-Packard (Nonaka & Takeuchi, The New New Product Development Game, 1986)
En su estudio, Nonaka y Takeuchi compararon la nueva forma de trabajo en equipo, con el avance en formación de melé (scrum en inglés) de los jugadores de Rugby, a raíz de lo cual quedó acuñado el término “scrum” para referirse a ella. (wikipedia)

https://hbr.org/1986/01/the-new-new-product-development-game/ar/1
https://hbr.org/2011/05/the-big-idea-the-wise-leader







Puede ser utilizado en cualquier tipo de desarrollo de software, desde paquetes completos, algunas partes de sistemas mas grandes, para clientes o proyectos internos.

Scrum esta fundamentado en cuatro piedras angulares las cuales se basan en el manifiesto ágil.

1.  Individuos e interacciones, sobre  procesos y herramientas.
2.  Producto funcional, sobre documentación exhaustiva
3. Colaboración con el cliente sobre negociación contractual
4. Respuesta al cambio sobre planificación exhaustiva

El marco en si es muy simple esta limitado a unas pocas reglas, artefactos, eventos y roles sin embargo la utilización de cada uno es importante y esencial para el correcto desarrollo de un proyecto con SCRUM.

1. Tres Roles:  Scrum Master, Product Owner, Scrum Team
2.  Una pila de requerimientos
3. Sprints
4. Sprint Planning meeting ( Que y Como), Daily Scrum Meeting,Sprint Review Meeting, Sprint Retrospective Meeting.

Uno de los aspectos importantes de Scrum es que se trata de gestionar proyectos autoorganizados con la ayuda de los miembros del equipo, no se trata de gestión de proyectos en el sentido clásico. Las responsabilidades de un project manager normal se dividen entre  el Scrum Master y el Product Owner. Aunque al final el equipo es quien decide cuanto  trabajo pueden realizar en la iteración.

Otro aspecto importante se trata de la mejora continua la cual debe ser  inherente al framework, inspeccionar y adaptarse. Inspeccionar los productos creados  y mejorarlos, esto incrementa la predictibilidad y minimiza los riesgos en los proyectos.

Scrum trabaja bajo el  hecho que los requerimientos cambian rápidamente o no son comprendidos totalmente al momento del inicio del proyecto. El detalle de los requerimiento son definidos hasta el momento de la implementación,  En Scrum los cambios y optimización del producto, requerimientos y procesos son parte del ciclo de ingeniería.

 Una de las piedras angulares de Scrum es la comunicacion, El Product Owner trabaja muy cerca con el equipo para identificar y priorizar la funcionalidad. La funcionalidad es escrita en términos de historias de usuario y estas se almacenan en la pila de requerimientos, la pila de requerimientos se refiere a todo lo que debe estar listo ,

El equipo esta empoderado para decidir que historias de usuario pueden finalizar en 2-4 semanas. Como el equipo se ha definido sus propias metas, ellos estan motivados y trabajan de la mejor manera posible logrando su mejor rendimiento. El Scrum Master es uno de los papeles importantes de Scrum y trabaja como un servidor/maestro del equipo, su principal tarea es que el equipo entienda como El marco scrum funciona. Protege al equipo de interrupciones externas y remueve los impedimentos para que el equipo logre su máxima potencial.


En general Scrum es utilizado en equipos pequeños de desarrollo 8 personas pero tambien pueden realizarse equipos múltiples en este caso se incluye la figura del Scrum Master Chief  para lograr realizar equipos distribuidos geográficamente distribuidos o proyectos de mayor envergadura.



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