{"id":10,"date":"2021-06-03T15:05:58","date_gmt":"2021-06-03T15:05:58","guid":{"rendered":"https:\/\/lafilosofiadelsoftware.wordpress.com\/?p=10"},"modified":"2021-08-23T22:17:53","modified_gmt":"2021-08-24T03:17:53","slug":"cargos-innecesarios-software","status":"publish","type":"post","link":"https:\/\/lafilosofiadelsoftware.com\/index.php\/2021\/06\/03\/cargos-innecesarios-software\/","title":{"rendered":"\u00bfSon todos los cargos en la ingenier\u00eda de software realmente necesarios?"},"content":{"rendered":"\n

Tocar\u00e9 un tema que puede llegar a herir susceptibilidades en algunas personas, antes de juzgar por favor leer todo.<\/p>\n\n\n\n

Alguna vez se han preguntado \u00bfes realmente necesario una persona de QA<\/a> en nuestro equipo? \u00bfNecesitamos un Scrum master para que nos de \u2018asistencia\u2019? \u00bfNos da valor tener un Agile Coach en nuestra empresa? Si la respuesta es s\u00ed a alguna de las preguntas anteriores d\u00e9jame decirte que tienes un equipo\/empresa a\u00fan con muchas oportunidades de mejora y te voy a explicar por qu\u00e9.<\/p>\n\n\n\n

Empecemos por el departamento de calidad la cual es un \u00e1rea creada por la incompetencia de los developers de garantizar calidad, son el fantasma de la navidad pasada creado por ellos mismos. He tenido la oportunidad en los \u00faltimos 10 a\u00f1os de encontrarme con excelentes tester y tambi\u00e9n de encontrarme con el que no entiende la misi\u00f3n de su cargo y su \u00fanica objetivo\/placer es de llenar de bugs al equipo (su misi\u00f3n es que el software funcione correctamente no llenar de bugs al equipo lo cual son dos cosas completamente diferente).<\/p>\n\n\n\n

Sin embargo, a pesar de que existan excelentes profesionales encargados de garantizar la calidad, no anula la siguiente afirmaci\u00f3n \u2018Es un cargo que NO deber\u00eda de existir y toca tenerlo por la incompetencia de los developers\u2019 son los mismos developers quienes deben garantizar la calidad del software, \u00bfentonces qu\u00e9 sucede? \u00bfpor qu\u00e9 no se logra?<\/p>\n\n\n\n

Existen varias razones:<\/p>\n\n\n\n

  1. Se nos ense\u00f1a desde la academia (universidad, cursos, bootcamps) que existe un rol encargado de garantizar la calidad. Esto genera una especie de bloqueo mental en los developers en que empiezan a creer que la calidad es responsabilidad de un equipo o personas diferentes a ellos, que ellos solo deben producir software y esta otra \u00e1rea encargarse de que no existan defectos, por supuesto que existen developers preocupados por la calidad y defensores n\u00famero 1 de la calidad, pero \u00bfson todos as\u00ed? esta pregunta la dejo para que se la respondan ustedes<\/li>
  2. La imposibilidad ver nuestros propios errores, la ceguera inconsciente de los developers haciendo m\u00e1s f\u00e1cil ver los errores ajenos a sus propios y obvios errores, lo cual lo aludo a:<\/li>
  3. Orgullo que puede llegar a sentir un developer al \u2018finalizar\u2019 su trabajo, que a\u00fan no comprende que el final, no es terminar el c\u00f3digo sino probarlo las veces y maneras necesarias hasta garantizar que esta correcto.<\/li>
  4. Tiempos de desarrollo apretados y la necesidad de sacar una versi\u00f3n al costo que sea, cayendo en la frase \u201cEs mejor sacar algo (con errores) a no sacar nada\u201d<\/li><\/ol>\n\n\n\n

    Empezando a depender menos del cargo<\/h1>\n\n\n\n

    Veamos una serie de pasos para lograrlo:<\/p>\n\n\n\n

    1. Lo primero es un cambio de mentalidad (sin esto no hay nada). El developer debe entender que la calidad del software es \u00fanica y exclusiva responsabilidad de \u00e9l. Olvid\u00e9monos del developer encargado de \u00fanicamente la etapa del COMO, \u00e9l debe participar en el QUE apoyando y debatiendo las definiciones de negocio. (M\u00e1s del 60% de los bugs nacen desde la etapa de definici\u00f3n. Adicionalmente siempre preguntarnos si todo lo que vamos hacer realmente sirve o le aporta al producto). Los developers deben estar llenos de coraje<\/a> y no escuchar las definiciones del Product owner con obediencia.<\/li>
    2. Un buen proceso de CI<\/a> en el que existan branch protegidos (v\u00e9ase gitflow<\/a>) y para que un nuevo desarrollo llegue a la rama \u201cdevelop\u201d debe pasar por un proceso de revisi\u00f3n de PR<\/a>. Lo anterior debe ir acompa\u00f1ado de una mentalidad de calidad, nada debe llegar a develop sin garantizar que est\u00e1 bien desarrollado (un developer que apruebe un PR sin hacer una revisi\u00f3n exhaustiva es un developer que no entiende a\u00fan su trabajo ).<\/li>
    3. Buenas pruebas unitarias y de integraci\u00f3n, no pruebas para cumplir con el coverage<\/a> que nos den un falso positivo y una sensaci\u00f3n de falsa calidad.<\/li>
    4. Revisiones pares o en conjunto de la funcionalidad terminada y no por partes. A veces sucede que el \u2018Developer A\u2019 le hace una revisi\u00f3n par al \u2018Developer B\u2019 y todo funciona correctamente, pero al integrar los desarrollos no funcione y qued\u00e1ndose con la idea de que funciona porque \u2018Developer A\u2019 hizo una revisi\u00f3n. Por supuesto no estoy diciendo que no sirva las revisiones Par al finalizar un desarrollo individual, digo que se debe hacer una revisi\u00f3n completa una vez se tiene lista la versi\u00f3n por Sprint<\/a> si es posible entre varios mejor.