El desarrollo de software ya no es lo mismo que años atrás, un ejemplo podría ser el desarrollo de software antes tenia un soporte grande en Hardware y era costoso comprarlo, eso costos ahora han bajado y dejaron de serlo.
3. Christian Paolo Vera Livia
AGENDA
• METODOS PARA EL DESARROLLO DE SOFTWARE.
• Caracteristicas principales ADAPTACIÒN A LOS CAMBIOS
• OPUESTOS A LOS METODOS TRADICIONALES (Predicitvos)
• Definen al Inicio .
• Alcance (Funcionalidad, Tecnologia)
• Costo
• Tiempo
• Establecen metodos de Monitoreo y Control
• Para prevenir desvios
20 Min
4. Proyecto de Desarrollo de Software
¿Para que un método de Gestión ?
PROBLEMA Intangibilidad del Software
¿De que color es algo que no podemos ver?
SOLUCIÓN
Método ÁgilMétodo Tradicional
5.
6. Desarrollo Agil : Manifesto
Propósito :
Estamos descubriendo mejores formas de desarrollar software haciéndolo y
ayudando a que otros lo hagan.
A través de este trabajo hemos llegado a valorar:
Esto quiere decir : Aunque valoramos los elementos de la
derecha, valoramos más los elementos de la izquierda.
http://agilemanifesto.org/iso/es/manifesto.html
7.
8. SCRUM
ROLES
• Scrum Master
• Dueño de Producto
• Equipo
ARTEFACTOS
• Backlog de Producto
• Backlog de Sprint
• Incremento de Producto
CEREMONIAS
• Planificación
• Reunión diaria
• Revisión
• Retrospectiva
9. LEAN KANBAN
El concepto de Lean optimiza el sistema de una organización para producir resultados
valiosos sobre la base de sus recursos, necesidades y alternativas, mientras reduce las
perdidas.
Las perdidas, por ejemplo, podrían ser la construcción incorrecta de un producto, el no
saber aprender, o las prácticas que impiden el proceso. Debido a que estos factores son
de naturaleza dinámica, una organización ágil evalúa la totalidad de su sistema y
continuamente hace ajustes de sus procesos.
Tres Reglas
• Mostrar el proceso tablero
• Limitar el trabajo en curso (WIP Work In Progress)
• Optimizar el flujo de trabajo
Es de origen Japonés es ideada por Toyota en productos tangibles , y quiere decir capacidad de
comprometerse al trabajo si solamente se tiene la posibilidad de hacerlo.
10. Extreme Programming (XP)
XP hace que sea posible mantener el costo de cambiar el software sin que éste aumente
radicalmente con el tiempo. Los atributos claves de XP incluyen el desarrollo gradual,
horarios flexibles, pruebas automatizadas de código, la comunicación verbal, el diseño en
constante evolución, Colaboración cercana y la vinculación de las unidades, de largo como
de corto plazo, de todos los involucrados
Valores
• Comunicación
• Simplicidad
• Retroalimentación
• Respeto
• Coraje
Hacer modificaciones a un software pero por detrás , modificar el código fuente sin alterar el
funcionamiento externo
Practicas
1. Cliente InSitu
2. Metáfora
3. Refactoring
4. Entregas cortas
5. TDD
6. Semana de 40 Horas
7. KISS
8. Propiedad Colectiva
9. Código Estándar
10. Programación de a pares
11. Integración Continua
12. Juego de planificación
11. Métodos Crystal
La intención de los métodos Crystal es centrarse en las personas; ser ligeros y fáciles de
adaptar. Debido a que las personas son primordiales, en el proceso de desarrollo y las
herramientas no son fijas, sino que se ajustan a los requerimientos y características
especificas del proyecto.
Se utiliza colores para decidir sobre la variante de un proyecto.
La familia Crystal se divide en:
• Crystal Clear (claro como el cristal - Para equipos de hasta 8 personas o menos.)
• Crystal Yellow (cristal amarillo - Entre 10 y 20 personas. ).
• Crystal Orange (cristal naranja - Equipos entre 20 y 50 personas.).
• Crystal Orange Web (cristal naranja web).
• Crystal Red (cristal rojo - Entre 50 y 100 personas.).
• Crystal Maroon (cristal marrón).
• Crystal Diamond (cristal diamante).
• Crystal Sapphire (cristal zafiro).
Metodologías Crystal tiene como característica dos dimensiones, tamaño y criticidad.
12. Métodos Crystal
Las 7 propiedades de las metodologías Crystal
1. Entregas frecuentes, en base a un ciclo de vida iterativo e incremental.
2. Mejora reflexiva. Que viene a ser mejora continua. Las iteraciones ayudan a ir
ajustando el proyecto, a ir mejorándolo.
3. Comunicación osmótica.
4. Seguridad personal.
5. Enfoque.
6. Fácil acceso a usuarios expertos.
7. Entorno técnico con pruebas automatizadas, gestión de la configuración e integración
continua.
13. Dynamic Systems Development Methods (DSDM)
DSDM establece la calidad y el esfuerzo en términos de costo y el tiempo desde el principio y ajusta los
entregables del proyecto para cumplir con los criterios establecidos, dando prioridad a las prestaciones
en las siguientes categorías: lo que "deben tener", "deberían tener", "podrían tener", y "no tendrán"
(mediante la técnica MoSCoW Prioritization).
Principios del DSDM
• Involucrar al cliente es la clave para llevar un proyecto
eficiente y efectivo.
• El equipo del proyecto debe tener el poder para tomar
decisiones que son importantes.
• DSDM se centra en la entrega frecuente de productos.
• El desarrollo es iterativo e incremental.
• Todos los cambios durante el desarrollo son reversibles.
• Las pruebas son realizadas durante todo el ciclo vital del
proyecto.
• La comunicación y cooperación entre todas las partes
interesadas .
Requisitos previos para el uso de DSDM:
• Interactividad, los usuarios y los jefes de Desarrollo.
• Motivación y participación entre las partes (humanas)
que integran el equipo.
• Intercambio de ideas o funcionalidades necesarias .
Fases :
• Pre-proyecto
• Viabilidad
• Fundamentos
• Exploración e Ingeniería.
• Despliegue
• Evaluación de Beneficios.
14. Feature Driven Development (FDD)
Opera bajo el principio de la realización de un proyecto donde éste se separa en pequeñas funciones
valoradas por el cliente que pueden ser entregadas en menos de dos semanas. FDD tiene dos
5 Procesos:
• Desarrollar el modelo global (Develop overall model),
• Construir una lista de características (Build feature list),
• Planificar (Plan by feature),
• Diseñar (Design by feature)
• Construir (Build by feature).
Principios
• El desarrollo de software es una
actividad humana
• El desarrollo de software es una
funcionalidad valorada por el cliente..
6 Roles principales
• Administrador de Proyecto
• Arquitecto Jefe
• Jefe de Desarrollo
• Programadores Jefe
• Dueños de clases (Trabajan bajo la guía del programador jefe en
diseño, codificación, prueba y documentación)
• Expertos en el dominio(Cliente, patrocinador , analista de negocios)
FDD es un método de desarrollo de ciclos cortos que se concentra en la fase de diseño y construcción. En la primera fase, el
modelo global de dominio es elaborado por expertos del dominio y desarrolladores; el modelo de dominio consiste en
diagramas de clases con clases, relaciones, métodos y atributos. Los métodos no reflejan conveniencias de programación
sino rasgos funcionales.
15. Test Driven Development (TDD)
Test Driven Development es un método de desarrollo de
software que consiste en escribir primero un código de
prueba automatizado y el desarrollo con la menor
cantidad de código necesarios para luego pasar la prueba.
El proyecto se divide en características pequeñas de valor
para el cliente que deben ser desarrolladas en el ciclo de
desarrollo más corto posible.
Las pruebas se escriben basadas en los requisitos y
especificaciones de los clientes.
Esto tiene unas implicaciones técnicas:
Diseñar el código según escribimos nuestros tests:
debemos encontrar un balance entre el diseño de UMLs y
la realización de tests para que nos orienten por donde
tenemos que ir.
El entorno de desarrollo tiene que ser capaz de decirnos
rápidamente el estado de nuestro código en todo
momento (debe ser rápido o sino se deja de hacer
pruebas, por lo que hay que diseñarlos para q sean lo más
rápido posibles)
TDD se puede clasificar en dos niveles:
Acceptance TDD (ATDD) que requiere
una prueba de aceptación
específica y Developer TDD (DTDD) que
tiene que ver con escribir sólo una
prueba de desarrollador.
· Diseñar componentes altamente cohesivos y muy poco acoplados para conseguir probarlos fácilmente.s en la fase
precedente se utilizan para diseñar y escribir el código de producción.
Principios
• Escribir nuevo código si tenemos
primero un test que falla.
• Eliminar duplicación (conseguir un
código lo más "bonito" posible)
16. Adaptive Software Development (ASD)
Significa Desarrollo Adaptable de Software es un
modelo de implementación de patrones ágiles para
desarrollo de software. Al igual que otras
metodologías ágiles, su funcionamiento es cíclico y
reconoce que en cada iteración se producirán cambios
e incluso errores.
El desarrollo de software adaptable (Adaptive
Software Development - ASD) es una metodología de
desarrollo que hace énfasis en aplicar las ideas que se
originaron en el mundo de los sistemas complejos,
adaptación continua del proceso al trabajo.
CICLO DE VIDA
Especular : Una primera fase de iniciación para establecer los principales objetivos y metas del proyecto en su
conjunto y comprender las limitaciones (zonas de riesgo) con las que operará el proyecto.
Colaborar : Es la fase donde se centra la mayor parte del desarrollo manteniendo una componente cíclica. Un
trabajo importante es la coordinación que asegure que lo aprendido por un equipo se transmite al resto y no
tenga que volver a ser aprendido por los otros equipos.
Aprender : La última etapa termina con una serie de ciclos de colaboración, su trabajo consiste en capturar lo
que se ha aprendido, tanto positivo como negativo. Es un elemento crítico para la eficacia de los equipos.
CARACTERISITICAS
Sus principales características del ASD son:
• Iterativo.
• Orientado a los componentes de
software (la funcionalidad que el
producto va a tener, características, etc.)
más que a las tareas en las que se va a
alcanzar dicho objetivo.
• Tolerante a los cambios.
• Guiado por los riesgos
• La revisión de los componentes sirve
para aprender de los errores y volver a
iniciar el ciclo de desarrollo
17. Agile Unified Process (AUP)
El Proceso Unificado Agil es una versión simplificada del Proceso Unificado de Rational (RUP). Este describe
de una manera simple y fácil de entender la forma de desarrollar aplicaciones de software de negocio usando
técnicas ágiles y conceptos que aún se mantienen válidos en RUP.
El AUP aplica técnicas ágiles incluyendo Desarrollo Dirigido por Pruebas (test driven development - TDD),
Modelado Agil, Gestión de Cambios Agil, y Refactorización de Base de Datos para mejorar la productividad.
El proceso unificado (Unified Process o UP) es un marco de desarrollo software iterativo e incremental.
A menudo es considerado como un proceso altamente ceremonioso porque especifica muchas actividades y
artefactos involucrados en el desarrollo de un proyecto software. Dado que es un marco de procesos, puede
ser adaptado y la más conocida es RUP (Rational Unified Process) de IBM.
AUP se preocupa especialmente de la gestión de riesgos. Propone que aquellos elementos con alto riesgo
obtengan prioridad en el proceso de desarrollo y sean abordados en etapas tempranas del mismo. Para ello,
se crean y mantienen listas identificando los riesgos desde etapas iníciales del proyecto. Especialmente
relevante en este sentido es el desarrollo de prototipos ejecutables durante la base de elaboración del
producto, donde se demuestre la validez de la arquitectura para los requisitos clave del producto y que
determinan los riesgos técnicos.
El proceso AUP establece un Modelo más simple que el que aparece en RUP por lo que reúne en una única
disciplina las disciplinas de Modelado de Negocio, Requisitos y Análisis y Diseño. El resto de disciplinas
(Implementación, Pruebas, Despliegue, Gestión de Configuración, Gestión y Entorno) coinciden con las
restantes de RUP.
18. Domain-Driven Design (DDD)
Fue concebido por Eric Evans en el año
2004 y gira en torno al diseño de un dominio básico.
"Dominio" se define como un área de actividad a la
que el usuario aplica un programa o funcionalidad.
Muchas de estas áreas se procesan por lotes y un
modelo es diseñado. El modelo consiste en un sistema
de abstracciones que se pueden utilizar para diseñar el
proyecto general y resolver los problemas
relacionados con los dominios loteados. Los valores
centrales de
Lenguaje Ubicuo. El usuario puede decir: “quiero
convertir a un prospecto en cliente cuando se cierre
una venta”. Esa petición así planteada es tan vaga que
el programador no puede hacer nada práctico con ella.
Pero es el punto de partida para definir con precisión
lo que es un prospecto, lo que es un cliente y cuándo y
cómo se convierte uno en el otro. DDD pone mucho
énfasis en que los programadores aprendan e
implementen el Lenguaje Ubícuo con las definiciones y
terminología exactamante como las usa el cliente.
Cada Contexto Acotado puede tener su propio
Lenguaje Ubícuo, o, dicho de otra forma, la misma
cosa (o muy parecida) se puede llamar de manera
diferente en un contexto que en otro.
La calidad de los modelos con los cuales construimos software tiene un impacto directo en los resultados
obtenidos, en la comunicación con los expertos del dominio y en la simpleza de mantenimiento.
La técnica DDD ha tomado nueva relevancia últimamente por la compatibilidad entre el concepto de
microservicios, relacionado con la arquitectura de software.
DDD no consiste solo en patrones y arquitecturas recomendadas.
DDD es una forma de afrontar los proyectos, forma de trabajar el equipo de desarrollo y su relación
directa con los expertos del dominio mediante el ‘lenguaje ubicuo’. Esta forma de trabajar y diseñar,
fundamental para el ciclo de vida de una aplicación
1.- Un Jefe de Proyectos debe Tener un bolita de cristal para saber lo que va a suceder en el futuro.(Predecir)
2.- En los proyectos tradicionales , No se llegan a las expectativas del cliente , ya que el resultado no era lo que se necesita , y el valor que este entrega(Costo, tiempo, alcancé).
3.- No se puede incluir un control de cambio, ya que no es flexible.
El desarrollo de software ya no es lo mismo que años atrás, un ejemplo podría ser el desarrollo de software
Antes tenia un soporte grande en Hardware y era costoso comprar el hardware, eso costos ahora han bajado y dejaron de ser costoso.
Hay proyectos que no se tienen ni idea cuanto tiempo van a durar , en los proyectos al inicio hay mucha incertidumbre , ejemplo , el cliente no sabe lo que quiere , puede cambiar el güiro de negocio o una nueva reglamento regulatorio, esto se vas disminuyendo cada vez que los proyectos vas avanzado, ya que cada vez tienes mas luces de cuanto el proyecto puede durar.
Todo esto hacer que se creen las metodologías agiles.
Metodo Tradicional : Busqueda de un acuerdo inmutable , previamente negociadoMetodo Agil : iterativo adaptable a cambios,
Scrum es un proceso de desarrollo de software iterativo y creciente utilizado comúnmente en entornos basados en el desarrollo ágil de software.
Aunque Scrum estaba enfocado a la gestión de procesos de desarrollo de software, puede ser utilizado en equipos de mantenimiento de software, o en una aproximación de gestión de programas.
O
Scrum es un framework de desarrollo ágil de software. El trabajo es estructurado en ciclos de trabajo llamados sprintes, iteraciones de trabajo con una duración típica de dos a cuatro semanas. Durante cada sprint, los equipos eligen de una lista de requerimientos de cliente priorizados, llamados historias de usuarios, para que las características que sean desarrolladas primero sean las de mayor valor para el cliente. Al final de cada sprint, se entrega un producto potencialmente lanzable / distribuible / comerciable.
Mi definición de Scrum
En lo personal, creo que para trabajar con Scrum, hay que entender la filosofía. Implementar Scrum implica un cambio de la forma de pensar en la organización de una empresa o equipo de trabajo. Scrum, entre otros principios, abraza la filosofía Kaizen, de mejoramiento contínuo, así como se basa también en los principios de la metodología Lean, y otras tantas herramientas que iré viendo en este blog.
En esta página iré aumentando de forma orgánica mi definición propia de lo que significa Scrum para mí y mi entorno de trabajo. Por eso, creo que esta página cambiará constantemente a medida que obtenga experiencai y vaya obteniendo distintos puntos de vista y enriqueciéndome a partir de los conocimientos de otros.
Una de las frases que recuerdo del curso CSM: “En Scrum, no tenemos el librito”. También me he quedado con una frase que Tobias Mayer publicó en Twitter hace un tiempo, y me parece una definición bastante acertada de lo que significa Scrum: Scrum es un framework basado en valores; no es una metodología, ni un proceso, ni una herramienta.
El fundamento de Lean es que la reducción de la longitud de cada ciclo (es decir, una iteración) conduce a un aumento de productividad mediante la reducción de los retrasos, ayuda en la detección de errores en una etapa temprana, y por consecuencia reduce la cantidad total de esfuerzo requerido para terminar una tarea. Los principios de software Lean se han aplicado con éxito en el desarrollo de software.
-Mostrar el procesos son los tableros físicos y se dividen en columnas y no tiene mucha resistencia al cambio, la primera columna es cola de espera y solo ingresan si hay un limite disponible
-Máximo de ítem en cada proceso( limitantes este en el WIP)
- El flujo de trabajo es la velocidad de los procesos , todos las personas al mismo tiempo solapados , cuellos de botellas cuando no tienen que hacer nada , los profesionales pueden ayudar al resto pueden hacer otras cosas del proyecto, y mejoran el proceso , kanban no realiza iteraciones cada determinado tiempo solo limita la cantidad trabajo al mismo tiempo
Extreme Programming (XP), que se originó en Chrysler Corporation, ganó fuerza en la década de 1990.
XP valora la comunicación, la retroalimentación, la simplicidad y el correr riesgos. Los diferentes roles en el
enfoque XP incluyen al customer, desarrolladore, rastreador y entrenador. Prescribe varias prácticas de
negocios, codificación y desarrollo, así como eventos y artefactos para lograr un desarrollo eficaz y
eficiente. XP ha sido adoptado ampliamente debido a sus prácticas de ingeniería bien definidas.
Explicación :
Propone 12 practicas técnicas , todas al mismo tiempo , se recomienda mesclarla con Scrum
De las 12 practicas técnicas las mas complicadas de agregar al proceso en un equipo de desarrollo son :
-Refactoring : técnica de programación que consiste en hacer modificaciones a un software pero por detrás , modificar el código fuente sin alterar el funcionamiento externo , limpieza de código , el usuario que usa el software no nota cambios
-Desarrollo guiado por pruebas , tiene mayor resistencia de los programadores , es la realización de test , primero no programas solo realizas el test,
-Código estandars, usar los estándares de la industria o estilos de las funciones, Mayúsculas y minúsculas ejemplo las pep8 de python
Las 7 propiedades de las metodologías Crystal
Las metodologías Crystal cumplen todas ellas con 7 propiedades esenciales, las siguientes:
1 – Entregas frecuentes, en base a un ciclo de vida iterativo e incremental. En función del proyecto puede haber desde entregas semanales hasta trimestrales. Para los que conozcan Scrum: en Scrum las entregas son, máximo, cada 4 semanas, en las Crystal se contemplan muchas más opciones.
2 – Mejora reflexiva. Que viene a ser mejora continua. Las iteraciones ayudan a ir ajustando el proyecto, a ir mejorándolo.
3 – Comunicación osmótica. Traducido al castellano, que el equipo esté en una misma ubicación física, para lograr la comunicación cara a cara.
4 – Seguridad personal. Todo el mundo puede expresar su opinión sin miedos, teniéndosele en cuenta, considerándose su opinión, etc.
5- Enfoque. Períodos de no interrupción al equipo (2h horas), objetivos y prioridades claros, definiendo así tareas concretas. Si llevas desde hace tiempo pasando por este blog, recordarás ya comentábamos, tiempo a, aquello de que el entorno físico afecta al rendimiento del desarrollador software (te dejo aquel post).
6 – Fácil acceso a usuarios expertos. Las Crystal (a diferencia de otras como XP) no exigen que los usuarios estén continuamente junto al equipo de proyecto (no todas las organizaciones pueden hacerlo), sí que, como mínimo, semanalmente debe haber reuniones y los usuarios deben estar accesibles.
7 – Entorno técnico con pruebas automatizadas, gestión de la configuración e integración continua. Prácticas comunes en casi todas las metodologías ágiles, te dejo un post sobre la integración continua y el “smoke test”.
Las 7 propiedades de las metodologías Crystal
Las metodologías Crystal cumplen todas ellas con 7 propiedades esenciales, las siguientes:
1 – Entregas frecuentes, en base a un ciclo de vida iterativo e incremental. En función del proyecto puede haber desde entregas semanales hasta trimestrales. Para los que conozcan Scrum: en Scrum las entregas son, máximo, cada 4 semanas, en las Crystal se contemplan muchas más opciones.
2 – Mejora reflexiva. Que viene a ser mejora continua. Las iteraciones ayudan a ir ajustando el proyecto, a ir mejorándolo.
3 – Comunicación osmótica. Traducido al castellano, que el equipo esté en una misma ubicación física, para lograr la comunicación cara a cara.
4 – Seguridad personal. Todo el mundo puede expresar su opinión sin miedos, teniéndosele en cuenta, considerándose su opinión, etc.
5- Enfoque. Períodos de no interrupción al equipo (2h horas), objetivos y prioridades claros, definiendo así tareas concretas. Si llevas desde hace tiempo pasando por este blog, recordarás ya comentábamos, tiempo a, aquello de que el entorno físico afecta al rendimiento del desarrollador software (te dejo aquel post).
6 – Fácil acceso a usuarios expertos. Las Crystal (a diferencia de otras como XP) no exigen que los usuarios estén continuamente junto al equipo de proyecto (no todas las organizaciones pueden hacerlo), sí que, como mínimo, semanalmente debe haber reuniones y los usuarios deben estar accesibles.
7 – Entorno técnico con pruebas automatizadas, gestión de la configuración e integración continua. Prácticas comunes en casi todas las metodologías ágiles, te dejo un post sobre la integración continua y el “smoke test”.
Las 7 propiedades de las metodologías Crystal
Las metodologías Crystal cumplen todas ellas con 7 propiedades esenciales, las siguientes:
1 – Entregas frecuentes, en base a un ciclo de vida iterativo e incremental. En función del proyecto puede haber desde entregas semanales hasta trimestrales. Para los que conozcan Scrum: en Scrum las entregas son, máximo, cada 4 semanas, en las Crystal se contemplan muchas más opciones.
2 – Mejora reflexiva. Que viene a ser mejora continua. Las iteraciones ayudan a ir ajustando el proyecto, a ir mejorándolo.
3 – Comunicación osmótica. Traducido al castellano, que el equipo esté en una misma ubicación física, para lograr la comunicación cara a cara.
4 – Seguridad personal. Todo el mundo puede expresar su opinión sin miedos, teniéndosele en cuenta, considerándose su opinión, etc.
5- Enfoque. Períodos de no interrupción al equipo (2h horas), objetivos y prioridades claros, definiendo así tareas concretas. Si llevas desde hace tiempo pasando por este blog, recordarás ya comentábamos, tiempo a, aquello de que el entorno físico afecta al rendimiento del desarrollador software (te dejo aquel post).
6 – Fácil acceso a usuarios expertos. Las Crystal (a diferencia de otras como XP) no exigen que los usuarios estén continuamente junto al equipo de proyecto (no todas las organizaciones pueden hacerlo), sí que, como mínimo, semanalmente debe haber reuniones y los usuarios deben estar accesibles.
7 – Entorno técnico con pruebas automatizadas, gestión de la configuración e integración continua. Prácticas comunes en casi todas las metodologías ágiles, te dejo un post sobre la integración continua y el “smoke test”.
Las 7 propiedades de las metodologías Crystal
Las metodologías Crystal cumplen todas ellas con 7 propiedades esenciales, las siguientes:
1 – Entregas frecuentes, en base a un ciclo de vida iterativo e incremental. En función del proyecto puede haber desde entregas semanales hasta trimestrales. Para los que conozcan Scrum: en Scrum las entregas son, máximo, cada 4 semanas, en las Crystal se contemplan muchas más opciones.
2 – Mejora reflexiva. Que viene a ser mejora continua. Las iteraciones ayudan a ir ajustando el proyecto, a ir mejorándolo.
3 – Comunicación osmótica. Traducido al castellano, que el equipo esté en una misma ubicación física, para lograr la comunicación cara a cara.
4 – Seguridad personal. Todo el mundo puede expresar su opinión sin miedos, teniéndosele en cuenta, considerándose su opinión, etc.
5- Enfoque. Períodos de no interrupción al equipo (2h horas), objetivos y prioridades claros, definiendo así tareas concretas. Si llevas desde hace tiempo pasando por este blog, recordarás ya comentábamos, tiempo a, aquello de que el entorno físico afecta al rendimiento del desarrollador software (te dejo aquel post).
6 – Fácil acceso a usuarios expertos. Las Crystal (a diferencia de otras como XP) no exigen que los usuarios estén continuamente junto al equipo de proyecto (no todas las organizaciones pueden hacerlo), sí que, como mínimo, semanalmente debe haber reuniones y los usuarios deben estar accesibles.
7 – Entorno técnico con pruebas automatizadas, gestión de la configuración e integración continua. Prácticas comunes en casi todas las metodologías ágiles, te dejo un post sobre la integración continua y el “smoke test”.
Quien más ha sido reconocido como padre del TDD ha sido Kent Beck
Quien más ha sido reconocido como padre del TDD ha sido Kent Beck
Quien más ha sido reconocido como padre del TDD ha sido Kent Beck
DDD incluyen el diseño orientado al dominio basado en modelos, lenguaje ubicuo y un contexto limitado.