Valores por defecto
Los “valores por defecto” están en el origen de buena parte de los problemas de comunicación.
Cada una de las partes suele dar por sentado ciertos aspectos. Asume que son obvios y evidentes, que la otra parte los conoce y los comparte, y que por tanto no es necesario mencionarlos ni explicitarlos.
Pero, en realidad, muchas cosas que nos parecen obvias no lo son hasta que las comunicamos.
En este post vamos a compartir contigo algunas de las cosas que en ASPgems asumimos “por defecto” y que, salvo petición expresa en contra, realizamos en todos los proyectos.
Estos son nuestros valores por defecto:
- Desarrollamos para la última versión estable de los navegadores Firefox, IE y Chrome
- Usamos HTML5 XHTML 1.0 Transitional
- Elegimos y empleamos las herramientas OpenSource más adecuadas para realizar todo el desarrollo
- Alojamos las aplicaciones en nuestro hosting, con un entorno interno de integración y uno de producción
- Utilizamos Pivotal Tracker para la gestión del proyecto
- No entregamos documentación formal: el código es la documentación
- No damos formación específica para las aplicaciones: no es necesario, ya que el cliente ha ido aprendiendo a medida que avanzaba el proyecto
- Monitorizamos la salud de la aplicación vía Pingdom y New Relic
- No escribimos tests automatizados hasta la fase de mantenimiento
- Trabajamos en remoto
- No hacemos subidas a producción en festivos o vísperas de festivos
- Las subidas a producción se hacen de forma automatizada, sin realizar cambios a mano
- Planificamos el desarrollo en sprints de una o dos semanas, intentando -dentro de lo posible- no actuar por emergencias (más allá de los problemas detectados en producción)
- No ofrecemos versión móvil de la web
- Incluimos tracking básico de Google Analytics, sin configuraciones adicionales
- Construimos un HTML bien estructurado para SEO, sin optimizaciones específicas para todas las posibilidades existentes (microformatos, breadcrumbs, añadir páginas categorizadas con enlaces, …)
- Ofrecemos una política de backups diarios
- Desarrollamos para el tráfico estimado, sin sobreoptimizar rendimiento para más carga de la que se prevé a corto plazo
- Opinamos -mucho- sobre cuál es la mejor manera de hacer las cosas y, siguiendo la filosofía less is more, intentamos maximizar la cantidad de cosas que NO se implementan para concentrarnos en lo que es esencial para el negocio del cliente
20 de octubre, 2010 - 18:38
Dos dudas:
- ¿Por qué no escribís test automatizados hasta la fase de mantenimiento? Parece un poco raro, no es que sea un totalitarista del TDD, pero escribirlos más o menos a la vez ayuda… a que estén escritos (en mi opinión, claro), sino luego es un esfuerzo muy grande.
- ¿Por qué no hay versión web? ¿o es que la versión estandar ya es lo suficientemente buena?
Por lo demás, siempre se aprende o recuerda algo con estas listas de principio… un saludo.
20 de octubre, 2010 - 18:43
Hola Aitor,
La discusión sobre los test es muy larga, pero en 140 caracteres la razón es porque la especificación cambia mucho y creemos que escribir test con especificaciones tan móviles es un sobre coste y se tarda mas, aunque no me gustaría iniciar aquí una discusión sobre TDD
No entiendo lo de no tener versión web, lo que hemos dicho es que no hacemos versión para móviles por defecto, en algunos proyectos si que hay versión móvil.
20 de octubre, 2010 - 18:54
Hola Agustin, con la explicación que has dado es más que suficiente, yo tampoco quiero discutir demasiado al respecto
Lo de la versión web quería ser la versión para móviles, perdona. Me referia a lo que comentas.
Gracias por las respuestas.
20 de octubre, 2010 - 19:00
AItor,
Sobre el TDD, hemos probado a hacer TDD y, por lo general, nos hace avanzar un poco más lento a la hora de sacar una primera versión a producción. Obviamente esa menor velocidad tiene varios beneficios, como un mantenimiento mejor, mayor facilidad para intercambiar miembros del equipo de desarrollo, o la posibilidad de poder subir de versión en el futuro.
En el balance entre las ventajas que nos ofrece y el coste que nos supone, con el tipo de proyecto, el tipo de cliente, y los plazos con los que desarrollamos (primera versión funcionando en dos semanas es un caso típico), hemos comprobado que en la mayoría de los casos no nos es posible introducir tests. Además en todos los proyectos en los que hemos pedido a nuestros clientes que escojan entre más funcionalidades desarrolladas para las primeras versiones, o mayor cobertura de tests, la respuesta es unánime: todos prefieren mayor funcionalidad.
Por esos motivos, en las primeras fases del desarrollo -por defecto- no programamos tests, salvo en los casos en los que consideremos que nos facilitan el trabajo de desarrollo.
Una vez salvada la primera fase, con el desarrollo más estabilizado y el proyecto más orientado, es cuando nos gusta programar la suite de tests que cubra las partes más críticas (nunca intentamos cubrir absolutamente todos los casos).
Este modelo, a nosotros, nos permite obtener las ventajas de la cobertura de tests, sin la ralentización inicial.
20 de octubre, 2010 - 19:07
Hola Javier,
es que lo vuestro es desarrollo super-ágil si la fase de mantenimiento empieza en dos semanas…
La curiosidad venía precisamente porque yo también estoy buscando el ritmo adecuado con el tema de TDD, pruebas automáticas y esas cosas, y no siempre es fácil encontrar el equilibrio. Nos vemos en la conferenciaROR, a ver si saco un rato para charlar un rato.
20 de octubre, 2010 - 19:31
No Aitor.. en dos semanas tenemos una primera versión.. normalmente la primera fase es un tiempo de entre uno y dos meses, con la primera entrega en dos semanas y el resto de entregas semanalmente. Una vez pasado ese mes o dos iniciales, es cuando sí recomendamos dedicar parte del mantenimiento a desarrollar la suite de test.
Espero verte en la conferencia
18 de julio, 2011 - 2:31
I know this if off topic but I’m looking into starting my own blog and was curious what all is required to get setup? I’m assuming having a blog like yours would cost a pretty penny? I’m not very internet smart so I’m not 100% positive. Any suggestions or advice would be greatly appreciated. Kudos
7 de noviembre, 2011 - 11:36
Websites worth visiting…
[...]here are some links to sites that we link to because we think they are worth visiting[...]……
13 de noviembre, 2011 - 5:57
Sin duda parece ser un desarrollo super agil, pero más que nada debido a tan buena metodología que manejan, realmente una estructura muy solidad y dorganizada.