Este documento discute diferentes metodologías para proyectos de software. Presenta Scrum, eXtreme Programming (XP) y Kanban como enfoques ágiles para el desarrollo de software. También discute sobre el Manifiesto Ágil y los 12 principios ágiles. Finalmente, menciona que Kanban puede ser una evolución guiada hacia la agilidad.
Tema N° 6 Técnicas para el Levantamiento y Recolección de RequisitosSaraEAlcntaraR
Tema N° 6 Técnicas para el Levantamiento y Recolección de Requisitos correspondiente a la Unidad II.- Ingeniería de Requisitos del Saber Ingeniería del Software II, dictado en el PNF en Informática de la UPTP "Luis Mariano Rivera".
Tema N° 7 Atributos de Calidad del Software según Norma ISO 25010SaraEAlcntaraR
Tema N° 7 Atributos de Calidad del Software según Norma ISO 25010 correspondiente a la Unidad II.- Ingeniería de Requisitos del Saber Ingeniería del Software II, dictado en el PNF en Informática de la UPTP "Luis Mariano Rivera".
Tema N° 6 Técnicas para el Levantamiento y Recolección de RequisitosSaraEAlcntaraR
Tema N° 6 Técnicas para el Levantamiento y Recolección de Requisitos correspondiente a la Unidad II.- Ingeniería de Requisitos del Saber Ingeniería del Software II, dictado en el PNF en Informática de la UPTP "Luis Mariano Rivera".
Tema N° 7 Atributos de Calidad del Software según Norma ISO 25010SaraEAlcntaraR
Tema N° 7 Atributos de Calidad del Software según Norma ISO 25010 correspondiente a la Unidad II.- Ingeniería de Requisitos del Saber Ingeniería del Software II, dictado en el PNF en Informática de la UPTP "Luis Mariano Rivera".
Evolución de aplicación de prácticas ágiles dentro de grandes organizaciones de todos los tamaños, sectores de actividad, tipos de proyectos y productos. PMI Pacifico Colombia Chapter - 05-ABR-2017. Alex Canizales.
Las Pruebas de Software son todavía una de las áreas más desatendidas del desarrollo y espliegue de los productos de software. Las Pruebas de Software son predominantemente vistas como una actividad periférica, casi una formalidad, antes del espliegue del software. Un cambio de actitud y un buen programa de estudios como fundamento hacia las Pruebas de Software pueden reducir tremendamente los problemas normalmente asociados con el lanzamiento del nuevo software y minimizar el riesgo implicado. El programa de estudio del ISTQB (International Software Testing Qualifications Board) Probador Certificado (Certified Tester) ofrece el mejor
entrenamiento estandarizado del mundo para los probadores de software.
Este libro le proporcionará el conocimiento esencial para ser un profesional en Pruebas, que incluye:
Fundamentos de Pruebas
Pruebas a través del Ciclo de Vida de Software
Técnicas Estáticas
Técnicas de Diseño de Pruebas
Gestión de Pruebas
Soporte de las Herramientas de Pruebas
Adquisición de Herramientas y Software en General en una Organización
Más de 200 preguntas de examen de muestra con soluciones
Ejercicios prácticos y soluciones por cada tema cubierto
Caso real, resuelto, como ejemplo a lo largo de los temas
Dos exámenes de simulación del examen real
Estándares de Pruebas
Excelente Bibliografía
Cabe señalar que este libro no es sólo para los probadores sino también para quienes están encargados de la adquisición de software en general, gerentes de tecnología, gerentes del Aseguramiento de la Calidad/Control de la Calidad (QA/QC), gerentes de sistemas, jefes de proyectos de software, analistas, arquitectos, desarrolladores, estudiantes y profesores de TI.
Asimismo este libro está diseñado para el autoestudio. El contenido comprende el programa de estudios necesario para aprobar el examen de certificación nivel básico definido por el ISTQB versión 2011 (Syllabus 2011).
Lean Inception: how to align people and build the right productPaulo Caroli
Lean inception is the effective combination of Design Thinking and Lean StartUp to decide the Minimum Viable Product (MVP). It is a collaborative workshop that will help a group of people — typically an agile team, a squad, or a product team -- understand, align and plan the building of the lean product.
Sesión 4 del curso Metodologías Ágiles de Desarrollo de Software de la Universidad de Alicante (http://www.dccia.ua.es/dccia/inf/asignaturas/MADS/2013-14)
El ciclo de vida de un proyecto se divide en cinco fases de gestión: inicio, planificación, ejecución, supervisión y cierre. Estas fases son la hoja de ruta para que tú y tu equipo superéis los proyectos más complicados.
Evolución de aplicación de prácticas ágiles dentro de grandes organizaciones de todos los tamaños, sectores de actividad, tipos de proyectos y productos. PMI Pacifico Colombia Chapter - 05-ABR-2017. Alex Canizales.
Las Pruebas de Software son todavía una de las áreas más desatendidas del desarrollo y espliegue de los productos de software. Las Pruebas de Software son predominantemente vistas como una actividad periférica, casi una formalidad, antes del espliegue del software. Un cambio de actitud y un buen programa de estudios como fundamento hacia las Pruebas de Software pueden reducir tremendamente los problemas normalmente asociados con el lanzamiento del nuevo software y minimizar el riesgo implicado. El programa de estudio del ISTQB (International Software Testing Qualifications Board) Probador Certificado (Certified Tester) ofrece el mejor
entrenamiento estandarizado del mundo para los probadores de software.
Este libro le proporcionará el conocimiento esencial para ser un profesional en Pruebas, que incluye:
Fundamentos de Pruebas
Pruebas a través del Ciclo de Vida de Software
Técnicas Estáticas
Técnicas de Diseño de Pruebas
Gestión de Pruebas
Soporte de las Herramientas de Pruebas
Adquisición de Herramientas y Software en General en una Organización
Más de 200 preguntas de examen de muestra con soluciones
Ejercicios prácticos y soluciones por cada tema cubierto
Caso real, resuelto, como ejemplo a lo largo de los temas
Dos exámenes de simulación del examen real
Estándares de Pruebas
Excelente Bibliografía
Cabe señalar que este libro no es sólo para los probadores sino también para quienes están encargados de la adquisición de software en general, gerentes de tecnología, gerentes del Aseguramiento de la Calidad/Control de la Calidad (QA/QC), gerentes de sistemas, jefes de proyectos de software, analistas, arquitectos, desarrolladores, estudiantes y profesores de TI.
Asimismo este libro está diseñado para el autoestudio. El contenido comprende el programa de estudios necesario para aprobar el examen de certificación nivel básico definido por el ISTQB versión 2011 (Syllabus 2011).
Lean Inception: how to align people and build the right productPaulo Caroli
Lean inception is the effective combination of Design Thinking and Lean StartUp to decide the Minimum Viable Product (MVP). It is a collaborative workshop that will help a group of people — typically an agile team, a squad, or a product team -- understand, align and plan the building of the lean product.
Sesión 4 del curso Metodologías Ágiles de Desarrollo de Software de la Universidad de Alicante (http://www.dccia.ua.es/dccia/inf/asignaturas/MADS/2013-14)
El ciclo de vida de un proyecto se divide en cinco fases de gestión: inicio, planificación, ejecución, supervisión y cierre. Estas fases son la hoja de ruta para que tú y tu equipo superéis los proyectos más complicados.
Sesión 3 del curso Metodologías Ágiles de Desarrollo de Software de la Universidad de Alicante (http://www.dccia.ua.es/dccia/inf/asignaturas/MADS/2013-14)
En el presente documento se describe una introducción a las metodologías ágiles, en los siguientes capítulos se detalla específicamente la metodología Scrum
Versión de la presentación "La alternativa ágil" usada en la charla del mismo nombre durante el Uniencounter de Marzo de 2011
Como novedad incorpora la parte "El profesional", y habla de orgullo, habilidades y software craftmanship :)
Desde mejorar equipos de desarrollo de software, hasta mejorar el flujo organizacional de empresas completas, en esta presentación muestro mi exploración del mundo de la mejora organizacional y cómo he ido descubriendo principios orientadores para lograrla a los largo de casi 2 décadas de trabajo
Kanban y la Transformación Organizacional - Las revoluciones pueden fracasar,...LeanSight Consulting
as organizaciones actuales están enfrentadas al literal "cambiar o morir". Sin embargo muchas de estas transformaciones fallan al diseñar grandes cambios organizacionales sin entender cuales realmente son los verdaderos problemas de productividad.
Sin importar si hay una estructura tradicional o ágil, el método Kanban ofrece una nueva mirada para hacer explicito los flujos de creación de valor, sus impedimentos, y desde ahi mejorar ágilmente.
Adoptar el marco de trabajo Scrum entrega grandes beneficios de colaboración y entrega incremental del trabajo. Sin embargo hay situaciones donde la realidad amerita una mirada más flexible. Aquí aplicar el método Kanban sobre el proceso Scrum puede ser una gran solución.
¿Cómo se entiende el modelo de madurez del método Kanban (Kanban Maturity Model) para hacer más fluido el trabajo de la organización de forma incremental?
Charla realizada para la Comunidad Kanban Argentina el 27/04/2021
En Scrum, uno de los 3 roles es el Product Owner, encargado final de definir la vision del producto en desarrollo, y de priorizar las funcionalidades de éste. Scrum tiene una forma acotada por lo definido por la Scrum Guide, y para hacer más fluido el trabajo, podemos usar el método Kanban sobre Scrum. Ahora bien, no basta con eso para asegurarnos de pasar de tomar pedidos y realmente impactar positivamente al negocio de la organización, para eso proponemos Lean Product Ownership, inspirado por el Ciclo de Deming como complemento perfecto al desarrollo guiado mediantea Kanban + Scrum. Tenemos formación y certificación disponible en http://www.academiaagil.com
¿Transformaciones con muchas células y sin impacto en el negocio? Lean y Kanb...LeanSight Consulting
Las empresas actuales están embarcadas en procesos complejos de transformación, donde se implementan células ágiles y otras innovaciones metodológicas con una gran inversión de tiempo y dinero.
Sin embargo, al menos un 70% fracasa: por ende no se logra impactar positivamente al negocio.
Haremos explícitas algunas de las causas y cómo Lean unido a Kanban sirven para lograr un mejor abordaje de los problemas a resolver, potenciado por un diseño organizacional alineado a cómo la organización crea valor.
Mucha gente se confunde cuando hablamos del Método Kanban porque creen que no pasa de ser un tablero con papelitos ("un _canvas_"). En esta charla abierta para la comunidad ágil de hispanoamérica explicamos los diversos significados de _Kanban****_ (desde Toyota, los tableros, los sistemas y el método enseñado por la Kanban University)
Como Kanban entiende las organizaciones : Los Lentes de KanbanLeanSight Consulting
Kanban no parte del supuesto de que hay que mirar el organigrama y cambiar puestos, sino de que hay que descubrir cómo fluye el valor en la organización, visualizarlo, y mejorar desde ahí paso a paso.
Presentamos un modelo creado por David Anderson, fundador de la Kanban University, explicando como podemos cambiar nuestra mirada desde la típica pirámide jerárquica a una red de servicios que colaboran para resolver necesidades de sus clientes
Infografía - Comparación entre Scrum y Extreme Programming XPLeanSight Consulting
Scrum y Extreme Programming tienen ciclos de trabajo similares y a la vez una gran diferencia entre ellos. En este diagrama se comparan ambos Frameworks a partir de los ciclos que componen sus prácticas
Flattening the Curve - Kanban and the challenge of managerial mindsetLeanSight Consulting
How do we use the common phrase "flatten the curve" to convince our applicants, who usually have more power than us, to limit their requests to the capacity of our work system?
Aplanar la curva - Kanban y el desafio del Mindset gerencialLeanSight Consulting
¿Cómo usar el lugar común de "aplanar la curva" para convencer a nuestros solicitantes, quienes usualmente tienen más poder que nosotros, a limitar sus pedidos a la capacidad de nuestro sistema de trabajo?
Video de la charla disponible en https://www.youtube.com/watch?v=M4oqmN83LaI
Índice del libro "Big Data: Tecnologías para arquitecturas Data-Centric" de 0...Telefónica
Índice del libro "Big Data: Tecnologías para arquitecturas Data-Centric" de 0xWord escrito por Ibón Reinoso ( https://mypublicinbox.com/IBhone ) con Prólogo de Chema Alonso ( https://mypublicinbox.com/ChemaAlonso ). Puedes comprarlo aquí: https://0xword.com/es/libros/233-big-data-tecnologias-para-arquitecturas-data-centric.html
Es un diagrama para La asistencia técnica o apoyo técnico es brindada por las compañías para que sus clientes puedan hacer uso de sus productos o servicios de la manera en que fueron puestos a la venta.
(PROYECTO) Límites entre el Arte, los Medios de Comunicación y la Informáticavazquezgarciajesusma
En este proyecto de investigación nos adentraremos en el fascinante mundo de la intersección entre el arte y los medios de comunicación en el campo de la informática.
La rápida evolución de la tecnología ha llevado a una fusión cada vez más estrecha entre el arte y los medios digitales, generando nuevas formas de expresión y comunicación.
Continuando con el desarrollo de nuestro proyecto haremos uso del método inductivo porque organizamos nuestra investigación a la particular a lo general. El diseño metodológico del trabajo es no experimental y transversal ya que no existe manipulación deliberada de las variables ni de la situación, si no que se observa los fundamental y como se dan en su contestó natural para después analizarlos.
El diseño es transversal porque los datos se recolectan en un solo momento y su propósito es describir variables y analizar su interrelación, solo se desea saber la incidencia y el valor de uno o más variables, el diseño será descriptivo porque se requiere establecer relación entre dos o más de estás.
Mediante una encuesta recopilamos la información de este proyecto los alumnos tengan conocimiento de la evolución del arte y los medios de comunicación en la información y su importancia para la institución.
Actualmente, y debido al desarrollo tecnológico de campos como la informática y la electrónica, la mayoría de las bases de datos están en formato digital, siendo este un componente electrónico, por tanto se ha desarrollado y se ofrece un amplio rango de soluciones al problema del almacenamiento de datos.
(PROYECTO) Límites entre el Arte, los Medios de Comunicación y la Informáticavazquezgarciajesusma
En este proyecto de investigación nos adentraremos en el fascinante mundo de la intersección entre el arte y los medios de comunicación en el campo de la informática.
La rápida evolución de la tecnología ha llevado a una fusión cada vez más estrecha entre el arte y los medios digitales, generando nuevas formas de expresión y comunicación.
Continuando con el desarrollo de nuestro proyecto haremos uso del método inductivo porque organizamos nuestra investigación a la particular a lo general. El diseño metodológico del trabajo es no experimental y transversal ya que no existe manipulación deliberada de las variables ni de la situación, si no que se observa los fundamental y como se dan en su contestó natural para después analizarlos.
El diseño es transversal porque los datos se recolectan en un solo momento y su propósito es describir variables y analizar su interrelación, solo se desea saber la incidencia y el valor de uno o más variables, el diseño será descriptivo porque se requiere establecer relación entre dos o más de estás.
Mediante una encuesta recopilamos la información de este proyecto los alumnos tengan conocimiento de la evolución del arte y los medios de comunicación en la información y su importancia para la institución.
Inteligencia Artificial y Ciberseguridad.pdfEmilio Casbas
Recopilación de los puntos más interesantes de diversas presentaciones, desde los visionarios conceptos de Alan Turing, pasando por la paradoja de Hans Moravec y la descripcion de Singularidad de Max Tegmark, hasta los innovadores avances de ChatGPT, y de cómo la IA está transformando la seguridad digital y protegiendo nuestras vidas.
Qué metodología será más adecuada para mi proyecto software
1. ¿Qué metodología será
más adecuada para mi
proyecto software?
miércoles, 01 de agosto de 2012
@agustinvillena
2. Agustín Villena
• Emprendedor desde 1998
• Aplicando agilidad desde 2002 en
–
–
–
–
–
Desarrollo de Software
Industria de la Creatividad
Sector Público
Sociedad Civil
Academia
@agustinvillena
3. ¿Quieres saber más?
• Desafio Kanban, tu primer paso a la gestión ágil
– http://leansight.com/desafio-kanban
• Síguenos en twitter
– @leansight
– @agustinvillena
• Únete a la conversación
– http://grupo.chileagil.cl
• Comparte tus dudas en la más completa base en español sobre agilidad
– http://failfast.chileagil.cl
@agustinvillena
5. • Muchos han tratado de encontrarlo
• Dicen que se encuentra en Lejano Oriente: Cathay,
India
@agustinvillena
6. Fabricas de Software
el Santo Grial de desarrollo de Software
• Efecto de producción masiva y economía de escala
• Mano de obra barata
– Modelo programático simplificado
– Herramientas de modelado, CASE, visual
• Especialización
– Análisis, Diseño, Implementación, Testing etc.
@agustinvillena
11. El polo “caótico” del
desarrollo de software
¿Mejor que la Software Factory?
@agustinvillena
12. Soy tellible de guen programador
•
•
•
•
•
•
“Echandole pa’ adelante” programming
No documento nada
Lo pruebo yo solito
Arreglo las cosas directo en producción
En el camino arreglamos la carga
Mi codigo es MIO
@agustinvillena
14. Porqué es difícil desarrollar software
Los planos (ideales) de un proyecto
Plano de Negocio
Valor
Problema
(Necesidad)
(meta)
Lenguaje de Negocio
Lenguaje
Común
Base
Para
qué
Funcionalidades
(Soluciones)
Qué
(producto)
Lenguaje Técnico
Calidad
TAREAS
Cómo
(tarea,
actividad)
Plano Técnico
@agustinvillena
Ámbito
de la
Gestión
15. Entorno de un proyecto de Software
Cliente
Problema de Negocio
Proyecto de
Software
Ingeniero
de Software
Producto de
Software
Equipo de
Desarrollo
Tecnología
@agustinvillena
16. Desarrollo de Producto Tradicional
Medida de Progreso: Avance a la siguiente Etapa
Waterfall
Requerimientos
Especificación
Problema:conocido
Solución:conocida
Diseño
Implementación
Verificación
Mantención
Fuente:
Eric Ries - Lean Startups Doing More with Less
http://assets.en.oreilly.com/1/event/30/Lean%20Startups_%20Doing%20More%20with%20Less%20Presentation.pptx
@agustinvillena
17. Waterfall
• MANAGING THE DEVELOPMENT OF LARGE SOFTWARE
SYSTEMS
• Winston W. Royce, Proceedings, IEEE WESCON, August 1970,
pages 1-9.
@agustinvillena
18. Waterfall
• MANAGING THE DEVELOPMENT OF LARGE SOFTWARE
SYSTEMS
• Winston W. Royce, Proceedings, IEEE WESCON, August 1970,
pages 1-9.
STEP 2: DOCUMENT THE DESIGN
At this point it is appropriate to raise the issue of - "how much documentation?"
My own view is "quite a lot;" certainly more than most programmers, analysts,
or program designers are willing to do if left to their own devices. The first rule
of managing software development is ruthless enforcement of documentation
requirements.
@agustinvillena
19. Waterfall
• MANAGING THE DEVELOPMENT OF LARGE SOFTWARE
SYSTEMS
• Winston W. Royce, Proceedings, IEEE WESCON, August 1970,
pages 1-9.
STEP 3: DO IT TWICE
After documentation, the second most important criterion for success revolves
around whether the product is totally original. If the computer program in
question is being developed for the first time, arrange matters so that the
version finally delivered to the customer for operational deployment is actually
the second version insofar as critical design/operations areas are concerned.
@agustinvillena
20. Epígrafe
Uno no se baña nunca dos veces
en el mismo río
Heráclito
@agustinvillena
21. ¿A qué se parece más el
desarrollo de software?
versus
@agustinvillena
22. Matriz de Complejidad de Stacey
Las dimensiones de la incertidumbre/riesgo
• La complejidad/riesgo de un
proyecto se puede ubicar a partir
de dos dimensiones de
incertidumbre: el grado de
certeza y el grado de acuerdo
• Para bajar la complejidad:
Poca certeza
=>
Realizar
experimentos
pequeños
Poco acuerdo
=>
Negociar
@agustinvillena
23. El sesgo técnico ante el valor
• “A classic engineering
mistake and one I've made
is confusing what is hard
and what is valuable”
– Max Levchin at StartUp
School 2011
@agustinvillena
24. Paradigmas sobre el Costo de los
Cambios
a medida que avanza el proyecto
Visión Tradicional
Sólo aplica a cambios
arquitectónicos
Costo
Visión Ágil
Mayoría de cambios pueden
tener este impacto
Tiempo
@agustinvillena
25. Manifiesto Ágil
(2001)
• En 2001, Kent Beck y otros autores de enfoques similares proponen
los Principios Ágiles:
Individuos e interacciones
Software funcional
Colaboración con el cliente
Procesos y herramientas.
por
sobre
Responder al cambio
@agustinvillena
Documentación exhaustiva
Negociación de contratos
Seguir un plan
26. 12 Principios Ágiles
Nuestra mayor prioridad es
satisfacer al cliente
mediante la entrega temprana y
continua de software
con valor.
Los proyectos se desarrollan en
torno a individuos
motivados. Hay que darles el
entorno y el apoyo que
necesitan, y confiarles la ejecución
del trabajo.
La atención continua a la excelencia
técnica y al
buen diseño mejora la Agilidad.
Aceptamos que los requisitos
cambien, incluso en etapas
tardías del desarrollo. Los procesos
Ágiles aprovechan
el cambio para proporcionar ventaja
competitiva al
cliente.
El método más eficiente y efectivo
de comunicar
información al equipo de desarrollo
y entre sus
miembros es la conversación cara a
cara.
La sencillez, o el arte de maximizar
la cantidad de
trabajo no realizado, es esencial.
@agustinvillena
Entregamos software funcional
frecuentemente, entre dos
semanas y dos meses, con
preferencia al periodo de
tiempo más corto posible.
Los responsables de negocio y los
desarrolladores
trabajamos juntos de forma
cotidiana durante todo
el proyecto.
El software funcionando es la
medida principal de
progreso.
Los procesos Ágiles promueven el
desarrollo
sostenible. Los promotores,
desarrolladores y usuarios
debemos ser capaces de mantener
un ritmo constante
de forma indefinida.
Las mejores arquitecturas,
requisitos y diseños
emergen de equipos autoorganizados.
A intervalos regulares el equipo
reflexiona sobre
cómo ser más efectivo para a
continuación ajustar y
perfeccionar su comportamiento en
consecuencia.
27. Armonización ágil del entorno de
desarrollo
Ciclo de Gestión del Proyecto Orientada al Valor
Cliente
Problema de Negocio
Proyecto de
Software
Ciclo de Gestión del Desarrollo en Equipo
Ingeniero
de Software
Ciclo de
Programación
de calidad
Producto de
Software
Equipo de
Desarrollo
Tecnología
XP lo organiza en ciclos de retroalimentación y
aprendizaje acelerado
Entorno de un
proyecto de software
@agustinvillena
28. Desarrollo Ágil de Productos
Medida de Progreso: Funcionalidad Validada por el Cliente
“Product Owner” or cliente in situ
Problema:conocido
Solución:desconocida
Fuente:
Eric Ries - Lean Startups Doing More with Less
http://assets.en.oreilly.com/1/event/30/Lean%20Startups_%20Doing%20More%20with%20Less%20Presentation.pptx
@agustinvillena
29. Scrum
(1996)
• Inspirado en el enfoque de gestión de la innovación de productos de
Hirotaka Takeuchi and Ikujiro Nonaka, 1986
• Sutherland and Schwaber , lo presentan en OOPSLA (1995)
• Define un conjunto de herramientas de gestión y visualización de
avance
• Metáfora:
– se requiere abarcar todas las disciplinas requeridas, tal como la formación de
scrum del rugby
• Es una metodología para gestionar desarrollos de productos
– ¡Cualquier tipo de producto!
@agustinvillena
30. Agile
Framework
Value Oriented
Management Cycle
Scrum
Product
Owner Role
Release
Planning
Meeting
Product
Backlog
Development
Sprint Planning Meeting
Teamwork Management Cycle
Potencially
Shippable
Release
Tasks
Scrum Master Role
Burn down Charts
Task Board
Daily Scrum Meeting
Sprint Retrospective Meeting
Scrum Scoreboard
@agustinvillena
avillena@dcc.uchile.cl
31. eXtreme Programming
(1998)
•
•
•
•
Kent Beck, 1999, “Extreme Programming Explained”
Enfoque empírico e integral de un proyecto de software
Equipos pequeños que incluyen al cliente
Premisa
– Llevar las buenas prácticas de desarrollo al extremo
@agustinvillena
32. Small
Releases
eXtreme
Programming
Agile
Framework
Value Oriented
Management Cycle
Planning Game
On Site
Customer
(One team)
User Stories
Definition
Acceptance Tests
Validation
Development
Iteration Planning
Tracking /
Informative Workspace
Stand Up Meeting
No Overtime
Pair Programming
(+ Move people
around)
Code Standards
Collective Code
Ownership
@agustinvillena
Quality Oriented
Incremental Development
Cycle
Coaching
Team Development
Teamwork Management Cycle
Tasks
Simple
Design
Test Driven
Development
Continuous
Integration
Refactoring
avillena@dcc.uchile.cl
33. Software Craftmanship
http://manifesto.softwarecraftsmanship.org/
• Manifiesto sale a la luz Marzo de 2009
• Busca devolver la excelencia técnica al rango de pilar del
movimiento ágil
Individuos e interacciones
Una comunidad de
profesionales
Software funcional
Software bien hecho
No sólo
Colaboración con el cliente
Responder al cambio
@agustinvillena
sino
que
Sociedades productivas
Constantemente agregar valor
34. Desarrollo versus Operaciones
Desarrollo
• Desarrollo
aporta valor
mediante
nuevas
funcionalidades
Conflicto
Nuevas
funcionalidades
implican riesgos
@agustinvillena
Operación
Operaciones
aporta valor
mediante
sistemas estables
y rendimiento de
éstos.
35. Pero el cambio es inevitable…
• Operaciones: cómo convivir con el cambio
manteniendo el riesgo bajo?
– Agilidad!
• Todos los involucrados en el nuevo sistema deben
trabajar juntos
• Migrar según metas pequeñas, usando
mecanismos de fácil restauración
– Ej: Máquinas virtuales con puntos de restauración
@agustinvillena
36. La solución: DevOps
Área 3:
Incorporar conocimiento de
proyectos en Operaciones
Área 1:
Extender entrega hasta
producción
Área 2:
Extender retroalimentación de
operaciones hasta el proyecto
Área 4:
Incorporar conocimiento de
Operacione en los proyectos
@agustinvillena
38. ¿Innovación Exitosa?
• No existen empresas innovadoras exitosas, sino
productos innovadores exitosos
– Que viven en un Océano Azul
• Ejemplo: Apple
Newton :
Fracaso
@agustinvillena
iPod:
Éxito
39. ¿Deseas resolver problemas imposibles?
¡Encuentra la forma de fallar más rápido!
• 1959:
– Premio de MMUS$ 1,3 al primer avión propulsado
por fuerza humana
• 1969: aun sin ganadores
– Paul MacCready miró el problema y observó:
• «Demoran 1 año en construir el avión, y 1 día en ponerlo
a prueba»
– Solución:
• avión fácilmente re construible
• 1 prueba por día
– Resultado:
• falló muchas veces, pero ganó el premio en poco tiempo
@agustinvillena
40. Qué dicen los líderes del
emprendimiento
• Steve Blank
– Check your hypotheses
– Get out of the building!
– Good engineers
understand their customers!
• Eric Ries
– Stop wasting people’s time!
@agustinvillena
41. Desarrollo de Producto en una Innovación Ágil
Medidad de Progreso: Aprendizaje Validado acerca de los Clientes ($$$)
Desarrollo de Cliente
desconocido
Problema:
Hipótesis,
Experimentos,
Revelaciones
Datos,
Retroalimentación,
Revelaciones
Solución:
desconocida
Fuente:
Eric Ries - Lean Startups Doing More with Less
http://assets.en.oreilly.com/1/event/30/Lean%20Startups_%20Doing%20More%20with%20Less%20Presentation.pptx
@agustinvillena
44. En las profesiones del conocimiento el
valor generado es invisible…
• entonces los profesionales serán permanentemente
interrumpidos
• Y sobrecargados
@agustinvillena
46. Gestión Tradicional
Push Scheduling
Work Items
Stage 1
Queue
In
Process
Stage 2
Queue
…
In
Process
Queue
…
Fuente:
Lean & kanban 101
http://availagility.wordpress.com/2009/06/11/zurich-lean-agile-scrum-slides/
@agustinvillena
Stage n
In
Process
Done
48. Si generamos un modelo
compartido de nuestro trabajo…
Equipo
Líder
ó Cliente
@agustinvillena
49. Pull Scheduling
Para de comenzar… ¡Comienza a terminar!
•
Vamos realizando la tarea correcta en el momento justo en que tenemos capacidad
Work Items
Stage 1
Queue
In
Process
Stage 2
Queue
…
In
Process
Queue
…
Fuente:
Lean & kanban 101
http://availagility.wordpress.com/2009/06/11/zurich-lean-agile-scrum-slides/
@agustinvillena
Stage n
In
Process
Done
50. Historia del Kanban
Aplicado al Desarrollo de Software
• David J. Anderson lo aplica por primera vez el 2004 en Microsoft
@agustinvillena
51. Partiendo con Kanban
1. Parte con la forma en que trabajas
ahora
–
Inicialmente, respeta los roles actuales, las
responsabilidades y los títulos de los puestos
de trabajo.
2. Acordar el buscar una mejora
incremental y evolutiva
@agustinvillena
52. 1.
2.
3.
4.
5.
Visualizar el Flujo de Trabajo
Limitar el Trabajo-en-Progreso
Medir y Administrar el Flujo
Explicitar las Políticas del Proceso
Mejorar Colaborativamente
–
Usando modelos y método científico
@agustinvillena
Profundidad
Niveles de profundidad en Kanban
58. Resumen
Extreme
Programming
Scrum
Lean Startup
Kanban
Qué es
Framework de Valores, Principios y Prácticas para desarrollo de
nuevo producto
Evolución
Funcionalidades
Funcionalidades y
Código
Modelo de Negocio,
Funacionalidades y
Código
Flujo de valor
(proceso)
Clientes
Único
Único
Por dscubrir
Múltiples
Cambio
Organizacional
Big Change Upfront
@agustinvillena
Meta-proceso de
gestión del cambio
Evolutivo