agile - manifiesto - metodologia xp
Scrum y Programación Extrema(XP): Mejores Prácticas (13)
Seguimos a Scrum para el desarrollo de software en nuestra organización. Aunque tenemos una experiencia justa con Scrum, al final del día no producimos un buen código fuente. La gente está hablando de combinar la Programación Extrema (XP) con Scrum para producir resultados predecibles.
He revisado los materiales de programación extrema, pero no pude obtener una buena imagen.
¿Cómo se utilizan Scrum y Extreme Programming en el desarrollo de software?
¿Qué quieres decir con ''buen código''? ¿Por qué es importante un buen código? ¿Está hablando de capacidad de mantenimiento? ¿Necesita esto un buen código o una buena documentación? ¿Está hablando de confiabilidad? ¿Necesita esto un buen código o buenas pruebas y requisitos documentados? Etc
Use el sentido común, establezca sistemas racionales de criterios y evaluaciones, intente ignorar las afirmaciones no confirmadas de éxito atribuidas a alguna técnica o herramienta.
Además de ágil / scrum, recomiendo lo siguiente (algunas ideas deben ser implementadas por la gerencia ... así que buena suerte):
- análisis y discusión con otros antes de escribir una línea de código; Esto incluye traer los devs y no-devs pertinentes
- Revisiones de código antes del check-in (esto puede ser obligatorio en TFS y otros sistemas de control de fuente)
- fomentar el libre flujo de ideas organizativamente (predicar con el ejemplo); nunca castigue a alguien por compartir sus pensamientos (bueno, w / en razón), ya que hacerlo contradice el flujo libre de ideas que las empresas son más ágiles (y más rentables)
- establezca una posición "senior" o "arquitecto" para un desarrollador, posiblemente contratado desde el exterior, que sea extremadamente competente pero que tampoco sea tímido al rechazar la administración por el bien de la arquitectura de s / w, evitar las "características" que comprometer la extensibilidad a largo plazo, etc.
Cada desarrollador individual, su estilo, sus habilidades y su deseo de absorber siempre nueva información tienen tanto que ver con la calidad del código y el éxito del producto final como con el proceso de desarrollo.
Si no tienes a las personas adecuadas, ninguna técnica de PM te ayudará. Primero encuentre a las personas adecuadas, a las que pueden producir un buen código por separado, y solo entonces se preocupará de combinarlas en un esfuerzo de equipo. Un individuo puede socavar el esfuerzo de todo el equipo.
En una nota al margen, una cosa que odio de SCRUM es la reunión diaria de pie. Yarrr.
Eche un vistazo a esta matriz de buenas prácticas comparando SCRUM y XP hechas por James Shore. Por cierto, encontré su book bastante útil si quieres entender XP. También hay algunos articles que pueden darle una idea de algunas de las prácticas.
Estás escribiendo código incorrecto porque:
- Tu equipo no sabe cómo.
- Nadie en los controles de autoridad, aprueba requiere un buen código.
- ¿No te dan suficiente tiempo?
- Demasiada confianza en el código heredado pobre.
- No dar herramientas adecuadas (control de fuente, entorno de desarrollo, comunicaciones, etc.)
No estoy seguro de que ninguno de estos tenga que ver con Agile / Scrum.
Krish, ¿cuál es tu posición? un gerente de equipo? Descubrí que lo mejor que se puede hacer como líder del equipo Scrum es colocar un problema antes que el equipo y dejar que el equipo encuentre una solución. Por ejemplo, siempre estábamos fuera del objetivo al final del sprint. Entonces, en una revisión posterior al sprint, hice la pregunta "dame la cantidad de horas que representa la capacidad de nuestro equipo para el sprint". Hubo tres resultados:
- Nunca habíamos estado más cerca de cumplir con nuestra marca
- el número era más alto que mi estimación :-))
- Todos los miembros del equipo ponen un esfuerzo extra.
Estamos utilizando herramientas de software (OnTime en nuestro caso) para realizar un seguimiento de todas las medidas importantes y debatir nuestras estadísticas después de cada carrera. Además, tenemos la práctica de cambiar al menos una cosa en cada sprint.
Espero que esto ayude, por favor no dude en pedir más
Matej
La metodología SCRUM es muy popular. La mejor manera para que una compañía de software use SCRUM podría ser realizar un análisis FODA a nivel individual para cada uno de los programadores. Empareje a los programadores con un XP de uso en una parte específica del proceso de desarrollo del proyecto. Luego, saliendo del análisis FODA, use Sashimi u otro ciclo de vida del proyecto basado en FODA individual. Aunque esto parece un gran desastre en un proyecto, no existe una "bala de plata" para una metodología perfecta o un ciclo de vida para un equipo. El gerente del proyecto debe comprender y asignar a cada miembro el rol en función de donde él o ella sienta que serán más productivos en el proyecto. solo mis 2 centavos
Las prácticas de Scrum son adecuadas para la colaboración y la priorización con el propietario del producto. Sin embargo, por sí solo, Scrum no permitirá el ritmo sostenible del equipo de desarrollo.
El enfoque de XP se centra en las prácticas de ingeniería Prácticas tales como desarrollo guiado por pruebas (TDD), base de código compartido, diseño simple y evolutivo, programación pareada, pruebas automatizadas, integración continua, deuda técnica, etc.
De todas las prácticas de ingeniería, TDD es más difícil de aprender y, en general, las prácticas de ingeniería tienen una curva de aprendizaje más alta que las prácticas de administración (Scrum). Sin embargo, sin las prácticas de ingeniería, el código llegará a un punto en el que no podrá mantener la velocidad. La razón es que el código tardará más y más en probarse y se volverá frágil en cambiar.
Si va a tomar las prácticas de ingeniería, lo mejor es integrar en el equipo un entrenador técnico o de ingeniería. El entrenador proporcionaría capacitación de introducción para cada práctica y, a través del emparejamiento, propagará rápidamente las prácticas a través del equipo.
Scrum y XP son un gran partido. Algunas investigaciones muestran que la combinación de Scrum y XP da como resultado los equipos ágiles más efectivos. Dado que cada enfoque es distinto pero complementario, será sabio usar Scrum y XP en cualquiera de sus equipos ágiles.
Scrum es el proceso Agile para la gestión de proyectos, por lo que no tiene un impacto en la calidad del código, aparte de su enfoque estricto en tener siempre un sistema de entrega potencial al final de cada "sprint" de 2-4 semanas. Al mantener los sprints cortos y obtener comentarios diarios, el gerente del proyecto tiene una mejor idea de cuánto esfuerzo requieren las nuevas características para implementar, y el equipo tiene una buena idea de la importancia relativa de cada nueva característica.
Todavía tienes que hacer el trabajo duro de programación. Hay muchos libros geniales sobre esto (como el Código Completo de McConnell, y El Programador Pragmático de Hunt y Thomas) y debes estudiarlos cuidadosamente y aplicarlos a tu trabajo.
Scrum es una metodología ágil de gestión de proyectos . No aborda las prácticas requeridas para crear "bienes" de ningún tipo, sino que nos brinda el proceso que nos llevará desde el inicio de una visión hasta el producto final, independientemente del proceso de desarrollo real. El proceso Scrum no te dice cómo crear calidad. Le muestra cuál es la calidad, dónde están sus problemas y lo desafía a solucionarlos.
La programación extrema es una metodología de desarrollo de software ágil. Nos da un proceso con el cual crear software de una manera ágil y productiva. Se ocupa de, aunque no se especializa en la gestión del proceso de desarrollo, y se centra principalmente en las prácticas de ingeniería necesarias para entregar software, con calidad.
Cuando se adopta Scrum con el propósito de desarrollar software, las prácticas de ingeniería se importan desde prácticas ágiles de desarrollo de software, la mayoría de las veces desde XP. Estas prácticas son aquellas que pueden adoptarse de una manera que está desacoplada del resto de las prácticas de desarrollo. En la mayoría de los casos, estas prácticas son: desarrollo impulsado por pruebas, refactorización, programación de pares e historias de usuario , aunque de ninguna manera son necesarias en Scrum, o la única forma de hacer las cosas (solo muy recomendable). El modelado ágil es otra fuente común de prácticas de ingeniería ágil.
En resumen, al mezclar Scrum y XP, que es, con mucho, la mezcla más común, se utilizan todos los artefactos de gestión de Scrum, por ejemplo, Sprints, Scrums diarios, retrospectivas, gráficos de grabación, etc., y se agrega TDD de XP, refactorización, Programación de pares y diseño JIT a través de Historias de Usuario.
Por supuesto, Scrum es Scrum, así es como comienza y adapta constantemente (refactoriza, si lo desea) el proceso para responder a las necesidades específicas de su organización.
Scrum no tiene nada que decir sobre la programación.
En mi opinión, no puede ser "ágil" sin las prácticas de ingeniería de software que le permiten, a nivel técnico, responder rápidamente a los cambios: diseño incremental, pruebas de unidad y aceptación, refactorización, integración continua, propiedad de código colectivo.
Esto está por encima de todas las otras cosas que se necesitan, como un alto nivel de participación de sus clientes y una comunicación efectiva dentro y fuera del equipo.
Junto con los otros libros mencionados aquí, The Art of Agile Development de James Shore y Shane Warden es el mejor libro sobre desarrollo de software ágil que existe.
[editar] Algunos enlaces a fuentes que otras personas han mencionado aquí:
Scrum y XP desde las trincheras de Henrik Kniberg (excelente presentación en infoq.com)
Tanto el Programador Pragmático (como lo menciona Jim Ferrans) y el Código Limpio son recursos excelentes para el programador ágil. También puede querer echar un vistazo a los libros de la serie de programación extrema.
Inspeccionar y adaptar.
No Silver Bullet
No hay un suero mágico para que los equipos tengan éxito solo porque están usando Scrum / XP / Agile et.all; Encuentra tus cuellos de botella y elimínalos uno por uno.
Actualización : Algunos sienten que mi respuesta no es lo suficientemente útil. Afirmo que las ''cicatrices ágiles'' me han dejado así - (Ponte mi sombrero útil) Tal vez deberías leer Scrum y XP desde las trincheras