Loading presentation...

Present Remotely

Send the link below via email or IM

Copy

Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.

DeleteCancel

Make your likes visible on Facebook?

Connect your Facebook account to Prezi and let your likes appear on your timeline.
You can change this under Settings & Account at any time.

No, thanks

Coaching Metodológico YPF - DSI

No description
by

Guillermo Amado

on 7 February 2013

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of Coaching Metodológico YPF - DSI

Progresiva
Adopción de Scrum Solapamiento con GIPS
Mejora de Gantts, incorporando criterio iterativo e incremental
Mejora de artefactos para gestión de Test y Bugs
Selección de alcance Reducido para una primera etapa
Propuesta para extensión a Análisis y Diseño. Octubre 2011: Convivencia con GIPS Estado a Marzo 2011: Proyectos sin gestión en C&P
Desvíos de Costo y Tiempo
Conflictividad con Proveedores
No hay seguimiento de Riesgos
No hay seguimiento de QA
No hay estándares de Arq.
No hay estimaciones al replanificar
No hay iteraciones en los proyectos
No hay proyectos ágiles
Imputación de desvíos a mantenimiento
TFS 2008 sólo como Repositorio
Sin Trazabilidad en el TFS
Sin herramientas de Gestión de Proyectos integral Adopción de Scrum dentro de GIPS
Migración a TFS2010+Templates Agiles
Tailoring de procesos
Control a Proveedores
Sumar proyectos al cambio
Mejora contínua Objetivos del proyecto de Coaching Metodológico Proveedor: Microsoft
Lider de Proyecto: Guillermo Fernández
Product Owner: Martín Larricart Junio 2011: Kickoff Migración a TFS 2010 Migración Exitosa
Sin desvíos de costo o tiempos
200 proyectos migrados
Adopción templates Scrum (MSF v5 y Scrum v1)
Customización Templates
Creación procesos para gestión de proyectos con TFS
Documentación técnica Octubre 2011: Fin Proyecto Análisis de experiencia Piloto
Diagnóstico de puntos a mejorar en GIPS
Definición de alcance de la propuesta Scrum (C&P)
Colaboración part-time de Estefanía Corti
Creación de SLA "10 mandamientos ágiles" v1 Agosto 2011: Análisis GIPS y MGD: Propuesta Metodológica Primer coaching en Scrum en la DSI
Escasa adherencia a metodología
Resistencia del proveedor a adoptar Scrum y TFS
Limitación de alcance metodológico: Sin Costos
Importante feedback como Lecciones Aprendidas Mayo-Ago 2011 (4 meses): Piloto SGMAYS - Buffa Sistemas Primer
Tailoring Scrum -Sin evidencia de cambios o autorizaciones
-Sin diferenciación de lo que es una mejora y un cambio
-Desvíos: 2 meses calendario y conflicto por renegociación de alcance, desvío 100% costo (mejoras consideradas cambios)
-Muy mala trazabilidad en TFS: Solo 270 Changesets con WI asociados
-Falta de Actualización diaria en TFS, en 8 Sprints sólo se registraron 117 WI y 820 hs de esfuerzo
-Regular gestión de Riesgos: 22 riesgos sin gestión
-Mala gestion Incidentes: 0 incidentes
-Utilización de otros documentos via mail en la gestión (xls, docs) y no el TFS como único repositorio
-Resistencia a la estimación con o sin metodología
-Autorizaciones tácitas y sin evidencia
-casi nula y deficiente registro de actividad diaria
-Muy pocos comentarios en Checkins Lecciones Aprendidas Proveedor: Exisoft/Pragma(A.Funcional/Test)
Lider de Proyecto: Santigo Aguilar
Product Owner: Rosana Scarabel Oct. 2011: INAS-BDA Proveedor: Aeroterra
Lider de Proyecto: Tomas Donda
Product Owner: Alejandra Cosentino Nov. 2011: Migración ArcGIS Sumar nuevos proyectos Proveedor: Buffa Sistemas/Pragma(A.Funcional/Test)
Lider de Proyecto: Sebastian Santos
Product Owner: Martín Crespo Dic. 2011: PAS Proveedor: Buffa Sistemas
Lider de Proyecto: Emiliano Castelli
Product Owner: José Luis Gomar Mayo. 2012: APA Informes de fin de Iteración
Compromiso de la iteración
Esfuerzo según Staff
Gestión de Riesgos
Gestión de Incidentes
BAR y cálculo de desvíos de Alcance, Esfuerzo o Duración Calendario
Retrospectiva y seguimiento de acciones correctivas y preventivas
Metricas y Análisis de Requerimientos, Bugs, Casos de Prueba, Calidad de Codificación, Trazabilidad
Etc... Informes a Gerencia
semi-automáticos
Se incorpora su complimiento mandatorio a pliegos
Se audita cada Proyecto al fin de cada Sprint
Se calcula % de adherencia a la metodología
Se arma un indicador histórico y el promedio se calcula para certificar entregables
Se realizan auditorías semanales semiautomáticas Abril 2012: Certificación según Mandamientos Ágiles Control a Proveedores Reemplazo de Estefanía Corti por Augusto Casano como asistente.
Incorporación de Patricia Diliberto, Ariel Lescano y Gastón Peña como Auditores.
Asistencia informal del equipo de testers de Pragma (Daniel Alloggio, Valeria Tabares)
Asistencia informal para Integración Contínua ( Control de Versiones YPF)
y más recursos a demanda... Febrero 2012: Crecimiento del equipo de coaching Gestión ágil Scrum con TFS
Registro diario de tiempos
Entregables incrementales
Plan de Comunicación y Reuniones
Gestión de Problemas y Riesgos
Gestión de Cambios
Matriz de Escalamiento
Roles y Responsablidades
Gestión de la Configuración (TFS)
Auditoría de la Mejora Contínua Revisión y aprobación de Mandamientos Ágiles v5 Mejora Contínua Armar el equipo de trabajo estable para poder hacer el seguimiento de más proyectos ágiles.
Incorporar a GIPS las prácticas de metodologías ágiles con el apoyo de los jefes de proyectos que han participado de la experiencia.
Realizar el tablero de control automáticos de proyectos ágiles
Combatir la resistencia al cambio de los Proveedores
Lograr el apoyo y compromiso de parte de personal de YPF (o contratados). Objetivo 2012: Institucionalizar Scrum+TFS en YPF Requerimientos de YPF Transparencia
Flexibilidad
Rigurosidad Metodológica
Compromiso
Confianza
Trabajo en Equipo
Autoorganización
Priorización
Respeto
Resolución de Conflictos Scrum Trazabilidad
Comunicación
Mantenibilidad
Seguridad y Resguardo
Gestión Distribuida de Proyectos
Gestion de Riesgos
Gestión de Pruebas (Test Manager)
Informes customizables
Dashboard y tablero de control online
Tracking diario remoto
Integración Continua
Escalable a otros frameworks no .Net TFS FIN Trazabilidad como Valor Agregado a la centralidad del WI Información que brinda la Trazabilidad como soporte a la PMO:
(COMO) Código Fuente y Work Items: Permite documentar la historia de un Work Item o Requerimiento, en cuanto a que clases, métodos, y código fuente en general implementan dicha funcionalidad.
(QUE) Requerimientos o CU devienen en Work Items ó Tareas de un Sprint : Permite documentar que Casos de Uso y Tareas que lo componen (WIs), implementan un Escenario o User Story. Permite relacionar un listado de requerimientos con su WBS de granularidad mas fina o especificación detallada.
(QUIEN) Responsables y Estados de un Work Item: Permite documentar quien es la persona asignada como responsable de codificar un WI, cerrarlo, reabrirlo, reasignarlo y asentar su finalización.
(CUANTO) Estimación de WorkItems y capacidad operativa: Permite conocer el esfuerzo real vs el estimado para desarrollar un WI, la capacidad operativa según el staffing del Team para todo el product backlog y los indicadores de productividad del team.
(CUANDO) Planificación y Work Items: En que Fase y Etapa del calendario se desarrollo y finalizó un WI.
(CAMBIOS) Work Items y sus transformaciones o transiciones: Permite documentar el ciclo de vida de un requerimiento, sus pedidos de cambio, los bugs que originó, las pruebas que lo validan, los riesgos asociados, los impedimentos que lo afectaron, etc.
(DOCUMENTACION) Work Items y Documentos que lo describen: Permite asociar a cada WI comentarios de su desarrollo y los documentos office asociados, sean especificaciones detalladas de requerimientos, casos de uso, requerimientos de cambio, minutas de reunión, diagramas UML, casos de prueba, análisis de impacto, problemas, riesgos o impedimentos asociados, etc.
(DONDE) Work Items, Builds y Branches : Permite conocer que código fuente y cuales WI asociados son implementados en ciertos Releases o Branches, logrando documentar la historia de cada Release (alpha, beta, hotfix, service pack, etc) y también cuales Builds están asociados a cada Branch, junto con el deploy o publicación automática de dichos Builds en distintos ambientes. Beneficios de la Trazabilidad (RESPALDO) Work Items y Evidencia de su ciclo de vida: Permite documentar evidencia para control de calidad, certificaciones o SCAMPI.
(MANTENIBILIDAD) Work Items y Branches: Permite asociar ciertas versiones de código fuente a Work Items para dar cuenta de Releases o Braches particulares. Genera Trazabilidad entre distintos Releases y permite que el código fuente pueda ser fácilmente interpretado por cualquier desarrollador o proveedor a partir de los WI que implementa.
(COMUNICACION) Work Items y sus Roles / Responsabilidades asociados: Permite comunicar con agilidad a los integrantes del Equipo de Desarrollo, al Product Owner y al Scrum Master, logrando efectividad en el seguimiento diario mediante informes de avance y tablero de control entre los integrantes del equipo (remoto incluso vía Web Access), ya que todo se centraliza en un solo lugar y se hace una sola vez por quien corresponda, permitiendo la customización de reportes y alertas de avance por rol o perfil de usuario.
(TRANSPARENCIA) Work Item y su estado a demanda: Permite comunicar transparentemente a todos los Involucrados, Stakeholders, Sponsors, Gerentes, PMO y QMO, el estado de cada WI o de todo el Proyecto mediante Indicadores, Medidas, Análisis y Documentación Asociada, demandada en cualquier momento, en cualquier lugar.
(INTEGRACION CONTINUA) Builds Automáticos y Workflows: Permite ejecutar builds automáticos y distribuidos ante cada checkin, logrando documentar la historia de cada build, que código fuente compiló y que WI implementó, permitiendo luego su publicación y distribución en distintos ambientes de prueba, staging y producción mediante un workflow predefinido y customizable.
(SEGUIMIENTO) Baseline, Actual, Remaining: Permite obtener snapshots del proyecto para su análisis de desvíos de duración, esfuerzo y costo, en cualquier momento y lugar, facilitando la detección temprana de desvíos y problemas, como así la mitigación de riesgos, cálculo de penalidades y compensaciones.
(RECOLECCION) Medidas y Análisis: Permite obtener y recolectar de forma simple y sencilla las medidas que habilitan el análisis de los principales indicadores del proyecto en cuanto a producto y proceso.
(CALIDAD) Aseguramiento y adherencia a estándares: Permite conocer , controlar y comunicar fehacientemente la adherencia a los estándares de calidad definidos por YPF para cada proyecto. Estrategias a tener en cuenta para una exitosa
implementación del TFS TFS requiere un liderazgo no solo técnico. Una ingeniería de requierimientos deficiente ocasiona el 45% de los fracasos en PM, en Arg el 78%. (Fuente:PMIBA/Curso GIPS). TFS por si solo no mejora esto.
Requiere no solo ejecutar el proyecto sino gestionarlo con buenas prácticas antes y durante su ejecución, utilizando un lenguaje común, adoptando una metodología de gestión de proyectos (MGD) + una metodología de gestión de desarrollo (SCRUM) + una herramienta customizada (template MSF for Agile v4.5 para TFS2008).
Requiere reuniones periódicas, compromisos, acuerdos documentados y comunicación formal e informal. TFS por si solo no visibiliza ni comunica lecciones aprendidas, ni mitiga riesgos ni administra el conocimiento, requiere interpretación de información, control cruzado de la gestión por una QMO técnica y tomar las decisiones correctas.
Requiere apoyo político de la Gerencia de la DSI Mapping Scrum con MGD Visite nuestros WEBSITES:
www.pragmaconsultores.com
- Información Detallada de Servicios
- Nuestra Experiencia: Clientes y Proyectos
- Nuestro Compromiso y Nuestra Metodología de Trabajo

