Estudio de tiempos y movimientos aplicado a la arquitectura de Software para disminuir el tiempo de desarrollo

interesante platica de Robert C. Martin

https://www.youtube.com/watch?v=p0O1VVqRSK0

CMMI viene del mismo lugar de donde nació TSP. Ya con eso te puedes imaginar la complejidad. Pero la filosofía está peor que en TSP porque la verdad es que CMMI fue pensado para fábricas de software: los programadores son obreros con habilidades mínimas y son intercambiables en cualquier momento del proceso.

Bravo mi estimado , es bueno saber que hay personas piensan como yo :)

Como dice Uncle Bob el día que se tenga la misma confianza a un programador como se tiene a un medico o a un abogado. Todas las cosas en nuestra labor cambiaran.

Y por eso es que hay mucho joven trabajando en IT, desvelandose y haciendo que las cosas pasen.

En cierta forma cuando mencionaste que no era una metodología, sino el concepto, entonces creí que después de todo no estaba tan mal lo que escribiste, pero siendo así no aporta mucho por no decir nada a lo que ya aporta toda la filosofía ágil.

Agile precisamente pone una base muy importante en la automatización con herramientas, Gradle, Pruebas Unitarias e Integración Contínua, incluso hasta propone un cambio de mentalidad con TDD.

Se agradece el aporte y los comentarios, es sano el debate, aunque en lo personal, no veo nada nuevo a lo que ya trae la filosofía ágile.

La metodología Scrum no es la única metodología ágil existen más metodologías Ágiles.

Jamás mencioné siquiera un solo concepto de Scrum, ni siquiera de forma indirecta. Indirectamente si mencioné conceptos de XP. Incluso desde mi primer post, mencioné LSD. No entiendo a que viene tu comentario.

Es de comprender que sin un caso concreto de implantación puedas no verlo útil, ya que hay que profundizar.

Recuerda que la solución más simple, en la mayoría de los casos es la mejor. Y esto es lo que ofrece agile.

No hay que perder de vista que el objetivo es disminuir el tiempo y los "movimientos".

De acuerdo, es el objetivo.

¿Como se puede desarrollar con menos?

Con principios simples. Lean Software Development dice en uno de sus 7 principios que se debe "eliminar el despilfarro":

+ Funcionalidad y código innecesario.
El equipo de desarrollo piensa "de más" en como preparar el sistema para posibles cambios que el usuario pida.

Otro de sus principios, habla sobre la burocracia:
+ Eliminar la Burocracia hasta donde más nos sea posible.
Te hablo con la experiencia en mano. Trabajo en uno de los Grupos Multi empresa más grandes de México (sí, la del banco y la de la TV) en donde hay toda una serie de procedimientos, mecanismos, autorizaciones, etc para cualquier cosa y sin embargo, podemos lidiar con todo ello de manera "ágil" teniendo a los usuarios de negocio contentos. Si te interesa podemos hablar sobre esto más adelante.

¿Como se puede soportar, mantener, migrar, etc con menos?

Con el equipo de desarrollo "ideal". Y con ideal me refiero simplemente a personal motivado, competente, con cierto grado de pensamiento abstracto y al frente un lider con la experiencia... Vaya! Parece demasiado, pero en realidad no lo es. Lléndonos a algo más técnico, entonces podemos sacar prácticas de XP.

En el banco donde trabajo, hay 2 grandes bases de datos donde se encuentran los miles de millones de clientes. Una en AS/400 y otra en Oracle. El plan del viceprecidente de sistemas del grupo fué migrar de AS/400 a Oracle. Una tarea bastante compleja por los cientos de flujos existentes, recordemos que no solo es un banco, sino que es un grupo conformado por varias empresas, por lo tanto existen muchisimos flujos de información.

La migración la tenemos a un 80% y todo marcha muy bien, después de que hace 8 años se realizó el primer intento y fué todo un fracaso.

Implantación de un arquetipo con las prácticas escogidas para una necesidad. (No me refiero a Maven, un arquetipo como una aplicación que no hace nada pero es la base para desarrollar otras)

Algo así, pero creo más bien en cuestión a librerías, utilidades, por poner un ejemplo sencillo. Tienes una clase Usuario con sus atributos de nombre, username, password, etc., en donde en el método setPassword tienes el código para hacerle un hash SHA-512 con un SALT y 10 Iteraciones. Entonces es algo que ya tienes a modo de librería y en tu repositorio.

Selección de tecnologías

