¡Metodología de desarrollo desde el ángulo del desarrollador!

La metodología de desarrollo según un desarrollador es utilizar la siguiente ruta para el desarrollo de aplicaciones Ruby on Rails.

1. Escriba una lista de objetivos, roles y características.

• Metas: cuáles son las metas de todo el proyecto, comerciales y de otro tipo. Esto le ayudará a decidir qué características son importantes.
• Roles: ¿quién utilizará el sitio? ¿Visitantes, miembros registrados, administradores? ¿Diferentes personas tienen diferentes puntos de vista sobre 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 foros y blogs; Administradores: moderar el contenido del usuario

2. Escribe una lista de historias.

• Una historia es diferente a una característica porque representa un hilo único de interacción desde la perspectiva de un usuario particular.
• Es común expresar historias en la forma "Como ____ quiero ____ para poder _____". Esto te obliga a responder tres preguntas importantes: ¿Para quién es esto? ¿Qué quieren hacer? ¿Por qué quieren hacerlo?
• Si no puede completar una historia en este formulario, es probable que aún no tenga una respuesta a una de estas tres preguntas, por lo que deberá pensar un poco para obtener las respuestas antes de que la historia sea procesable.
• Ej: “Como administrador, quiero prohibir a los usuarios el foro para poder mejorar la calidad del contenido enviado por los usuarios en el sitio.
• Escriba estas historias en tarjetas. Esto le ayudará en la estimación y priorización.

3. estimar 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 apégate a ello.
• No se obsesione demasiado con la exactitud de las estimaciones. Muchas cosas afectan el tiempo que te lleva terminar una historia, por lo 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 requieren poco esfuerzo, como historias que resultarán en la creación de un modelo simple con un controlador REST, de historias que requieren mucho esfuerzo, como interconectar su aplicación con una API de terceros desafiante, o una historia que requerirá que uses una tecnología con la que no estás muy familiarizado.
• Escribe la estimación en cada tarjeta.

4. Prioriza las historias

• Reorganice las tarjetas en el orden en que le gustaría abordar las historias.
• Sólo el propietario del producto puede realmente tomar esta decisión. Hay muchas cosas que intervienen en la priorización: plazos, pruebas de usuario, valor comercial, etc. La estimación puede tener mucho que ver con la priorización, porque ilumina el costo de oportunidad. Tal vez el propietario del producto realmente quiera ese panel de administración detallado, pero si todas las historias para que eso funcione suman 40 puntos, vale la pena dedicar un mes solo a esta función. Quizás el propietario del producto todavía quiera la historia.
• ¿Hay alguna historia que no encaje en el producto mínimo viable para lanzar? Si es así, deberías moverlos hacia abajo. Intente completar una aplicación que funcione lo más rápido posible para poder presentarla a los usuarios.
• En este punto, suelo mover mis tarjetas a Pivotal Tracker, pero conozco a muchas personas que prefieren lápiz y papel.

5. Pruebe la primera historia hasta completarla

• Empezar con pepino Escriba una función de Cucumber que cubra la interacción del usuario con el sitio de principio a fin. Defina los pasos no definidos a medida que los encuentre, y cuando encuentre su primer error, sabrá que hay un comportamiento que desea y que su aplicación no tiene (esto sucederá muy rápidamente al principio, porque su aplicación en blanco no tienen 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.
• Continuar a Rspec Escribe la prueba para el comportamiento que desearías tener.
• Escribe tu código Escriba el código para aprobar la especificación. Esto lo llevará a lo largo de su aplicación, desde el enrutamiento a la interfaz de usuario, los modelos, el esquema de la base de datos y el controlador. Abordará estos fragmentos de código en el orden al que le indiquen sus pruebas.
• Repite hasta que pase el Pepino y termines la historia.
• Ahora es un buen momento para arreglar el estilo CSS, suponiendo que ya tengas el diseño terminado. Si trabajo solo o sin un diseñador, me gusta intentar estructurar la interfaz de usuario en papel o en algo como Balsamiq Mockups incluso antes de comenzar a codificar la historia.

6. Acepta 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 tus pruebas? No rompiste la construcción, ¿verdad? Si es así, necesitas arreglar lo que rompiste.
• Si trabaja solo, puede ser útil que otra persona lo acepte, ya que puede resultar difícil ver su propio trabajo con ojos objetivos.

6. Repetir hasta terminar

Así es como hago las cosas. De ninguna manera es 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 sobre el 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 de Rails estarán de acuerdo en que el flujo de trabajo adecuado es: 1) Identificar un una sola historia 2) Escribe pruebas para ello 3) Complétala. 7. Implementación

Recomendamos implementar la aplicación en la nube debido a la escalabilidad, el tiempo de actividad, la rentabilidad y muchos otros factores. Somos expertos en despliegue en la nube, ya sea Heroku, Rackspace o AWS.

Herramientas: Capistrano, Apache, Passenger, Heroku, GIT/SVN (se utiliza principalmente GIT)

8. Soporte posterior a la implementación

Una vez que la aplicación está activa, siempre es necesario respaldarla para que el usuario final tenga una experiencia agradable. Utilizamos AMC para las aplicaciones que desarrollamos y contratamos recursos para encargarnos de las mejoras de nuevas funciones, la corrección de errores y el mantenimiento del servidor las 24 horas, los 7 días de la semana. En resumen, con ello garantizamos que la aplicación que desarrollamos también se gestiona y mantiene correctamente.

Herramientas: BugZilla, Redmine, Pivotal Tracker, servicio de asistencia técnica