¿Qué metodología de programación sería adecuada para nosotros?

Desafortunadamente, alguien le ha enseñado a nuestra alta dirección la palabra "ágil" y ahora quieren que avancemos hacia ella. Tengo una comprensión periférica de ágil (en principio) pero nunca lo he usado en la práctica. Por lo que sé, no será una buena opción para nuestra organización. En este momento, las cosas son bastante grungey. Así es como es;

Somos un equipo muy pequeño: dos desarrolladores, un DBA, un diseñador. La compañía para la que trabajo gana una cantidad desproporcionadamente grande de dinero en relación con su tamaño, y casi el 95% de eso son ventas en línea puras.

Desde una perspectiva de desarrollo, estamos sujetos a muchas invasiones de escritorio durante un día típico (somos soporte técnico y también desarrolladores), el trabajo puede caer del cielo con regularidad en cualquier momento si un miembro del equipo de ventas le promete algo a alguien . También emprendemos proyectos más grandes, y son una pesadilla con las constantes interrupciones. ¡Algunos de nosotros estamos empezando a arrancarnos el pelo! Los gerentes no técnicos elaboran los planes del proyecto en hojas de cálculo de Excel, donde intentan dividir la tarea en oraciones pequeñas que puedan entender y poner una fecha al lado de cada una. Estas fechas siempre son terriblemente poco realistas y a menudo se pierden, y nuestras reuniones (que tenemos alrededor de una vez por semana) se llenan regularmente de momentos incómodos con personas que preguntan "por qué no se ha hecho esto todavía".

Estoy bastante seguro de que Agile no es el indicado para nosotros. Ahora, dado que (y lo he intentado) esta compañía no cambiará sus formas , y solo el equipo de desarrollo está dispuesto a cambiar, ¿existe una metodología de desarrollo que podamos adoptar que sea una buena opción para salvarnos un poco de cordura?

En realidad, Agile fue diseñado para abordar muchos de los problemas exactos que tiene. Si la gerencia realmente ha comprado y no pervertirá el proceso, podría ver una gran mejora. Déjame abordar tus problemas punto por punto. Mi experiencia es con scrum, así que hablaré desde ese punto de vista, pero estoy seguro de que otras implementaciones tienen beneficios similares.

• trabajo cayendo del cielo Estas historias se ponen en la parte inferior de la cartera de pedidos hasta que el propietario del producto y el equipo puedan reunirse para acordar avanzar. Su prioridad se determina en relación con todos los demás compromisos de su equipo, y esa prioridad es visible para todas las partes interesadas que estén interesadas en mirar. Debería ser extremadamente raro agregar una nueva función en el medio de un sprint, y solo los errores de mayor prioridad deberían poder interrumpir un sprint. Es sorprendente cuántas "emergencias" pueden esperar hasta el final de la próxima semana, cuando se hace una expectativa regular.
• emprender proyectos más grandes Tendrá la visibilidad para mostrar cómo las prioridades a corto plazo impactan sus proyectos a largo plazo. Si las personas mueven continuamente historias de usuarios frente a sus proyectos a largo plazo, está bien, pero para tomar esa decisión, todos sabrán el impacto que tendrá en el cronograma del proyecto a largo plazo.
• los planes de proyecto son elaborados por gerentes no técnicos. Se supone que las historias de los usuarios deben estar escritas desde un punto de vista no técnico, pero su equipo scrum debe estar facultado para hacer estimaciones y determinar detalles de implementación.
• las fechas son terriblemente poco realistas Su equipo maneja todas las estimaciones, porque ustedes son los que saben lo que están haciendo. Si esas estimaciones no son aceptables para el negocio, deben decidir cómo priorizar las características. Si necesitan más trabajo del que puede manejar, la necesidad de contratar a más personas será claramente visible.
• a menudo se pierden las fechas Primero, sus estimaciones serán más realistas, lo que debería ayudar. Además, estás mordiendo trozos más pequeños y realmente los estás terminando , lo que ayuda a la empresa a sentir que has producido algo útil incluso si no está completo.
• reuniones llenas de momentos incómodos Agile tiene más visibilidad y un ciclo de retroalimentación mucho más rápido, con un propietario del producto muy involucrado. Sus problemas de bloqueo y razones de demora no deberían ser una sorpresa.
• también haciendo soporte técnico Al contrario de la creencia popular, ágil no es incompatible con un horario dividido. Scrum influye en tus interrupciones en la velocidad de tu equipo. Si normalmente pasa la mitad de su tiempo haciendo soporte técnico, simplemente tendrá la mitad de la velocidad.

