#13 del libro peopleware, hiring a juggler: "https://blogs.kde.org/2004/04/22/hiring-jugglers"
"...muchos proyectos informáticos públicos que han pasado por mil manos..."
Este es el problema, y no sólo por los fallos de seguridad que son los que salen en la noticias y llaman la atención, lo que está mal de base es la forma en la que la administración desarrolla el software que necesita. A ver cuando alguien entiende que el software no es un producto cerrado que se encarga como el que compra una mesa, el software es algo en constante evolución que contiene las reglas de negocio con las que funciona la administración, el conocimiento sobre cómo está construido este software y la capacidad para cambiarlo no se puede dejar en empresas externas, tiene que estar en la propia administración.
Si no tienes capacidad de modificar el software que gobierna tu administración sin recurrir a empresas externas, has perdido tu autonomía como organización y no tienes control sobre la calidad del software que te gobierna. Actualmente el software tiene un papel CENTRAL en cualquier organización compleja, y cada vez tendrá un papel más y más importante, si lo dejas en manos de terceros, y encima de terceros cuya única preocupación es vender horas de programadores y llenarse los bolsillos, pues estos son los resultados. Claro que no es un problema aislado el caso de lexnet, es una evidencia más (como si hubiera ya pocas), de que este modelo de desarrollo de software para la administración no funciona y además nos cuesta una pasta a todos.
"El precario sector del software", no el sector no, una parte del sector es precario, por suerte no todo son cárnicas. ¿qué porcentaje del sector tienen esas carnicas?, la verdad es que no tengo ni idea, ni yo ni nadie porque no hay números de esto, no se puede hablar de las cárnicas como si fueran "todo" el sector porque no lo son.
De todas maneras, el problema gordo por desgracia no tiene que ver sólo con corruptelas y amiguismos como dice el de los tuit, ojala, pera la realidad es que hasta en una licitación limpia se siguen haciendo las cosas mal porque lo que falla es el enfoque de cómo la administración construye el software que necesita.
El problema es que la administración utiliza el mismo procedimiento para hacer software que para comprar mesas de despacho, el software no es un producto con X características que se empieza un día y se termina otro. El software en un administración es el sistema nervioso de la administración, es donde están las reglas de negocio que rigen su funcionamiento, si mañana quieres cambiar el funcionamiento de esa administración eso lo vas a tener que reflejar en tu software de alguna manera. Este software no es un desarrollo cerrado, es algo vivo que esta en constante cambio . Con esto en mente, externalizar todo el desarrollo es una barbaridad, la propia administración tendría que tener la capacidad de desarrollar y evolucionar este software, y sobre todo, tener de forma interna el conocimiento para hacerlo. Otra cosa es contratar empresas externas especializadas en esto y aquello para que te ayuden con determinadas cosas, cosas como formar a tu equipo, cosas como hacer una auditoria de seguridad etc,etc.
Mientras esto no cambie, la administración seguirá construyendo software de mierda gastando mucho más dinero del necesario, que sale de los bolsillos de todos. Los únicos contentos con la situación, los dueños de las cárnicas que se forran a costa de construir software de mierda en condiciones para sus trabajadores, no se si precarias, pero desde luego no muy buenas.
#91 No, no estoy diciendo eso, no inventes, y un consejo, de paso deja de inventar porcentajes así a boleo sin el más mínimo criterio.
No hacéis más que llorar, españa es una mierda!, las carnicas son una mierda!, no tengo suerte!. Y luego alguien os plantea que en esta profesión hay alternativas a eso, y lo atacais como si fuera el enemigo, pues nada chico, a seguir nadando en la mierda que parece que es lo que os gusta, es alucinante.
#86 ¿Manipular?, estoy informando de que igual que hay ofertas de mierder como la que tu has puesto hay otras muchas empresas que si buscan talento y ofrecen unas condiciones razonables. Evidentemente exigen unos conocimientos, no te van a pagar 45k al año por reinstalar windows con 0 años de experiencia.
Ahora, con esta información ya que cada cual haga lo que quiera, una opción es ver que piden este tipo de empresas que ofrecen buenas condiciones y prepararse en esa dirección, luego otra segunda opción es seguir lamentándose de lo mala que está la cosa. Cada cual que elija, yo sólo informo y no tengo ningún interés. En realidad si tengo uno, que alguien que este empezando en este mundo no se desanime con tanto cenizo, que esta profesión puede ser una forma cojonuda de ganarse la vida.
#91 No, no estoy diciendo eso, no inventes, y un consejo, de paso deja de inventar porcentajes así a boleo sin el más mínimo criterio.
No hacéis más que llorar, españa es una mierda!, las carnicas son una mierda!, no tengo suerte!. Y luego alguien os plantea que en esta profesión hay alternativas a eso, y lo atacais como si fuera el enemigo, pues nada chico, a seguir nadando en la mierda que parece que es lo que os gusta, es alucinante.
#59 Por contrastar, así a boleo entrando en trabajosRails y cogiendo la primera oferta para madrid: http://www.trabajosrails.com/jobs/506-senior-backend-developer
Hay una dicotomía muy grande en el sector, entra trabajar en una carnica y trabajar en una empresa de producto.
#86 ¿Manipular?, estoy informando de que igual que hay ofertas de mierder como la que tu has puesto hay otras muchas empresas que si buscan talento y ofrecen unas condiciones razonables. Evidentemente exigen unos conocimientos, no te van a pagar 45k al año por reinstalar windows con 0 años de experiencia.
Ahora, con esta información ya que cada cual haga lo que quiera, una opción es ver que piden este tipo de empresas que ofrecen buenas condiciones y prepararse en esa dirección, luego otra segunda opción es seguir lamentándose de lo mala que está la cosa. Cada cual que elija, yo sólo informo y no tengo ningún interés. En realidad si tengo uno, que alguien que este empezando en este mundo no se desanime con tanto cenizo, que esta profesión puede ser una forma cojonuda de ganarse la vida.
#91 No, no estoy diciendo eso, no inventes, y un consejo, de paso deja de inventar porcentajes así a boleo sin el más mínimo criterio.
No hacéis más que llorar, españa es una mierda!, las carnicas son una mierda!, no tengo suerte!. Y luego alguien os plantea que en esta profesión hay alternativas a eso, y lo atacais como si fuera el enemigo, pues nada chico, a seguir nadando en la mierda que parece que es lo que os gusta, es alucinante.
#72 O gente que trabaja en remoto desde cualquier parte porque son muy buenos en lo suyo, o gente que ante la situación ha decidido montarselo por su cuenta y correr el riesgo, o gente que se fue unos años a esas malditas ciudades y luego pudo volver a su zona con la experiencia adquirida, o en definitiva, gente que piensa que su futuro profesional no depende de factores externos (aka suerte) y que han sabido buscarse la vida (que ni es tan difícil, ni requiere tanto sacrificio en esta profesión por dios).
Ahora, si lo que quieres es quedarte en tu casa y esperar que alguien llame un día a la puerta ofreciendote 3000 euros por currar 3 días a la semana, pues entonces, coincido contigo en que para eso hace falta suerte.
#68 No, es más dificil, requiere más esfuerzo, pero no es cuestión de suerte.
De todas maneras, si tu crees que es cuestión de suerte, pues nada, sigue esperando a ver si un día te toca. Mientras tanto te podría hablar de gente casi en cualquier lugar de españa a la que le va de puta madre en esta profesión, y todos tienen algo en común, ninguno se quedó sentado esperando su "suerte".
#69 #52 #61 No es 100% suerte pero tampoco es 0%. Yo caí relativamente pronto en mi carrera laboral en un área que ha tenido tirón, eso fue suerte porque con 1 año y poco de experiencia laboral yo no tenia ni idea de que tipo de tecnologías tenían futuro y cuales no. Aparte de eso, supe aprovechar la oportunidad de manera digamos medio decente, cambiando de curro un par de veces y aprendiendo mas y mas de mi área. Eso no fue suerte. Pero las cosas no son blancas o negras.
Por ejemplo, quien nada mas licenciarse empieza de junior en SAP tiene una suerte que te cagas. Es un área de nicho bien pagada y que se usa en todas las empresas gordas, y con una barrera de entrada bastante gorda porque formarte por tu cuenta es muy difícil. La oportunidad muchas veces SI es suerte, saber aprovecharla (o saber huir a tiempo de otros curros donde no aprendes nada) no lo es.
#71 Es que SAP es practicamente monopolio, menudo garito tiene montado. Me hace gracia cuando la gente dice que si Microsoft esto, Microsoft lo otro... ja! 
#69 Y tuvieron la suerte de estar en el momento adecuado en el lugar preciso. Clientes que acaban de llegar, proyectos de reciente creacion, etc. o sea lo que comunmente se conoce como suerte.
Como contrapunto yo conozco a gente que se parte el lomo por la empresa, obtiene certificaciones, etc y no recibe ni una misera palmadita en la espalda. Y tu podrias decir: "si es bueno pues que se busque la vida" y yo te diria "si, en Madrid o Barna, pero... ¿y si no quieres vivir en esas mierdas de ciudades?"
#72 O gente que trabaja en remoto desde cualquier parte porque son muy buenos en lo suyo, o gente que ante la situación ha decidido montarselo por su cuenta y correr el riesgo, o gente que se fue unos años a esas malditas ciudades y luego pudo volver a su zona con la experiencia adquirida, o en definitiva, gente que piensa que su futuro profesional no depende de factores externos (aka suerte) y que han sabido buscarse la vida (que ni es tan difícil, ni requiere tanto sacrificio en esta profesión por dios).
Ahora, si lo que quieres es quedarte en tu casa y esperar que alguien llame un día a la puerta ofreciendote 3000 euros por currar 3 días a la semana, pues entonces, coincido contigo en que para eso hace falta suerte.
#61 El primer paso para que cambie tu "suerte" en esta profesión es precisamente entender que no es cuestión de suerte.
#63 En ciudades que no sean Madrid o Barna... Si, es cuestión de suerte.
#68 No, es más dificil, requiere más esfuerzo, pero no es cuestión de suerte.
De todas maneras, si tu crees que es cuestión de suerte, pues nada, sigue esperando a ver si un día te toca. Mientras tanto te podría hablar de gente casi en cualquier lugar de españa a la que le va de puta madre en esta profesión, y todos tienen algo en común, ninguno se quedó sentado esperando su "suerte".
#69 #52 #61 No es 100% suerte pero tampoco es 0%. Yo caí relativamente pronto en mi carrera laboral en un área que ha tenido tirón, eso fue suerte porque con 1 año y poco de experiencia laboral yo no tenia ni idea de que tipo de tecnologías tenían futuro y cuales no. Aparte de eso, supe aprovechar la oportunidad de manera digamos medio decente, cambiando de curro un par de veces y aprendiendo mas y mas de mi área. Eso no fue suerte. Pero las cosas no son blancas o negras.
Por ejemplo, quien nada mas licenciarse empieza de junior en SAP tiene una suerte que te cagas. Es un área de nicho bien pagada y que se usa en todas las empresas gordas, y con una barrera de entrada bastante gorda porque formarte por tu cuenta es muy difícil. La oportunidad muchas veces SI es suerte, saber aprovecharla (o saber huir a tiempo de otros curros donde no aprendes nada) no lo es.
#71 Es que SAP es practicamente monopolio, menudo garito tiene montado. Me hace gracia cuando la gente dice que si Microsoft esto, Microsoft lo otro... ja!
#69 Y tuvieron la suerte de estar en el momento adecuado en el lugar preciso. Clientes que acaban de llegar, proyectos de reciente creacion, etc. o sea lo que comunmente se conoce como suerte.
Como contrapunto yo conozco a gente que se parte el lomo por la empresa, obtiene certificaciones, etc y no recibe ni una misera palmadita en la espalda. Y tu podrias decir: "si es bueno pues que se busque la vida" y yo te diria "si, en Madrid o Barna, pero... ¿y si no quieres vivir en esas mierdas de ciudades?"
#72 O gente que trabaja en remoto desde cualquier parte porque son muy buenos en lo suyo, o gente que ante la situación ha decidido montarselo por su cuenta y correr el riesgo, o gente que se fue unos años a esas malditas ciudades y luego pudo volver a su zona con la experiencia adquirida, o en definitiva, gente que piensa que su futuro profesional no depende de factores externos (aka suerte) y que han sabido buscarse la vida (que ni es tan difícil, ni requiere tanto sacrificio en esta profesión por dios).
Ahora, si lo que quieres es quedarte en tu casa y esperar que alguien llame un día a la puerta ofreciendote 3000 euros por currar 3 días a la semana, pues entonces, coincido contigo en que para eso hace falta suerte.
Porque no se han leído peopleware, en concreto el capítulo "furniture police" un libro fundamental sobre management, centrado en desarrollo de software pero extrapolable a cualquier trabajo de oficina en muchos casos. Y mira que es antiguo...
#104 Estoy de acuerdo con casi todo lo que dices, pero no entiendo esa insistencia en decir que el agilismo es una metodologia en lugar de un conjunto de principios y valores. Scrum por ejemplo, define una serie de herramientas concretas para dar soporte a esos principios, scrum es un método concreto de materializar esos principios y valores, pero el agilismo en si no prescribe ningún proceso concreto, por eso no creo que el agilismo se pueda catalogar como metodología porque sólo define un marco conceptual y no procesos concretos.
Entiendo que esto es más un problema de naming y de semantica que otra cosa, por lo que dices me da la sensación de que estas considerando al agilismo como el conjunto de esos valores y principios más una serie de metodologias concretas que los materializan. En mi visión el agilismo es sólo el marco conceptual y las metodologías son procesos concretos para materializar las ideas de ese marco conceptual. Pero estamos hablando de lo mismo.
En lo que no estoy de acuerdo contigo es que el problema sea que la gente se lea el manifiesto y piense que el agilismo es algo hipster o poco serio. Yo el problema que me encuentro con más frecuencia es el contrario, que la gente se lee una guia de Scrum y lo aplica siguiendo la receta a ciegas sin leerse el manifiesto y sin entender los principios, y esto lleva a implementaciones de scrum fallidas y terminar haciendo cargo-cult scrum. Un ejemplo clasico es cuando la dirección de la empresa X decide implantar scrum porque algún jefecillo ha oído campanas pero luego quieren una estimación inicial del proyecto a un año vista, "Responding to change over following a plan" pero me das una fecha exacta de fin.
Y claro que esto es serio e ingenieristico si quieres llamarlo, no se si has visto esta charla de Gleen Vanderburg, si no la has visto echale un ojo que intuyo que te va a gustar:
Y hombre no te trato de tonto, pero no me vengas "corrigiendo" y afirmando cosas como "no existe tal cosa como valores ágiles" taxativamente cuando precisamente los autores del manifiesto, que son en definitiva los que han definido que es y que no es agilismo, dicen explicitamente que el manifiesto es un conjunto de valores y principios.
Y yo también me decido a esto, desde la época en la que a los que hablábamos de cosas como TDD o scrum nos miraban raro y nos juntábamos cuatro gatos en las primeras reuniones de agile madrid para contarnos las penas.
#96 El "agilismo" no es una metodología concreta, en realidad el termino agil aparece en una reunión donde diversas personas con cierta relevancia dentro del sector y que proponían cada uno diferentes metodologías buscan que cosas tienen esas metodologías en común y redactan el famoso manifiesto agil que se compone concretamente de 4 valores y 12 principios.
Tipos específicos de proceso son scrum, extreme programing o incluso kanban. Pero el agilismo no prescribe ningún proceso especifico, se limita a exponer un conjunto de valores y practicas. Y esto no lo digo yo, lo dicen sus creadores, si no te gusta la definición se lo puedes comentar a jeff shuterland, kent beck, alistair cockburn etc,etc.
Por ejemplo, en palabras de Jeff Shuterland, el creador de scrum: "The Agile Manifesto established a common set of overarching values and principles for all of the individual agile methodologies at the time.", articulo completo: https://msdn.microsoft.com/en-us/library/dd997578(v=vs.120).aspx
#101 Se perfectamente quien es Kent Beck, de hecho me gusta su libro 'TDD by Example'.
Dicho esto, yo opino que el agilismo si es una metodologia. Es especificamente una metodología de resolución de problemas de alta incertidumbre. Basicamente el concepto principal del agilismo es que cuando tus problemas tienen mucha incertidumbre, es muy probable que te equivoques. El problema de equivocarse no es el coste del error en si, sino cuanto tardas entender que te equivocaste.
Si estas creando un software y entendiste mal algo, cuanto mas continúes en tu error, mas caro será. Por lo que cuanto antes te des cuenta de si vas por el buen camino o no, mejor.
Para poder crear este marco de trabajo de iteraciones cortas, se han de dar una serie cirscumstancias especificas que permitan hacer el setup de la iteracion, ejecutarla y comprobar resultado, obteniendo feedback. Entonces, es en esta parte donde puede ser útil esta parte filosófica de la que se habla (demasiado creo yo). Por ejemplo, es imposible montar un ciclo de iteraciones con feedback para resolver un problema si no tenemos claro donde empieza y acabar la iteración. Ni tampoco tenemos claro como validar la iteración ni nada.
Si no me crees que el agilismo es unica y exclusivamente esto, podemos escoger cualquier metodología especifica que resuelve un problema especifico usando agilismo y ver si esto que estoy diciendo es cierto. En todas vamos a encontrar el mismo patrón: una estructura y prácticas pensadas para favorecer el setup de un ciclo de feedback.
De hecho, otro gran error que cometes es pensar que agilismo lo ha inventado Kent Beck y los demás. En realidad el agilismo (metodologías iterativas) es mucho mas antiguo que Kent Beck y que Xtreme programming etc. De hecho, tienes ejemplos en Toyota desde al menos 1940.
https://en.wikipedia.org/wiki/Kanban
Podrías argumentar que fueron Kent Beck y los demás quien lo llamaron agilismo. Y estoy de acuerdo y es un nombre bueno, pero el concepto es mucho mas antiguo que ese nombre.
Cualquier punto del agile manifesto está pensado para crear un modelo de iterativo basado en el feedback en lugar de en la planificación:
Individuals and interactions over processes and tools
Evidentemente, por que los procesos se han de diseñar upfront, de antemano, igual que las herramientas. Mientras que los humanos se adaptan al cambio. (recuerda que la adptación al cambio es la obsesión de Kent Beck: build for change, not the future. Y esa obsesión es fruto del sistema basado en el feedback.
Si usasemos procesos, no podríamos ser agiles. Es decir, no podríamos crear un ciclo de feedback rapido y responder al feedback según necesitemos, pues estaríamos rehaciendo los procesos todo el tiempo para que se adapten a nuestra evolución.
Working software over comprehensive documentation
Claro, por que la documentación es cara de hacer y cuando el software evoluciona sin parar en ciclos rapidos, se queda obsoleta muy rapido.
Customer collaboration over contract negotiation
Claro, por que la realidad la descubrimos poco a poco a través de las iteraciones, por lo que negociar de antemano todo es imposible.
Responding to change over following a plan
Y la última, la mas basica y de lo que va todo: los planes solo funcionan cuando puedes predecir, y solo puedes predecir hasta cierto nivel de incertidumbre.
Pero echemos un vistazo a las metodologías especificas que surgen del concepto iterativo incremental del agilismo:
Scrum: iteraciones de tamaño semana, donde el ciclo lo que valida es que el software que construimos y el valor que aportamos es el esperado. Para poder crear el ciclo del que hablo, se define un input claro (user story) y un output claro (software que cumple la user story y unos criterios de aceptación comunes, especificados en la definition of done). Un inicio de ciclo claro (planning) y un final de ciclo claro (entrega, final de sprint). Las reuniones de pie y todas esas tonterías, basicamente son por que la gente tiene tendencia a planificarlo todo, asi que cuanto menos dure la reunión, menos waterfall se vuelve la gente.
TDD (Test Driven development): iteraciones cortas, de minutos, basadas en pruebas repetibles de software, a través de las cuales se descubre la mejor forma de resolver un problema o diseñar una parte de nuestro programa. En lugar de planificar todo upfront, con TDD el diseño emerge durante las pruebas, como consecuencia de los ciclos de feedback cortitos e incrementales.
Customer Development (Lean startup para los hipsters): iteraciones cortas y rapidas para diseñar productos que sacar al mercado. Ciclos de feedback claros, pruebas claramente definidas y con un resultado claro. A través de las iteraciones se va mejorando el producto usando el feedback real de mercado.
Estos son 3 ejemplos de problemas clasicos resueltos con metodologias agiles: gestion de proyectos de software, diseño y desarollo de software y desarollo de productos. Los 3 tienen en común una incertidumbre muy grande que impide aplicar waterfall. Por eso en los 3 se aplica un sistema que se reduce al final a iterar con feedback para dar pasos pequeños, ver si el paso ha sido correcto, y luego dar el siguiente. Así hasta llegar a donde quieres.
La verdad es que me da mucha pena lo que está pasando con el agilismo. La gente se lee el agile manifesto y se piensa que esto es algo de hippies, que esto va de una filosofia, unos principios, un 'estilo' de hacer las cosas. Pero al final todo esto es mucho mas ingenieristico. Esto va da la forma mas eficiente de llevar a cabo una tarea cuando la incertidumbre es muy alta: y esto no lo digo yo, lo dice Kent Beck en su libro 'Extreme Programming Explained':
https://en.wikipedia.org/wiki/Extreme_programming
Pero normalmente la gente no lee este tipo de libros, como the four steps to the epiphany o Exteme programming explained. A mi me gusta entender las bases de las cosas y reflexionar sobre lo que hago y por que lo hago, pero al menos no me trates de #101 de tonto o de ignorante en una materia a la que dedico mi vida y de la que algo se y he leído.
#104 Estoy de acuerdo con casi todo lo que dices, pero no entiendo esa insistencia en decir que el agilismo es una metodologia en lugar de un conjunto de principios y valores. Scrum por ejemplo, define una serie de herramientas concretas para dar soporte a esos principios, scrum es un método concreto de materializar esos principios y valores, pero el agilismo en si no prescribe ningún proceso concreto, por eso no creo que el agilismo se pueda catalogar como metodología porque sólo define un marco conceptual y no procesos concretos.
Entiendo que esto es más un problema de naming y de semantica que otra cosa, por lo que dices me da la sensación de que estas considerando al agilismo como el conjunto de esos valores y principios más una serie de metodologias concretas que los materializan. En mi visión el agilismo es sólo el marco conceptual y las metodologías son procesos concretos para materializar las ideas de ese marco conceptual. Pero estamos hablando de lo mismo.
En lo que no estoy de acuerdo contigo es que el problema sea que la gente se lea el manifiesto y piense que el agilismo es algo hipster o poco serio. Yo el problema que me encuentro con más frecuencia es el contrario, que la gente se lee una guia de Scrum y lo aplica siguiendo la receta a ciegas sin leerse el manifiesto y sin entender los principios, y esto lleva a implementaciones de scrum fallidas y terminar haciendo cargo-cult scrum. Un ejemplo clasico es cuando la dirección de la empresa X decide implantar scrum porque algún jefecillo ha oído campanas pero luego quieren una estimación inicial del proyecto a un año vista, "Responding to change over following a plan" pero me das una fecha exacta de fin.
Y claro que esto es serio e ingenieristico si quieres llamarlo, no se si has visto esta charla de Gleen Vanderburg, si no la has visto echale un ojo que intuyo que te va a gustar:
Y hombre no te trato de tonto, pero no me vengas "corrigiendo" y afirmando cosas como "no existe tal cosa como valores ágiles" taxativamente cuando precisamente los autores del manifiesto, que son en definitiva los que han definido que es y que no es agilismo, dicen explicitamente que el manifiesto es un conjunto de valores y principios.
Y yo también me decido a esto, desde la época en la que a los que hablábamos de cosas como TDD o scrum nos miraban raro y nos juntábamos cuatro gatos en las primeras reuniones de agile madrid para contarnos las penas.
Un articulo de un medio generalista sobre "desarrollo de software agil" que se queda en la anécdota, no es estar a las 9:06 en punto o salir a las 6 lo que hace que esta empresa funcione, son los valores y los principios que esta empresa tendrá si son verdaderamente agiles, y esta forma de reunirse y organizarse será consecuencia de la aplicación de estos valores y principios. Vamos que nadie se piense que si pone una reunión a las 9:06 su empresa/equipo va a funcionar mejor así por arte de magia, será simplemente el enésimo caso de cargo cult (http://www.jamesshore.com/Blog/Cargo-Cult-Agile.html)
Y espero que el código que sale en la foto no sea un ejemplo de lo que hacen... un método que no cabe en la pantalla, duplicación de código evidente, dos elseif y uno que solo contiene un comentario... canela fina jeje.
#92 el agilismo es una metodología de resolución de problemas de alta incertidumbre. Es una metodología iterativa con ciclos cortos que a través del feedback reduce el coste provocado por la incertidumbre.
no existe tal cosa como valores ágiles, ya que insisto en que el agilismo no es una filosofía, sino un tipo especifico de proceso.
#96 El "agilismo" no es una metodología concreta, en realidad el termino agil aparece en una reunión donde diversas personas con cierta relevancia dentro del sector y que proponían cada uno diferentes metodologías buscan que cosas tienen esas metodologías en común y redactan el famoso manifiesto agil que se compone concretamente de 4 valores y 12 principios.
Tipos específicos de proceso son scrum, extreme programing o incluso kanban. Pero el agilismo no prescribe ningún proceso especifico, se limita a exponer un conjunto de valores y practicas. Y esto no lo digo yo, lo dicen sus creadores, si no te gusta la definición se lo puedes comentar a jeff shuterland, kent beck, alistair cockburn etc,etc.
Por ejemplo, en palabras de Jeff Shuterland, el creador de scrum: "The Agile Manifesto established a common set of overarching values and principles for all of the individual agile methodologies at the time.", articulo completo: https://msdn.microsoft.com/en-us/library/dd997578(v=vs.120).aspx
#101 Se perfectamente quien es Kent Beck, de hecho me gusta su libro 'TDD by Example'.
Dicho esto, yo opino que el agilismo si es una metodologia. Es especificamente una metodología de resolución de problemas de alta incertidumbre. Basicamente el concepto principal del agilismo es que cuando tus problemas tienen mucha incertidumbre, es muy probable que te equivoques. El problema de equivocarse no es el coste del error en si, sino cuanto tardas entender que te equivocaste.
Si estas creando un software y entendiste mal algo, cuanto mas continúes en tu error, mas caro será. Por lo que cuanto antes te des cuenta de si vas por el buen camino o no, mejor.
Para poder crear este marco de trabajo de iteraciones cortas, se han de dar una serie cirscumstancias especificas que permitan hacer el setup de la iteracion, ejecutarla y comprobar resultado, obteniendo feedback. Entonces, es en esta parte donde puede ser útil esta parte filosófica de la que se habla (demasiado creo yo). Por ejemplo, es imposible montar un ciclo de iteraciones con feedback para resolver un problema si no tenemos claro donde empieza y acabar la iteración. Ni tampoco tenemos claro como validar la iteración ni nada.
Si no me crees que el agilismo es unica y exclusivamente esto, podemos escoger cualquier metodología especifica que resuelve un problema especifico usando agilismo y ver si esto que estoy diciendo es cierto. En todas vamos a encontrar el mismo patrón: una estructura y prácticas pensadas para favorecer el setup de un ciclo de feedback.
De hecho, otro gran error que cometes es pensar que agilismo lo ha inventado Kent Beck y los demás. En realidad el agilismo (metodologías iterativas) es mucho mas antiguo que Kent Beck y que Xtreme programming etc. De hecho, tienes ejemplos en Toyota desde al menos 1940.
https://en.wikipedia.org/wiki/Kanban
Podrías argumentar que fueron Kent Beck y los demás quien lo llamaron agilismo. Y estoy de acuerdo y es un nombre bueno, pero el concepto es mucho mas antiguo que ese nombre.
Cualquier punto del agile manifesto está pensado para crear un modelo de iterativo basado en el feedback en lugar de en la planificación:
Individuals and interactions over processes and tools
Evidentemente, por que los procesos se han de diseñar upfront, de antemano, igual que las herramientas. Mientras que los humanos se adaptan al cambio. (recuerda que la adptación al cambio es la obsesión de Kent Beck: build for change, not the future. Y esa obsesión es fruto del sistema basado en el feedback.
Si usasemos procesos, no podríamos ser agiles. Es decir, no podríamos crear un ciclo de feedback rapido y responder al feedback según necesitemos, pues estaríamos rehaciendo los procesos todo el tiempo para que se adapten a nuestra evolución.
Working software over comprehensive documentation
Claro, por que la documentación es cara de hacer y cuando el software evoluciona sin parar en ciclos rapidos, se queda obsoleta muy rapido.
Customer collaboration over contract negotiation
Claro, por que la realidad la descubrimos poco a poco a través de las iteraciones, por lo que negociar de antemano todo es imposible.
Responding to change over following a plan
Y la última, la mas basica y de lo que va todo: los planes solo funcionan cuando puedes predecir, y solo puedes predecir hasta cierto nivel de incertidumbre.
Pero echemos un vistazo a las metodologías especificas que surgen del concepto iterativo incremental del agilismo:
Scrum: iteraciones de tamaño semana, donde el ciclo lo que valida es que el software que construimos y el valor que aportamos es el esperado. Para poder crear el ciclo del que hablo, se define un input claro (user story) y un output claro (software que cumple la user story y unos criterios de aceptación comunes, especificados en la definition of done). Un inicio de ciclo claro (planning) y un final de ciclo claro (entrega, final de sprint). Las reuniones de pie y todas esas tonterías, basicamente son por que la gente tiene tendencia a planificarlo todo, asi que cuanto menos dure la reunión, menos waterfall se vuelve la gente.
TDD (Test Driven development): iteraciones cortas, de minutos, basadas en pruebas repetibles de software, a través de las cuales se descubre la mejor forma de resolver un problema o diseñar una parte de nuestro programa. En lugar de planificar todo upfront, con TDD el diseño emerge durante las pruebas, como consecuencia de los ciclos de feedback cortitos e incrementales.
Customer Development (Lean startup para los hipsters): iteraciones cortas y rapidas para diseñar productos que sacar al mercado. Ciclos de feedback claros, pruebas claramente definidas y con un resultado claro. A través de las iteraciones se va mejorando el producto usando el feedback real de mercado.
Estos son 3 ejemplos de problemas clasicos resueltos con metodologias agiles: gestion de proyectos de software, diseño y desarollo de software y desarollo de productos. Los 3 tienen en común una incertidumbre muy grande que impide aplicar waterfall. Por eso en los 3 se aplica un sistema que se reduce al final a iterar con feedback para dar pasos pequeños, ver si el paso ha sido correcto, y luego dar el siguiente. Así hasta llegar a donde quieres.
La verdad es que me da mucha pena lo que está pasando con el agilismo. La gente se lee el agile manifesto y se piensa que esto es algo de hippies, que esto va de una filosofia, unos principios, un 'estilo' de hacer las cosas. Pero al final todo esto es mucho mas ingenieristico. Esto va da la forma mas eficiente de llevar a cabo una tarea cuando la incertidumbre es muy alta: y esto no lo digo yo, lo dice Kent Beck en su libro 'Extreme Programming Explained':
https://en.wikipedia.org/wiki/Extreme_programming
Pero normalmente la gente no lee este tipo de libros, como the four steps to the epiphany o Exteme programming explained. A mi me gusta entender las bases de las cosas y reflexionar sobre lo que hago y por que lo hago, pero al menos no me trates de #101 de tonto o de ignorante en una materia a la que dedico mi vida y de la que algo se y he leído.
#104 Estoy de acuerdo con casi todo lo que dices, pero no entiendo esa insistencia en decir que el agilismo es una metodologia en lugar de un conjunto de principios y valores. Scrum por ejemplo, define una serie de herramientas concretas para dar soporte a esos principios, scrum es un método concreto de materializar esos principios y valores, pero el agilismo en si no prescribe ningún proceso concreto, por eso no creo que el agilismo se pueda catalogar como metodología porque sólo define un marco conceptual y no procesos concretos.
Entiendo que esto es más un problema de naming y de semantica que otra cosa, por lo que dices me da la sensación de que estas considerando al agilismo como el conjunto de esos valores y principios más una serie de metodologias concretas que los materializan. En mi visión el agilismo es sólo el marco conceptual y las metodologías son procesos concretos para materializar las ideas de ese marco conceptual. Pero estamos hablando de lo mismo.
En lo que no estoy de acuerdo contigo es que el problema sea que la gente se lea el manifiesto y piense que el agilismo es algo hipster o poco serio. Yo el problema que me encuentro con más frecuencia es el contrario, que la gente se lee una guia de Scrum y lo aplica siguiendo la receta a ciegas sin leerse el manifiesto y sin entender los principios, y esto lleva a implementaciones de scrum fallidas y terminar haciendo cargo-cult scrum. Un ejemplo clasico es cuando la dirección de la empresa X decide implantar scrum porque algún jefecillo ha oído campanas pero luego quieren una estimación inicial del proyecto a un año vista, "Responding to change over following a plan" pero me das una fecha exacta de fin.
Y claro que esto es serio e ingenieristico si quieres llamarlo, no se si has visto esta charla de Gleen Vanderburg, si no la has visto echale un ojo que intuyo que te va a gustar:
Y hombre no te trato de tonto, pero no me vengas "corrigiendo" y afirmando cosas como "no existe tal cosa como valores ágiles" taxativamente cuando precisamente los autores del manifiesto, que son en definitiva los que han definido que es y que no es agilismo, dicen explicitamente que el manifiesto es un conjunto de valores y principios.
Y yo también me decido a esto, desde la época en la que a los que hablábamos de cosas como TDD o scrum nos miraban raro y nos juntábamos cuatro gatos en las primeras reuniones de agile madrid para contarnos las penas.
#43 El master Dijkstra decia: "Program testing can be used to show the presence of bugs, but never to show their absence!". Personalmente soy defensor de cosas como TDD y es mi forma de trabajo, pero si algo falla en producción falla y hay que arreglarlo tengas los tests que tengas. La falta de competencia técnica es un problema igual que lo es la falta de competencia en la gestión y la definición de producto, y normalmente suelen ir juntas.
Hombre está bien que lo eliminen si eso sirve para que el Visual Studio arranque un poquito más rápido...
UML puede tener su valor en determinadas situaciones, para explicar algunas cuestiones de diseño y tener una visión compartida en el equipo, pero esto se puede hacer en una pizarra, en una hoja de papel o en cualquier herramienta sencilla. No veo la necesidad de tenerlo integrado en un IDE, así que por mi estupendo, los IDE's como VS lo que necesitan es hacer menos cosas y hacerlas mejor y más rápido no tropecientas funcionalidades que se usan raramente y sólo sirven para sobrecargar de funcionalidad el monstruo.
#103 Es una forma de catalogar un uso real que se hace de UML en la industria, y fowler lo que hace es simplemente reflejar esa realidad ponerle un nombre y ayudarnos a todos a entender las motivaciones de la gente que usa las cosas de una determinada forma. Y Fowler, creeme, sabe de lo que habla. Leete el articulo.
#90 Eso que llamas "diagramas y bolitas" es un uso del UML que fowler catalogaba como "UML as Sketch" (http://martinfowler.com/bliki/UmlMode.html como siempre, leer a a fowler obligatorio :P), dibujos informales que pueden ayudar sobre todo para compartir en un equipo una idea de diseño, a mucha gente le ayuda verlo visualmente y no esta mal tener un lenguaje común de modelado donde sepamos que es una flecha y que es una caja, aunque sin mucho formalismo porque entonces te pierdes en los detalles y precisamente eso juega en contra de tener una visión compartida de algo simple y rápida.
Lo que nunca ha funcionado muy bien es tratar de usar "UML as blueprint" o "UML as programming language", donde UML tiene un rol central en el desarrollo, en general las herramientas visuales de programación visual o mediante diagramas se han demostrado con los años bastante ineficientes y engorrosas y hoy en día poca gente se plantea su uso, los más viejunos podemos recordar como estas herramientas se supone que iban a ser la panacea a finales de los 90 principios de los 2000 y al final como tantas cosas en software la cosa quedo en agua de borrajas.
#101 Si, porque listos los de UML, cuando lo diseñaron, dijeron "coño, vamos a llamar todo lo que esta dibujado con diagramas y bolitas "UML as Sketch", y nos quedamos tan anchos".
Es una forma de decir mira, mi forma de programacion es Patatin, todo lo que no sea mi forma de programacion es "Patatin as Sketch".
Olé.
#103 Es una forma de catalogar un uso real que se hace de UML en la industria, y fowler lo que hace es simplemente reflejar esa realidad ponerle un nombre y ayudarnos a todos a entender las motivaciones de la gente que usa las cosas de una determinada forma. Y Fowler, creeme, sabe de lo que habla. Leete el articulo.
#101 Quizás de forma más general, y no solo aplicado a UML, a veces se olvida que un buen profesional sabe la diferencia entre cuando debe saltarse las "normas" y cuando debe aprovecharlas. Al final todo es un compromiso entre lo que ganas y lo que pierdes, un diagrama muy general puede ayudar a entender fácilmente cuál es la idea detrás de un módulo.
Una de las primeras cosas contra las que te advierten al estudiar programación son las variables globales y los goto. Es una regla del pulgar válida, pero que cuando seas profesional tendrás que valorar donde te conviene saltártela.
#70 En una metodología en las que las fases de testing y despliegue se colocan sólo al final del proyecto, eso es waterfall, los problemas tanto funcionales que se descubren en la fase de testing como de infraestructura y no funcionales que se descubren en la fase de despliegue llegan siempre al final del proyecto, aunque las cosas se hayan echo bien, cuando llegan esas fases el tiempo que se va a tardar en resolver esos problemas es totalmente indeterminado, como metodología es absurdo, es un proceso mal planteado. De echo si hablas de metodologías "clasicas" incluso RUP define su proceso como iterativo, nadie ni clásicos ni agilistas, hacen waterfall en realidad.
Tu hablaras de TU práctica del día a día o de la que hayas conocido, evidentemente si no cumples los principios agiles no estas haciendo agilismo así que no esperes otra cosa que alguien te venga "siempre con lo mismo de que no se aplican bien los principios ágiles" hasta que los apliques bien o dejes de decir que haces agilismo, una de dos. Yo llevo más de diez años aplicando metodologias agiles en mi día a día y ayudando a empresas a hacerlo, no hablo de sólo de "teoría" te hablo de cosas que en puesto en practica decenas de veces.
Yo creo que tenemos que empezar a cambiar la mentalidad y pensar al reves, en lugar de pensar "¿es posible hacer este trabajo en remoto?" yo me plantearía "¿que nos obliga a que este trabajo se tenga que hacer en una oficina?".
El trabajador se ahorra tiempo de desplazamientos y gana en calidad de vida y la empresa se ahorra en costes, todo el mundo sale ganando.
#21 Uno de los principios de XP, que se puede considerar la primera metodología ágil ampliamente conocida, es precisamente sustainable pace o ritmo sostenible vamos (http://www.extremeprogramming.org/rules/overtime.html). Si metes horas extra por sistema no estas siendo ágil, estas haciendo el tonto porque pocas cosas hacen más daño a un proyecto que quemar al equipo con horas extras.
Waterfall, que ni siquiera existe como metodología por cierto es más bien un error de interpretación de un paper, no es bueno ni para el trabajador ni para el producto, para el trabajador supone una etapa de falsa tranquilidad inicial seguido de un deadline al final que suele ser un absoluto desastre ahora si que horas extras a tutiplen y una carga de estrés brutal. Si vas entregando un proyecto en pequeñas iteraciones sostenibles el trabajador puede vivir con tranquilidad y hacer un buen producto, esto claro si se siguen los principios agiles, si nos limitamos a decir que hacemos scrum y lo único que hacemos es llenar las paredes de posit de colores y poner deadlines cada dos semanas pues entonces al carajo, lo que tenemos son mini-waterfalls de dos semanas.
#41 gran argumentación
#47 #28 siempre con lo mismo de "eso es que no se aplican bien los principios ágiles".
Nos ha jodido, es que si se aplicara bien la metodología tradicional, tampoco haría falta correr a última hora.
Yo os hablo de la práctica del día a día, y vosotros de la teoría. Al final es un problema de cultura del trabajo general, que no se arregla con metodologías concretas.
#70 En una metodología en las que las fases de testing y despliegue se colocan sólo al final del proyecto, eso es waterfall, los problemas tanto funcionales que se descubren en la fase de testing como de infraestructura y no funcionales que se descubren en la fase de despliegue llegan siempre al final del proyecto, aunque las cosas se hayan echo bien, cuando llegan esas fases el tiempo que se va a tardar en resolver esos problemas es totalmente indeterminado, como metodología es absurdo, es un proceso mal planteado. De echo si hablas de metodologías "clasicas" incluso RUP define su proceso como iterativo, nadie ni clásicos ni agilistas, hacen waterfall en realidad.
Tu hablaras de TU práctica del día a día o de la que hayas conocido, evidentemente si no cumples los principios agiles no estas haciendo agilismo así que no esperes otra cosa que alguien te venga "siempre con lo mismo de que no se aplican bien los principios ágiles" hasta que los apliques bien o dejes de decir que haces agilismo, una de dos. Yo llevo más de diez años aplicando metodologias agiles en mi día a día y ayudando a empresas a hacerlo, no hablo de sólo de "teoría" te hablo de cosas que en puesto en practica decenas de veces.
Yo tengo 37 y desde los 20 trabajo desarrollando software. A los 50 espero seguir dedicando a lo mismo porque es lo me gusta hacer.
Del articulo hay algunas cosas un poco ridiculas, como pensar que la evolución de un programador es terminar siendo analista y luego jefe de proyecto, esto será así en algunos lugares donde existen estas jerarquías absurdas donde un programador termina gestionando un equipo o donde el gestor es el jefe de los programadores, ninguna de las dos cosas tiene sentido. La tendencia es que cada vez exista menos jerarquía, por supuesto según niveles de experiencia o capacidad se tendrán distintas responsabilidades dentro de un equipo, pero los equipos tienden a ser más planos y la figura del gestor de proyectos a desaparecer en favor de equipos autogestionados con contacto directo con los clientes/responsables de producto. En ese contexto ser "programador" no implica quedarse toda la vida en el escalón más bajo por no querer o no estar capacitado para asumir tareas de gestión, simplemente con los años vas ganando experiencia y asumes más responsabilidades técnicas en los proyectos.
Y leyendo las opiniones de otros profesionales en el articulo, me entristece ver que seguimos a vueltas con las tonterías del intrusismo y los "no-informáticos". Para mi los únicos intrusos en esta profesión son los malos desarrolladores, y de estos por desgracia tenemos para dar y regalar, con titulo y sin titulo.
Muy deacuerdo con todo lo que dice el articulo, es importante ponerse algunas "normas" para no volverse un ermitaño del todo, como por ejemplo no trabajar en pijama jeje o salir al tomar el cafe fuera o dar una vuelta de cuando en cuando. Por un lado se puede aprovechar mucho mejor el día si te marcas unos horarios y por otro lado corres el riesgo de volverte loco y no desconectar nunca, es cuestión de plantearse unos buenos hábitos.
Lo único en lo que no coincido es sobre el punto de "aprender de tus compañeros", trabajar en remoto no implica trabajar sólo, yo paso la mayoría del día haciendo pair programming en remoto, igual que lo haría si estuviera en la misma oficina en presencial. Un equipo remoto que use bien sus herramientas de comunicación puede estar mucho mejor coordinado y compartir muchas más cosas que un equipo presencial con gente que se pone los cascos para trabajar y se aísla del mundo.
De todas formas prefiero el trabajo en remoto combinandolo con días en presencial de cuando en cuando, pero bueno cada equipo es diferente y tiene que encontrar la forma en la que todos estén más cómodos, que al final es lo que te permite hacer un buen trabajo.
Pues depende, hay trabajos donde la relación entra las horas dedicadas y lo que se produce es directamente proporcional y muy evidente, y luego hay otros trabajos donde esa relación no es tan evidente e incluso un número de horas excesivo puede ir en contra de la productividad.
Por lo general, en aquellos trabajos donde se necesite cierto grado de creatividad y frescura mental para resolver problemas más o menos complejos la relación entre horas y productividad no es nada evidente, depende mucho de cada persona, lo que realmente aumentaría la productividad en estos casos es dejar la libertad a cada persona de que decida cuantas horas dedicar, cuando dedicar esas horas, desde donde prefiere trabajar etc,etc. Esa libertad en la forma que organizas tu trabajo que te permita trabajar con comodidad es lo que te va a permitir tener la mente fresca y enfocada cuando estes haciendo tu trabajo, y si un tio es productivo para la empresa me da igual que trabaje 6 horas, 4 o 10 o que trabaje por las mañanas, por las tardes o en su casa de madrugada.
Aunque parezca lo normal, lo que es tremendamente extraño y anti-productivo es obligar a la gran mayoría de trabajadores a hacer las mismas horas, los mismos días de la semana, a tener que desplazarse a diario, aunque sean personas con formas de trabajar totalmente diferentes, con necesidades totalmente diferentes y se dediquen a actividades totalmente diferentes.
#41 Vamos, que aquellos trabajos en los que no sale a cuenta reducir la jornada son aquellos que tienen más probabilidades de ser sustituidos por robots. Blanco y en botella...
La historia es difícil de creer, no sólo se debe sino que es imprescindible en cualquier sitio serio automatizar la labor de testing, lo que no es creible es que la automatización que construyo le sirva durante 6 años sin cambios, el software que estaba probando tendría nuevas features en esos 6 años digo yo y tendría que ir actualizando esas pruebas automáticas para que probasen esas nuevas features, en caso contrario una de dos esa empresa lleva 6 años sin añadir nada nuevo a su software, parece poco creíble, o el tio realmente no estaba haciendo ni el huevo.
Me preocupa que la moraleja parezca ser "no automatices que te quedas sin trabajo", cuando debería ser justo lo contrario, si automatizas las partes mecánicas de tu trabajo podrás dedicarte ha hacer cosas mucho más satisfactorias que pasar una bateria de pruebas manualmente todos los días, cosas como seguir automatizando pruebas y mejorar la detección y los informes de error, automatizar otro tipo de pruebas (pruebas de carga, pruebas de rendimiento), ayudar al equipo de desarrollo para que los fallos no lleguen a QA (por ejemplo enseñandoles a crear ellos sus propias pruebas automáticas). Si haces estas cosas no sólo no perderas tu trabajo sino que te convertiras en alguien con unos concimientos tremendamente valiosos tanto para esa compañia como para muchas otras, a un experto en automatización de pruebas no le falta el trabajo y además tiene un trabajo interesante. Un tio de QA que no automatice y se dedique a apretar botones siguiendo un plan de pruebas tiene un trabajo monotono y aburrido a más no poder y ningún conocimiento especialmente valioso.
Este tema me preocupa que me acerco peligrosamente a los 40 jaja. En mi experiencia entre las distintas variables que determinan si alguien es buen o mal desarrollador la edad no es de lo más determinantes, conozco chavales de menos de 25 que son increíblemente buenos y gente de más de 40 anquilosados, y también conozco todo lo contrario. Al final la edad va acentuando lo que uno es, el que es bueno con la edad irá siendo mejor y mejor por la experiencia acumulada y el que es malo cada vez sera peor por el desgaste, la falta de actualización y el encabezamiento con x formas de hacer las cosas anticuadas y que siguen aplicando porque si, sin contextualizarlas, porque en el fondo nunca las entendieron