You are currently browsing the tag archive for the ‘scrum’ tag.

Tengo ya un poco más de 20 años trabajando en el área informática, he trabajado como digitador, analista, diseñador,  programador, implementando, dando soporte, capacitando, etc.  en fin  casi cada función del área creo que la ha realizado,  me siento más cómodo en análisis y diseño, y  he tenido la suerte de  participar en el desarrollo de aplicaciones que se han usado en todos y cada uno de los ministerios  e instituciones gubernamentales del  país, dicho esto puedo decir que  cuando se trata de desarrollo de aplicaciones siempre surge la incertidumbre de cuánto tiempo llevará desde concebir hasta implementar un producto, en nuestro caso éramos un grupo de cuatro hacelo todo, que con más entusiasmo que experiencia tuvimos muchas satisfacciones y también otras tantas frustraciones. Ahora con el correr del tiempo pienso que usábamos una metodología bastante parecida a la denominada Metodología Agil,  y nuestro ambiente de trabajo estaba, casualmente, diseñado para mejorar la productividad, es más me atrevería a decir que la gestión de los proyectos usábamos algo parecido a SCRUM, ya entonces practicábamos algo de extreme programing y todo eso nos trajo muy buenos resultados. Hoy de nuevo recuerdo esos días gloriosos, los extraño al observar deficiencias tales como la nula participación activa y frecuente de los usuarios, ni hablar de  las condiciones inadecuadas de trabajo.  hablando de usuarios, estos no han evolucionado al ritmo de la tecnología,  tienen  conocimientos  muchos más actualizados  que hace diez  años pero aun no asumen su papel en el proceso, claro hay excepciones, pero lo cierto es que hay un estancamiento en el campo de la ingeniería de software (su aplicación) que hace fracasar los proyectos,  porque los sistemas no hacen lo que deberían y duran una eternidad, todo el mundo se queja de ellos pero nadie participa. ¿La responsabilidad? de todos, de los encargados de las aplicaciones por  no exigir compromiso de los usuarios y de estos por no haber comprendido, después de tanto tiempo que los sistemas no son cajitas mágicas que adivinan lo que ellos quieren. de no empoderarse de sus procesos ni tomar decisiones. La metodología de desarrollo puede ser la mejor del mundo pero sin el compromiso de los dueños de los sistemas al fin de cuentas -los usuarios- no hay programador o diseño  que pueda hacer exitoso un proyecto.

Lo anterior me hizo pensar en ambientes de trabajo óptimos para el desarrollo de software, se han preguntado ¿por qué ciertas instalaciones, por ejemplo la NASA,  cuentan con grandes salones de mando donde todos sus especialistas están cerca? la razón es que así se mejora la comunicación, la colaboración se maximiza  y se corrigen rápidamente los errores. En el campo de la ingeniería de software se puede lograr algo parecido, se llaman bullpen, si así como en beisbol, y  deben además de facilitar la comunicación, contar con espacios para reuniones, separar la gente que necesita hacer llamadas, pero a la vez tener rápido acceso  a grupos multidisciplinarios,  y más importante aún, contar con war rooms, donde normalmente están los programadores en silencio sin ser molestados, por cierto tiempo al menos. les dejo el link para que vean más detalles.

http://www.agileadvice.com/2008/05/12/referenceinformation/the-best-agile-practices-to-implement-now-highest-return-on-investment/