Lo que la gerencia y las ventas deben darse cuenta es que ágil no es una forma de ejercer un control más estricto sobre el equipo de desarrollo, le da al equipo más autonomía para hacer lo que son buenos mientras ayuda a la empresa a considerar de manera realista todas sus prioridades cuando asigna trabajo a el equipo.

Yo diría que aproveche sus caprichos de gestión! Parece que te están haciendo un favor y te están dando un impulso para mejorar tus métodos de trabajo.

Diles OK, iremos ágiles, requiere entre otras cosas:

• una separación de desarrollo y apoyo
• Un proceso formal de recopilación de requisitos, bajo el control del equipo de TI. "Historias", etc., suena muy vago, pero en realidad es un método "formal" disfrazado para parecer informal.
• la programación está bajo el control del equipo de TI.

Si no aceptan esto, entonces diles que no puedes ser ágil.

Agile no es una metodología de programación, Agile es una metodología de gestión de proyectos. Si la gerencia superior realmente quiere que pruebe esta nueva palabra de moda que han encontrado, deben ser capaces de comprender que el método Agile comienza desde arriba e involucra a la gerencia en cada paso del camino. Si necesita darles una dosis dura de realidad, tal vez organice una presentación de Powerpoint de 30 minutos sobre Agile para darles un poco de educación. Los gerentes aman Powerpoint.

Sin embargo, si, como usted dice, el equipo de desarrollo son las únicas personas dispuestas a cambiar, entonces ninguna metodología de desarrollo podrá ayudarlo. Sin un alivio del resto de sus deberes, las interrupciones continuarán ocurriendo y se le pedirá que cumpla con los plazos que simplemente no puede cumplir.

Mi consejo en este escenario es educar, no regañar, a la gerencia sobre cómo es realmente en la primera línea.

Ninguna metodología de desarrollo de software y gestión de proyectos puede ayudar en una organización donde el personal de ventas dicta el horario diario. ¿Cómo se supone que debes gestionar un proyecto en medio de una semana de trabajo tan caótica y distraída?

Muchos gerentes superiores ven el valor de Agile y desean los beneficios, pero casi nunca pueden hacer los cambios internos necesarios para asegurarse de que la mudanza sea exitosa. Las únicas tiendas exitosas de Agile que conozco comenzaron de esa manera. No puedo recordar una sola instancia en mi experiencia profesional de una tienda de desarrollo de software gestionado por ventas o en cascada que hace el cambio porque requiere un cambio fundamental en la cultura.

¿Es posible este cambio en la cultura? Sí, pero en su caso casi seguro que no.

Por lo general, un competidor necesita un cambio de cultura que amenace la existencia de la empresa o una situación de cambio o fabricación u otra situación similar para justificar una reorganización. En su situación, su empresa se encuentra en el otro extremo del espectro, donde el dinero en este momento es fácil y todos engordan.

Las empresas NUNCA cambian desde adentro cuando el dinero es fácil. ¿Por qué deberían hacerlo? Son exitosos a pesar de las fallas de desarrollo de software, no debido a los éxitos de desarrollo de software.

