Metodologías de programación

SCRUM

Orale, a mi también me interesa saber esto. Estaría chido que alguien se aventara una anécdota para que los mas novatos nos enteremos mejor de lo que normalmente pasa en el mundo laboral y la metodologías de programación.
Saludos.

Yo trabajé en una empresa cuyo mayor interés era llevar TSP. Al parecer les interesaba incluso más la metodología que el resultado. El proceso más estricto que he visto en cualquier lugar.

Era un desastre. Los equipos para los proyectos, bastante inflados porque se necesita una persona por proyecto que sólo se encarga de supervisar el proceso, no hace nada más, y otra que no me acuerdo si supervisa a los supervisores o qué carajos pero ya era una para varios equipos pero era sólo para el proceso, no para nada directamente relacionado con el proyecto.

Y cuidado si no llevas el proceso de manera meticulosa. Ah ya terminaste lo que tenías que hacer? Ah es el mejor código que has escrito en tu vida? ME VALE MADRES! Dónde están las horas que dedicaste a esto? Quiero ver tus tiempos de codificación, pruebas, errores, correcciones, compilación (sí, había que cronometrar la compilación, porque es una fase del proceso que no te puedes saltar, no importa que Eclipse está compilando mientras escribes tu código).

Lo más arcaico de todo ese proceso, es la necedad de que existe una fase de codificación, la cual empieza cuando tecleas la primera línea de código y termina en el momento en que arranca el compilador. Nada de desarrollo cíclico; en el momento en que compilas por primera vez, terminó la fase de codificación. Por eso hay una fase en medio de revisión; terminas de escribir tu código, y lo revisas tú, A MANO, porque pues eso es mejor que dejar que el compilador te señale donde te faltó un punto y coma o escribiste mal el nombre de un método etc. En fin. A partir de que compilas, si el compilador te da errores, bienvenido a la fase de depuración; sigues programando, pero ya son puras correcciones. Se supone que durante la fase de codificación tienes que haber codificado tooooooooooda tu aplicación. Absurdo.

Creo que sería bueno tener una versión "light" de PSP, pero sobre todo con herramientas adecuadas. Tener el maldito excel abierto todo el día además del IDE en el que estás trabajando es absurdo. Lo peor es que les propuse hacer un desarrollo interno para automatizar muchas de esas cosas, con una base de datos centralizada que capturara toda esa info y sacara reportes y demás cosas que incluso eliminaría la necesidad de tener un supervisor de proceso por equipo, pero nooooooooooooooooooo porque entonces qué va a hacer esa persona? Si es una experta en el proceso!!! Y así se la cobran al cliente, aunque mucho de su tiempo se le va en tareas tan tediosas como estar sacando datos del excel de cada miembro del equipo y juntándolos en un megaexcel para sacar sus reportes. Sí... una empresa de desarrollo que internamente usa mil macros de excel para sacar esos reportes, que cada PROGRAMADOR tuvo que capturar a mano en su hojita, en vez de que todo eso se fuera directamente a una base central donde se pueden sacar los reportes con tres méndigos queries.

En fin, esa fue mi experiencia con un proceso demasiado estricto. Tal vez a algunos les guste. No es que me guste revolcarme en el caos absoluto, tampoco, obvio debe haber cierto orden, pero esto era una exageración. TSP es el fascismo totalitario de las metodologías.

Creo tiene cosas buenas,
1 el que entiendas el problema a resolver antes que codifiques lo veo como algo necesario,
2 llevar un diagrama de clases de bajo alto nivel y lo lleves después a bajo nivel y seamos honestos a muchos no les gusta hacer diagramas(para que si esos no se ejecutan o compilan)
3 La creación de tu SET de pruebas( hay quien no escribirá ni una sola) antes de la codificación para definir los escenarios lo veo también como algo necesario.
4 La fase de codificación para tolda tu aplicación , ahí si definitivo ABSURDO.

Ahora una es la "carnita del proceso" y otro el proceso en si y no es exagerar llevarlo al dedillo (al menos en mi experiencia no fe así) , ya hay herramientas mas alla del excel pero aun uno como developer debes alimentar la chunche esa.

