Please enable JavaScript.

Coggle requires JavaScript to display documents.

PRODUCCIÓN DE SOFTWARE - Coggle Diagram

- - - - Software de aplicación
      - Software de programación
      - Software de sistema
  - - - Detectar necesidades del negocio (nicho de mercado)
      - ¿Cómo podemos aportar valor y en dónde?
      - ¿Por qué y para quién?
      - Presupuesto
      - Modelo de negocio
    - - Recursos (personas, capacidades, tecnología,...)
      - Actividades (definidas en tiempo y prioridad)
      - Calendario (objetivos a corto, medio y largo plazo
    - - Reflexionar sobre buenas prácticas y estrategias que mejoren procesos
- - - - Gestión predictiva
        
        Agendas
        
        Presupuestos
        
        Universal
        
        LA FORMA MÁS EFICIENTE DE HACER UN TRABAJO, ES HACERLO BIEN A LA PRIMERA
      - Ingeniería de procesos
        
        Repetibles
        
        Eficaces
        
        LA CALIDAD DEL RESULTADO DEPENDE DE LA CALIDAD DE LOS PROCESOS
    - - Velocidad
      - Incertidumbre
      - Eficiencia y previsibilidad ya no son las claves del éxito
    - - El sentido común es el menos común de los sentidos
    - - 1986: Concepto de SCRUM
      - 1995: se formaliza marco de trabajo SCRUM
      - 2001: Manifiesto ágil
    - - 12 principios
        
        Satisfacer al cliente
        
        Los cambios se aceptan y aprovechan
        
        Entrega frecuente de producto funcionando
        
        Colaboración diaria del negocio y los desarrolladores
        
        Personas motivadas
        
        Conversación cara a cara
        
        Medimos producto funcionando
        
        Promovemos el ritmo sostenible
        
        Atención continua a la excelencia técnica
        
        La simplicidad es esencial
        
        Equipos auto-organizados
        
        Mejora continua
      - Individuos e interacciones sobre procesos y herramientas
      - Software funcionando sobre documentación extensiva
      - Colaboración con el cliente sobre negociación contractual
      - Respuesta ante el cambio sobre seguir un plan
  - - - Concepto - (Especulación - Exploración - Revisión) - Cierre
    - - Un buen plan ejecutado contundentemente hoy, es mejor que un plan perfecto ejecutado dentro de un mes
      - Poco detallada
        
        Prioridad del negocio
        
        Basada en el trabajo inmediata
      - Planificación -> NO
        Adaptación continua -> SI
    - - Propietario del producto
        
        Visión y único responsable del producto
        Establece la prioridad del producto
      - Equipo
        
        Aportan valor con cada incremento
        Autoorganizados y multidisciplinar
        Responden como equipo (3-9 personas)
      - Scrum Master
        
        Guía y transmisor del conocimiento
        Líder del equipo
        Resuelve impedimentos
      - Interesados
        
        Retro-información, Sugerencias...
        NO DECIDEN
    - - Product Backlog
      - Sprint Backlog
      - Incremento
    - - Yo como ...
        Deseo ...
        Para ...
      - Criterios de aceptación
        
        Descripción a alto nivel
        
        Como se demostrará que está finalizado
        
        Consecuencias de la historia
        
        Acuerdo entre cliente y equipo
        
        Casi hecho NO ES hecho
        
        Hay que ser explícitos!!
        
        Idealmente equivaldrá a una prueba automática
      - Pila de Sprint
        
        Funcionalidades de la pila de producto que nos comprometemos a completar durante un Sprint con el objetivo de obtener un incremento
        
        Descomponemos las historias en tareas a resolver durante el sprint
  - - - Perfiles de negocio
        
        Que entienden poco de tecnología, pero saben mucho de retorno de inversión, de funcionalidades, de requisitos, etc
      - Perfiles tecnológicos
        
        Que saben mucho de tecnología, pero conocen poco del negocio habitualmente
    - - Criterios de aceptación o escenarios: Es una descripción de cada caso específico de la narrativa. Tal escenario tiene la siguiente estructura
        
        Comienza al especificar la condición inicial, la cual es asumida como verdadera al inicio del escenario. Esto puede consistir en una causa o varias
        (Dado....)
        
        Después declara cuál evento causa el inicio del escenario
        (Cuando...)
        
        Finalmente, declara el resultado esperado, en una o más cláusulas
        (Entonces...)
    - - DevOps permite que los roles que antes estaban aislados (desarrollo, operaciones TI, ingeniería de la calidad y seguridad) se coordinen y colaboren para crear productos mejores y más confiables
    - - La integración continua (CI) es el proceso de compilar y probar código automáticamente cada vez que un miembro del equipo confirma los cambios de código en el control de versiones
      - la idea es integrar dentro de las prácticas del desarrollo pruebas automáticas
      - Ayuda a detectar errores al principio del ciclo de desarrollo, lo que hace que sean menos costosos de corregir
      - El código se compila, prueba e implementa en u uno o varios entornos de prueba y producción
      - Los sistemas generan artefactos implementables, incluida la infraestructura y las aplicaciones
      - Los procesos de versiones automatizados consumen estos artefactos para publicar nuevas versiones y correcciones en los sistemas existentes
      - Los sistemas que supervisan y envían alertas se ejecutan continuamente para impulsar la visibilidad de todo el proceso de CD
  - - - Tiempo real
        
        Unidad absoluta (horas o días)
        
        Determina el espacio temporal necesario para construir una historia
        
        Nos una medida empírica (Depende de la persona)
      - Puntos de historia / Tiempo ideal
        
        Unidad relativa al equipo (juicio de expertos)
        
        Determina la cantidad de trabajo necesaria para construir una historia
        
        Dificultad
        
        Tamaño
        
        Es una medida empírica (igual para todos)
        
        Establece el equilibrio en entregas
        
        Simplifica el seguimiento y control de trabajo
    - - Velocidad = Trabajo / Tiempo
        
        Trabajo = Tiempo ideal + puntos
  - - - Sprint
        
        Iteración de desarrollo
        
        No más de 4 semanas
      - Planificación del sprint
        
        ¿Cuánto va a durar el sprint y qué vamos a hacer?
        
        8 horas Sprint de 1 mes, proporcionalmente menor en sprints mas cortos
      - Scrum Diario
        
        Seguimiento diario del avance
        
        15 minutos
      - Revisión del sprint
        
        4 horas Sprint de 1 mes, proporcionalmente menor en sprints mas cortos
        
        Revisión del incremento realizado en el sprint
      - Retrospectiva
        
        ¿Cómo fue el Sprint?
        
        3 horas Sprint de 1 mes, proporcionalmente menor en sprints mas cortos
    - - Marco de trabajo (framework) simple
      - Sistema iterativo e incremental
      - Presupone requisitos indefinidos y cambiantes
      - Conocimiento tácito de las personas
      - Trabajo priorizado por EL VALOR DE NEGOCIO
      - Entrega continua y temprana
      - Auto-organización de los equipos
      - Visibilidad diaria del progreso
    - - Gestión Técnica
        Modelos y prácticas
        
        Explícito
        
        Procesos
        
        Tecnología
      - Gestión experta
        Experiencia profesional
        
        Tácito
        Expertos en la operativa del proceso
        
        Personas
    - - La calidad del resultado depende en gran medida del saber hacer de las personas
  - - - KAIZEN (Mejora continua)
      - LEAN (Eliminar desperdicio)
      - Parámetros a controlar
        
        MURA
        
        Discrepancia - Variabilidad del flujo de trabajo
        
        MURI
        
        Tensión - Sobrecarga de trabajo que produce cuellos de botella
        
        MUDA
        
        Desperdicio
    - - Work In Process (WIP)
        
        Limitar el trabajo en proceso
        
        Solo se añaden tareas si nuestro WIP acordado lo permite
    - - Flujo de trabajo en estados diferenciados
      - Dividir el trabajo en bloques
      - Radiador de información
  - - - Documentos
      - Ofertas
      - Dibujos
      - Esquemas
      - Etc
    - - git init
        
        Inicializa un repositorio
      - git add
        
        Agrega cambios al staging area
      - git status
        
        Muestra el estado de los cambios
      - git reset HEAD
        
        Elimina un cambio del staging area
      - git commit
        
        Envía un cambio del staging al repositorio
      - git rm
        
        Borra un cambio del repositorio
      - git checkout
        
        Trae la última versión del cambio, crea y cambia de rama
      - git brach
        
        Muestra las ramas
      - git merge
        
        Fusiona las ramas
      - git remote add origin
        
        Relaciona repo local a un repo remoto
      - git clone
        
        Clonar repositorio remoto
      - git pull
        
        Trae la última versión del repo remoto
      - git push
        
        Envía los cambios del repo local al repo remoto
- - - - Usuario interactuando con el sistema
    - - Pantallas, páginas y elementos visuales para interactuar
  - - - Empírica
        
        Porque no se basa en opiniones o sensaciones, sino en pruebas de usabilidad realizadas en laboratorio y observadas mediante trabajo de campo
      - Relativa
        
        Porque el resultado no es ni bueno ni malo, sino que depende de las metas planteadas o de una comparación con otros sistemas similares
  - - - Significado emocional
- - - - No tienen por qué ser errores o bug de programación, ya que pueden no ser técnicamente incorrectos y el programa funciona correctamente
      - Indican deficiencias en el diseño y pueden hacer que se realice un desarrollo más lento
      - Aumentan el riesgo de errores o fallos en el futuro
  - - - Se refiere a la responsabilidad única que debiera tener cada programa con una tarea bien especificada y acotada
    - - Toda clase, módulo, método, etc. debería estar abierto para extenderse pero debe estar cerrado para modificarse
    - - Si la clase A es de un subtipo de la clase B, entonces deberíamos poder reemplazar B con A sin afectar el comportamiento de nuestro programa
    - - Ningún cliente debería estar obligado a depender de los métodos que no utiliza
    - - No debería existir dependencias entre los módulos, en especial entre módulos de bajo y de alto nivel