a

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...

a

#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.

a

#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

a

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.

a

#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.

a

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.

a

#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.

a

#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.

a

#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.

a

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.

a

#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.

a

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.

a

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.

a

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.

a

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.

a

Para empezar no tengo muy claro que es eso de "desarrollador web" y que sentido tiene categorizar a los desarrolladores simplemente por que el mecanismo de entrega sea web, mobile, desktop o haga aplicaciones por linea de comandos. ¿Hablamos de desarrolladores que tunean un wordpress para una pyme?, ¿o hablamos de desarrolladores de sistemas más complejos que ofrecen una UI web al usuario?. En estas categorías se mezcla todo y no tiene ningún sentido hacer la media y decir "esto es lo que gana un desarrollador web en X" porque en realidad eso de "desarrollador web" es un concepto tan difuso que no dice nada.

Un desarrollador automatiza cosas y programa reglas de negocio, si eso luego se traduce en una web, una app de mobil o lo que sea es sólo un detalle más que tiene que dominar dentro de su profesión, que es desarrollar software, igual que tendrá que dominar mecanismos de persistencia, concurrencia, pruebas automáticas, control de versiones y otras doscientas cosas más.

Vamos que estas estadísticas no valen absolutamente para nada, quien quiera ver lo que se puede ganar en otro pais que busque ofertas concretas que se ajusten a sus conocimientos/experiencia en otros países y compare con lo que te ofrecen aqui, y claro informarse bien de lo que cuesta vivir en ese pais, impuestos etc,etc y con eso si que puedes sacar alguna conclusión de si te compensa o no la aventura. Pero estas cosas, aparte de para que algunos maldigan su suerte, no sirven pa na.

a

#135 Bueno hombre, en realidad lo importante de lo que dice es que en el trabajo no deberías aprender al mismo tiempo que trabajas sino que deberias aplicar técnicas que domines cuando estés cobrando por desarrollar un proyecto. Se suele usar la metafora del músico, que antes de salir al escenario que es por lo que le paguen tiene que ensayar un buen número de horas previas.

Esto no implica necesariamente que tengas que trabajar 40horas y dedicar otras 20h por tu cuenta, nosotros por ejemplo estamos tratando de dedicar 4 días de la semana a proyectos precisamente para tener el quinto día para poder seguir aprendiendo y por supuesto este día no se lo vamos a facturar a ningún cliente. No creo que sea productivo ni sano dedicar 60h semanales a trabajar, aunque esto depende del ritmo y las ganas de cada cual off course yo en el pasado he dedicado esas y muchas más porque me apetecía hacerlo, pero tampoco es de recibo cobrarle a un cliente por hacer un proyecto con la tecnología X y dedicar parte del tiempo que le estas cobrando precisamente a aprender esa tecnología en la que el cliente supone que eres experto.

Robert martin tiene muchas cosas buenas y a aportado mucho a la comunidad de desarrollo, pero a veces sus planteamientos son muy radicales y hay que tomarlos con calma. Parte de su juego y del "personaje" que ha construido consiste en llamar la atención a través de planteamientos muy radicales en las formas, en el fondo suele tener razón, pero las formas a veces se pasa tres pueblos.

a

#120 Esas arquitecturas "empresariales" javeras..., mucho se puede hablar sobre eso y poco bueno jeje. Por lo general no son precisamente un ejemplo de buenas practicas OO. No es en la parte de los controladores donde estas arquitecturas tienen el mayor problema, la capa de servicios y los mapeos 1-1 de las clases de la dominio con tablas son un problema bastante más grave, el típico modelo anémico: http://www.martinfowler.com/bliki/AnemicDomainModel.html

Y el debuger lo carga el diablo, si lo usas mucho algo huele mal, probablemente falten test, es una herramienta para emergencias, si lo usas muy habitualmente es que entonces estas demasiado habitualmente en una emergencia, cuidao con eso que es malo para el corazón :P.

a

#102 El SRP es un principio de OO referido a clases o modulos. Aunque es muy subjetivo se suele interpretar como "que las clases sólo tengan una razón para cambiar". En tu misma pregunta te estas dando la respuesta: "para una pagina que tiene VARIAS FUNCIONALIDADES....", parece claro que en tu caso ese controlador tiene varias responsabilidades, una por funcionalidad, entendido como varias razones para cambiar, tu controlador deberá cambiar si alguien decide cambiar la funcionalidad x, y o z.

Más que pensar en que motivos tienes para separar las cosas piensa en que motivos tienen esos métodos para estar juntos, desde el punto de vista de la cohesión ¿que comparten esos métodos para que tenga sentido que estén en la misma clase? (siendo los controladores normalmente clases sin estado, es decir, que no comparten nada, sería incluso cuestionable porque hay que hacer una clase con métodos en lugar de simples funciones como controladores, aunque esto puede depender del framework/tecnología que uses que es muy posible que no permita métodos como elementos de primer nivel).

De todas formas el SRP es un principio bastante subjetivo, si por ejemplo tus controladores no hicieran nada más que transformar una request http en una petición a otra u otras clases de tu sistema y transformar la respuesta de esas clases en una respuesta Http entonces se podría argumentar que el controlador sólo tiene la responsabilidad de serializar/deserializar peticiones http y delegar en otras clases de tu sistema la verdadera funcionalidad, y probablemente sería un argumento razonable para tener varios métodos en el mismo controlador.

Eso si, si tienes un controlador con tropecientos métodos y que encima implementa sin delegar en nadie las distintas funcionalidades de tu aplicación, pues entonces no hay que hilar tan fino, eso es un lio de narices claramente mal diseñado.

a

#57 ¿Y que me quieres decir?, Que lo hayas visto no significa que no sea una barbaridad. Aunque un millón de moscas coman mierda, la mierda sigue siendo mierda.