Mi consejo final es que si yo fuera tú, buscaría algo mejor. La gente aquí tiene buenos consejos, pero he visto esta canción y baile antes y simplemente no funciona en tu situación.

mire extremeprogramming.org - XP es una forma de Agile con aspectos fáciles de entender que puede elegir y elegir a la carta; un muy buen lugar para comenzar

el compromiso del cliente de no cambiar de opinión durante una interacción sería un buen punto de partida para su entorno, por lo que parece ;-)

Si uno considera el panorama de las metodologías, tanto tradicionales como contemporáneas, uno se daría cuenta de que "Agile" es más una "antimetodología" que una metodología. Los patrones apuntan a representar la solución del "mejor caso" para un problema dado dentro de un contexto particular. Los intentos de violar directamente una solución o patrón de este tipo, generalmente se conocen como "antipatrones" o prácticas de caso peor. Del mismo modo, mientras que las verdaderas metodologías de desarrollo de software intentan prescribir las mejores prácticas en el desarrollo de soluciones, "Agile" (Scrum, XP, etc.) intentan violar directamente cualquier estructura dentro del proceso de desarrollo de software, a favor de un caótico fortuito enfoque - que (en los últimos tiempos), también parece exigir aplausos de los espectadores (ingenuos).

Dicho esto, es apropiado tener en cuenta el contexto en el que surgió la filosofía ágil. Aunque en ese momento existían metodologías iterativas sofisticadas (p. Ej., Proceso unificado), la metodología principal seguía siendo el antiguo enfoque en cascada, que prescribía una "mejor práctica" de análisis de requisitos completo, luego diseño completo, luego desarrollar / codificar la solución, luego implementar la solución. Claramente, este enfoque de ingeniería para el desarrollo de software fue desaconsejado, y resultó en un montón de papeleo antes (y a veces sin nunca) ver una solución ejecutable.

Sin embargo, todavía no garantiza la expulsión del bebé con el agua del baño, como fue el caso de los magos de Agile. El enfoque ágil casi impone una negación directa de todo lo que se utilizó antes, excepto tal vez la codificación real de la solución. Claramente, esto es una indicación de una visión limitada por parte de sus creadores, o tal vez es simplemente un caso de "no hay nadie tan ciego, como aquellos que no quieren ver".

Sin embargo, el mérito de Agile es que fomenta procesos simplificados y se centra en el código ejecutable, que es inevitablemente su entrega final.

AHORA, para responder su pregunta más directamente:

Dada su visión general de su entorno, le sugiero que primero seleccione una implementación ágil (es decir, Scrum, XP, etc.). Luego, personalice el enfoque para adaptarse a su entorno, delineando un proceso claro de cómo trabajará su equipo, por ejemplo:

• Recibir solicitud de usuario (s);

• Priorizar las solicitudes de los usuarios;

• Calcule el impacto de la mejora en el sistema existente (tal vez durante sus reuniones de pie diarias / semanales);

• Calcule el tiempo de desarrollo de cada mejora y comuníquelos a los diversos usuarios que lo soliciten;

• Realizar mejoras reales en el sistema existente (es decir, codificación).

• Realice pruebas de usuario y obtenga el compromiso de los usuarios (por ejemplo, por correo electrónico) de que los cambios solicitados se han implementado con éxito.

Esto debería proporcionar cierta estructura (y orden), al tiempo que se mantiene una apariencia de un enfoque ágil.

Dicho lo anterior, recuerde que la antigua forma de hablar en inglés, "Tan ágil como un mono", ¡no fue acuñada sin razón!

Diría que necesita una metodología como Agile es esencial para su equipo. Como su empresa está tan desorganizada, necesita estar más organizado dentro de su propio equipo de desarrollo. Sin embargo, no creo que sus gerentes no técnicos tengan nada que ver con eso.

Si va a retrasar a su personal de ventas y exigir plazos realistas, debe justificarlo con planes organizados.

