¿Me convierte en un mal programador si no me gusta la metodología Agile? [cerrado]


10

Me gustan las pequeñas iteraciones. Me gustan las pruebas unitarias. Me gusta la revisión de código. Lo que no me gusta es comenzar con poca o ninguna documentación. ¿Estoy solo en esto? ¿Simplemente tengo un malentendido del proceso?

Cualquier pensamiento sería apreciado.


2
En primer lugar, no hable sobre la metodología ágil. El movimiento ágil es realmente una filosofía de desarrollo, que fomenta la adopción de una variedad de prácticas y metodologías, según corresponda.
Eric Wilson

1
"¿Tienes un malentendido del proceso?" - sí
vartec

2
"La metodología ágil que debe seguirse estrictamente no es una metodología ágil verdadera"

1
Hola Dan, no parece haber un problema solucionable en tu pregunta, y preguntas como "Creo / siento X, ¿otros sienten lo mismo?" no están en el tema aquí . Si tiene un problema específico con el que necesita ayuda, no dude en preguntar al respecto.

Todos comienzan con poca o ninguna documentación. La pregunta es cómo divide su tiempo entre la documentación y el código: ¿primero toda la documentación? ¿O solo todo lo que necesita para comenzar?
Carson63000

Respuestas:


18

Recuerde, Agile no significa que no hay documentación, Agile significa que usted comprende que el "cliente" no sabe todo lo que quiere, por lo que no puede darle un documento de requisitos enormes que lo describa todo. Agile aboga por hablar constantemente con el cliente y decirle "¿Es esto lo que quieres?" o "¿Cómo funcionará X cuando ocurra Y?" así que juntos crean los requisitos.

Dicho esto, no, no hay nada malo en ti si no te gusta una metodología en particular. La mayoría de las personas parecen elegir varios aspectos de diferentes metodologías de todos modos.


10
+1 Agile no significa que no hay documentación . La gente parece pensar que era Agile significa; no es. Valora el software de trabajo sobre la documentación completa; no niega el valor en la documentación.
Aaron McIver

10

La metodología ágil establece que solo hace lo que necesita en ese momento. Si desea / necesita más documentación de la que se proporciona, entonces ese es un problema con el proceso, y no es usted. Hay momentos en que se necesita mucha documentación para que el proyecto continúe. No es contrario a Agile necesitar esto. No se puede justificar la holgura en los requisitos bajo la apariencia de Agile. Este es realmente un gran problema que he visto. Muchas personas se vuelven perezosas por adelantado y lo atribuyen al proceso. La verdadera pregunta debe hacerse: "¿Los desarrolladores tienen lo que necesitan?" Si la respuesta es no, entonces se necesita hacer más trabajo.

Ahora esto se puede llevar al extremo, y alguien puede decir: "Bueno, no puedo trabajar en ello a menos que todo el programa esté documentado". A veces esto es cierto, pero el equipo necesita echar un vistazo y ver si esto es realmente necesario.


8

No veo por qué te haría un mal programador solo porque no te gusta una metodología en particular. Puede dificultarle la integración con las tiendas que lo implementan; Dicho esto, tengo algunas dudas sobre cuán efectivamente se implementa en todas partes.

Lo que lo convierte en un mal programador es un código incorrecto, lo sé, fácil, pero puede gustarle / ser brillante en todas las metodologías que quiera, y aún así ser un mal programador porque su código no es adecuado.


3

La idea básica de Agile es que, a menos que tenga un don de precognición, no puede prever un futuro lejano. Por lo tanto, no puede documentar lo que no puede prever.

Eso no significa que no tenga documentación en absoluto. Documenta el diseño técnico para los requisitos actuales (y, por supuesto, documenta los requisitos en sí mismos) y documenta la implementación actual . No se espera que documente cómo se verá el sistema después de 10 sprints más, ya que vive en un mundo dinámico, los requisitos pueden cambiar.


2

Creo que estás malinterpretando el proceso. ¿Qué documentación quieres? Antes de comenzar necesitas algún tipo de objetivo. Comienzo con casos de uso que obtengo de conversaciones con mi cliente. No paso días haciendo diagramas elegantes. Hablamos, y luego escribo una página Wiki, y repasamos eso. Luego escribo algunas pruebas. Luego escribo un código.


2

Hay una combinación infinita de tamaños de equipo, dominios, idiomas, personalidades, presupuestos y requisitos. No existe una metodología única que sea mejor para cada situación. Del mismo modo, muchas personas tienen preferencias y estilos personales.

Incluso si no le gusta, vale la pena probar nuevas ideas y analizar críticamente los resultados. Hay muchas cosas que no me gustan, pero después de probar por un tiempo, aprendo a amar. Como las aceitunas.

La otra cosa es que las modas cambian regularmente. Fui criado con Waterfall, trabajé en un equipo que trató de hacer todo en Rational Unified Process, que era lo "mejor" en ese momento. Pronto, Ágil será reemplazado por algo más nuevo y mejor y nadie volverá a mencionar la palabra Ágil nuevamente.

Así que no sienta que necesita una metodología como Agile. (Personalmente no me gusta) No te hace un mal programador.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.