que - ¿Agile realmente ha trabajado para ti como desarrollador?
mongodb español (13)
He conocido a muchas personas para quienes Agile ha funcionado realmente bien, y la mayoría de ellas son gerentes y arquitectos que planifican y delegan el trabajo. Sin embargo, realmente no he encontrado muchos buenos desarrolladores convencidos de que Agile esté trabajando para ellos.
Por supuesto, puedes decir si Agile no está funcionando para ti, no lo estás haciendo bien. Pero independientemente de los remixes de Agile, ¿funciona para usted como desarrollador? ¿Y por qué? ¿Alguien más piensa, dentro de una estructura de equipo tradicional (o cercana a ella), Agile se siente más como una forma de microgestión que la autogestión?
¿Realmente ha funcionado Agile? " Si "
Antes de que existiera la "Programación ágil", existían metodologías equivalentes en gran parte no reconocidas. Pensé que se llamaban prototipos incrementales, pero aparentemente esto se ha dividido en eso y prototipos evolutivos .
Sospecho que muchos o la mayoría de los sistemas exitosos fueron construidos así. Solo porque la metodología creció, un nuevo nombre no significa que apareció de repente.
Es solo que Waterfall y otras técnicas de gestión dañadas consiguieron toda la prensa.
Yo digo obras ágiles. Yo digo que es lo único que ha funcionado.
Agile ha funcionado de maravilla para mí como desarrollador en mi entorno actual. Aquí hay algunas prácticas y por qué parece funcionar tan bien:
Programación de pares: esto evita que alguien sienta que el código es de su propiedad. Los pares de desarrolladores tienden a hacer un código mejor que el código de "ciencia loca" de una persona que parece suceder si una persona escribe un montón de código de forma aislada. Esto también permite que alguien más sea llevado si alguien se va y esa característica o mejora tiene que hacerse mientras la persona está fuera. A veces, un desarrollador puede pensar que algo será genial, pero si nadie más puede entender el código, es inútil tenerlo, a menos que sea perfecto y estético, lo cual no es probable.
Scrum: esto crea una responsabilidad y una comunicación para que cada persona sepa lo que está haciendo la otra. Si alguien quiere saber cómo va el sprint, solo aparecerse en el stand. El standup es realmente simple, ya que son solo 3 preguntas: ¿Qué hice ayer, qué estoy haciendo hoy y qué me impediría hacerlo?
Desarrollo guiado por pruebas: se practica una variación en esto cuando trabajo, por lo general, tratamos de realizar pruebas para la mayoría del código de plomería que estamos escribiendo para personalizar un CMS en el gran proyecto que estamos realizando. Esta mentalidad puede ser difícil de entender, aunque se vuelve más fácil a medida que uno la practica más.
YAGNI - El principio de "No lo vas a necesitar" que realmente puede ser difícil si has sido un programador perceptivo que generalmente incluye 101 cosas como una mentalidad de "Bueno, podría necesitar esto algún día ...". Otra forma de poner esto es una idea "Mantenlo simple, estúpido".
Sprints: la idea aquí parece evitar la sensación de estar abrumado, ya que estamos trabajando durante 2 semanas en esto o aquello, y no miramos demasiado hacia adelante, ya que puede cambiar.
Demostraciones: mostrar lo que hemos hecho, obtener comentarios sobre lo que es bueno y lo que no lo es, es crucial para mejorar las cosas y tener la idea de que queremos una "mejora continua" en el proyecto y lo que es lo suficientemente bueno hoy, no ser lo suficientemente buenos mañana y mejorar en lo que hacemos.
MIP, Retrospectivas: la capacidad de mirar hacia atrás a lo que se hizo en las retrospectivas es útil para desahogar frustraciones, celebrar que las cosas funcionen bien y encontrar maneras de abordar los puntos débiles. El MIP es donde determinamos nuestro futuro para el próximo sprint en términos de cuáles serán los objetivos y cuánto tiempo pensamos que tomarán varias cosas utilizando un par de herramientas de estimación diferentes, una para los puntos en "épicas" como las llamamos y el otro por horas en una tarea o carta individual que es parte de una historia que es algo entre la épica y una pequeña pieza de trabajo.
Storywall e historias de usuarios: ahora esta herramienta de baja tecnología, ya que son solo unas pocas pizarras, con separadores y postes, proporciona cierta estructura para las cosas. Tenemos carriles para cada una de las épicas y varias columnas para los estados de trabajo: trabajo atrasado, en desarrollo, en desarrollo o en prueba. También hay lugares para la acumulación de tareas, tarjetas bloqueadas, preguntas, estándares y prácticas, y algunas otras cosas que pueden ser útiles para que los gerentes puedan ver para obtener una visión general del estado actual si desean una imagen más amplia de lo que lo harían. llegar al standup.
Ventanas rotas / deuda técnica / tareas: estas son similares en algunos aspectos y son útiles como una forma de ilustrar que la calidad es importante, es decir, no queremos ventanas rotas que puedan explicarse fácilmente en términos no técnicos ya sea utilizando una casa en un barrio o el sistema de metro de Nueva York como puntos de partida. La deuda técnica es algo que no agrega inmediatamente valor comercial que a veces es importante utilizar para prevenir algunos problemas, ya que puede haber problemas con una arquitectura en particular y, por lo tanto, se puede gastar parte de un sprint haciendo un re-arco que tiene que ser comunicado de modo que si hay un sprint con poco para demostrar esta es la razón.
No sé si la idea de un equipo "auto-organizado" o "auto-gestionado" es parte de Agile, pero ha sido un reto para mí tener suficiente fe y confianza en mis compañeros de trabajo que Las cosas funcionarán bien. Los profesionales que forman el resto de mi equipo saben lo que se debe hacer, son personas honestas, razonables y honestas con el fin de hacer el trabajo y no tener problemas con las cosas. No hay egos o malas actitudes que realmente ayuden a fomentar la formación de un equipo.
Agile no es una metodología, es un subconjunto de metodologías que tienen un conjunto común de objetivos, y más a menudo que esas metodologías no tienen resultados muy variados según la composición del equipo, la cultura corporativa y la implementación.
Desde el principio de mi cabeza, las prácticas de desarrollo puramente ágiles incluirían programación en pares, TDD, historias de usuario sobre especificaciones, la suposición de que todo el código se va a refaccionar varias veces (aunque esto es parte de TDD) y revisiones de código más que nada. Las cosas que nos impactan son los enfrentamientos diarios, el involucramiento con los usuarios de forma regular y directa, las introspecciones postmortem y los ciclos de desarrollo muy ajustados.
Agile no me ha funcionado, la razón principal es que los sistemas que desarrollo normalmente necesitan una arquitectura bien definida y bien pensada, que no se puede realizar con un enfoque ágil. Los enfoques ágiles tienden a escribir tan poco código como sea necesario para aprobar las pruebas aplicables y, por lo tanto, para hacer crecer el sistema de manera orgánica. Esto puede ser bueno desde muchas perspectivas, pero causa estragos desde el punto de vista arquitectónico.
Desde la perspectiva de los desarrolladores creo que funciona bien. En mi punto de vista, las técnicas ágiles tienen en común que el bucle entre la definición de la tarea, el trabajo en la tarea y la retroalimentación de esa tarea es muy pequeño en comparación con los enfoques no ágiles.
Tome TDD como ejemplo: codifique la prueba, barra roja, codifique la funcionalidad, barra verde, refactor, barra roja, corregir, barra verde.
Desde la perspectiva de los gerentes, este bucle de retroalimentación más rápido también es cierto: reunión diaria uno, estado verde, reunión diaria dos, estado amarillo, contramedidas / reasignar recursos, reunión diaria tres, estado verde.
La respuesta inmediata y saber a dónde se dirige le da una sensación de seguridad.
Desde mi experiencia personal, la metodología Agile tiende a crear una gran deuda técnica a largo plazo, y aunque puede ahorrarle (como propietario / a de una empresa) un par de dólares a corto plazo, a largo plazo volverá y morderá tú. Lo que no solucione ahora le costará muchas horas de trabajo arreglarlo a un costo mucho mayor del que le habría costado invertir algunas horas más en el problema original.
Agile siempre es excelente desde el punto de vista de los principiantes y de la administración, pero no conozco a un programador experimentado que realmente lo ame. El objetivo de Agile es ahorrar dinero de desarrollo para una empresa, no tiene nada que ver con la calidad real del producto. De hecho, la mayor parte de la metodología promueve un código incorrecto que se hace rápidamente sobre un código bien diseñado. La diferencia es que dentro de unos años, tendrá que hacer todo el trabajo nuevamente, mientras que el código bien diseñado puede durar décadas sin correcciones. Los buenos programadores no necesitan la metodología Agile la mayor parte del tiempo.
Tenemos una biblioteca de lógica de negocios escrita hace 22 años aquí por un solo equipo de 3 programadores que utilizan la metodología de cascada, y ese código no ha necesitado una sola corrección desde entonces. Debido a que se le enseñó correctamente, estaba bien diseñado y los tres programadores se tomaron su tiempo y tuvieron cuidado con su implementación. En cambio, la metodología Agile les pedirá a esos tres que hagan el mínimo estricto para asegurarse de que pasen algunas pruebas mal definidas y luego esperen hasta la próxima vez que golpee una pared para agregar un poco más de código de cinta adhesiva. Es una forma ridícula de trabajar y va en contra de cada fibra de ingeniero en mi cuerpo.
Hasta el día de hoy, me niego a trabajar en un entorno Agile, porque francamente no lo necesito, y no necesito un empleador que piense que lo necesito.
En el llamado ''equipo tradicional'', el desarrollo ágil aumentaría la visibilidad de los desarrolladores individuales para la administración. Eso probablemente permitiría a los gerentes y arquitectos planificar mejor su trabajo. Por supuesto que se podría interpretar como microgestión.
Pero desde una perspectiva organizativa, si produce resultados, a quién le importa.
En mi empresa, hicimos un cambio total a las prácticas ágiles hace aproximadamente 4 años cuando llegó un nuevo vicepresidente. Este vicepresidente había tenido éxito con Agile en el pasado y decidió que era lo que necesitábamos.
Resulta que tenía razón. En ese momento era un desarrollador (aunque un poco menor), y me encantaban las prácticas. La programación en pareja realmente ayudó a la transferencia de conocimientos y evitó la formación de silos de conocimiento. Las pruebas unitarias, el desarrollo guiado por pruebas y el énfasis en las pruebas en general crearon un código más robusto que no se diseñó en exceso. No Big Design Up Front significaba que, en lugar de pasar 6 meses escribiendo documentos de requisitos (momento en que el mercado nos había superado), estábamos creando prototipos y entregando valor real a los clientes en un momento oportuno. Trabajar estrechamente con un sustituto del cliente (en nuestro caso, un gerente técnico de productos) redujo considerablemente el tiempo de retroalimentación del ciclo, lo que nos ayudó a entregar lo que el cliente realmente quería.
Nuestra organización tenía bastantes desarrolladores talentosos, pero éramos muy propensos a la codificación de vaqueros. A algunos desarrolladores no les gustaron las nuevas prácticas ("¿Qué quieres decir con las pruebas de escritura? ¡Soy un desarrollador!"), Pero en general a todos les encantaron los cambios. Las tasas de defectos disminuyeron, las tasas de satisfacción de los clientes aumentaron y nuestra oficina se hizo muy bien considerada en nuestra empresa.
Hace aproximadamente un año me convertí en gerente, y uso mucho las prácticas Agile, incorporando también algunos principios Lean (análisis de flujo de valor, eliminación de desechos, kanban). La reducción de los ciclos de lanzamiento ha sido una actividad continua, y ahora mi equipo publica con la mayor frecuencia posible (¡con calidad!), A menudo cada dos semanas. No hemos reportado defectos de campo por parte de mi equipo en el último año, y los vendedores y la administración de productos adoran los ciclos de lanzamiento más cortos.
Como desarrollador, Agile realmente aumentó mi confianza en el trabajo con varias áreas de código (ahora me siento nervioso cuando cambio algo en un paquete que NO tiene un 100% de cobertura de pruebas unitarias), me enseñó a ser más bueno programador (pensando en las implicaciones de las pruebas, los impactos del negocio, etc.), y me ayudó a escribir código simple y autodocumentado. Como gerente, Agile y kanban me dan previsibilidad, menores tiempos de entrega, menores tasas de defectos y un equipo capacitado. Esto no es teoría, ni especulación, ni agitar las manos: la moral de nuestro equipo, la tasa de defectos, la satisfacción del cliente y el balance general han demostrado que Agile puede hacer cosas maravillosas para una organización.
En mi primer trabajo, teníamos scrums diarios, escribíamos pruebas automatizadas, compilaciones automatizadas, par programamos, etc. Habíamos estado en el surco ágil durante varios años. Y por nuestros esfuerzos, fuimos recompensados con un software que no tocaría con un poste de 20 pies. La calidad de nuestro producto fue atroz: lo describiría como la piratería gradual de 100 desarrolladores aficionados.
Qué salió mal:
La compañía en la que trabajé tenía una reputación notoria de contratar a desarrolladores de nivel de entrada para el salario más bajo ($ 25-27K / año era la norma), y con frecuencia subcontratábamos el trabajo al mejor postor en el extranjero. He oído que Agile simplemente no funciona en desarrolladores sin experiencia, y creo que se demostró a través del código y nuestra tasa de rotación.
No hay documentación de ningún tipo. Sin documentación funcional, sin documentación técnica, sin requisitos, sin seguimiento de errores. Nadie escribió nada en medios persistentes: todos los requisitos y errores se comunicaron por correo electrónico, boca a boca y mentalmente psíquico.
Pésimas pruebas: nuestras pruebas automatizadas fueron invaluables, pero las pruebas de control de calidad y UAT fueron un desastre. Como no teníamos ninguna documentación formal de requisitos, los usuarios de control de calidad no sabían qué funcionalidad nueva estaban probando, por lo que todo el control de calidad consistió más o menos en pruebas aleatorias de extremo a extremo. Las pruebas de aceptación del usuario se realizaron en producción: instalamos el producto en los servidores de nuestros clientes e informamos de errores a medida que ocurrían en la producción.
Desarrollo impulsado por la crisis: los errores se manejaron usando "OMG, TENEMOS QUE ARREGLAR ESTE Y REDEPTAR PRONTO. AHORA AHORA AHORA. ¡NO HAY TIEMPO PARA LA PRUEBA, SOLO SOLICITARLO!" metodología de gestión.
Aunque hicimos todo bien y realmente nos adherimos a los principios ágiles del libro, la metodología fracasó más que cualquier otra cosa que haya visto.
En contraste, la compañía para la que trabajo ahora utiliza una metodología similar a una cascada, produce unos cientos de páginas de documentación para cada proyecto, tiene pocas pruebas automatizadas, pero un equipo de control de calidad considerable. Curiosamente, la calidad de nuestro producto es total y el entorno de trabajo es de una magnitud superior a la de la otra empresa.
Sé que muchas personas han tenido la experiencia opuesta. Como suele ser el caso, las metodologías no son un martillo dorado: probablemente pueda iniciar un proyecto exitoso sin importar la metodología que elija. En mi experiencia con proyectos exitosos y no exitosos, tengo la sensación de que la metodología no importa tanto como el entorno: los desarrolladores cómodos, felices y los administradores de proyectos sanos son todo lo que se necesita para hacer que un proyecto funcione.
Para comentar sobre los Principios del manifiesto ágil de mi experiencia en un sitio que lo probó .
Nuestra máxima prioridad es satisfacer al cliente a través de la entrega temprana y continua de software valioso.
Esta fue una espada de doble filo para mi último sitio: se consideró valioso como 100% perfecto y libre de errores.
Bienvenido cambiando los requisitos, incluso tarde en el desarrollo Los procesos ágiles aprovechan el cambio para la ventaja competitiva del cliente.
Todavía me comunico con ese sitio y, justo hoy, debido a su fecha límite de entrega, se les dio un cambio de requisitos. Así era como estaban las cosas; Es casi como si quisieran el fracaso.
Ofrezca software de trabajo con frecuencia, desde un par de semanas hasta un par de meses, con una preferencia por el plazo más corto.
La norma durante muchos años fue básicamente construir y desplegar diariamente, por hora, casi en tiempo real ...
La gente de negocios y los desarrolladores deben trabajar juntos todos los días a lo largo del proyecto.
Algunas de las reuniones / revisiones con respecto a esto fueron hilarantes. Nos reprendieron por no trabajar con la gente (porque nos pidieron que no lo hiciéramos porque ya trabajaban de 9 a 10 horas por día) y luego por molestarlos porque estaban ocupados.
Construye proyectos alrededor de individuos motivados. Deles el ambiente y el apoyo que necesitan y confíen en ellos para hacer el trabajo.
Ahh, aquí está nuestro problema ... Teníamos PC de primera línea, pero la parte comercial no era favorable. La moral positiva esencialmente fue eliminada después de aproximadamente un año ... Esto también niega su preocupación por la microgestión (si se implementa correctamente).
El método más eficiente y efectivo de transmitir información hacia y dentro de un equipo de desarrollo es la conversación cara a cara.
Esto funcionó bien. Personalmente prefiero el correo electrónico porque odio tomar notas.
El software de trabajo es la principal medida del progreso.
No hay duda aquí.
Los procesos ágiles promueven el desarrollo sostenible. Los patrocinadores, desarrolladores y usuarios deben poder mantener un ritmo constante por tiempo indefinido.
Estoy de acuerdo con este 100%; El problema con el último equipo de negocios con el que trabajé fue la expectativa de 30 horas al día, 10 días a la semana y 400 días no era un ritmo con el que estuviera de acuerdo.
La atención continua a la excelencia técnica y el buen diseño mejoran la agilidad.
Aquí es donde se necesitaba algo de moral de desarrollador y educación.
La simplicidad, el arte de maximizar la cantidad de trabajo no hecho, es esencial.
Me encanta este y ha sido uno de mis objetivos. Sin embargo, hubo una actitud de "si no estás escribiendo, no estás trabajando" que fue difícil de superar.
Las mejores arquitecturas, requisitos y diseños surgen de los equipos auto-organizados.
Estoy de acuerdo con esto en un 90%, mi única advertencia es que deben ser equipos bien educados y bien informados.
A intervalos regulares, el equipo reflexiona sobre cómo ser más efectivo, luego ajusta y ajusta su comportamiento en consecuencia.
Simplemente fracasamos aquí y probablemente causó muchos otros problemas que tuvimos. El aspecto comercial fue realmente bueno al decir "debe hacer lo que nosotros decimos que debe hacerse".
Para terminar, si está trabajando en un lugar donde todos están informados y a bordo con una metodología ágil, debería ser un gran lugar para trabajar. Cuando el objetivo es un gran software, solo el impulso llevará a cualquier proyecto.
Soy un desarrollador y un administrador al mismo tiempo, por lo que tengo una visión especial o mi opinión es totalmente inválida. ;)
Diré que Agile significa muchas cosas. Es en realidad una familia completa de metodologías y directrices en este punto.
Exponerse a sí mismo a todas estas ideas interesantes es realmente la cosa. Como gerente, es muy difícil para mí decretar que todo el equipo adopte de repente toda una metodología, pero si me ven constantemente tratando de mejorar cada aspecto de mi juego, creo que lo aprecian. Y con suerte, si les gusta lo que ven, siguen mi ejemplo.
Me las arreglé para implementar lentamente un montón de cosas de Scrum sin (con suerte) salir como una herramienta. Los informes de quemado, las reuniones de pie y las tarjetas de historias en la pizarra realmente nos han hecho mejores en el software de envío. Por ejemplo, en cualquier proyecto, las tareas se realizan constantemente antes o después de lo previsto. En un proyecto realmente grande, puede ser muy difícil saber qué está haciendo con su fecha de envío. Con los informes de quema, puedo decir lo que hace un deslizamiento a nuestra fecha de envío, y si necesitamos comenzar a cortar las características para cumplir con un plazo.
Eso es más una cuestión de administración, pero a los otros desarrolladores aquí les importa porque podría significar que pueden mantener sus trabajos o evitar una marcha de la muerte. :)
Pero no son solo cosas de la gerencia. En Agile hay muchas recomendaciones sobre las mejores prácticas para el control de fuentes, pruebas de unidades, etc. Solo buenas prácticas sólidas. Como industria, somos bastante terribles con la mentoría, por lo que es bueno que esta información esté disponible.
Supongo que lo que hace que un proyecto "ágil" sea ágil, es la metodología: "Diseñar para hoy, no para mañana".
Para cualquier sistema de software que no sea crítico para la vida, esta es una manera de mantener a los programadores programando en lugar de discutir las edades sobre el diseño. Tenga en cuenta que el diseño no se desecha, solo se realiza en trozos más pequeños y, por lo tanto, más reemplazables.
Todas las otras técnicas que están asociadas con ágil, como la programación en pares, son ideas más prestadas que también podrían usarse de manera efectiva en cualquier otra metodología.
Ahora, ¿esta técnica ''funciona''? ¡Sí! Si se aplica correctamente, la técnica promueve que el producto de software esté listo para el envío en cualquier momento para reaccionar ante la competencia.
Por otro lado, como los programadores sienten que están codificando más, generalmente son más felices. Y se irritan menos al escribir especificaciones porque esta fase es inherentemente siempre pequeña.
Pero nuevamente, si sabe exactamente cuál va a ser su producto y especialmente si es crítico para la vida como el transbordador espacial, el desarrollo ágil no es lo que desea.
Casi todas las administraciones están conscientes de "Agile" a estas alturas: es esto, ¿sabes? Solo por su pregunta inicial, asumiría que algo realmente está yendo mal. Realmente te recomiendo leer un libro como Prácticas de un desarrollador ágil (como lo sugiere el título: se trata de lo que hay para ti).
Algunos gerentes leen un libro y luego saben de qué se trata ágil . Te están diciendo qué hacer y todo está bien, ¿no es así?
Si miras a tu alrededor, hay muchos desarrolladores (en compañías Agile) que no pueden decirte en un segundo cuál es el propósito de un stand-up , y eso es un problema. Si usted (y tal vez nadie más) no sabe por qué el StandUp no mejorará las cosas.
Observe el seguimiento del tiempo (y la estimación del tiempo): hay algunos gerentes que piensan que se trata de medir la cantidad de trabajo que realiza : Oye, usted tiene un contrato de 40 horas, pero la herramienta de seguimiento del tiempo dice que solo ha estado trabajando durante 38 horas esta semana. ! No es así como debe usarse.
Lo único que puede hacer al respecto: necesita aprender qué métodos ágiles existen. Los gerentes mediocres escogerán los que les parezcan interesantes. Los buenos gerentes entenderán el por qué y no solo elegirán los métodos para su beneficio directo, sino también aquellos que harán que el equipo sea más feliz / eficiente / en equipo (Equipo contra Grupo de trabajo).
PD Algo que realmente necesitas cuidar: en Agile no hay lugar para holgazanes. Todo el mundo tiene que hacer cosas por su cuenta. Tienes que poner interés personal en el éxito del producto. Si no haces las cosas por tu cuenta, alguien te dirá qué hacer (y luego está la microgestión).