También en una nota aparte, si le llegan con estimaciones sin consultar a técnicos, simplemente rechace a quemarropa.

Quizás centrarse en los aspectos incrementales / iterativos es lo que tanto su equipo como las partes interesadas que caen del cielo necesitan para poder entregar de manera regular y consistente. Con el tiempo, el equipo de ventas y la gerencia confiarán en que cuando presenten una nueva solicitud de función, pueden estar seguros de que su equipo cumplirá en un plazo adecuado.

Por supuesto, debe invertir en pruebas de unidad / sistema / regresión, compilaciones automatizadas, alimentación de perros, etc., para llegar allí si aún no está allí.

Primero sugeriría recopilar algunos datos. Siéntese en un momento tranquilo y descubra cuál es realmente el status quo: cómo se hacen las cosas. Si la gerencia está decidida a implementar algo que puedan llamar ágil, entonces descubra algo que funcione para su equipo, redacte un documento, déle una bofetada al nombre "Agile" y estará listo. Tenga en cuenta que lo único que realmente saben sobre ágil es la palabra, y alguna asociación vaga con rapidez para su definición habitual en inglés. Entonces, lo que estoy recomendando es que su equipo se enfrente al problema, encuentre un sabor que funcione para usted y luego lo presente a su gerencia como la forma Ágil (tm). De lo contrario, algunos PHB recogerán un libro e intentarán colocar la clavija cuadrada en el agujero redondo y nadie estará contento.

Si opta por una forma "pura" de agilidad, puede ser difícil que su equipo también tenga que cumplir el rol de soporte. Seamos realistas, su jefe puede tener dificultades para aceptar a los miembros de su equipo que responden a las solicitudes de la mesa de ayuda diciendo "déjenme crear un elemento atrasado, lo abordaré en (tiempo hasta el final del sprint) semanas".

El mayor obstáculo es el dinero. Si todo es salsa verde, es mucho más difícil decir que algo está mal y necesita cambiar.

La mejor de las suertes.

Por el contrario, me parece que un método ágil es exactamente lo que necesita para hacer frente a los plazos incumplidos, las expectativas poco realistas y los proyectos mal planificados.

Su gerencia ha indicado que están interesados ​​en esta nueva palabra de moda. Lo más probable es que quieran usarlo para promocionar la comercialización de sus productos. esto no es necesariamente algo malo, pero deberá gestionarse con mucho cuidado si desea que un método ágil funcione para usted.

La mitad de la batalla es obtener la aceptación de la gerencia. Tenerlos receptivos a la idea misma de Agile es la mayor parte de la batalla. El resto es asegurarse de que sus expectativas se gestionen para que sigan queriendo que usted sea ágil, y evitar que se desencanten cuando sus gerentes sientan que su control sobre la gestión de proyectos se les está escapando de las manos.

Antes de que su empresa decida algo, recomendaría contratar un entrenador ágil para hacer un seminario y taller de medio día. Haga que todos piensen en equipo, tanto gerentes como desarrolladores, sobre lo que Agile cree que funcionará para usted, y lo que cree que no funcionará. Si, por otro lado, la gerencia confía en su criterio, entonces deberá familiarizarse con una serie de prácticas y métodos ágiles, y crear un seminario o el suyo propio. Personalmente, me inclinaría por conseguir un entrenador experimentado, para que no pierdas mucho tiempo y mantengas el impulso. Mientras tanto, tome una copia de un par de buenos libros de Agile como referencias, léalos detenidamente, pero también déjelos colgados en su escritorio donde la gerencia pueda verlos. La psicología subliminal puede hacer maravillas en una situación como la que has descrito.

Como mínimo, recomendaría leer lo siguiente:

• Desarrollo de software Lean - Mary & Tom Poppendieck
• Desarrollo de software ágil - Robert C. Martin

y para crédito extra (porque creo que es un gran compañero para los otros libros que mencioné):

• Código limpio - Robert C. Martin