Metodología de desarrollo ágil para
Creación de aplicaciones Rails
Escribimos una lista de objetivos, funciones y características
- Objetivos: cuáles son los objetivos de todo el proyecto, tanto empresariales como de otro tipo. Esto le ayudará a decidir qué características son importantes.
- Funciones: ¿quién va a utilizar el sitio: visitantes, usuarios registrados, administradores? ¿Diferentes personas tienen diferentes visiones de la misma información en el sitio?
- Características: ¿cuáles son las categorías básicas de interacción en el sitio? Por ejemplo: Usuarios: registro, uso de los foros y blogs; Administradores: moderación del contenido de los usuarios.
Escribimos una lista de historias
- Una historia es diferente de una función porque representa un único hilo de interacción desde la perspectiva de un usuario concreto.
- Es habitual expresar las historias en forma de "Como ____ quiero ____ para poder _____". Esto te obliga a responder a tres preguntas importantes: ¿A quién va dirigido? ¿Qué quieren hacer? ¿Por qué quieren hacerlo?
- Si no puedes completar una historia de esta forma, es probable que aún no tengas respuesta a una de estas tres preguntas, por lo que tendrás que pensar un poco para obtener las respuestas antes de que la historia sea procesable.
- Ejemplo: "Como administrador, quiero expulsar a los usuarios del foro para poder mejorar la calidad de los contenidos enviados por los usuarios.
- Escriba estas historias en tarjetas. Esto le ayudará en la estimación y priorización.
Estimamos que las historias
- La estimación es un tema enorme en sí mismo, pero la idea básica es asociar un nivel particular de esfuerzo con cada historia.
- Las escalas más comunes son 0/1/2/3/4, 0/1/2/4/8. No creo que esto sea increíblemente importante, pero elige algo y quédate con ello.
- No te obsesiones demasiado con la exactitud de las estimaciones. Hay muchas cosas que influyen en el tiempo que se tarda en terminar una historia, así que las pequeñas diferencias en la complejidad de la historia tienden a perderse en el ruido.
- Su objetivo aquí es diferenciar las cosas que son de bajo esfuerzo, como las historias que resultarán en la creación de un modelo simple con un controlador REST, de las historias que son de alto esfuerzo, como la interfaz de su aplicación con una API de terceros desafiante, o una historia que le obligará a utilizar una tecnología con la que no está muy familiarizado.
- Escribe la estimación en cada tarjeta.
Priorizamos las historias
- Reorganiza las cartas en el orden en que quieras abordar las historias.
- Sólo el propietario del producto puede tomar realmente esta decisión. Hay muchas cosas que intervienen en la priorización: plazos, pruebas con usuarios, valor de negocio, etc. La estimación puede tener mucho que ver con la priorización, porque ilumina el coste de oportunidad. Tal vez el propietario del producto realmente quiere que el panel de administración detallada, pero si todas las historias para hacer que el trabajo total de 40 puntos, ¿vale la pena gastar un mes en esta característica. Tal vez el propietario del producto todavía quiere la historia
- ¿Hay historias que no encajan en el producto mínimo viable para lanzar? Si es así, deberías moverlas hacia abajo. Intenta completar una aplicación que funcione lo antes posible para poder ponerla a disposición de los usuarios.
- En este punto, suelo mover mis tarjetas a Pivotal Tracker, pero conozco a muchas personas que prefieren lápiz y papel.
Probamos la primera historia hasta su finalización
- Empieza con Cucumber Escribe una función de Cucumber que cubra la interacción del usuario con el sitio de principio a fin. Define los pasos indefinidos a medida que llegues a ellos, y cuando encuentres tu primer fallo, sabrás que hay un comportamiento que deseas que tu aplicación no tiene (Esto sucederá muy rápidamente al principio, porque tu aplicación en blanco no tiene mucho comportamiento).
- Si tengo interacciones de Javascript que son una parte clave de la interacción del usuario, intento que Cucumber las pruebe usando la etiqueta @javascript.
- Continúe con Rspec Escriba la prueba para el comportamiento que le gustaría tener.
- Escriba su código Escriba el código para hacer pasar la especificación. Esto te llevará por toda la aplicación, desde el enrutamiento hasta la interfaz de usuario, los modelos, el esquema de la base de datos y el controlador. Abordarás estas piezas de código en el orden que te indiquen las pruebas.
- Repite hasta que se te pase el Pepino y hayas terminado con la historia.
- Ahora es un buen momento para arreglar el estilo CSS asumiendo que tienes el diseño hecho. Si estoy trabajando solo o sin un diseñador, me gusta tratar de wireframe la interfaz de usuario, ya sea en papel o en algo como Balsamiq maquetas antes de empezar a codificar la historia.
Aceptamos la historia
- ¿Es aceptable la historia? ¿Hace lo que querías? De lo contrario, debe regresar y hacer que funcione como se suponía. Escribir las pruebas de Cucumber con antelación ayuda a evitar que esto suceda.
- ¿Pasan todas las pruebas? No has roto la compilación, ¿verdad? Si es así, tienes que arreglar lo que has roto.
- Si trabajas solo, puede ser útil que otra persona haga la aceptación por ti, ya que puede ser difícil ver tu propio trabajo con ojos objetivos.
Repetimos hasta terminar
Así es como yo hago las cosas. No es ni mucho menos la única forma de hacer las cosas, pero es una forma muy común de hacer las cosas en Rails. Creo que hay un buen debate en torno al valor de la estimación ágil, o de tecnologías particulares como Cucumber vs. Steak o RSpec vs Test::Unit, pero la mayoría de los desarrolladores Rails estarán de acuerdo en que el flujo de trabajo adecuado es:
1) Identificar una única historia
2) Escribir pruebas para ello
3) Complétala.
Spanish 
English 
Japanese 
German 
French 
Italian 
Swedish