El equipo de desarrollo en su conjunto lo decide.

No pretendo entrar en un debate diciendo que los métodos ágiles son los mejores, de hecho, aunque mencionó "principios simples", lo son, pero dada nuestra cultura, a los desarrolladores nos cuesta aplicar estos principios y comprometernos. La escencia de lo que menciono es que no veo algo relevante o nuevo el transpolar la teoría de tiempos y movimientos al desarrollo de software, como te lo he planteado, básicamente esos principios ya están más que establecidos y probados por los principios ágiles.

paranoid_android , Parece ser que después de mucho tiempo no te preocupaste por saber cuál es el enfoque del estudio de movimientos y de sus aspectos negativos.

Veo que prácticamente todo lo que escribiste es un mero fusil de lo que hay en internet y que, como es costumbre, se encuentra en sitios que tienen poca calidad de lo que publican.

Quién sabe quién se fusiló a quién, pero en un sitio similar de donde te fusilaste el texto, se encuentra un texto más extenso
(tal vez el original) en donde se habla de los aspectos negativos de esa teoría de tiempos y movimientos. Se menciona el riesgo de que los seres humanos caigan en la tentación de querer robotizar a las personas.
También se menciona que uno de los principales aspectos negativos para los trabajadores es que la teoría pretende enfocarse en la especialización de la mano de obra. Entonces, tendríamos robotitos que hicieran sólo unas cosas a la mayor velocidad posible, con la consiguiente pérdida de creatividad por andar pensando en algo así como estarle dando vuela a un tornillo durante 12 o 15 horas todos los días (de acuerdo a los horarios de trabajo en México)

Si me especializo en colocar llantas de un auto de carreras, toda mi vida voy a depender de eso y voy a tener que obedecer como un autómata y el día que ya no le sirva a mi patrón, voy a andar de pepenador, robando o vendiendo articulos robados y todo por haberme "especializado" de acuerdo a lo que dicta la teoría del estudio de tiempos y movimientos.
.

Lo que parece que estás haciendo es reinventar la rueda o el agua hervida. No hay para qué regresar a esas teorías si en la actualidad en las escuelas ya nos hablan de la necesidad de contar con mejores herramientas para tratar de automatizar el desarrollo del software. También en las escuelas, tal vez desde el nivel de secundaria, ya se enseña la importancia de contar con librerías de código para reutilizarlo.

Y, a pesar de tener tanta teoría y práctica que en otros países sí tiene éxito, en México el resultado es un completo fracaso, y el fracaso no se debe a que los mexicanos sean unos tontos, sino más bien a que una enorme cantidad de mexicanos son corruptos y cobardes. Menciono esto por la enorme corrupción que podemos ver en las áreas de sistemas en donde les interesa más el dinero que les van a dar por autorizar la compra o desarrollo de algún equipo o software, o la contratación de cierto personal, en vez de enfocarse a crear buenos sistemas utilizando las mejores prácticas.

Fíjate nada más, antes muchas chicas se iban a chambear a Sullivan y ahora se cuelan de project managers, gerentes de cuenta, o "analistas" que andan hablando de tiempos, semáforos rojos, verdes, violetas, azules, y un montón de cosas más, pero prácticamente nunca o nunca han programado ni saben cambiar un disco duro. Es como si quisiera yo andar de encargado de una panadería o de una obra y nunca me hubiera batido de harina o de mezcla.

Debido a que muchas veces los responsables de las áreas de sistemas se quieren clavar la lana, no contratan al personal con el perfil adecuado, y además quieren exprimir al máximo a los esclavos y por eso la mayoría de los esclavos sale muy tarde de su centro de esclavitud.
.

Tal vez sería más útil que en vez de mostrarnos tu intento de reinventar la rueda o el agua hervida, nos mostraras algún intento para proporcionarle placer a tanto corrupto y/o cobarde que hay en México y así pudieran cambiar ese placer por el placer que les dan las drogas, el alcohol, la lujuria (en cuanto a deseo desenfrenado de adquirir ropa, autos, mansiones, sexo etc.) o inclusive el bienestar que pelean furiosamente los inútiles que no saben gran cosa del puesto que ocupan y andan de arrastrados ayudándole a su jefecito a robar (y de estos está tupido el gobierno, aunque también muchas de las áreas de tecnologías de información).

.

Bueno, no deseo salirme totalmente del tema, pero es que pienso que para que funcionen en México todas esas teorías y prácticas fabulosas que en otros países supuestamente tienen un rotundo éxito, la mentalidad de la mayoría de los mexicanos tiene que cambiar primero.

