Y que sobre la documentación?

Muchas veces, nos encargamos de hacer grande manuales de guía, los cuales en la mayoria de las oportunidades ni siquiera son leidos una vez. y en base a eso… ¿Es estríctamente necesario entregar tanta documentación si finalmente quizá ni se lea? ¿ Por qué no utilizar ese tiempo tan valioso dentro de un proyecto en otra iteracción?

Más que mal, si algo ocurre con el software o la implementación tecnologíca te llamarán seguro, o no?

La idea es que el dueño del producto, participe activamente realizando aportes significativos, no con el ánimo de estar controlando como va la solución, sino más bien viendo el grado de satisfacción y que si lo que pidió se ésta terminando con los aportes o cambios que quizo realizarle a la solución en plena costrucción. Lamentablemente, en Chile eso no ocurre todos los dias, bueno eso lo podemos discutir luego.

Creo que basta un pequeño handbook, y la capacitación (que sin ningúna duda está en cuestionamiento), así además, ayudamos a la ecología.

Opiniones?

Anuncios

Es dificil implementar una metodología ágil en empresas chilenas?

Si pensaramos en restablecer las metodologías de desarrollo de software en Chile (si es que las ocupan), quiza pensariamos en:

– Cultura chilena : reacia al cambio y floja

– Resultados rápidos

– Diferencias de Lenguaje

– Porque no tenemos   metodología

– Lo técnico es mirado en menos

– Estructura Piramidal ( líder tipo gurú )

– Pre-historia y médicos brujos

– Prejuicios y estereotipos

– Individualismo y desconfianza

– Falta conocimiento de agilidad

Como podemos ver las causas podrían ser varias. Pero si resumimos  todas estas razones en una simple palabra podemos decir que nuestra razón por que nos cuesta tanto implementar agilidad en Chile , es por un tema cultural.

Si buscamos resultados Rápidos , es porque estamos en una cultura que el éxito mediático se privilegia, independiente de la cantidad de tiempo que este éxito dure.Lo que importa es que seamos exitosos rápidamente.

Lo técnico es mirado en menos, porque lo que es importante en nuestra cultura son los cargos que ejercen poder, que gestionan , que cortan, quizás los chilenos somos una cultura que le gustan mandar y ser mandado.

Las estructuras piramidales nos sirven , para poder mantener nuestra premisa del mandato y obediencia , las estructuras horizontales no soportan este tipo de interacción.

La falta de conocimiento de agilidad responde principalmente a nuestra temor al cambio , a mirar las cosas de una manera distinta , por que esto implica generar quiebres que no siempre son bien mirados.

El Individualismo y desconfianza son un elemento central de nuestra cultura, es por eso quizás que necesitamos y justificamos las estructuras piramidales. Estas permiten que dejemos de sacar la vuelta

La agilidad implica un cambio en la cultura de una empresa , en la forma en que nos relacionamos y establecemos estas interacciones y determinamos lo importante. Un cambio de cultura en la empresa. Es como la  pastilla roja de matrix. Después no hay regreso  !!

A veces pienso… hasta donde llegarás google…?

Algunas veces concientizo cuando me veo utilizando algún “producto” de google , y no llego a conclusiones tan sanas.

Este verdadero pulpo de la red quiere ser eso; google == Inet, y creo que es mucho. Se que operacional y laboralmente es muy buena, puede ser por eso que se refleje lo productivo e innovador de sus productos y “servicios”.

Pero si existe el monopolio… estoy seguro que esto va hacia alla.

Opiniones?

Programación Extrema???

En la programación extrema se da por supuesto que es imposible prever todo antes de empezar a codificar. Es imposible capturar todos los requisitos del sistema, saber qué es todo lo que tiene que hacer ni hacer un diseño correcto al principio. Es bastante normal hacer un diseño, ponerse a codificar, ver que hay faltantes o errores en el diseño, empezar a codificar fuera del diseño y al final el código y el diseño, o no se parecen, o hemos echado un montón de tiempo en cambiar la documentación de diseño para que se parezca al código. En vez de tratar de luchar contra todo eso, lo asume y busca una forma de trabajar que se adapte fácilmente a esas circunstancias. Básicamente la idea de la programación extrema consiste en trabajar estrechamente con el cliente, haciéndole mini-versiones con mucha frecuencia (cada dos semanas). En cada mini-versión se debe hacer el mínimo de código y lo más simple posible para que funcione correctamente. El diseño se hace sobre la marcha, haciendo un mini-diseño para la primera mini-versión y luego modificándolo en las siguientes mini-versiones. Además, no hay que hacer una documentación para el diseño, no hay mejor documentación que el mismo código. El código, por tanto, también se modifica continuamente de mini-versión en mini-versión, añadiéndole funcionalidad y extrayendo sus partes comunes.

