#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.
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.
#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.
#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.
#132 Es que pruebas automatizadas nada de nada.
Sonar, Hudson y esas cosas nos las cuentan en los cursos de formación contínua...luego volvemos a mundo cruel
Gracias por el enlace, lo leeré con interés
#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.
#110 Muchas gracias por la respuesta.
Es un proyecto Spring, JPA, etc... Los jsp se comunican con los controller (hay uno específico para las peticiones ajax por cada jsp que lo precisa) estos con los SpringServices y estos con los dao ambos con sus correspondientes interfaces e implementaciones separados.
Además están los command que suelen ser los bean de formulario y diversos validators.
En teoría los controller solo mapean y traducen como bien dices aunque alguna ñiapa que otra contienen 
Lo que si que es cierto es que haciendo debug a veces puedes perder el hilo por la de saltos que hay entre métodos públicos y privados. Mi impresión es que la complejidad es notable pero bueno en eclipse inspeccionando los valores de los objetos y con el outline para no perder la referencia te apañas.
#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.
#132 Es que pruebas automatizadas nada de nada.
Sonar, Hudson y esas cosas nos las cuentan en los cursos de formación contínua...luego volvemos a mundo cruel
Gracias por el enlace, lo leeré con interés
#110 amén bro
#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.
Esta graciosete, teniendo en cuenta que mi curro consiste entre otras cosas en ir a empresas a ayudarles con desastres de este tipo, se siente uno identificado, me falta la camisa, tengo que buscarme una
#35 Uno de los principios SOLID, el primero, es Single Responsability, que dice algo así como que un clase debería tener una única responsabilidad. 6000 lineas de código en una sóla clase indica que esa clase tiene un montón de responsabilidades y que más que probablemente se pueda dividir en muchas clases con responsabilidades más concretas y mejor definidas.
6000 lineas es una exageración del video, en realidad es una autentica barbaridad, más de 200 0 300 ya deberían poner el foco sobre esa clase para revisar si el diseño es adecuado. Con 6000 lineas no es que este mal diseñada, es que no esta diseñada en absoluto, más bien es código vomitado sobre el teclado.
En 6000 lineas se viola el SRP (single responsability principle) con claridad pero no sólo eso, en tantas lineas da tiempo a violar prácticamente todos los principios de la Orientación a Objetos que se te ocurran (nivel de acoplamiento brutal con seguridad, cohesión ridícula, Open close me da la risa etc,etc). Por supuesto que es siempre evitable llegar a eso.
#57 Pues huye de ahí cómo de la enfermedad
Y ojo, que en todos lados cuecen habas: Ésta es la clase View (de la cual extienden todos los botones, textos, imágenes, layouts... de Android) https://android.googlesource.com/platform/frameworks/base/+/refs/heads/master/core/java/android/view/View.java
#44 #48 #51 Una clase una sola responsabilidad? No será un método de clase una sola responsabilidad?
Según eso, para una página que tiene varias funcionalidades en vez de tener un controller con varios métodos que mapeen cada funcionalidad debería tener uno por cada una?
En el proyecto en el que yo estoy eso sería como ver un unicornio
#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.
#110 Muchas gracias por la respuesta.
Es un proyecto Spring, JPA, etc... Los jsp se comunican con los controller (hay uno específico para las peticiones ajax por cada jsp que lo precisa) estos con los SpringServices y estos con los dao ambos con sus correspondientes interfaces e implementaciones separados.
Además están los command que suelen ser los bean de formulario y diversos validators.
En teoría los controller solo mapean y traducen como bien dices aunque alguna ñiapa que otra contienen
Lo que si que es cierto es que haciendo debug a veces puedes perder el hilo por la de saltos que hay entre métodos públicos y privados. Mi impresión es que la complejidad es notable pero bueno en eclipse inspeccionando los valores de los objetos y con el outline para no perder la referencia te apañas.
#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.
#132 Es que pruebas automatizadas nada de nada.
Sonar, Hudson y esas cosas nos las cuentan en los cursos de formación contínua...luego volvemos a mundo cruel
Gracias por el enlace, lo leeré con interés
#110 amén bro
#102 No, has leído bien: Una clase => una responsabilidad.
En tu ejemplo de la página y el controller, supongo que si la página tiene mas de una funcionalidad, deberías subdividirla en componentes con interfaces bien definidas entre sí, de esta manera puedes testear (y reutilizar) cada componente/controller por separado.
Luego creas un controller adicional que se encarga de coordinar los diferentes componentes (a través de sus controllers).
Parece un rollo, pero es que así se crea una solución mas limpia y fácil de entender y mantener.
#102 Una clase. https://en.wikipedia.org/wiki/Single_responsibility_principle
Ejemplo. CompanyContoller: funcionalidad -> gestionar las llamadas http a la entidad company.
Puede tener distintos métodos Insert, Update, Select, etc... pero la funcionalidad de insert deberá realizarse dentro de un componente diferente. Si mezclas lógica en el controller que no sea para empaquetar objetos de entrada / salida está haciendo más cosas.
Por supuesto luego se puede ser más flexible o un nazi de la ordoxia.
#125 Gracias. Bueno ese ejemplo más o menos lo cumplimos...pero un cumplimiento estricto desde luego que no.
#169 los podcast de jh jeje, anda que no a llovido desde eso.
No todo el mundo es igual ni esta en la misma situación eso esta claro, lo único que digo es que esta profesión si te gusta lo que haces puede ser muy satisfactoria y ni todo es un camino de rosas ni todo es estar explotado en una consultora. Si me pongo en la situación de alguien que este pensandose en meterse en esta profesión y lea estas cosas, sinceramente se esta llevando una idea que no es realista de la profesión como conjunto. Yo a cualquiera que tenga pasión por el desarrollo le recomendaría sin dudarlo que siguiera adelante, porque además de ser un trabajo apasionante te va a permitir vivir más que dignamente y dedicarte a lo que te gusta, y no me gustaría que alguien con esa pasión se vea desanimado por visiones tan pesimistas y que sólo reflejan una parte, la peor, de esta profesión.
#165 Pues depende de lo que busques, si eres una carnica que vendes tiempo de gente lo que te interesa es comprar ese tiempo lo más barato posible y venderlo lo más caro, es decir pagar lo menos que puedas, luego pides setecientas cosas que en realidad no hacen falta para tener "en cartera" a alguien que puedas mandar a diferentes clientes porque tiene X o Y en su curriculum, aunque luego no tenga ni idea.
Si eres una empresa que hace software, entonces lo que buscas a alguien que sepa hacer software como dios manda. En ese caso más te vale buscar gente capacitada y pagaras lo que tengas que pagar por la persona que necesitas porque sin esas personas no hay software y sin software no hay negocio.
¿Cuantas empresas hay de un tipo y de otro?, pues no lo se, no manejo estadísticas (como ese 90% que te has sacado de la manga) pero lo que si te puedo decir por que lo veo a diario es que a las empresas que están en el segundo grupo les cuesta mucho esfuerzo encontrar gente. Vamos que hay muchas formas de ganarse bien la vida con esta profesión, que es lo único que estoy diciendo.
#166 Cuantas empresas "hacen software"? las consultorias venden horas, no hacen software. Intentan hacer la cuadratura del cirulo con gente desmotivada, mal pagada pero que les saque las castañas del fuego.
Pues ya me gustaria que me dieses referencias de esas que estan en el segundo grupo. Yo lo que veo es que el que puede se va a "cliente" es decir, trabajar para una empresa con contrato en el departamento informatico de esta, no en una charcutera.
#161 No se si me contestas a mi o te has equivocado, pero no se donde he dicho que "cualquiera" pueda entrar a programar o que eso sea buena cosa. Precisamente muchas empresas, no carnicas, les cuesta realmente mucho trabajo encontrar gente verdaderamente capacitada.
#164 Cuantas empresas buscan a gente capacitada y cuantas buscan a el mas barato? Porque pedir piden hasta saber lanzar sondas a marte y 5 años de experiencia en sofware que salio hace 3 al mercado, luego se quejan de que no encuentran candidatos por el sueldo y condiciones que estan dispuestos a dar. El 90% son asi.
#165 Pues depende de lo que busques, si eres una carnica que vendes tiempo de gente lo que te interesa es comprar ese tiempo lo más barato posible y venderlo lo más caro, es decir pagar lo menos que puedas, luego pides setecientas cosas que en realidad no hacen falta para tener "en cartera" a alguien que puedas mandar a diferentes clientes porque tiene X o Y en su curriculum, aunque luego no tenga ni idea.
Si eres una empresa que hace software, entonces lo que buscas a alguien que sepa hacer software como dios manda. En ese caso más te vale buscar gente capacitada y pagaras lo que tengas que pagar por la persona que necesitas porque sin esas personas no hay software y sin software no hay negocio.
¿Cuantas empresas hay de un tipo y de otro?, pues no lo se, no manejo estadísticas (como ese 90% que te has sacado de la manga) pero lo que si te puedo decir por que lo veo a diario es que a las empresas que están en el segundo grupo les cuesta mucho esfuerzo encontrar gente. Vamos que hay muchas formas de ganarse bien la vida con esta profesión, que es lo único que estoy diciendo.
#166 Cuantas empresas "hacen software"? las consultorias venden horas, no hacen software. Intentan hacer la cuadratura del cirulo con gente desmotivada, mal pagada pero que les saque las castañas del fuego.
Pues ya me gustaria que me dieses referencias de esas que estan en el segundo grupo. Yo lo que veo es que el que puede se va a "cliente" es decir, trabajar para una empresa con contrato en el departamento informatico de esta, no en una charcutera.
#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.