Archivos Mensuales: agosto 2014

Documentación – recibiendo un feedback

Un feedback de un amigo Ingeniero en Software, me hace pensar en las formas que en las empresas documentan para llegar a certificaciones de alto nivel de maduración de software o CMMI.

Para comprender un poco más de CMMI(Captability Maturity Model Integration) son colecciones de buenas prácticas que ayudan a las organizaciones a mejorar sus procesos.

Fue desarrollado por la Software Enginnering Institute(SEI).

Este modelo, denominado CMMI para el desarrollo (CMMI-DEV) proporciona un conjunto completo e integrado de guías para desarrollar productos y servicios.

Las empresas gastan mucho dinero para certificar en CMMI, ISO o alguna certificación que le permita vender, no solo dentro del País sino también fuera de la misma o también para demostrar que en se cumplieron todas las normas a nivel de maduración de Software, el problema está en que toda la inversión hecha en esa documentación para llegar a la certificación se quedó en algún lugar olvidado por el mundo, porque la finalidad tal vez no era la “MEJORA EN LOS PROCESOS “, tal vez era otra.

Además, no se utiliza para la mejora continua sino, que solo está para que cuando auditoria venga a revisar y ver las documentaciones, pruebas, puntos de control, esta todo en su lugar, fantástico.

Ahora meto Calidad (cuando un software es medianamente medible en calidad, cuando cumple los requisitos de la historia de usuario, se puede decir que tiene calidad, porque cumple un criterio de aceptación).

Lo normal es que se cumpla con los requerimientos de usuario, que es lo que en verdad necesita el software, pero lo más difícil y lo dice #ITIL dentro de lo que es Servicio la expectativa del Cliente es lo más difícil de cumplir o sea casi imposible.

Dentro de mi experiencia en la parte de Análisis Funcional la documentación ingresa por las Historia de Usuario dentro de un esquema de #Agiles #Scrum, esa historia de usuario no da la a nosotros el requerimiento del usuario (en este caso el Usuario es el Dueño del Producto o Propietario de datos si quieren llamarlo así).

Después se trabaja con los casos de uso y en los diagramas de estados y actividades y si no comprendes un caso de uso verifícalo con un diagrama de colaboración (Pero eso es trabajo de Análisis)….ATENCION SEGUIMOS DOCUMENTANDO….

Si documentamos dentro de Iteraciones como nos da a entender #Scrum es posible un mantenimiento porque después de que se pueda terminar un Sprint dentro de la Retrospectiva se puede evaluar algunos puntos sobre documentación.

Ahora, es mejor tener todas la mejores prácticas a mano y poder concluir uno mismo un ciclo de vida de desarrollo de software, no todos tiene ISO o CMMI , la mayoría maneja sus propios procesos o documentaciones, porque así le va bien y además su producto con esa documentación que puede ser pobre o no le da resultados fantásticos.

“No tengas miedo de inventar tu propio ciclo de vida del software que se adecue a tu realidad. El ciclo de vida _perfecto_, es un modelo, tu vive en el mundo real.” (Gracias @johannarothman)” – gracias Ale.

Anuncios

Salud en el Desarrollo de Software

La Salud de los Desarrolladores

Escuchando un podcast sobre un tema de salud

A ver si nos ponemos a pensar, un programador está como mínimo 8 horas frente a una computadora, y es un trabajo sedentario.

Se pasan muchas horas trabajando en la oficina y después uno vuelve a la casa y toma de nuevo la computadora para seguir, puede investigar o contestar mail personales.

Generalmente la enfermedad de Sistemas, es el Túnel carpiano, salvo que las personas tengan mecanografía, o sepan cómo posicionar las manos en el teclado, pero la mayoría esto de mecanografía y de postura no se les enseña en las Universidades.

Que pueden hacer para mitigar este riesgo (algunos ejemplos):

  • Teclados y Mouse Ergonómicos
  • Buena luz para el trabajo
  • Ir a un gimnasio
  • Comprender una buena postura
  • La Altura de Monitor

Esto está todo estudiado, no es que uno dice por decir, esta verificado las posturas ya que este trabajo puede dar problemas a lo largo de tiempo.

En internet existe un montón de buenas prácticas de mantener una buena postura, es importante ver, ya que este tipo de trabajo se va a hacer por mucho tiempo.

Además de la postura, tenemos el tema de comer mal, es casi normal y casi diría común, comer sobre el teclado, mirando email, mirando páginas, bueno esto no está bien.

Darse unos minutos, salir del frente de la computadora e ir a comer algo o tomar un café, baja también los niveles de stress y ansiedad.

La mala calidad de alimentarse, galletitas, gaseosas, café y además estar con mala postura aumentan drásticamente el riesgo de que el desarrollador a futuro este con problemas de salud.