También se debe considerar un muy buen agregado para que toda esta maravilla funcione: la programación en parejas y cada una de sus reglas o sugerencias (suena mas libre ).

Algo tiene que ver la imagen puesta en este post.

Opiniones?

Cumplio 10 años y nadie lo ha celebrado tanto (Y lo usan mucho)

Diez años después de su concepción, la Apache Software Foundation (ASF) se convirtió en uno de los líderes del desarrollo de software libre. En la conferencia ApacheCon 2009 de esta semana, Apache está festejando sus diez años de operación. ¡Y vaya si tienen para celebrar! La fundación Apache apadrina 65 proyectos, 33 proyectos en incubación en Apache Incubator, y más de 20 bases de código en Apache Labs. El aniversario oficial es en junio, pero Apache decidió esperar a la conferencia de esta semana para festejar.

Salu2

¿Debes irte a los metodologías ágiles?

Atleta1-34bee
El uso de un método ágil no es para todos. Hay que tener en cuenta varias cosas si se decide a seguir por este camino. Sin embargo yo ciertamente creo que estas nuevas metodologías son extensamente aplicables y deben ser usadas por más personas de las que actualmente lo consideran. En el ambiente actual, la metodología más común es codifica y corrige.  Aplicar más disciplina que caos casi seguramente ayudará, y el acercamiento ágil tiene la ventaja de que es mucho menos de un paso que un método pesado. Mucha de la ventaja de los métodos ágiles es de hecho su peso ligero. Los procesos más simples son más probables de ser seguidos cuando uno no está acostumbrado a ningún proceso en absoluto.Una de las limitaciones más grandes de estas nuevas metodologías es cómo manejan equipos más grandes. Como muchas nuevas tendencias, ellos tienden a ser usados primero a escala pequeña antes que a gran escala. También a menudo se han creado con énfasis en equipos pequeños. La XP explícitamente dice que está diseñada para equipos de no más de veinte personas. Hay que recordar que muchos equipos de software pueden reducirse en tamaño sin reducir su productividad total.Otras tendencias ágiles están destinadas a equipos más grandes. La FDD fue diseñada originalmente para un proyecto de cincuenta personas.  Scrum se ha usado para manejar tamaños similares. Esperanzadoramente un mensaje que queda claro en este artículo es que los acercamientos adaptables son buenos cuando sus requisitos son inciertos o volátiles. Si tu no tienes requisitos estables, entonces no está en la posición tener un plan estable y seguir un proceso planeado. En éstas situaciones un proceso adaptable puede ser menos cómodo, pero será más eficaz. A menudo la barrera más grande aquí es el cliente. Como yo lo veo es importante para el cliente entender que seguir un proceso predictivo cuando los requisitos cambian es arriesgado tanto para ellos como para el desarrollo.  Si tu va a tomar la ruta adaptable, necesitas confiar en tus desarrolladores e involucrarlos en la decisión. Los procesos adaptables cuentan en que tu confías en tus desarrolladores, de modo que si usted considera a sus desarrolladores de baja calidad y motivación, usted debe usar un acercamiento predictivo.Para resumir; los siguientes factores sugieren un proceso adaptable:

  • Requisitos inciertos o volátiles  
  • Desarrolladores responsables y motivados  
  • Clientes que entienden y se involucrarán.  

Estos factores sugieren un proceso predictivo

  • Un equipo de más de cien.
  • Un precio fijo, o más correctamente un alcance o contrato fijo.

Comentarios?

Salu2

5 Buenos motivo para utilizar Kanban

nota-amarillaKanban es un enfoque ágil para la gestión de proyectos, que se basa en el flujo continuo de trabajo (a diferencia del desarrollo iterativo propuesto por Scrum). En este artículo vamos a ver 5 buenas razones para las cuales investigar sobre Kanban y considerar su adopción.

