XP vs Tradicional buena gestión de proyectos [cerrado]

Question

He estado en la industria de TI durante 10 años, pero he trabajado en "tradicionalmente". equipos de proyecto gestionados (tanto bien gestionados como mal gestionados).

He oído hablar del " nuevo " scrum o XP tipo de gestión de proyectos y anhelaba ser parte de uno (como gente s / w siempre nos gusta algo nuevo, supongo) pero no tengo la oportunidad.

Mi pregunta es la siguiente: ¿cuáles son sus experiencias al pasar al " nuevo " manera - ¿fue significativamente mejor o peor o no fue diferente? ¿Ha habido alguna mejora en la tasa de éxito del proyecto al usar la forma de desarrollo XP o es igual a cualquier proyecto tradicional bien administrado?

Esta no debería ser una cuestión política, sino solo sus experiencias cuando se mudó al nuevo mundo o experimentó al menos una vez y de regreso.

Gracias de antemano

Answer 1

Antes de oír hablar de XP, tenía un muy buen gerente (Mike) en un trabajo temprano que tenía. Estaba acostumbrado a administrar ingenieros y pasó a administrar software. Después de algunas malas experiencias de trabajo, volví a mirar su estilo versus la típica gestión de proyectos que tenía antes y después de trabajar con él.

• Nos reunimos con todos al menos una vez al día, pero nos dio espacio para trabajar
• Usó una pizarra blanca con dos columnas, las personas que trabajan y en lo que están trabajando cualquiera pueden mirar esa pizarra y ver si se ha hecho o se está haciendo algo
• Tenía a todos en el tren cruzado. Aprendí rcs y luego cvs allí y cómo usar make files
• Funcionó productivamente " post mortum " cuando se completó una tarea. Él haría una pregunta como "¿habría ayudado si X?" o "la próxima vez, podemos intentar ..."
• Mantuve a todos trabajando en tareas cortas y gestionamos nuestro tiempo, por lo que siempre trabajamos en algo pero nunca tuvimos un montón de cosas acumuladas

Mike hizo todo en papel. Mantendría cuadernos y fichas con él. Insistió en que todo lo que le pidiera la gerencia se convirtiera en tareas manejables, a menudo escritas en tarjetas de notas. Se negó a que alguien trabajara en algo que no podía explicarse claramente o tenía un objetivo claro. Él le preguntaba a los vicepresidentes "¿a qué te refieres con más rápido?" "¿Qué tipo de métricas deben mostrar los informes?" "¿Por qué debería ser esto una prioridad?" Parecía tener una paciencia casi infinita al escribir lo que había que hacer y lo que se entiende por "hecho"

Cuando leí por primera vez el libro XP, me sorprendió lo familiar que era "la forma en que Mike trabajaba"

Parece que Agile solo se trata de implementar un conjunto de mejores prácticas y evaluar cómo funcionan en su entorno. Cuando no funcionan, cámbialos. Cuando trabajan, quédate con ellos.

Creo que el verdadero problema con la gestión de proyectos tradicional es que la mayoría de las veces, realmente no existe. Me sorprende la cantidad de tiendas que afirman usar RUP o Code Complete o incluso Agile, y en realidad no tienen nada reconocible como gestión de proyectos. Claro, hay reuniones. Y la gente llamó a los gerentes de proyecto. Pero haga una pregunta simple como "qué se ha hecho en el proyecto X". o "qué queda por hacer en el proyecto Y" Y nadie tiene una respuesta. Tienen que cavar a través de correos electrónicos o señalar un archivo de proyecto de MS cómico inexacto.

Si una persona afirmó estar a dieta y no pudo responder preguntas sobre lo que estaba comiendo o cómo se ejercitaba; ¿aceptarías que realmente estaban a dieta?

Answer 2

Te llevas tu equipaje viejo cuando vas. Lo que significa que cualquier mala práctica de gestión de proyectos que haya tenido anteriormente aún persistirá.

Sin embargo, diré que las cosas mejoraron mucho cuando comenzamos a cerrar el círculo entre nosotros y el cliente. Una retroalimentación y creación de prototipos mayor y más frecuente con el cliente significa muchos menos momentos en que el cliente dice: "Esto no es lo que quería".

Answer 3

He usado (un poco modificado) Scrum antes en el trabajo y aquí están mis pensamientos:

• Las reuniones diarias y el agotamiento proporcionaron motivación para avanzar en las tareas.
• Nuestro gerente podría hablar con colegas al otro lado del charco y mostrarles "esto es en lo que estamos trabajando este mes".
• Sabía exactamente qué tareas tenía que hacer y ya había estimado el tiempo necesario para completar.
• Cuando las prioridades cambiaron (nuevas tareas, errores importantes agregados), hubo un proceso bien definido para manejar agregarlos al sprint o simplemente empujarlos al trabajo atrasado.

Answer 4

Estas son respuestas encantadoras, pero creo que todos confunden la gestión de proyectos con las metodologías de desarrollo / diseño.

Answer 5

Estoy en un equipo que comenzó Scrum hace unos meses y parece que estamos haciendo las cosas más rápido y con mucho menos "desperdicio". (proyectos que se desechan). Solo mis observaciones de nuestro pequeño equipo (4 desarrolladores).

Answer 6

