2008-11-16 11 views

Respuesta

19

Bueno OP, no hay una sola guía documentado paso a paso para el 'desarrollo ágil de software' y cualquier procedimiento que se alinea con the manifesto califica como ágil

Pero también entiendo que para empezar, tiene que haber una fase de aprendizaje "de mano"/"por el libro". Así que recomendaría que - eche un vistazo a su proceso de desarrollo actual. Descubra las actividades de "desperdicio" que implican mucho tiempo y retome una práctica ágil que contrarresta/minimiza el tiempo dedicado a esa actividad. p.ej. Si está luchando de forma rutinaria con los problemas de compilación, configure un servidor de integración continuo primero y establezca una rigurosa verificación previa de verificación. En lugar de cambiar todo de tal manera que todo el mundo se sienten perdidos y alienados,

  • recoger una práctica a la vez
  • invertir alrededor de 2-3 semanas con it..get cómodo con él
  • cheque si todo el mundo en el equipo siente que es útil. Si es así, quédese con él, hágalo parte de su nuevo proceso. De lo contrario, descartar y encontrar y reemplazar con otro remedio alternativo.

En caso de que todo el equipo es nuevo para ágil, lo recomiendo (en orden de intensidad)

  • prácticas de un desarrollador ágil (Andy Hunt, Venkat S., libro delgado, alto valor relación -to-página para los novatos)
  • ágiles Principios prácticas y Patrones (Robert Martin & Miqueas)
  • Conducta semanal que consigue better 'sesiones para ciertas prácticas como TDD (Beck, astels, et.all), Refactoring (Fowler , Joshua K.), etc. que seguramente tendrán grandes recompensas.
  • un mes o así en .. ir a por los libros de filosofía como XP aceptar el cambio - Beck, Libros magra Poppendieck, ágil S/w Desarrollo - Alistair Cockburn, Peopleware - DeMarco, Lister

que había recomendamos echar un vistazo a books listed here

+0

Gran respuesta. muchas gracias. Lo haré – ecleel

+0

@Gishu su enlace no funciona. – Inquisitive

9

Hay una serie de screencast llamada Autumn of Agile, que ofrece una introducción a los principios ágiles.No hay que muchos episodios todavía, pero el plan episodio se ve así:

  • Valores ágil y Prácticas general
  • principios básicos de diseño OO
  • patrones de diseño en Acción
  • Prueba Bases Unidad
  • Mock Objects
  • TDD
  • archivo de Proyecto/Organización carpeta
  • control de código fuente Fundamentos
  • integración continua/Construir Automatización
  • Principios de planificación de proyectos ágiles
  • Visión general de dominio determinadas por el diseño de conceptos fundamentales
+0

WAW, Great Erik. gracias por esos episodios útiles :) – ecleel

2

cuál es la mejor forma de hacerlo es adoptar un enfoque de desarrollo ágil de software depende mucho sobre la situación en la que se encuentra. ¿Por qué quiere adoptar Agile? ¿Qué beneficios son más importantes para ti? ¿Cuáles son los mayores problemas que necesita resolver? ¿Tiene los recursos para hacer una adopción disruptiva todo en uno? ¿O prefiere comenzar con una adopción incremental de toma más larga y potencialmente más dolorosa?

Recomiendo mucho el libro "Patrones de adopción ágiles" para ayudarlo a pensar cuál es el enfoque de adopción adecuado para usted. También podría ser una buena idea obtener ayuda directa (en el sitio) de alguien con conocimiento en desarrollo Ágil: alguien que pueda observar a su equipo, ver patrones y antipatterns y aportar su experiencia sobre cómo tratar con ellos.

Una de las prácticas que siempre me gustaría adaptar como una de las primeras son las retrospectivas de iteración. Esos son vitales para el ciclo de adaptación de los enfoques ágiles.

3

Henrik Kniberg reunió un short PDF, rápido y fácil de leer. Puedes comenzar leyéndolo. Obtendrás la respuesta a tu pregunta y mucho más.

+0

Gracias Philippe. PDF útil :) – ecleel

1

Voy a la segunda recomendación de Ilja para el libro: http://www.amazon.com/Agile-Adoption-Patterns-Roadmap-Organizational/dp/0321514521

creo que la pieza más valiosa del libro es la descripción de lo que las prácticas a adoptar primero en alcanzar determinados valores de negocio (calidad, tiempo en el mercado, ...).

críticas del libro: http://www.amazon.com/Agile-Adoption-Patterns-Roadmap-Organizational/dp/0321514521 Capítulo de Muestra: http://www.informit.com/store/product.aspx?isbn=0321514521#info8

finalmente vuelven a unirse a una lista de correo ágil en groups.yahoo.com ya sea ScrumDevelopment o AgileProjectManagement se adapte a sus necesidades bien.

1

He leído un montón de libros ágiles , y el único libro que realmente podría recomendar de todos ellos es "The Art of Agile Development" de James Shore.

1

La mejor manera es contratar a un entrenador ágil con experiencia técnica. Consigue que alguien trabaje en tu equipo que haya hecho cualquier método ágil que quieras adoptar (scrum, xp, crystal, kanban, ... lo que sea) antes.Tendrán que ver sus circunstancias laborales y, preferiblemente, trabajar en el entorno para ayudar. Verifique sus referencias y asegúrese de que realmente lo hayan usado en la práctica. Un montón de aspirantes y falsificaciones.

Tener a alguien con experiencia en el equipo marca la diferencia. Es extremadamente difícil adoptar desde solo leer un libro. Estás tratando de cambiar una cultura y no puedes hacer eso usando una lista de verificación o un algoritmo. Es una cosa de complejidad social. Estás tratando de alentar el comportamiento emergente en un sistema complejo.

Si no puede contratar un entrenador ágil, busque otras personas en el equipo o en su departamento o empresa que tengan experiencia y pídales que 'vuelvan para ver al equipo. Muéstreles sus circunstancias y obtenga su opinión.

Diferentes equipos necesitarán diferentes piezas de asesoramiento - que depende de muchas cosas, incluyendo los miembros del equipo, el tipo de tecnologías que utiliza, el tipo de negocio que trabaja en ...

Por encima de todo, hacer contacta con agilistas locales y aprende cara a cara.

1

No eres ágil o no, eres más o menos ágil.

para empezar a recibir más ágil de lo que ya está haciendo,

  • visualizar más (métricas que aparecen en pantalla, tablero visual, etc)
  • obtener más información y acortar ciclos de retroalimentación (IC métricas de código, , métricas de errores, etc)
  • reducen la cantidad de trabajo simultáneo en curso (WIP) - es decir, reducen la multitarea tanto a nivel individual y de equipo

Si usted es capaz de probar algo n ew recomendaría Kanban. Es la herramienta ágil más flexible y menos prescriptiva, y usted comienza visualizando su flujo de trabajo y limitando su WIP.

Cuestiones relacionadas