En algunas empresas comenzaron a colocar una cesta de frutas, para que puedan comer un poco sano y tomar agua, colocando unos cartelitos de comer sano. Esto es un tema de conciencia, por eso no vamos a poder obligar a todos, pero al menos estamos intentando en dar una ayuda al desarrollador.

Otra alternativa es el #estreching o estiramiento o sea parar unos minutos y levantarse de sus asientos y comenzar a estirarse esto es una técnica, si empiezan a hacer esto es mejor que este observado o que de los primeros pasos de una persona profesional, y esto es para evitar que alguien haga un estiramiento mal y al final termina siendo peor el remedio que la enfermedad.

También la comodidad con que se está en la oficina, acordemos que la mayor parte estamos en la oficina o lugar de trabajo. Debemos tener una comodidad acorde a nuestro trabajo.

Documentando Software – parte II

Documentación de Sistemas

Bien continuamos con la documentación de sistemas, ahora si pensamos que importante es la documentación, también deberíamos pensar en que importante es mantener un estándar.

Si vamos a generar manuales, procedimientos o procesos mantengamos siempre un estándar, si usamos una forma de documentar usemos siempre la misma.

Java tiene su documentación (java doc) además introduce el CamelCase para poder comprender mejor aún el código de programación.

Ahora de Parte del programador, debería escribir la definición de su programa, fecha, versión, es un buen comienzo para comenzar a tener documentado el código.

Esto también es ahorro. Ahorro de tiempo y de dinero.

Los que dicen que no se documenta tanto en #agiles, no es tan “así” porque depende de la Naturaleza de la empresa, las empresas que hacen ventas en línea o que bien hacen ventas de consumo no tienen los mismos niveles de compromiso que las empresas financieras.

Todo va a depender de la entidad controladora que tipo de documentación requiere para su auditoria.

Y es ahí la diferencia, las metodologías ágiles si bien uno de sus puntos es la documentación básica, y como escribí un poco más arriba no es tan así dependiendo de los factores Gubernamentales, Leyes de Gobiernos.

Documentando Software

Documentación de Sistemas

Algunas buenas prácticas tratan de que la documentación no sea larga ni extendida, pero cuando hace falta es pérdida y cuando existe es ahorro.

Mejor llegar a un término medio ni tan grande ni tan pequeño.

Cuando hablamos de Documentación de Software, estamos hablando de todos los documentos que abarcan la creación y el mantenimiento de un software, no solo de su creación, sino que cada modificación de la misma, deriva también a una modificación en la documentación, llámese nuevas políticas o nuevos procesos, los RFC (Ordenes de Cambios), también exigen una modificación en la parte documental del sistema.

La documentación no solo se basa en la idea o en la necesidad de crear un proceso o comprar un producto para que nos ayude o nos dé una solución a un problema dentro de la empresa.

La Documentación nos da el poder de saber los que hicimos a través del tiempo y estamos dejando una historial para futuros usuarios que manejarían o modificarían dicho software.

Haciendo esto se ganaría tiempo tanto en el desarrollo como en la educación de futuros usuarios ya que tendríamos creados manuales técnicos, manuales de usuario, manuales administrativos de sistema, manuales de contingencia.

Un Ejemplo:

Cuando hay un problema en un proceso ,el programa hizo mal un cálculo y el desarrollador está de vacaciones, que hacemos, como sabemos que hizo , entramos al programa y miramos eso puede llevar horas para saber que exactamente hizo. No sería más fácil leer un manual de procesos en donde en un español entendible nos pueda explicar con facilidad que quería hacer ese proceso , así ganamos tiempo en saber que quería hacer y podemos corregir con más facilidad, eso es un ahorro de costo , energía y recurso que no se tiene en cuenta muchas veces.

Entonces debemos comenzar a ver la existencia de documentación, contratos, inicio de proyectos o proyectos finalizados.

Al saber que si existe documentación podemos tener muchas respuestas a las preguntas de los ejecutivos de la empresa, podemos también proyectarnos a futuro con una mejor línea de base.

Servicios (ITIL)

Administración de Servicios
La información es un recurso valioso para el éxito y la supervivencia de las organizaciones

* Por la Entrega de valor para la organización
* Por el Soporte a la estrategia del negocio
* Por su aporte a Mejorar la eficacia operativa

Sea cual fuera el origen, es clara la gran dependencia del Negocio con respecto a TI.

Por ello los clientes/usuarios tienen necesidades y expectativas crecientes respecto a las soluciones que provee una organización TI, sea interna o externa.