Un proceso demasiado estricto hace que definitiva no quieres ni pensar en PSP/TSP.

Hay puntos que se rescatan pero como todo exceso siempre es malo.

Happy Coding ... o debo decir happy excel programming LOL

Creo que el problema ahi era el encargado de llevar esa metodologia (gerente, lider de proyecto o como se llame), la filosofia de PSP es piensa, diseña y considera todas la variables antes de codificar, que seria algo asi como el diseño, y despues, solamente codifica. Segun las personas que crearon esta metodologia, es mejor hecharle todas las ganas a la primera fase aqui explicada. En realidad asi fuerzas a tu cerebro a pensar.

Creo que eso de codificar toda la aplicacion, fue una exageracion de ellos, porque muy bien se podria hacer un ciclo por modulo (diseño, codificacion, etc), y ya pensandolo bien, me atreveria a decir que no entendieron la filosofia de PSP.

Y considero (como mdrmtz) que hay MUCHAS cosas rescatables de PSP.

RUP tiene conceptos muy importantes. Creo la metodologia ideal seria adaptar RUP a una metodologia agil, mas algunas cosas muy importantes de PSP.

Creo que se de que empresa hablas, si en algo sirve de consuelo, ese proyecto si se realizó. Pero hasta donde yo me quedé aún no estaba terminado.
Lo cierto es que tal como lo dices era el extremo del fanatismo en los procesos , yo terminé odiándolo pero la verdad tienen cosas buenas que aportar tanto el PSP como el TSP pero en ese lugar creo que perdieron el camino.

Demasiado proceso y pocas nueces, tan poquitas que cuando comparó la experiencia con scrum terminas amando scrum, lo importante es implementar una metodología de manera adeacuada para el proyecto adecuado. Con TSP todo pintaba bien en los lanzamientos hasta que enfrentabas el componente y te dabas cuenta de que no tenias idea de como implementarlo con la tecnología del proyecto, entonces ... ¿overhead? eso no pinta bien para ti, demasiado trabajo que no se ve, ni está planeado y al final retraso en la herramienta.

Creo que TSP y PSP funciona mejor cuando ya tienes cierta experiencia en las tecnologías implicadas si no, usar mejor otras opciones, no creo que todas las metodologías apliquen a todos los proyectos, en el mismo scrum no todas las técnica aplican a todos los casos hay que decidir cuales si. Incluso tanto el TSP como el PSP debe adaptarse.

La retroalimentación es el ánimo del TSP, la corrección del error para tener estimaciones con márgenes de error cada vez menores, por que no realizar lo mismo con el proceso ajustándolo a cada equipo en cada proyecto y no aplicar la misma caja cuadrada solo por que tiene el logo institucional, seguiría siendo TSP y PSP bien se pueden seguir reglas mínimas pero dar libertades. Lo importante cuando te equivocas viene después cuando retroalimentas y aplicas las lecciones aprendidas, a mi no me sonaba lógico seguir con lo mismo lanzamiento tras lanzamiento, en fin.

Por si gustan de ahondar en el tema Watts Humphrey dedicó a QuarkSoft el capítulo dos de su último libro Reflections on Management: How to Manage Your Software Projects, Your Teams, Your Boss, and Yourself. Addison-Wesley, Reading, MA.

Pero en mi opinión las empresas usan el TSP más como estrategia comercial que por una preocupación legitima, y lo digo por el CMMI y sus niveles que así como me fué en la feria, no garantizan nada pero venden más.

Hola pues yo platicare de mi experiencia con estas fabulosas metodologias de manera general yo he trabajdo en el sector privado y publico y les puedo comentar que en mi experiencia las metodologias agieles en el sector publico nomas no funcionan las metodlogias pretenden solo tomar lo necesario y entregar un producto del alta calidad y eficiente en el menor tiempo pero en gobierno lo que importa es q entregues 3 carpetas de pura documentacion aunque no tengas nada construido :S

respecto a RUP Dios es el papa de todas las metodologias Agiles!!! jajajaa XD rifa si y solo si lo usas en una empresa de sector publico para entregar resultados SCRUM o XP