www.qafactory.com
- Fábrica de Aseguramiento de la Calidad
- Beneficios y Detalle del Servicio Argentina
San Martín 575 • 2º
(C1004AAK) Buenos Aires
Tel (+54-11) 4327-1999
pragma@pragma.com.ar España
López de Hoyos 35 • 1º
(28002) Madrid
Tel (+ 34) 91-745-9912
practia@practia.es Chile
Luis T. Ojeda 0191 • Of. 701,
Providencia, Santiago
Tel (+56-2) 334-3361
practia@practia.cl Contáctenos: Coaching Metodológico a la DSI de YPF en Scrum y TFS E. Galeano en Memoria del Fuego...
"Gracias a Helena Villagra, que fue la crítica implacable y entrañable de estos textos..." Alcance Interno y Externo Analisis Comparativo de metodologías 2 posibilidades de
aplicación de Scrum Elección de
opción acotada -Finalizado, Producción en Agosto, total 10 meses
-Desvío calendario (4 meses) por subestimación de testing y tecnología (uso de componentes) y por alta rotación (mala gestión de rrhh del proveedor) y baja calidad del desarrollo
-29.000 LDC, Code Metrics superado
-Arquitectura MVC2 (anticuada VS2008), sin TDD (testeo Unitario)
-Sin proyecto base de datos (oracle).
-Sin integración continua.
-65 builds manuales en 2 branches.
-17 Sprints (2 semanas aprox.) + 2 meses co-location de Test como acción correctiva ante desvíos
-14 Riesgos gestionados
-3 Impedimentos gestionados
-347 Test Cases manuales en Test Manager, 2 planes de test, (343 pasados, 29 fallidos), sin testeo automático.
-8 auditorías (Mandam. Agiles) 80% promedio de adherencia.
-400 links a Código en 800 Bugs.
-1450 links a Código en 700 Tareas.
-Buen registro de actividad diaria, esfuerzo total registrado: 4700 hs en 1120 Tareas y Bugs.
-Utilización de documentos en GIPS y en TFS como repositorio complementario
-Estimación COCOMO en Sprint 1 y 2 y luego Ojo experto
-Autorizaciones entregables con evidencia
-Buena cantidad de comentarios en Checkins, 1200 de 1930
-1 solo cambio aprobado y autorizado
-Diferencia de lo que es una mejora y un cambio INAS-BDA Lecciones Aprendidas Proveedor: Buffa Sistemas/Pragma(Test)
Lider de Proyecto: Carlos Buiz
Product Owner: Carlos Brochinni Junio. 2012: Gestion Riesgos Proveedor: Buffa Sistemas
Lider de Proyecto: Sebastián Santos
Product Owner: Fernando Beck Junio 2012: Vetting Proveedor: Buffa Sistemas
Lider de Proyecto: Sebastian Santos
Product Owner: Federico Delgado Julio 2012: YWalk -Finalizado , total 9 meses
-Desvío calendario (1 mes) por incidentes y demoras con firma de contratos, adquisición software y hardware y por mala gestión de rrhh del proveedor (renuncia de 2 PL) y baja adherencia a la metodología Scrum
-Arquitectura GIS, sin TDD (testeo Unitario)
-Sin proyecto base de datos.
-Sin integración contínua.
-Sin builds manuales ni automáticos (No .net). 1 branch
-10 Sprints (3 semanas aprox) + 2 meses de Test sin gestión Scrum por abandono de metodología.
-9 Riesgos sin gestión
-7 Impedimentos mal gestionados
-1 Test Case manual en Test Manager, con bajo testeo (22 pasadas, 4 fallidos) y sin testeo automático.
-4 auditorías (Mandam. Agiles) 65% promedio de adherencia.
-Ningún link a Código en 40 Bugs.
-Ningún link a Código en 50 Tareas.
-Nulo registro de actividad diaria, esfuerzo total registrado: 30 hs.
-Utilización de documentos en GIPS, sin uso de TFS como repositorio de documentación de desarrollo.
-Estimación ojo experto en muy pocas tareas
-Autorizaciones entregables con evidencia
-Casi Nulo esfuerzo registrado: 383 hs. de 50 Tareas.
-Pocos changesets comentados 10 de 30.
-Sin cambios aprobados ni autorizados
-Diferencia de lo que es una mejora y un cambio Migración ARCGIS -Finalizado, Producción en Julio, total 6 meses
-Desvío calendario (2 días).
-No usa Arquitectura MVC, Framework 3.5, sin TDD (testeo Unitario)
-52.000 LDC, Code Metrics superado
-Sin proyecto base de datos.
-Sin integración continua.
-1 unico build (con errores) manual registrado en 3 branches.
-9 Sprints (3 semanas aprox.)
-2 Riesgos gestionados
-0 Impedimentos gestionados
-260 Test Cases manuales en Test Manager, sin testeo automático. (3 Test Case ejecutados, 40 tests pasados, 7 fallidos)
-4 auditorías (Mandam. Agiles) 70% promedio de adherencia.
-40 links a Código en 120 Bugs.
-190 links a Código en 300 Tareas.
-Bajo registro de actividad diaria, esfuerzo total registrado: 810 hs en 310 Tareas y Cambios.
-Utilización de documentos en GIPS como único repositorio
-Estimación Ojo experto luego del sprint 4
-Autorizaciones entregables con evidencia luego del sprint 4
-Ppocos comentarios en Checkins 90 de 150.
-9 cambios aprobados y autorizados
-Diferencia de lo que es una mejora y un cambio PAS -Finalizado, Producción en Julio, total 3 meses
-Desvío calendario (4 días).
-No usa Arquitectura MVC, sin TDD (testeo Unitario)
-16.000 LDC, Code Metrics superado.
-Sin proyecto base de datos.
-Con integración continua parcial (sin deploy automatico).
-32 builds (12 con errores) en 4 branches.
-4 Sprints (3 semanas aprox.)
-3 Riesgos gestionados
-2 Impedimentos gestionados
-44 Test Cases manuales en Test Manager (95% ejecutados, 31 pasados), sin testeo automático.
-2 auditorías (Mandam. Agiles) 96% promedio de adherencia.
-18 links a Código en 10 Bugs.
-300 links a Código en 47 Tareas.
-Alto registro de actividad diaria, pero sin esfuerzo registrado en PB: 10 hs en 32 PBItems.
-Utilización de documentos en GIPS como único repositorio
-Estimación Ojo experto
-Autorizaciones entregables con evidencia
-Todos los comentarios en Checkins 160 de 160.
-Nincun cambios aprobados ni autorizado
-Diferencia de lo que es una mejora y un cambio APA -Finalizado Etapa II, en prueba usuario, salida producción Agosto, total 2 meses
-Desvío calendario (0 días).
-Usa Arquitectura MVC3, sin TDD (testeo Unitario)
-8.000 LDC, Code Metrics superado.
-Sin proyecto base de datos.
-Con integración continua (sin deploy automatico).
-71 builds (19 con errores) en 1 branch.
-7 Sprints (1 semana)
-0 Riesgos gestionados
-5 Impedimentos gestionados
-18 Test Cases manuales en Test Manager (50% ejecutados, 6, pasados, 1 fallido), con 1 (un) testeo automático.
-Sin auditorías (Mandam. Agiles).
-36 links a Código en 88 Bugs.
-100 links a Código en 450 Tareas.
-Poco registro de actividad diaria, sin esfuerzo registrado en PB: 0 hs en 30 PBItems.
-No se guardan documentos en TFS ni en GIPS
-No hay Estimación cuantitativa
-Autorizaciones Parciales de entregables con evidencia
-Casi todos los comentarios en Checkins 260 de 290.
-Ningun cambios aprobados ni autorizado
-Diferencia de lo que es una mejora y un cambio Gestión Riesgos -Finalizado Etapa II, en prueba usuario, salida producción Agosto, total 2 meses
-Desvío calendario (0 días)
-Usa Arquitectura MVC3, sin TDD (testeo Unitario)
-5.600 LDC Code Metrics superado
-Sin proyecto base de datos
-Con integración continua y deploy automático
-58 builds (9 con errores) en 1 branch
-6 Sprints (1 semana)
-0 Riesgos gestionados
-0 Impedimentos gestionados
-23 Test Cases manuales en Test Manager (98% ejecutados, 12 pasados, 10 fallidos), con 1 (un) testeo automático.
-Sin auditorías (Mandam. Agiles)
-0 links a Código en 38 Bugs.
-25 links a Código en 126 Tareas.
-Poco registro de actividad diaria, sin esfuerzo registrado en PB: 28 hs en 17 PBItems.
-No se guardan documentos en TFS ni en GIPS
-No hay Estimación cuantitativa
-Autorizaciones Parciales de entregables con evidencia
-Casi todos los comentarios en Checkins 93 de 106.
-Ningun cambio aprobado ni autorizado
-Diferencia de lo que es una mejora y un cambio Vetting YWalk -En Kickoff, transcurrido 15 dias
-Desvío calendario ??
-Usa Arquitectura MVC3, JAVA Tablet, sin TDD (testeo Unitario)
-? LDC Code Metrics superado
-Sin proyecto base de datos
-Sin integración continua ni deploy automático
-? builds (? con errores) en 1 branch para .NET
-? Sprints (2 semanas)
-? Riesgos gestionados
-? Impedimentos gestionados
-? Test Cases manuales en Test Manager (?% ejecutados, ? pasados, ? fallidos), sin testeo automático.
-Sin auditorías (Mandam. Agiles)
-0 links a Código en 0 Bugs.
-0 links a Código en 7 Tareas.
-Nulo registro de actividad diaria, sin esfuerzo registrado en PB.
-No se guardan documentos en TFS ni en GIPS
-No hay Estimación cuantitativa
-No hayAutorizaciones Parciales de entregables con evidencia
-Pocos comentarios en Checkins 6 de 9
-Ningun cambio aprobado ni autorizado
-Sin diferencia de lo que es una mejora y un cambio x kickoff -Desvío Importante en Calendario
-Uso de componentes (Infragistics) poco conocidos por el proveedor, pedir certificaciones
-Controlar la rotación de RRHH del proveedor
-Mala calidad de codificación y bajos criterios de aceptación para pasaje a QA
-Demoras en pedidos de servidores de QA
-Demoras en pasajes de ambientes vía Control de Versiones
-Arquitectura MVC2 anticuada
-Sin TDD
-Escasa Gestión de Riesgos e Impedimentos
-Base (Oracle) no soportada por Microsoft para Proyectos de Base de Datos en VS2008, analizar alternativas de comparación de esquemas entre ambiente y versiones
-Necesidad de tomar en cuenta una heurística por rework de aprox. 25% del esfuerzo por cada elemento de trabajo.
-Estimación por ojo experto muy optimista. Utilizar COCOMO o estimación por escenarios (pesimista, normal, optimista) -Buenas métricas de código
-Buena Trazabilidad de WI y Cod. Fuente
-Buena cobertura de Test Cases y Ejecución de los mismos
-Buen Tracking de esfuerzo por parte del proveedor
-Buena Adherencia a Mandam. Agiles
-Estimación COCOMO exitosa (al principio)
-Buena gestión de las autorizaciones y certificaciones parciales
-Buena cantidad de comentarios en Checkins
-Buena gestión de los cambios y de las mejoras, sin conflicto. -Uso de tecnología (GIS) no usualmente desagregada en requerimientos detallados (WBS)
-Imposibilidad de métricas de código por tecnología.
-Controlar la rotación de RRHH del proveedor, vacaciones y jefes de proyectos
-Demoras en pedidos de licencias y servidores de QA y Producción
-Demoras en pasajes de ambientes vía Control de Versiones
-Sin posibilidad de testeo unitario por tecnología (GIS)
-Escasa Gestión de Riesgos e Impedimentos
-Base (Oracle) no soportada por Microsoft para Proyectos de Base de Datos en VS2008, analizar alternativas de comparación de esquemas entre ambiente y versiones
-Necesidad de designar Testers con skill adecuado (mal diseño Test Cases) y usar la herramienta en profundidad.
-Casi Nula cobertura de Test Cases
-Estimación por ojo experto muy optimista. Utilizar Delphi o estimación por escenarios (pesimista, normal, optimista)
-Muy mala Trazabilidad de WI y Cod. Fuente
-Muy mala gestión de los comentarios en checkins
-Muy mal Tracking de esfuerzo por parte del proveedor
-Muy Baja Adherencia a Mandam. Agiles -Buena gestión de las autorizaciones y certificaciones parciales
-Buena gestión de los cambios y de las mejoras, sin conflicto. -No uso de MVC
-No uso de TDD
-Sin proyecto BD
-Sin Integración Continua (se anticiparon pedidos de pasajes de ambientes)
-Nulo uso de Builds para controlar calidad de desarrollo
-Casi nula gestión de riesgos e impedimentos
-Muy Mala gestión de test, solo diseño básico de Test Cases, poca cobertura y nula ejecución de los mismos.
-Baja adherencia a Mandam. Agiles
-Estimación por ojo experto recién a mitad de proyecto
-Bajo registro de tracking en todo el proyecto, nulo antes del sprint 4.
-Pocos comentarios en Checkins
-Regular trazabilidad de WI y Cod Fuente -Buenas métricas de código
-Buen uso de Branches
-Buena gestión de las autorizaciones y certificaciones parciales
-Buena gestión de los cambios y de las mejoras, sin conflicto. -No uso de MVC
-Sin TDD
-Escasa Gestión de Riesgos e Impedimentos
-Sin Proyectos de Base de Datos
-Sin esfuerzo registrado en PBacklog -Buenas métricas de código
-Excelente Trazabilidad de WI y Cod. Fuente
-Buena gestión de Builds y Branches
-Integración Continua Parcial (sin deploy automático)
-Buena cobertura de Test Cases y Ejecución de los mismos (aunque tardía)
-Buen Tracking de estados de WI por parte del proveedor
-Excelente Adherencia a Mandam. Agiles
-Buena estimación Ojo Experto
-Excelente gestión de las autorizaciones y certificaciones parciales
-Excelente cantidad de comentarios en Checkins
-Buena gestión de los cambios y de las mejoras, sin conflicto. -No uso de TDD
-Sin proyecto BD
-Sin Deploy Automático
-Nulo uso de Branches
-Nula gestión de Riesgos
-Parcial gestión de test, Parcial ejecución de los mismos.
-Parcial gestión de las autorizaciones y certificaciones
-Nula adherencia a Mandam. Agiles
-Baja estimación por ojo experto, sin datos cuantitativos de esfuerzo
-Bajo registro de tracking en todo el proyecto por parte del proveedor, reemplazado por daily meetings
-No se guardan documentos en TFS ni en GIPS
-Mala trazabilidad de WI y Cod Fuente -Uso de MVC3
-Buena calidad de Builds
-Integración Continua
-Tests Automáticos
-Aceptable gestión de Incidentes
-Buenas métricas de código
-Buenos comentarios en Checkins
-Buena gestión de los cambios y de las mejoras, sin conflicto. -Nulo uso de Branches
-No uso de TDD
-Sin proyecto BD
-Sin Integración Continua
-Sin deploy automático
-Nulo uso de Builds para controlar calidad de desarrollo
-Casi nula gestión de riesgos e impedimentos
-Aún sin gestión de test
-Nula adherencia a Mandam. Agiles
-Sin estimación cuantitativa ni cualitativa
-Sin Sprint Backlog ni WBS
-Nulo registro de tracking
-Nulos comentarios en Checkins
-Nula trazabilidad de WI y Cod Fuente
-Nula gestión de las autorizaciones y certificaciones parciales
-Aun sin gestión de cambios ni de mejoras. -Uso de MVC -No uso de TDD
-Sin proyecto BD
-Nulo uso de Branches
-Nula gestión de Riesgos
-Nula gestión de riesgos e impedimentos
-Parcial gestión de test, buena ejecución de los mismos.
-Regular gestión de las autorizaciones y certificaciones parciales
-Mala priorización de WI y Bugs
-Nula adherencia a Mandam. Agiles
-Mala estimación por ojo experto, sin datos cuantitativos, apenas datos cualitativos de esfuerzo
-Nulo registro de tracking en todo el proyecto por parte del proveedor, reemplazado por daily meetings
-No se guardan documentos en TFS ni en GIPS
-Nula trazabilidad de WI y Cod Fuente
-Mala gestión de los cambios y de las mejoras, con conflicto por no adecuación a metodología ultra-ágil -Uso de MVC3
-Buena calidad de Builds
-Integración Continua
-Tests Automáticos
-Deploy Automático en PRETEST
-Buenas métricas de código
-Buenos comentarios en Checkins
Full transcript