1. Poder realizar entregas en cualquier momento

En Scrum o XP no se pueden hacer entregas a mitad de la iteración. En Kanban se pueden hacer entregas en cualquier momento. Cuando una historia de usuario está lista, la podemos entregar. Obviamente que todo un desafio preparar al entorno de desarrollo de esta manera. Requiere que se haga un “branch por característica” en el controlador de versiones, que se hagan merge frecuentes, integración continua y pruebas. Y todo esto nos da la habilidad de entregar seguido. Es algo por lo que vale la pena esforzarse.

A un Dueño del Producto le interesa mucho esta capacidad. ¿Se implementó una historia de usuario importante? Perfecto, publiquémosla mañana en la versión v2.15.2. Nuestros clientes se beneficiarán con esta entrega lo antes posible. Menor tiempo de espera – clientes más contentos.

Un detalle importante: necesitamos tener una buena suite de pruebas automatizadas, sino será muy dificil hacer entregas pequeñas con buena calidad.

2. Poder cambiar las prioridades al vuelo

En Scrum (usualmente) no podemos agregar historias al vuelo dentro de un sprint. O al menos no es un proceso facil, y los equipos de desarrollo suelen resistirse a reemplazar una historia del backlog del sprint. La historia ya fue discutida, estimada, etc. La nueva historia se podría discutir de forma apresurada, perdiendo detalles y como consecuencia se podría generar un re-trabajo importante. Por lo tanto, en general las iteraciones tienen contenido fijo.

En Kanban, si tenemos un requerimiento urgente o una historia de usuario muy importante, la podemos agregar como primer elemento de la cola. Será tomada ni bien haya capacidad disponible. Es el sueño de todo Dueño del Producto.

3. No hay necesidad de iterar

¿Por qué necesitamos de iteraciones? Las iteraciones sirven para descubrir rápidamente problemas reales en el proceso de desarrollo. Más aún, establecen un ritmo sustentable y varios rituales. Sin embargo, hay un punto donde el proyecto puede no necesitarlas más.

Mi visión es que necesitamos iterar primero, fluir después. El backlog ya no está tan definido, los planes cambian con frecuencia. Aprendimos a ser ágiles en general, y las iteraciones ya no ayudan tanto. Sin las iteraciones no hay necesidad de reuniones de planificación y demos. Son desperdicio. En cambio, tenemos reuniones justo-a-tiempo con las personas interesadas en cada historia de usuario.

Kanban establece un ritmo más complejo y puede llevar tiempo en ajustarse. De todas formas, las iteraciones brindan un ritmo estable, y puede ser un motivo por el cual mantener las iteraciones sobre el final del desarrollo.

4. No hay necesidad de estimar

¿Por qué necesitamos estimar? En el desarrollo iterativo necesitamos predecir cuántas historias podremos completar en la próxima iteración. Incluso podemos predecir la fecha de entrega basándonos en un backlog estimado y la velocidad del equipo. Otro motivo para estimar es que el Dueño del Producto quiere saber qué tan grande son ls historias. Si es muy grande, el Dueño del Producto puede decidir moverla a la siguente entrega. Sino, puede decidir incluirla en la próxima iteración.

Obviamente, el desarrollo iterativo necesita de las iteraciones. Pero si dejamos de iterar, deja de ser un problema. ¿Puede vivir sin estimaciones un Dueño del Producto? Bueno, si.¿Por qué no? Cuando el equipo ya tiene un ritmo en el Kanban, lo único que puede necesitar un Dueño del Producto es saber si una historia es grande, mediana o pequeña.

En nuestra situación, las estimaciones son un desperdicio. No perdemos tiempo estimando. Tenemos un backlog priorizado y tomamos las historias de usuario más importantes y las implementamos. En algunas situaciones podría no funcionar, pero tenemos un producto maduro y cientos de requerimientos de los clientes. No hay un campo claro de desarrollo, así que normalmente no tenemos fechas de entrega definidas. Hacemos entregas cuando está listo.

5. Visualización perfecta del flujo

El tablero de Kanban brinda una vista clara del trabajo en progreso. Visualiza el flujo y permite una planificación y seguimiento rápido. Es una muy buena herramienta!