No tengo mucha experiencia en el campo laboral, apenas tengo 2 años y medio aproximadamente en la primera empresa que entre no tenían una metodología como tal implantada formalmente pero se llevaban algunos estándares como análisis, diseño, codificación y pruebas.
A mí se me entregaba un Caso de uso para comenzar codificar y al entregar el requerimiento alguien más hacia las pruebas y se me entregaba un documento con los errores del modulo si los había y como replicarlos, hacia las correcciones y listo, al siguiente requerimiento. Esta empresa planeaba certificarse en CMMI ya no se en que acabo todo porque me salí.
Ahora en el proyecto en el que estoy digamos que su metodología es platicarte los requerimientos(porque para que haces un documento si eso va a quitar tiempo) y ya puedes empezar a codificar haces tus estimaciones pero lo que dices siempre es mucho y entonces es mejor el tiempo que ellos te dan, y tu tiempo ya corrió no importa que no esté todo lo que necesites listo como tablas, datos, etc debes entregarlo a tiempo “no importando como” y ahora ya que acabaste palmadita en la espalda y haz la siguiente y las pruebas? … bien gracias

en gobierno lo que importa es q entregues 3 carpetas de pura documentacion aunque no tengas nada construido :S

Amén.

De acuerdo con lo de ciclos, PSP lo considera de hecho, pero aún así creo que es absurdo hoy en día querer codificar todo a mano rechazando cualquier asistencia de compilador (autocomplete, correcciones que salen sin tener siquiera que salvar, etc).

Lo de diseñar o al menos plantear bien el problema a resolver antes de ponerse a codificar es algo fundamental en cualquier metodología, no es exclusivo de PSP. Lo de las pruebas, creo que hasta prefiero el enfoque de TDD (aunque TDD llevado al extremo tampoco me gusta nada). Los ciclos en TSP son muy grandes, el proceso en sí es demasiado rígido, muy complejo (al grado de requerir gente dedicada a llevarlo que no hace nada más), y las herramientas demasiado rudimentarias (se puede hacer algo mucho más fregón, hay esfuerzos como el psp dashboard, pero cuando se ponen de necios con querer usar solamente lo que dice el libro que es la mugre hoja de excel, bueno... ya ni cómo ayudarlos).

CMMI ahora que lo mencionan, es otra pesadilla. Y una farsa en muchos casos; yo vi de cerca la experiencia de mandar hacer software a la India, con una empresa certificada como CMM 5, y se tardaban hasta 3 semanas para entregar una pantalla de alta/baja/cambio de una tabla onda maestro/detalle con pocas columnas y reglas de negocio bastante simples. Estamos hablando de algo que le debería tomar cuando mucho una semana a un programador mediocre. Pero pues de a cinco dolaritos la hora, es bien barato, no?

Eso suena a XP pero deformado

jajaaaj jja Cierto es como comprar cosas chinas!!! jaajaa XD el ifon con Android!! jajaja XD

El objetivo de codificar a mano es que tu mente funcione al 100%, que tengas la small and big picture en tu cerebro, conozcas las librerias necesarias del lenguaje que usas para lo que estas haciendo, que evites perder tiempo preguntandole a google que hace cada metodo de cada clase(por ejemplo), con el fin de hacer mas rapido la codificacion. Que estes 100% concentrado y que no se te pase ningun error.

Una de las filosofias de PSP es evitar cualquier error, mientras mas temprana sea la etapa mucho mejor.

Por eso psp pide hacer un analisis y diseño perfecto desde el principio, por eso te pide tambien codificar todo a mano, y al llevar estadisticas de los errores que cometes, vas corriguiendo los mas frecuentes (forzando tu cerebro a trabajar mas, ya sea aprendiendo el lenguaje, o mejorando en el analisis y diseño) y caminando a la perfeccion poco a poco. El fin de todo esto es evitar bugs a toda costa.

Otra cosa importante en PSP es que tengas una idea casi exacta de lo que tardaras en implementar el trabajo o requerimientos que te asignan.

Gracias a todos, la verdad muy unteresantes todos sus comentarios, por lo pronto, pues igual sigan publicando, que como vemos es un tema de gran interés... Gracias!!!