Una Introducción a Scrum Una Scrum Jorge Jorge Hernán Abad Londoño
[email protected] Agosto 2009
Agenda
Metodologías ágiles Scrum El juego de la estimación
METODOLOGÍAS ÁGILES
El Manifesto Manifesto gil gil –– uuna na declaración ddee valores declaración Indi div vid idu uos e nter nte nt e erac ra acc cc o ones on ne es s
sobre
Procesos y errram en er enttas
Software que funciona
sobre
Documentación exhaustiva
Colaboración Responder ante el cambio
sobre
sobre
Fuente: www www.agilemanifesto.org .agilemanifesto.org
Nego Ne goc cia iac ció ión n de Seguimiento de un plan
Algunos principios y valor valores es ágiles
La prioridad mayor mayor es la satisfacción del cliente haciendo entregas continuas de software valioso para él Los cambios son bienvenidos bienvenidos siempre La medida principal de progreso progreso es el software funcionando El gestor es un facilitador no un controlador Equipos auto-organizados y multidisciplinares multidisciplinares Inspeccionar y adaptar Me ora ora con conti tinu nuaa Respeto, Respeto, claridad y comunicación comunicación Ritmo sostenible La arquitectura y diseño emergen
Ágil no es hacer lo que se quiera
… ni tampoco programación heroica
La magia no existe
Ken Schwabe Schwaberr: “En Scrum, un grupo en el que que se lleven mal entre ellos, no comprendan el negocio del cliente y trabajen con malas herramientas... también producirán incrementos periódicos... periódicos... de basura. basura. ” Dan visibilidad y transparencia transparencia desde el principio, aunque no resuelven resuelven todos los problemas. problemas. No ser extremista, usar lo que te funcione e recom en a pr mero usar o o, uego acer modificaciones. modificaciones. Cuidado con “Scrum but…”
HISTORIA DE USUARIOS
Fuente Wikipedia
Historias de Usuario
Una historia de usuario es una representación de un requerimiento de software escrito en una o dos frases utilizando el lenguaje común del usuario. Las historias de usuario son utilizadas en las metodologías de desarrollo ágiles para la especificación de requerimientos (acompañadas de las discusiones con los usuarios y las pruebas de validación). Cada historia historia de usuario debe debe ser limitada, esta debería debería poderse poderse escribir escribir sobre una nota adhesiva pequeña. Dentro de la metodología XP las historias de usuario deben ser escritas por los clientes.
Historias de Usuario
Las historias de usuario son una forma de los usuarios sin tener que elaborar gran cantidad de documentos formales y sin requerir de mucho tiempo para administrarlos. Las historias de usuario perm permit iten en respo espond nder er r pi pida dame ment ntee a lo loss requerimientos cambiantes.
Características
Independientes unas de otras: De ser necesario, combinar las historias dependientes o buscar otra forma de dividir las historias de manera que resulten independientes. Negociables: La historia en si misma no lo suficientemente explícita como para considerarse un contrato, la discusión con los usuarios debe permitir esclarecer su alcance y éste debe dejarse explícito bajo la forma de pruebas de validación. Valoradas por los clientes o usuarios: Los intereses de los clientes y de los usuarios no siempre coinciden, pero en todo caso, cada historia debe ser importante para alguno de ellos e llos más que para el desarrollador. desarrollador. Estimables: Un resultado de la discusión de una historia de usuario es la estimación del tiempo que tomará completarla. Esto permite estimar el tiempo . Pequeñas: Las historias muy largas son difíciles de estimar e imponen restricciones sobre la planificación planif icación de un desarrollo iterativo. Generalmente se recomienda la consolidación de historias muy cortas en una sola historia. Verificables: Las historias de usuario cubren requerimientos funcionales, f uncionales, por lo que generalmente gene ralmente son verificables. Cuando sea posible, la verificación debe automatizarse, automatizarse , de manera que q ue pueda ser verificada en cada ca da entrega del proyecto. proyecto.
Características
Si bien el estilo puede ser libre, la historia preguntas: ¿Quién se beneficia?, ¿qué se quiere? y ¿cuál es el beneficio? Por ello, algunos autores[1] recomiendan redactar las historias de usuario según el formato:
Como (rol) quiero (algo) para poder (beneficio).
Beneficios
Al ser muy corta esta representa requisitos del modelo de negocio que pueden implementarse rápidamente (días o semanas) Necesitan poco mantenimiento Mantienen una relación cercana con el cliente Permite dividir los los proyectos proyectos en pequeñas pequeñas entregas erm ermite ite estim stimaar ci mente nte e es uer uerzo e desarrollo Es ideal para proyectos proyectos con requerimientos volátiles o no muy claros
Limitaciones
Sin pruebas de validación pueden quedar abiertas a distintas interpretaciones interpretaciones haciendo difícil utilizarlas como base para un contrato Se requiere requiere un contacto permanente con el cliente durante el proyecto proyecto lo cual puede ser difícil o costoso Podría resultar difícil escalar a proyectos grandes Requiere desarrolladores muy competentes Sin pruebas de validación pueden quedar abiertas a distintas interpretaciones interpretaciones haciendo difícil utilizarlas como base para un contrato Se requiere requiere un contacto permanente con el cliente durante el proyecto proyecto lo cual puede ser difícil o costoso Podría resultar difícil escalar a proyectos grandes Requiere desarrolladores muy competentes
SCRUM
Est Estamos staamos perdiendo la la carrera carrera ddee relevos “En enfoque de ‘carrera de relevos’ en el ... conflicto con los objetivos de máxima velocidad y flexibilidad. flexib ilidad. En su lugar, lugar, un enfoque enfoque holíst holístico ico o estilo estilo ‘rugby ‘rugby’’ - don donde de un equipo intenta ir a la distancia como una unidad, pasando la pelota hacia adelante y actuales requisitos competitivos". Hirota Hirotaka ka Takeuch akeuchii and Ikujiro Ikujiro Non Nonaka aka,, “The New New New Product Product Developm Development ent Game”, Harvard Business Review , January 1986.
Scrum en 100 palabras • Scrum es un proceso ágil que nos permite centrarnos en ofrecer el más alto valor de negocio en el menor . • Nos permite rápidamente y en repetidas ocasiones inspeccionar software real de trabajo (cada dos semanas o un mes). • El negocio fija las prioridades. Los equipos se autoorganizan a fin de determinar la mejor manera de . • Cada dos semanas o un mes, cualquiera puede ver el software real funcionando y decidir si liberarlo o seguir mejorandolo en otro sprint.
SCRUM
Scrum es una una metodología para la gestión de proyectos, proyectos, expuesta expuesta por Hirotaka Takeuchi e Ikujiro Nonaka, Nonaka, en el ar cu o 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 productos representan cada vez un porcentaje más El mercado exige ciclos de desarrollo más cortos.
SCRUM
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 Siguiendo el símil símil depor deportivo tivo,, 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.
SCRUM
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 flexibilidad en la producción: Xerox, Canon, Honda, NEC, Epson, Brother, 3M o Hewlett-Packa Hewlett-Packard; rd; y son: ◦
◦
◦
◦
◦
◦
Inestabilidad consustancial al entorno de de desarr desarrollo ollo.. Equipos auto-organizados. Sola So la amie amiento nto de las las fases fases del del desa desarr rrol ollo lo.. Multi-aprendizaje. Control sutil. Transferencia de aprendizaje a nivel organizacional.
SCRUM
Aunque surgió como modelo m odelo 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 e n VMARK, luego en e n Informix y finalmente finalm ente en Ascential Software Soft ware Corporation). En 1996 lo presentó junto junt o 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
Orígenes de Scrum
Jeff Sutherland ◦
◦
Ken Schwaber ◦
◦
◦
ADM Se presenta Scrum en OOPSLA 96 con Sutherland Autor de tres libros sobre Scrum
Mike Beedle ◦
Scrums iniciales en Easel Corp en 1993 IDX 500 personas haciendo Scrum
Patrones Scrum en PLOPD4
Ken Schwaber and Mike Cohn ◦
Fundaron conjuntamente la Scrum Alliance en 2002, inicialmente dentro de la Agile Alliance
Scrum ha sido sido utilizado por: po r : •Microsoft •Yahoo
•Intuit •Nielsen Media
•Electronic Arts •High Moon Studios •Lockheed Martin •Philips • •Nokia •Capital One •BBC •Intuit
•BMC Software •Ipswitch •John Deere •Lexis Nexis • •Salesforce.com •Time Warn Warner er •Turner Broadcasting •Oce
Scrum ha sido sido utilizado para: para:
Software comercial Desarrollos internos Desarrollos bajo Contrato Proyectos Proyectos Fixed-price Fixed-price Aplicaciones Financieras Aplicaciones certificadas ISO 9001 Sistemas Embebidos Sistemas con requisitos 7x24 y 99.999% de disponibilidad Joint Strike Fighter
• Desarrollo de video juegos • Sistemas críticos de soporte ,
• Software de control satelital • Sitios Web • Software para Handheld • Teléfonos portátiles • Aplicaciones de Network • Aplicaciones de ISV • Algunas de las más grandes aplicaciones en uso
Características
Es una de las metodologías ágiles E ui os auto-or anizados El producto avanza en una serie de “Sprints" de dos semanas a un mes de duración Los requisitos son capturados como elemento elementoss de una lista lista de “Produc “Productt Backlog Backlog""
Util Utiliz izaa normas gener nerativ tivas para cr crear un un entorno ágil ágil para la entrega de proyectos proyectos Uno de los “pr “proceso ocesoss ágile ágiles” s”
Nivel ddee ruido Nivel ruido de de un un proyecto Lejos de Acuerdo
Anarquía s o t i s i u q e
Cerca de Acuerdo
Complejo
Fuente: Strategic Management and Organizational Dynamics by Dynamics by Ralph Stacey in Agile Software Development with Scrum by Scrum by Ken Schwaber and Mike Beedle.
Simple e a d z e a t r c e r e C C
Tecnología
e a d z e s t r o e j e L C
Scrum
24 horas
Sprint 2-4 semanas
Objetivo del Sprint
Return Gift wrap Cancel Product Backlog
Sprint Backlog
Incremento del producto potencialmente entregable
Poniendo todo todo junto
Imagen disponible en www.mountaingoatsoftware.com/scrum
Sprints
En Scrum los pr proyectos oyectos avanzan avanzan en una serie serie de “S rints” Análogo a las iteraciones en XP La duración típica es 2–4 semanas o alo sumo un mes calendario La duración constante conduce a un mejor ◦
El product es diseñado, codificado y testeado durante el Sprint
esarro o secuencia vs. superpuesto Requisitos
Diseño
En lugar de hacer todo de una cosa a la vez ...
Có d i g o
Test
...los equipos Scrum hacen un poco de todo
Source: “The New New Product Development Game” by Takeuchi and Nonaka. Harvard Business Review, Review, January
No hay ccambios ambios en en un un sprint s pr i n t Cambios
Planee anee la du duración del sp sprint en en to torno a cu cuánto tiempo mpo uste sted puede compromet meterse a man manttener los ca cambi mbios fuer fueraa del del spri sprinnt
Scrum Framew Framework ork Roles
•Product owner •ScrumMaster •Team Reuniones •Sprint planning •Sprint review •Sprint retrospective •Daily scrum meeting Artefactos
•Product backlog •Sprint backlog •Burndown charts
Scrum framew framework ork Roles
•Product owner •ScrumMaster •Team Reuniones •Sprint planning •Sprint review •Sprint retrospective •Daily scrum meeting Artefactos
•Product backlog •Sprint backlog •Burndown charts
Product Owner
Defi Define ne las las func funcio iona nalilida dade dess del del prod produc ucto to Decid ecidee sob obrre las las fech echas y conten ntenid idoos de lo loss relea eleasses Es respo espons nsab able le po porr la renta entabi bililida dadd del del prod produc ucto to (ROI (ROI)) Prio Pr iori riza za func funcio iona nalilida dade dess de acue acuerrdo al valo valorr del del mercado/negocio si es necesario Acept epta o rrec echa hazza lo loss re result sultaados del trabajo bajo del equ quip ipoo
El ScrumMaster
Representa a la gestión del proyecto
de Scrum Remueve impedimentos Se asegura de que el equipo es completamente funcional y productivo roles y funciones Escudo del equipo de interferencias externas
El Team
Típi Típica camen mente te de 5 a 9 pers person onas as Multi-funcional: ◦
Los miembros deben ser full-time ◦
Puede haber excepciones excepciones (Ej.: Infraestructu Infraestructura, ra, SCM, etc.) etc.)
Los equipos son auto-organizativos auto-organizativos ◦
Programadores, testers, analistas, diseñadores, etc.
Idealmente, no existen títulos pero a veces se utilizan de acuerdo a a organizaci n
Solo puede haber cambio de miembros entre los sprints
Scrum Framew Framework ork Roles
•Product owner •ScrumMaster •Team
Reuniones
•Sprint planning •Sprint review •Sprint retrospective • Artefactos
•Product backlog •Sprint backlog •Burndown charts
Capacidad del Equipo
Sprint Planning meeting Priorización
• Analizar evaluar el Product Backlog Condicione s d el Negocio Producto Actual
Tecnología
•
Backlog Seleccionar el objetivo del Sprint
del Sprint
Planificación
• Decidir como alcanzar el objetivo • •
del Sprint (diseño) rear e pr n ac og areas en base a los temas del Product Backlog (user stories / features) Estimar Sprint Backlog en horas
Backlog
Planificación del Sprint
El equipo selecciona los temas a partir par tir del Product Backlog que pueden comprometerse a completar e crea e pr nt ac og ◦
◦
Se identifican tareas tareas y cada una es estimada (1-16 horas) Realizado colaborativamente, no solo por el ScrumMaster
El diseño de Alto Nivel es considerado
COMO lanificador de vacaciones, YO QUIERO ver fotos de los hoteles.
Codificar la interfaz de usuario (4) Escribir los test fixtures (4) Codificar la clase foo (6) Actualizar test de performance (4)
Daily Scrum
Parámetros ◦
◦
Dura 15 minutos Parados
No para la solución de problemas problemas ◦
◦
Sólo los miembros del equipo, ScrumMaster y Product Owner, pueden hablar Ayuda a evitar otras reuniones innecesarias
Tod Todos odos os rees espo sppond onden nden en 3 preguntas 1 ¿Qué hiciste ayer?
2 ¿Qué vas a hacer hoy?
3
No es dar un status report al Scrum Master Se trata de compromisos delante de pares p ares
Sprint review
El eq equipo presenta lo re realizado durante el sprint Norma rmalme lmente adopta pta la forma de un unaa demo de la las nueva uevass carac aracte terí ríst stic icas as o la arqu arquit itec ectu turra subyacente Informal Regla de 2 hs hs preparación No usar usar di diaapo posi siti tiva vass Todo el equi equipo po parti particcip ipaa Se in invita a to todo el mu mundo ◦
◦
Sprint retr etrospect ospectiv ivee
Periódicamente, se echa un vistazo a lo que funciona y lo que no Normalmente 15 a 30 minutos Se realiza luego de cada sprint Todo el el equip equipoo particip par ticipaa ScrumMaster Product owner Equipo Posiblemente clientes y otros otros ◦
◦
◦
◦
Start / Stop / Continue
Todo el equipo se reúne y discute lo que les Comenzar a hacer Dejar de hacer Esto es sólo una de las muchas maneras de hacer una retrospectiva.
Con Co nti tin nua uarr ha haci cie end ndo o
Scrum framew framework ork Roles
•Product owner •ScrumMaster •Team Reuniones •Sprint planning •Sprint review •Sprint retrospective •Daily scrum meeting Artefactos
•Product backlog •Sprint backlog •Burndown charts
Product Backlog
Este es el product backlog
Los requisitos requisitos deseados en el proyecto Idealmente cada tema tiene valor para el usuarios o el cliente Priorizada por el Pr Product oduct Repriorizada al comienzo de cada Sprint
Ejeemp Ej Ejemplo mplo lo de Pr Prod Product oduc uctt Back Ba Backlog cklo logg Backlog item
Estimación
erm r que un nv a o a acer una reserva. Como invitado, quiero cancelar una reserva.
5
Como invitado, quiero cambiar las fechas de una reserva.
3
Como un empleado de hotel, puedo ejecutar disponible Mejorar el manejo de excepciones
8
. ..
30
. ..
50
Ejeemp Ej Ejemplo mplo lo de Pr Prod Product oduc uctt Back Ba Backlog cklo logg
El objetivo objetivo del Sprint
Una breve declaración de cual será el foco del traba o durante el s rint Ciencias Biológicas
Aplicación con B.Datos
Funciones de apoyo técnico necesarios para estudios de genética de poblaciones.
Hacer que la aplicación se ejecute en SQL Server, además de Oracle. Servicios Financieros Soportar más indicadores técnicos que la empresa ABC en tiempo real y streaming de datos.
Ges Gestión esti tióón ddel el Sprint Spr prin intt Backlog Back Ba cklo logg
Los individuos eligen las tareas El trabajo nunca es asignado
diariamente Cualquier miembro del equipo puede añadir, borrar o cambiar el Sprint Backlog El trab trabaj ajoo para para el Sp Spri rint nt emer emerge ge Si el trab trabaj ajoo no está está clar claroo, defi defini nirr un tema tema del del Sp Spri rint nt subdi subdivid vidirl irlaa luego luego.. Actualizar el trabajo restante a medida de que más se conoce
Ejemplo ddee Sprint Ejemplo Sprint Backlog Sp Backlog Ba Tareas Codificar UI Codificar negocio Testear negocio negoci o Escribir ayuda online scr
L
M
M
J
V
8
4
8
16
12
10
4
8
16
16
11
8
4
12
r a c ase oo oo
Agregar error logging
8
Ejempl Ejemplo ploo ddee Sprint Sprin Spr intt Backlog Backlog Ba
Seguimiento
Es recomendable, que el propietario del producto emplee una hoja de cálculo, alguna herramienta similar, o el soporte de una intranet, para guardar en formato digital la pila del producto. Pero Pero no es aconsejable emplearla como base b ase para trabajar sobre ella en la reunión proyectándola sobre la pantalla de la sala. físicos; y usar una pizarra y fichas removibles (adhesivas, con chinchetas o magnéticas).
Tab able lerro de tra traba bajo jo
n rea super or on e e crum anager co oca a pr nc p o e a reunión la capacidad real del sprint a 3, 4 y 5 semanas (A); y al final (D), las notas con: el objetivo establecido, duración del sprint, funcionalidades de la pila del producto comprometidas, hora fijada para las reuniones diarias y fecha prevista para la reunión de revisión del sprint.
B.- Una franja franja para ordenar ordenar los elementos elementos de de la pila del producto producto de mayor mayor a menor prioridad.
C.- Una franja franja paralela paralela para descompo descomponer ner cada cada elemento elemento de la pila del producto en las correspondientes tareas tareas de la pila del sprint.
Pruducto
Sprint
Objetivoo del sprint Objetiv
Otra forma de ver el tablero de mando
Otra forma de ver el tablero de mando
Recordemos
Un Sprint Burndown Burndown C Chart hart s r u o H
Tareas
L
Codificar UI Codificar Negocio Testear Negocio
M
M
J
8
4
8
16
12
10
7
8
16
16
11
50 40 s r 30 u o H20
10 0
Mo n
Tue
Wed
T hu
Fri
V
8
Escalabilidad
Normal Normalment mentee los los equi equipos pos son de 7 ± 2 personas ◦
Factores Factores a tener cuenta ◦
◦
◦
◦
La escalabilidad proviene de equipos de equipos Tipo de aplicación Tamaño del equipo Dis ersión del e ui o Duración del proyecto
Scrum se ha utilizado en múltiples proyec proyectos tos de más de 500 personas
Expansión a través través de Scrum de scrums
Scrum de scrums de scrums
Scrum of Scrums / MetaMeta-Scrum -Scrum m u r c S
EL JUEGO DE LA ESTIMACIÓN
Poker Game Poker Game
Planificación de póquer es una variación del método Delphi. Es simple, se burla y los resultados de estim Planificación de póquer se utiliza para estimar el esfuerzo o el tamaño relativo de las tareas en el desarrollo desarrollo de software de manera fiable. Los miembros del equipo del proyecto se reúnen y en unas pocas ron as me an e e o er ame egan a un consenso sobre el tamaño de cada tema o tarea.
La baraja de Cartas
Cada Cada juev juevo de cartas cartas inclu incluyye los números 0, (0,5), 1, 2, 3, 5, 8, 13, 20, 40, 100, y, a veces, un café tarjeta. Cada miembro del equipo necesita una baraja de cartas
La reunión reunión de de pplanificación lanificación ((1) 1)
Al comienzo de la planificación de póquer, cada estimador se le da un mazo de cartas. Para cada Historia de Usuario o tema que se se va a estim estimar ar,, un m moderad oderador or lee la descrip descripción. ción. El moderador suele ser ser el propietario del producto o una analista. Sin embargo, el , que no ha hay privilegio especial asociado con el papel.
La reunión reunión de de pplanificación lanificación ((2) 2)
El Dueño Dueño del producto producto (Pr (Product Owner) Owner) responde responde todas las preguntas que tienen los estimadores. selecciona una carta de forma secreta e individual. Las tarjetas no se muestran hasta que todos hayan hayan hecho su estimación. Luego todos muestran al mismo tiempo la carta elegida El grupo puede discutir la historia y sus estimaciones durante unos minutos más. Principalmente se indaga a as as personas que es n e anas e a me a que explique su posición. Tras el debate debate se hace otra ronda ronda de estimacion estimacion en privado.
La reunión reunión de de pplanificación lanificación ((3) 3)
Valores altos de tiempo implican ◦
◦
Alta complejidad se recomienda en lo posible dividir en tareas más pequeñas.
Si sale (?) Implica que no se tiene idea de que se esta hablando Si sale la taza de café, indica que la persona esta casada.
Resultados
En muchos casos, las estimaciones estimaciones . contrario se debe repetir el proceso. El objetivo es converger a una única estimación.
Donde seguir?
www.mountaingoatsoftware.com/scrum www.scruma iance.o e.org www.controlchaos.com
[email protected]
Una lista de Una de lecturas lecturas sobre SScrum crum
Agile Agile and Iterative Development: Development: A Manager’ Manager’ss Guide Guide
Larman
by Craig
Agile Estimating and Planning by Mike Cohn
by Ken Ken Schwaber Schwaber Agile Retrospectives Retrospectives by Esther Derby and Diana Larsen Agile Software Development Ecosystems by Jim Highsmith Agile Software Development Development with Scrum by Ken Schwaber and Mike Beedle Scrum and The Enterprise by Ken Ken Schwaber Schwaber User Stories Applied for Agile Software Development by Mike Cohn Artículos semanales en www.scrumalliance. www.scrumalliance.org org Agile Agile Proje Project ct Manage Managemen mentt with Scrum Scrum
Aviso de Aviso de Copyright Copyrig ighht
Usted es libre libre de: ◦
◦
Modificar Modificar-- adaptar adaptar el trabajo trabajo
Bajo las siguientes condiciones ◦
CompartirCompartir- copiar, copiar, distribuir y trasmitir el trabajo
Atribución. Ud. debe atribuir atrib uir el trabajo en la manera especificada por el autor o licenciante (pero de ninguna manera que sugiera que ellos aprueban su uso del trabajo).
Nada Nada de lo di diss uest uestoo en esta esta lice licenc ncia ia menoscaba o restringe los derechos morales del autor. Para más información ver http://creativecommons.org/licenses/by/3.0/ http://creativecommons.org/licenses/by/3.0/
Información de Contacto Presen Presentad tado o por: por: Mike Mike Coh Cohn n
[email protected] www.mountaingoatsoftware.com (720) 890-6110 (office)
Tomado de:
Una Una intr introdu oducc cción ión a Scrum Scrum - Ernest Ernestoo .
