Este documento presenta 10 principios básicos para entregas de software exitosas. Estos principios incluyen la planificación de documentación, transparencia en la información y pruebas, usar la menor cantidad de componentes posibles, no innovar más allá de los requerimientos, ponerse en el lugar del usuario, realizar siempre pruebas formales, simular instalaciones independientes, corregir problemas heredados, evitar egos, y comunicar todos los cambios.
4. Principios básicos para entregas exitosas 3. Principio de Parsimonia Utilizar la mínima cantidad de componentes con los que se pueda llevar a cabo la entrega. Esto incluye: --cantidad de pasos que debe tener el proceso de instalación (cantidad de casillas); --manera en que están armados los portlets (minimizar la cantidad de JAR’s internos, por ejemplo), y --lógica misma de los desarrollos (cuanto más simple, mejor).
5. 4. Principio de No Innovar Si se ha alcanzado un punto en el que se cumple con la funcionalidad requerida no introducir más cambios o validarlo doblemente con la persona responsable de administrar los requerimientos de cambio. Principios básicos para entregas exitosas
6. 5. Principio de Empatía Evitar el “acá funciona”. Ponerse en el lugar del otro hasta reproducir el problema, comprenderlo y brindar una solución. Recomendado: --No deberían hacerse simplificaciones en los entornos o atajos que luego producen este tipo de problemas, o de lo contrario contar con un mecanismo de compensación ; --Ejecución de un plan de pruebas conjunto . Principios básicos para entregas exitosas
7. 6. Probar SIEMPRE • Garantizar la entrega con un proceso de testing formal . Este paso debe ser realizado siempre, con mayor o menor profundidad pero SIEMPRE . • La profundidad y características de la prueba ante cada entrega no debe ser decisión del programador que la realiza ni del equipo técnico, aunque se apoye en ellos. • Cada cambio o entrega debe tener un análisis de impacto adecuado para determinar las pruebas necesarias. Principios básicos para entregas exitosas
8. 7. Principio de Desmarque Realizar un simulacro de instalación independiente de la entrega y del grupo de desarrollo: --instalador, persona que se «desmarque» del desarrollo --instalación en un entorno propio (ajeno a desarrollo), usando documentación y recursos disponibles en el SharePoint. Principios básicos para entregas exitosas
9. 8. Síndrome de “la Pesada Herencia” • Si «heredamos» algo que funciona mal debemos corregirlo. • Corrección de errores: -- Identificar el problema -- Plantear la solución o pedir ayuda. Puede haber una o varias soluciones y consensuar la mejor disponible o aplicable. • Culpabilidad vs. responsabilidad. Principios básicos para entregas exitosas
10. 9. Ego del Programador --Prohibido decir “que desastre, yo lo hubiera hecho mejor”. --En su lugar, proponer una mejora. Esa mejora puede ser en forma de “work item”. --No pueden ocurrir problemas con solución conocida que no figuren en una mejora planificada. Principios básicos para entregas exitosas
11. 10. Principio de "CeSo": Cero Sorpresa (seamos CasaFantasmas del Código) La entrega no puede contener cambios no informados . De lo contrario se invalida el ciclo de prueba y se pone en riesgo la confianza del equipo. Las instancias para informar un cambio son: --Documento de Entrega. --Estado Abierto, no corregido, en ADS. Principios básicos para entregas exitosas
12. Resumen 1. Planificar Documentación de Entrega 2. Transparencia Oscurantismo Cero 3. Principio de Parsimonia 4. Principio de No Innovar 5. Principio de Empatía 6. Probar SIEMPRE 7. Principio de Desmarque 8. Síndrome de la «Pesada Herencia» 9. Ego del Programador 10. Principio de «CeSo»: Cero Sorpresa Principios básicos para entregas exitosas
Notas del editor
Respondiendo a la pregunta de cómo podría evitarse los problemas que se dan en las entregas surgió esta serie de 10 puntos necesarios para que una entrega tenga éxito. Comparando esto con los resultados obtenidos en cada entrega en particular tendremos la respuesta a qué podríamos hacer para que los errores cometidos no sean algo recurrente.