Llegamos a ustedes gracias a:



Columnas de opinión

Doce consejos para evitar el bloqueo en la nube

Por: David Taber, CEO de SalesLogistix

[12/04/2012] En Star Wars, Coruscant es un planeta entero que es una ciudad. Y en la película, los flujos de tráfico se ven en tres dimensiones a medida que todo el mundo vuela alrededor - sin ningún tipo de accidentes. Como es ciencia ficción, no hay atascos de tráfico.
Las cosas no son tan agradables en el mundo real. Si no, trate de conducir en Bangalore o en Roma. Nunca he visto ningún accidente de tráfico en Roma (¿los Fiat simplemente se vaporizarán con el impacto?), Pero he estado en taxis que se han ido por el lado equivocado de la calle, y sobre la acera, y que han pasado sobre adoquines.
En la nube de la ciencia ficción, la implementación es suave y sin complicaciones, al borde de un botón. Esto es cierto para aplicaciones sencillas que no tienen una gran cantidad de dependencias o interacciones con sistemas externos o aplicaciones de terceros. Y hasta puede ser cierto para las implementaciones complejas de nube si hace lo siguiente:
* Verifique las licencias de conducir. Para evitar atascos de tráfico y los accidentes en las implementaciones, las certificaciones administrativas realmente importan (incluso más que las certificaciones de desarrollo en la mayoría de los casos).
* Haga que sus equipos scrum incluyan una fase para el proceso de revisión de la arquitectura de los cambios propuestos. Algunos de los cambios en los controles de acceso, reglas de validación, e incluso los valores de lista de selección que suenan más inocentes, pueden tener grandes repercusiones. Esto se agrava si tiene más de un equipo scrum trabajando en paralelo.
*Si puede encontrar una herramienta de gestión de la configuración (o al menos de auditoría) que funcione en la mayoría de las tecnologías de nube, úsela. Si no puede, utilice documentos de la versión para realizar un seguimiento de lo que está cambiando. Google Docs funcionan bien, sobre todo si almacena la documentación en archivos estáticos a una base semanal.
* Tenga pruebas unitarias para todos los módulos que tengan más del 90% de cobertura de prueba y haga prueba de acierto de los principales casos positivos y negativos. Por la lógica de negocio, considere el uso del desarrollo basado en pruebas.
* Ejecute todas las pruebas unitarias y registre los resultados de todos los días, incluso si no hay un cambio en su código. Su plataforma SaaS o elementos de software de terceros pueden haber cambiado sin su conocimiento. Si hay alguna falla en la prueba de la unidad, eso va para su equipo scrum como su historia de máxima prioridad.
* Utilice ANT o algún sistema similar de despliegue de secuencias de comandos. En una base regular, y trate de seguir las mejores prácticas de integración continua (CI) de Agile.
* Tenga pruebas a nivel del sistema. Para que ejerciten cada interfase externa con datos de prueba representativos, y que hagan una simple comprobación estadística sobre la base de datos (por ejemplo, "¿tenemos un 50% de nuevos clientes desde la última ejecución de la prueba?"
* Ejecute todas las pruebas del sistema y registre los resultados al menos una vez a la semana, incluso si no hay ningún cambio en su código. No solo puede haber cambiado la plataforma o los elementos de software de terceros, los datos de su sistema pueden haberse ampliado o modificado de manera que invocan las rutas del código en una forma no probada. Las fallas en las pruebas van al equipo scrum con la más alta prioridad.
* Tenga varias cajas de arena (equipos para pruebas), en esencia, una por cada sub equipo, que con frecuencia se sincronicen/actualicen. El ciclo de sincronización/actualización debe ser un elemento expresamente previsto que se convierte en parte de la agenda del equipo scrum.
* Tenga prácticas de control. Para el sistema de administración de la configuración que impidan los cambios experimentales que persisten más allá del experimento.
*  Tenga controles que prevengan los cambios no documentados. Para cualquier recinto de seguridad o sistemas de producción.
* Tenga controles que impidan cambios que se aplican directamente a los sistemas de producción.
Qué hacer en el mundo real
La ciencia ficción está bien, pero los proveedores de nube están innovando como locos y es demasiado pronto para la implementación de estructuras y disciplina. Los mejores proveedores de nube hacen un buen trabajo para sus clientes directos, pero no hay mucho que puedan hacer por la tecnología de otros proveedores, por no hablar de los servicios de código abierto.
Simplemente todos los equipos no han puesto en marcha la infraestructura de implementación ni las disciplinas mencionadas anteriormente. Si está en esa situación, es necesario que evalúe el riesgo de dónde se encuentra y le de prioridad a las correcciones en consecuencia a ello.
Si su equipo está en riesgo inmediato (por ejemplo, no se puede obtener una implementación de corrección de errores), la primera prioridad es salir de su plataforma. Al igual que con un giro, la regla es centrarse en conseguir el control de la situación, y no llegar a donde quiere ir. Entonces, averigüe la forma de simplificar el problema girando las cosas, reduciendo el número de variables. Una vez que tenga el fuego apagado, asegúrese de que la infraestructura de implementación y las prácticas se priorizan por encima de cualquier desarrollo de nueva funcionalidad. ¿Por qué? Ha acumulado una deuda técnica que tiene que ser pagada. Asegúrese de que cada nuevo proyecto paga un "impuesto de implementación", por lo que el despliegue de la infraestructura y la disciplina no carecen de recursos, y puede aumentar la altura del desafío a medida que aumenta el número de partes en movimiento. De lo contrario, nunca saldrá de su situación de estancamiento.
David Taber, CIO (EE.UU.)
David Taber es el autor del nuevo libro de Prentice Hall, "Salesforce.com Secrets of Success" y es el CEO de SalesLogistix, una consultora certificada de Salesforce.com que se centra en la mejora de procesos de negocio mediante el uso de los sistemas de CRM.