He encontrado que el movimiento general hacia las prácticas Agile / XP es muy positivo, en muchos sentidos, carga la calidad en el proceso del proyecto / desarrollo. Necesitará la aceptación de la gerencia y del equipo para ver realmente el éxito ... algunas sugerencias:

• pruebe cualquier cambio con un proyecto pequeño (2-3 personas)
• entienda en qué áreas su equipo actual puede mejorar (calidad, productividad, tiempo de comercialización) e incorpore algunos procesos Agile / XP / Scrum (lo que sea) en ... no los incorpore todos en al mismo tiempo y comprender qué procesos abordan qué problemas antes de cualquier cambio
• si es posible: haga un seguimiento de las áreas que desea cambiar y compárelas con otro proyecto en ejecución al mismo tiempo (el simple enfoque de mejorar algo a menudo es suficiente para mejorarlo, hay un estudio / término para esto, pero lo olvido qué es)
• a veces verás una caída en el rendimiento cuando comiences un nuevo proceso, esto es parte de la curva de aprendizaje
• nunca asuma que un buen cambio hoy seguirá siendo un buen cambio mañana, siempre revise las áreas de su proyecto y esté listo para cambiar cualquier proceso en cualquier momento
• ningún cambio sigue siendo bueno para siempre, al igual que refactorizar el código, refactorizar sus procesos
• asegúrese de obtener la aceptación del equipo y la gerencia, no puede forzar el éxito

Answer 7

Me gustan algunas de las cosas que hacen los enfoques ágiles, pero también valoro algunas de las cosas que hacen los enfoques tradicionales.

Ambos pueden funcionar, al igual que una mezcla de los dos, que es lo que creo que funciona mejor para mi equipo ahora. He implementado el desarrollo incremental y realmente nos ayuda; El desarrollo iterativo es un poco más difícil y todavía estamos trabajando en eso. Sin embargo, tenemos una variedad de componentes, y muchos de nuestros interesados ??(y PM) prefieren artefactos e hitos tradicionales. Así que tenemos que seguir encontrando el equilibrio adecuado.

También he encontrado que aún más importante que la metodología son las personas que lo implementan. Las buenas personas encuentran la manera de hacer un buen trabajo y hacer las cosas independientemente de la metodología, aunque ciertamente la metodología puede tener efectos sobre la eficiencia (y la moral :)). Sin embargo, los recursos mal alineados pueden usar la mejor metodología y encontrar formas de entregar malos resultados.

Answer 8

Para desarrolladores, las excelentes lecciones de XP & amp; Co. son ciclos de lanzamiento más cortos y un enfoque más evolutivo, en el sentido de que el cambio de requisitos se acepta como parte natural de cualquier proyecto. Además, los clientes sugieren soluciones, pero los diseñadores y desarrolladores deben comprender los problemas.

Lecciones para gerentes: los desarrolladores no son convertidores de código de especificaciones intercambiables, sus fortalezas y debilidades individuales pueden hacer una diferencia de productividad de 10 o más para un tema determinado. El conocimiento y la experiencia son las habilidades más valiosas en su equipo, y los desarrolladores pueden enseñar a cada uno. Los gerentes no necesitan entender lo que hacen los desarrolladores para hacer cumplir los resultados deseados.

---

XP y amp; Las empresas suelen mezclar soluciones con el problema de hacer un cambio de empresa . El consultor heroico de XP que guarda un solo proyecto condenado, retrasado y descarrilado actúa en gran medida como un amortiguador entre el desarrollo y la gestión. Pero si está buscando qué aprender, debe separar estos aspectos.

Lo que aprendí en los últimos años es que los errores no son un defecto de la personalidad, y que el cielo no se cae cuando cambian las especificaciones. Aprendí que si bien los errores de diseño siguen siendo los más caros de hacer, no hay un solo "perfecto". diseño. En lugar de hacer algo bien, debemos implementar salvaguardas que, de todos los detalles, ninguno salga mal, y he aprendido a usar el margen de maniobra entre "correcto". y "no está mal" a nuestra ventaja.

Answer 9

Mi experiencia ha sido que prefiero usar Scrum sobre los enfoques tradicionales, ya que no ha sucedido a menudo que los requisitos puedan permanecer sin cambios durante la duración de un proyecto donde generalmente los proyectos parecen ejecutarse al menos 6 meses a mi actual. más de un año.

También puede darse el caso de que no haya ninguna gestión de proyectos y todos simplemente se esfuercen por "hacer que funcione". entonces tener algo de estructura formal es bueno sobre nada. Hay algo en la pregunta de qué tan bien se une el equipo y los egos rara vez aparecen, ya que no es el código de alguien sino el código del equipo y hay una especie de grupo que piensa dónde, mientras que cada persona tiene su punto de vista, nadie trata de hacer que todos los demás vean las cosas de esa manera.

A veces me parece que algunos enfoques de Scrum y Agile que he usado terminan siendo como rápidos en lugar de una gran cascada. Lo que quiero decir es que el ciclo de reunir requisitos - Analizar y diseñar - Implementar - Probar - Implementar y obtener requisitos actualizados parece repetirse una y otra vez, de modo que lo que sale al final sería extremadamente difícil de establecer al comienzo del proyecto a menos que el patrocinador del proyecto pueda dar requisitos muy detallados que nunca cambiarían.