Creo que habla muy mal de tí el hacer copy-paste de algo que parece que no entiendes, y mostrarlo como si entendieras una buena parte del tema. Nos dices que tienes experiencia de cómo lo que mencionas tiene éxito en otros países, pero tu forma de exponer el tema me hace pensar que a lo mejor nos estás choreando.

Por ejemplo, cuando quieres "adaptar" esa teoría robotizante y aplicarla al software cuando escribes:

"..Deben emplearse el menor número de elementos o therbligs y éstos se deben limitar de más bajo orden o clasificación posible.
En software podría equivaler a Desarrollar el menor número de componentes (Respetando los principios de arquitectura de software) ..."

Sucede que la teoría dice (no dice en el sitio de donde te lo fusilaste) que hay que usar menor número de therbligs para evitar que al aplicarlo a los seres humanos, se les robotice. Y tú estableces una relación extraña entre el no querer robotizar y el usar menores componentes de software. Si creas innecesariamente muchos componentes de software, no robotizas; pero si usas muchos therbligs sí tienes el riesgo de hacerlo y de fastidiar a los esclavos.

.

No obstante, me parece muy útil tu participación porque la discusión nos permite darnos cuenta de por qué no funciona lo que aparentemente es fácil que funcione en forma similar a como funciona que en otras partes del mundo.

Te invito a que continúes con este análisis. Tal vez sí hayas viajado a otros países y hayas participado exitosamente con lo que dicen esas teorías pero parece que no puedes expresarlo y entonces así no nos sirve de mucho lo que nos expones porque creo que la mayoría pensamos que esa teoría no sirve de mucho y además parece que afortunadamente en muchos países no se aplica a los seres humanos.

Saludos,

Parece que eres mal analista paranoid_android.
.

paranoid_android, al parecer interpretaste bastante mal lo que escribí y tienes muy baja tu autoestima.
Comento esto porque en lo último que escribí no hay nada de donde se pueda decir que corresponde a alguna emoción. Más bien posiblemente algo te molestó y por eso contestaste como adolescente diciendo "no estás al nivel para responderte". Así responden los adolescentes cuando sienten su ego lastimado por alguna verdad y se sienten impotentes para responder porque no tienen ningún argumento para desmentir tal verdad que su interlocutor por pura casualidad descubrió.
.

Estamos aquí para ayudarnos, no para agredirnos. Casi es seguro que te sentiste atacado y eso también habla mal de tí, porque puede ser señal de que también eres un mal analista, ya que interpretas mal a tu interlocutor cuando sientes que dice alguna o varias supuestas verdades. Imagínate con esa actitud ¿cómo vas a analizar un sistema? luego por eso se dan problemas entre analistas y usuarios, porque el analista tal vez sí sabe mucho de java pero quiere casi imponerle sus ideas al usuario y además lo malinterpreta.
.

No todo es java, frameworks y bases de datos. También es muy importante nuestra actitud mental; principalmente no interpretar mal.

Nada más ve cómo no eres congruente contigo mismo: si no valiera la pena contestarme, entonces ¿por qué contestaste?

Por alguna razón participaste. Si sólo querías presumir, pues sé sincero contigo mismo y dilo. No tiene por qué pasarte nada si lo dices, a menos que sí andes algo mal de la cabeza y seas congruente con tu nick "paranoid_android" y la mayoría de las veces andes todo paranoico como un androide y viendo moros con tranchete por todos lados.

Ya que te animaste a participar, ¡continúa! casi con seguridad que si te animas también vas a aprender un poco a analizar, argumentar y a no andar malinterpretando a las personas.

Lo que nos comentaste sobre los therbligs y la cantidad de componentes suena como a que yo quisiera establecer una relación entre preparar tacos y la cantidad de componentes:
"Menos tortilla" = ¡Excelente!
"Menos componentes" = ¡Excelente!

pero igual puedo establecer otra relación similar e igual de inútil y extraña:

"Menos carne" = ¡Excelente!
"Menos componentes" = ¡Excelente!

.

.

Si nos vamos por el lado de que piensas que te están atacando, entonces tú fácilmente me podrías tapar la boca, demostrando, no suponiendo, que hay una relación útil, que se puede aprovechar, entre la reducción de therbligs y la reducción de componentes.
.

Adelante, ¡limpia tu mente de toda esa basura de telarañas y razonemos, que se supone que es nuestra actividad favorita!
.