Introducción
Si ya tienes conocimientos de Scrum puedes adelantarte esta sección, si apenas estas empezando a investigar al respecto, sigue adelante con esta breve introducción.
Actualmente, y desde hace unos meses en México se percibe un crecimiento por el interés en Scrum, algunas empresas y algunas personas no saben que criterios utilizar para elegir la entidad certificadora y basamos (me incluyo) nuestra decisión en lo que solemos escuchar en la oficina o con nuestros amigos involucrados en el medio.
Un poco de historia.
Si, historia, aunque no todos estemos atraídos por la historia, en este caso es necesario para entrar en contexto, no te preocupes, trataré de no aburrirte con fechas.
Tenemos que poner nuestro punto de partida en el siglo pasado, a finales de los 50’s y principios de los 60’s cuando hubo un “boom” en la demanda de profesionales que pudiesen programar software, la industria no sabía como debía manejar esta nueva “cosa” intangible (software) que montábamos sobre mecanismos tangibles (hardware) que eran bastante robustos y costosos.
El ser humano en su naturaleza por organizar y definir formas para que el desarrollo de software estuviese estandarizado reunió a un grupo de expertos-no_expertos, — les llamo Expertos, debido a que eran quienes estaban construyendo software, eran los representantes máximos de diferentes naciones en temas de computación, no había nadie más. Les llamo No_Expertos dado que en aquellos tiempos no existían las carreras de ingeniería de software y/o informática y/o computación que hoy en día tenemos–.
Este grupo se reunió para que definir como debíamos de construir software. El término ingeniería de software se mencionó por primera vez en dos conferencias realizadas en la OTAN en 1968 y 1969 (aquí te dejo el link por si quieres darle un vistazo), en dicha conferencia el tema fue la “crisis de software” y se buscó un enfoque de ingeniería que buscaba reducir costos y llevar a un software más confiable.
Los programadores tomaban como referencia otras áreas de la ingeniería, como la Civil, Mecánica y/o Eléctrica, incluso la habían ejercido de tal manera que la ingeniería de software era algo completamente nuevo.
Lo anterior derivó en una definición de ingeniería de software que trataba de emular-imitar otras ingenierías, ¿te suena el rol de Arquitecto en el ramo de la construcción como en el ramo de tecnología?, ¿o qué me dices de los planos de un edificio versus los planos escritos en lenguaje unificado de modelado (UML)?
Fue así, como se impulsó una forma de construir software mediante la definición de un modelo altamente predictivo y secuencial que hoy en día conocemos como Cascada o Waterfall (por el inglés), y que puedes certificarte con una institución internacional llamada PMI (Project Management Institute)… Qué por cierto, si un día te presentas en uno de estos cursos te encontrarás a más de uno que no viene de TI.
Una manera diferente de hacer las cosas.
Como platicábamos en aquellos tiempos, de común acuerdo todos empezaron a desarrollar software de manera predictiva utilizando cascada, ¿el resultado?, empezaron a surgir más y diferentes problemas en la industria del software, durante las décadas de los 70’s y 80’s, ¿Cuáles eran?
- Desborde de presupuesto. Tratar de predecir el proyecto desde un inicio llevaba a no concluir en tiempo, y por lo tanto, elevaba los costos anticipados del proyecto, de hecho, eso aún pasa en muchas empresas en México.
- Liberación de software defectuoso. Por tratar de liberar a producción en tiempo y forma se descuidaban actividades de aseguramiento de calidad que provocaban liberaciones defectuosas, y por consiguiente, el esfuerzo por “parchar” dichos defectos en siguientes versiones. Creo que esto también esta vigente en nuestro país y en algunos otros.
- Funcionalidades inútiles. Hablamos de funcionalidades que el usuario final nunca utilizó, que a alguien se le ocurrió que eran buena idea, las metió en el documento de especificación de requerimientos, el equipo de desarrollo las construyó y el equipo de pruebas ejecutó diversos escenarios para asegurarse de que la implementación fuera correcta, ¿Alguna vez has usado todas las características de las aplicaciones instaladas en tu smartphone?
Dado lo anterior surgieron pensamientos e ideas para construir software fuera del canon, algunas de estas personas incluso se sintieron “sucios” por no tener hermosos diagramas de Gantt y no estar diseñando los planos de sus sistemas mediante elegantes diagramas de UML, la razón, no tenían tiempo, urgía más construir software antes que pasar por las etapas de análisis y diseño.
Entre este grupo de personas (ubicados en diferentes zonas geográficas), se encuentra una persona de nombre Jeff Sutherland, quien en conjunto con Ken Schwaber, empiezan a dar forma a sus ideas después de leer un artículo publicado en 1986 en la revista de Harvard: “The new new product development game”, ideas que después se plasmarían en el Framework de Scrum.
El 2001 y el manifiesto ágil.
Como mencionábamos, Jeff y Ken, junto con otro grupo de personas sabían que se debía encontrar una forma diferente de desarrollar software, una forma en la cual se evitaran los problemas que todos los proyectos a nivel internacional estaban presentando, una manera a la que posteriormente le llamarían “ágil”.
¿Quiénes se encontraron entre febrero 11 y 13 de 2001 para escribir y firmar dicho manifiesto?, solo por mencionar a algunos de ellos:
- Jeff Sutherland. Uno de los creadores de Scrum.
- Kent Beck. Uno de los creadores de la Programación Extrema y el Desarrollo Orientado por Pruebas.
- Ken Schwaber. Co-creador de Scrum.
- Martin Fowler. También co-creador de la Programación Extrema y experto en análisis y diseño orientado a objetos con UML.
- Mike Beedle. Doctor en física y autor del primer libro de Scrum y el primero documento publicado sobre Scrum.
- Robert C. Martin. También se le conoce como Uncle Bob , incluso una de sus empresas tiene el mismo seudónimo. Es co-autor de diversos libros, por mencionar The Clean Coder, Clean Architecture.
- Ward Cunningham. El tercer co-creado de la Programación Extrema, también creo el primer sitio Wiki.
Si quieres revisar la lista completa, aquí te dejo el sitio oficial y aquí esta otro enlace con un breve biografía de cada uno.
¿A qué va todo lo anterior?
Ya que estamos en contexto, a partir de este momento, en el futuro te platicaremos de Scrum, eXtreme Programing, Kanban y el mundo relacionado al desarrollo de productos de software bajo el enfoque Agile.
¿Te gustaría conocer más y certificarte en el camino? Te invito a que me acompañes a mi siguiente curso de certificación, escríbeme a michel.perez@fractal-ti.com.
El blog de Jorge García (yoryo) 