Si hablamos sobre necesidades y expectativas del cliente
El cliente espera:
* Que se provea los niveles de servicios compatibles con las necesidades del negocio (esto quiere decir que si una empresa da un servicio de 24×7 la atención también debe estar 24X7).
* Entregar soluciones con calidad estable y predecible.
* Que tenga una voluntad de mejorar permanentemente en la Calidad (Atentos a Mejorar).
* Manifestar una actitud proactiva de satisfacción a las necesidades.
* Poseer un sentido de “urgencia” en la solución del problema y en la implementación de nuevos requisitos.

Para poder satisfacer estas necesidades y requerimientos dentro de una organización TI se requiere de una administración efectiva de sus recursos (upssss)…

Cuando leemos sobre que es una “Administración Efectiva”, hablamos de una correcta y eficiente Administración de Servicios, la misma requiere de :
* Una reingeniería de los procesos, para que se ajusten a la nueva tecnología y necesidades del negocio(esto quiere dar a entender revisión de los procesos ya existentes).
* Una tecnología que soporte los procesos y herramientas para automatizar y a apoyar la Gestión del Área de TI.
* Una organización TI con objetivos
– Orientada al Servicio
– Focalizada en el Cliente y en la Cultura del Servicio
– Preocupada por la mejora constante de la calidad ( cambio de cultura orientada al servicio).

Gamificación

En los últimos meses, un nuevo término se ha abierto paso con fuerza en el universo del marketing y la publicidad: “gamification”. Como su propio nombre indica, la denominada “gamification” es la aplicación de los conceptos y las técnicas de los juegos a otras áreas de actividad.

Tambien exite la misma terminología para el Desarrollo de Software Ágil.
Dentro del equipo de desarrollo se utiliza para dar mas motivación al Programador, generalmente suele darse en puntuaciones

Entre los conceptos y las técnicas más empleados en los juegos, destacan, por ejemplo, las recompensas, los niveles, los progresos, las cuentas atrás, las herramientas, el contenido gratuito y los programas de fidelización.

¿Cómo pueden aplicarse los conceptos y las técnicas de los juegos a las marcas? Las oportunidades son en realidad infinitas. Sin embargo, la fusión del marketing y “gamification” se plasma habitualmente en las siguientes técnicas:

– Los programas de fidelización
Algunas marcas que han descubierto ya los beneficios de los programas de fidelización son, por ejemplo, Hilton, Jetblue o Subway. Los programas de fidelización de estas marcas utilizan la misma mecánica de los juegos para lograr que sus clientes repitan con la compañía.

– La integración de aplicaciones móviles
Las apps móviles son hoy por hoy terreno abonado para la denominada “gamification”. Foursquare, por ejemplo, premia a sus usuarios con alcaldías virtuales, con descuentos y con productos gratuitos. GetGlue, por su parte, recompensa su fidelidad al usuario con pegatinas y premios. También las aplicaciones de fitness se sirven de los niveles y las recompensas para mantener en buena forma al usuario.

– La integración web
Webs como The Huffigton Post, SEOmoz y Mashable están apostando ya por la “gamification” para premiar de alguna manera a sus lectores. En estos portales, leer un determinado número de artículos, hacer comentarios, y compartir contenido con otros usuarios tiene “premio”. Ante la creciente demanda de soluciones de “gamification” en la web, han surgido empresas como BunchBall, Big Door y Badgeville, que proporcionan a las marcas soluciones de software para la integración de estas técnicas en la web.

Programacion a Pares – XP

Programacion a Pares

Ayudándonos entre nosotros

Es más divertido de lo que parece: dos programadores en una computadora. Uno conduce, el otro navega. Los roles cambian con fluidez, se comunican constantemente. Juntos, logran terminar el trabajo más rápido de lo que podrían estando solos.

El conductor tipea. Se enfoca en las tácticas – escribir código limpio que compile y funcione. El navegante se enfoca en la estrategia – cómo encaja este código en el diseño general, qué pruebas harán que el código avance, y qué refactors mejorarán la base de código.

Las parejas se auto-gestionan, seleccionan compañeros que puedan ayudar con la tarea en curso. Rotan cada un par de horas para compartir perspectivas y conocimiento.

Es incrieble como aumenta la capacidad en este metodo de desarrollo, lo viví y lo sigo viviendo en los ciclos de desarrollos #ágiles es sumamente efectivo para sacar resultado en poco tiempo  además de tener no solo una persona con el conocimiento de lo que hicieron sino que tambien tiene su backup.

Dos cabezas piensan mejor que una y eso es cierto, cuando uno solo hace el trabajo, una buena practica es ver un review del codigo o del trabajo que hizo entre todos, llamese grupo de trabajo para poder ver una mejora.

Estas buenas practicas ayudan a la autogestión de la persona y del gurpo a ser más maduro.