Lugar:
“Mapocho Plex” Huelén 164 piso 2

Fecha y Horario:
Semanalmente desde Lunes 2 de Mayo de 2011, de 19:30 a 21:30.

Pre-requisitos

El pre-requisito principal es tener un equipo que desarrolle soluciones basadas en tecnología (web, software, diseño, etc) y estar interesado en implementar cambios basados en la cultura ágil

• ¿Tu equipo está sobrecargado de trabajo?
• ¿No sabes como priorizar entre los diversos clientes?
• ¿Tu equipo no tiene claro sus avances, o realiza trabajo duplicado?
• ¿Se repiten los mismos errores una y otra vez?
• ¿Eres cliente de un proveedor tecnológico y no sabes como hablar con él?
• ¿Te cuesta priorizar cuales son las funcionalidades más relevantes que deben ser implementadas?

En mayo y junio de 2011 implementaremos una instancia para formar y acompañar a aquellas personas que tengan que “lidiar” con equipo de trabajo dentro del contexto de alta incertidumbre, en particular líderes de equipo de software y clientes de proyectos de desarrollo. La Agilidad permite alinear negocio con tecnología de manera periórdica generando relaciones profesionales productivas y gratificantes.

Se abordarán los  los siguientes contenidos:

• Actualizarse en principios y prácticas de gestion ágil
• Técnicas de trabajo colaborativo ágil
  • Planning Game, o cómo alinear constantement el valor de negocio con las posibilidades tecnológicashttp://c2.com/cgi/wiki?PlanningGame
  • Kanban http://www.limitedwipsociety.org
  • GameStorming http://www.gogamestorm.com/
  • Retrospectivas http://www.retrospectives.com/
• Establecer un trabajo colaborativo entre líderes de diversas empresas, analizando los casos particulares, contrastando experiencias y transmitiendo experiencia.
• Y lo más importante: Aplicar los aprendido a la realidad de cada asistente

Inscríbete Aquí

El formato de la Clinica es de sesiones semanales junto al resto de los participantes, de aproximadamente 2 hrs, mas acompañamiento remoto, todo esto por un periodo de 8 semanas, los lunes de 19:30 a 21:30 en grupos de aproximadamente 10 personas (si se excede este cupo se realizará un taller paralelo los miércoles a la misma hora), según el siguiente calendario:

INSCRIBETE HACIENDO CLICK AQUÍ.

Lugar:

Sede Puerto Montt Universidad Austral de Chile. Sala N° 25 Tercer piso Edificio Pabellón Salas (frente a Biblioteca). Pueden entrar por la entrada de los microbuses pues hay estacionamientos justo detrás del edificio. En este mapa es el edificio 8.

Fecha y Horario:
Viernes 29 de Abril de 2011, 9:00 a 17:30. Existirá un break de 1 hora para almorzar. Se puede almorzar en el casino de la universidad.

Pre-requisitos, Ambiente de desarrollo e instrucciones de configuración

El único pre-requisito es saber programar software. Las prácticas de desarrollo ágil serán ejemplificadas usando el lenguaje python, lo que no inhibe su posterior adpatación a otros ambientes de desarrollo.

Cada asistente debe llevar su equipo personal de desarrollo. Tienen que llevarlo configurado siguiendo estas instrucciones

Aprovechando una nueva invitación, esta vez por la organización Mujeres Empresarias para contarles de mi experiencia en redes sociales (ganada gracias a ChileÁgil ) me ha invitado a  Puerto Varas para fines de mes a un encuentro con profesionales emprendedoras y no puedo dejar pasar la oportunidad de hacer un taller en donde, en un día, se viva en la práctica un proyecto ágil desde su diseño hasta su implementación usando Diseño Guiado por Tests. Entre otros temas, veremos:

• Diseño de un ecosistema de objetos simples que conforman un sistema complejo, usando tarjetas Clase, Responsabilidad, Colaborador
• Implementación incremental de un sistema usando Dimensional Planning
• Programación de objetos con calidad intrínseca usando Test Driven Development (Desarrollo Guiado por Tests)

Todo esto con una metodología 100% aplicada (no me gusta teorizar ) para que se lo lleven a sus lugares de trabajo .

Este taller se realizará el día viernes 28 de abril en Puerto Montt, en la Escuela de Ingeniería de la Universidad Austral. Para conocer costos , consulten en el siguiente formulario de contacto.

La presentación está disponible aquí.

En Extreme Programming (XP) el Unit Testing es una práctica fundamental del ciclo de desarrollo al llevar a cabo un proyecto al permitir al equipo de desarrollo modificar y refactorizar el código existente sin miedo a romper funcionalidades, pues cada una de ellas tiene un test asociado que debe cumplirse y que, en principio, verifican la validez de toda la “superficie de contacto” de cada uno de los módulos que conforman el sistema.

Esta capacidad de adaptarse al cambio es fundamental en proyectos ágiles, donde el cambio no es percibido como algo peligroso o nocivo, sino intrínseco a un proyecto y como un factor que debe ser tomado en cuenta en todo el proceso de gestión y desarrollo.

A pesar de esto, el Unit Testing requiere de mucha disciplina para llevarse a cabo, pues para cada funcionalidad que se desee agregar se debe escribir, antes que nada, uno o varios test que comprueben que la funcionalidad está implementada correctamente. Esta necesidad de escribir las pruebas antes de la funcionalidad propiamente tal nos obliga a escribir pruebas que no dependen del código que hayamos escrito (pues aún no existe) volviéndonos jueces más imparciales a la hora de evaluar nuestro trabajo.

Finalmente, el estar forzados a escribir tests antes de implementar funcionalidades nos obliga a considerar con más detenimiento las responsabilidades y diseño de éstas, lo que generalmente se traduce en código más robusto y entendible para otros desarrolladores.

El ímpetu por agregar funcionalidades constantemente o por deadlines inminentes son fuertes tentaciones para no escribir unit tests, pero debemos ser capaces de racionalizar que el escribir previamente tests de unidad ya estamos subconscientemente definiendo el comportamiento de nuestro nuevo método o función sin preocuparnos del código particular detrás de él, lo que nos da claridad al momento de definirlo, además que escribir código de buena calidad en este momento nos ahorra dolores de cabeza al tener que extenderlo o mantenerlo a futuro.

En este artículo damos una pincelada inicial al desarrollo guiado por tests (Test Driven Development) con un ejemplo práctico, mediante el cual nos podemos desvincular de las particularidades del lenguaje de programación o del problema y concetrarnos en el flujo del desarrollo. En particular tampoco nos vamos a concentrar en el círculo de gestión de proyecto o de generación de valor para el cliente.

Nuestro ejemplo

En este ejemplo, y como parte de un sistema más grande, se nos solicita implementar un “stack”, una estructura de datos que representa una pila de objetos, en el que podemos insertar elementos (“push”) y sacar elementos (“pop”) uno a uno y en orden predefinido, en el que cada vez que realizamos un “pop” sacamos el último elemento que fue insertado al stack.

Para este caso definimos las siguientes funcionalidades:

• Se deben poder crear stacks
• Se debe poder insertar elementos en el stack mediante “push”
• Se deben poder extraer elementos mediante “pop”
  • Si en este caso el stack está vacío, se debe gatillar un error o excepción
• Se debe poder consultar el tamaño (número de elementos) de un stack en cualquier momento

Definición de la plataforma

Para llevar a cabo nuestro proyecto usaremos Python gracias a su flexibilidad y popularidad, además de requerir muy poco código inicial para definir funcionalidades.

Aquellos que no son familiares con Python no debieran tener mayores problemas siguiendo la guía pues el código es muy intuitivo, sólo se tiene que bajar el intérprete de Python si se ejecuta en Windows, pues en Linux y OS X viene incluido con el sistema operativo.

En principio podemos hacer unit testing escribiendo un programa común y corriente que llame los métodos de la clase que nos interesa y verifique manualmente sus resultados, pero dicha alternativa es engorrosa y de automatización no trivial. En vez de eso usaremos unittest, una suite de testing automatizado para Python inspirada en JUnit, por lo que su comportamiento debiera ser familiar para quienes han hecho testing antes.

Apegándonos a la convenciones, implementaremos el stack como una clase llamada Stack y definida en el archivo stack.py, los tests correspondientes a esta misma clase los definiremos en una clase llamada TestStack y definida en el archivo test_stack.py

Primera iteración

Test

En principio tenemos que escribir un test para cada una de las funcionalidades que vamos a implementar, inclusive el hecho de que nuestra clase Stack esté definida por nosotros, por lo que la primera versión de nuestro archivo test_stack.py es como sigue:

from stack import Stack

Para ejecutar nuestro test simplemente ejecutamos

python test_stack.py

De lo que obtenemos

Traceback (most recent call last):
  File "test_stack.py", line 1, in
    from stack import Stack
ImportError: No module named stack

¿Parece un test muy trivial? Imaginémosnos que Python ya define una clase Stack como parte del lenguaje y también en el paquete stack, en ese caso el test no habría arrojado ningún error y habríamos notado de inmediato que algo anda mal, ahorrándonos el proceso de cambiar el nombre de la clase para no tener colisiones con la definición de Python.

Lo único criticable del test es que debiera “reportar” que no hay una clase Stack disponible en vez de caerse, algo que se puede corregir, pero que preferimos no hacerlo pues complicaríamos innecesariamente los test posteriores.

Implementación

Para hacer que nuestro test “pase” necesitamos definir la clase Stack en el archivo correcto (stack.py)

class Stack:
    pass

Necesitamos agregar el “pass” dentro de la clase pues aún está vacía, algo que es inválido en Python, por lo que se usa esa palabra clave para que no lance errores al momento de ejecutarse.

Si ejecutamos nuevamente el test ejecuta sin decir nada, lo que nos indica que aprobamos el primer test.

Segunda iteración

En esta ocasión vamos a testear e implementación la creación de stacks

Test

En esta ocasión nuestro test es más concreto que el anterior y aprovecha la biblioteca unittest. Para usarla, cada una de nuestras clases que se dediquen a la ejecución de tests tiene que heredar de la clase unittest.TestCase.

Una vez creada la clase, definimos los tests, que son todos los métodos dentro de la clase cuyo nombre empiece con “test” y que son llamados automáticamente cuando se ejecuta el test.

import unittest
from stack import Stack

# Tests para la clase Stack
class TestStack(unittest.TestCase):
    # Test para verificar el constructor del stack
    def test_stack_creation(self):
        s = Stack()

if __name__ == '__main__':
    unittest.main()

Cuando se carga el test se define la clase TestStack y, si es que llamamos explícitamente el test (“python test_stack.py”) la condición al final del archivo (que está fuera de la clase) es cierta y se ejecuta unittest.main(), que carga y ejecuta todos los test definidos en la clase TestStack y muestra los resultados.

Como no hemos definido un constructor para Stack es natural que esperemos que nuestro nuevo test falle, pero al ejecutarlo nos damos cuenta que, si bien el test carga, no hay ningún error

.
----------------------------------------------------------------------
Ran 1 test in 0.000s

OK

Esto se debe a que Python crea un constructor vacío para sus nuevas clases si estas no lo definen, así que, lamentablemente, tendremos que aceptar que el test no tuvo la oportunidad de “fallar”

Implementación

No hay cambios a la clase Stack

Tercera iteración

Ahora testearemos e implementaremos la inserción (“push”) y remoción (“pop”) de elementos del stack. Como en el test dependen una de la otra crearemos ambas pruebas simultaneamente, quizás no es muy estricto pero nos ahorra complicar innecesariamente el código.

Test

Crearemos un test que inserta algunos elementos y después los extrae, verificando que estén en el orden correcto. Además crearemos un segundo test que verifica que se lance un error o excepción si tratamos de quitar un elemento de un stack vacío.

Ejecutar estos tests generan dos errores, ambos apuntando a que aún no están definidos los métodos push y pop.

import unittest
from stack import Stack

# Tests para la clase Stack
class TestStack(unittest.TestCase):
    # Test para verificar el constructor del stack
    def test_stack_creation(self):
        s = Stack()

    # Test para verificar que la insercion y remocion
    # se hacen en el orden correcto
    def test_insert_and_remove_elements(self):
        s = Stack()
        s.push('a')
        s.push('b')
        s.push('c')

        self.assertEqual(s.pop(), 'c')
        self.assertEqual(s.pop(), 'b')
        self.assertEqual(s.pop(), 'a')

    # Test para verificar que la remocion de un stack
    # vacio gatilla una excepcion
    def test_exception_on_pop_empty_stack(self):
        s = Stack()
        self.assertRaises(Exception, s.pop)

if __name__ == '__main__':
    unittest.main()

Para probar la inserción y remoción de elementos en orden, usamos los métodos push para rellenar un stack para luego desapilarlos uno por uno, verificando que sean los que esperamos. En el segundo test inicializamos un stack vacío y tratamos de extraer un item, ante lo cual esperamos que la implementación arroje un error de tipo Exception, lo cual hace pasar el test.

Implementación

Para aprobar los tests, implementamos los métodos conflictivos

# Clase que implementa una lista LIFO
class Stack:
    # Constructor vacio
    def __init__(self):
        self.list = list()

    # Metodo que agrega un nuevo elemento al final de la lista
    def push(self, element):
        self.list.append(element)

    # Metodo que extrae el ultimo elemento de la lista y lo retorna
    def pop(self):
        try:
            return self.list.pop()
        except IndexError:
            raise Exception()

Si ejecutamos nuevamente los test estos aparecen OK

Cuarta iteración

Para terminar, implementamos un método size() que retorna el tamaño actual del stack sobre el que es llamado.

Test

Para esta funcionalidad definimos un único test, que verifica los cambios de tamaño en un stack a medida que insertamos y extraemos elementos.

import unittest
from stack import Stack

# Tests para la clase Stack
class TestStack(unittest.TestCase):
    # Test para verificar el constructor del stack
    def test_stack_creation(self):
        s = Stack()

    # Test para verificar que la insercion y remocion
    # se hacen en el orden correcto
    def test_insert_and_remove_elements(self):
        s = Stack()
        s.push('a')
        s.push('b')
        s.push('c')

        self.assertEqual(s.pop(), 'c')
        self.assertEqual(s.pop(), 'b')
        self.assertEqual(s.pop(), 'a')

    # Test para verificar que la remocion de un stack
    # vacio gatilla una excepcion
    def test_exception_on_pop_empty_stack(self):
        s = Stack()
        self.assertRaises(Exception, s.pop)

    # Test para verificar el tamano de un stack
    def test_stack_size(self):
        s = Stack()
        self.assertEqual(s.size(), 0)
        s.push('a')
        self.assertEqual(s.size(), 1)
        s.push('b')
        self.assertEqual(s.size(), 2)
        s.pop()
        self.assertEqual(s.size(), 1)

if __name__ == '__main__':
    unittest.main()

Como nos esperamos, el test falla porque el método size no está definido

Implementación

Para pasar este último test solo necesitamos definir el método size en nuestra clase

# Clase que implementa una lista LIFO
class Stack:
    # Constructor vacio
    def __init__(self):
        self.list = list()

    # Metodo que agrega un nuevo elemento al final de la lista
    def push(self, element):
        self.list.append(element)

    # Metodo que extrae el ultimo elemento de la lista y lo retorna
    def pop(self):
        try:
            return self.list.pop()
        except IndexError:
            raise Exception()

    # Metodo que retorna el tamano del stack
    def size(self):
        return len(self.list)

Chile, siendo favorecido por numerosas condiciones propicias, se considera hoy en día un destino de outsourcing y offshoring muy atractivo. Varias empresas multinacionales ya han descubierto Chile y han establecido sus operaciones aquí. Lo que buscan es un entorno estable, transparente y con buenas condiciones fiscales.

Sin embargo, lo que más diferencia a Chile comparado con los destinos de outsourcing tradicionales como China o India es la zona horaria: idéntica o con poca diferencia de buena parte de EE UU. Gracias a esta zona horaria favorable y el Internet es posible tener una comunicación directa y diaria entre proveedor y cliente, o en muchos casos de offshoring, incluso equipos distribuidos, donde parte de este equipo se encuentra en EE UU y el otra parte en Chile.

Muchos estudios dicen que el mayor problema con los outsourcing radica en la calidad. Los que indagaron más en el tema, encontraron que estos problemas de calidad son un mero resultado de requerimientos mal entendidos. Lejanía geográfica, cultural e incluso de idioma, comunicación por vía escrita, aun mediante documentos pautados y sin encuentros cara a cara se generan muchas dificultades para los analistas y programadores que requieren entender el dominio del negocio para el cual están construyendo los programas.

Al parecer, las empresas que envían sus operaciones a Chile han aprendido la lección y buscan una comunicación más directa, cara a cara y mucho más frecuente entre el cliente y el programador. De allí nace el fenómeno de nearshoring. A continuación recogeremos la opinión de algunos colegas referente al tema desde el mismo “campo de la batalla”:

“En todos los proyectos en los cuales he participado en el Citi, siempre he tenido una comunicación diaria con el EE UU. Me ha tocado pasar largas horas comunicado telefónicamente o en conferencia con EE UU. Lo que se refiere a la división geográfica del equipos, no hay muchas reglas. A veces, la mayor parte de equipo esta aya, en otras ocasiones solamente los analistas se encuentran en EE UU. También me ha tocado comunicarme directamente con el cliente…
Lo que se refiere a la metodología, depende del proyecto. En el último proyecto estuvimos aplicando Programación Extrema con reuniones diarias con el cliente y con pruebas unitarias automatizadas. Últimamente, tuvimos que abandonar alguna de estas practicas.”
Francisco, Citibank Chile

“En Experian estamos oficialmente aplicando Scrum, pero la verdad es que la aplicación de la metodología deja mucho por desear. Una mitad del equipo esta aquí en Santiago y la otra en EE UU. Todos los días partimos con los “daily stand-ups”. La mayor problematica son los requerimientos: en este proyecto particular el autor del Producto es uno de nuestros gerentes senior y su disponibilidad es escasa”.
Jaime, Experian Chile

“He trabajado como analista en Tata Consultancy Services, Chile. Mi trabajo era de analista, tener reuniones con el cliente y escribir documentos con los Casos de Uso. Estos los enviábamos a nuestro equipo en India, y ellos se encargaban de la implementación. La Verdad es que hubo muchos problemas de comunicación y de requerimientos malentendidos. En fin, tuve que emprender un viaje a India en la fase final de un proyecto en un intento de salvarlo.”
Rodrigo, ex empleado de Tata Consultancy Services, Chile

En Chile, la industria local se ha percatado de este fenómeno, pero aun asi hace falta saber posicionarse y marcar la diferencia.
Las prácticas de outsourcing y offshoring tradicional, especialmente en el ámbito de mano de obra simple, son muchas veces fuertemente criticadas tanto en el lugar de origen (países desarrollados) como en el destino, en los países no desarrollados y de obra de mano barata. El termino “sweatshop” ilustra bien el fenómeno de explotación de mano de obra donde los trabajadores pasan largas horas trabajando bajo condiciones inmundas, sin derechos y seguros que aquí damos por obvias.
No hay duda, sin embargo, que las prácticas de offshoring y outsourcing fueron motores de desarrollo de los países como China e India en las últimas décadas, y que en el ámbito informático pueden proveer muchos efectos positivos:

• disminuir fuga de cerebros
• proveer más oportunidad de empleo
• ayudar a mejorar el nivel profesional
• ayudar al desarrollo del país

Chile sin embargo, con su población de 16 millones no es capaz de competir en el ámbito de “outsourcing masivo”. India y China representan los poderes globales y son capaces de competir sobre la base de meros números. Es un ámbito donde las metodologías tradicionales han encontrado una tierra fértil. Las empresas certificadas en CMMI Nivel 5 de madurez se cuentan en centenares.En Chile, empresas certificadas CMMI Nivel 3 o superior se cuentan con dedos de una mano.

La oportunidad de Chile radica en proveer servicios de alta calidad, donde las mejores soluciones son los resultados de una comunicación transparente, directa e involucrada con el cliente.
Es exactamente el modelo ágil que prescribe algunas recetas que se ajustan muy bien a la realidad local y a lo que buscan las empresas extranjeras con Chile en la mira.

Comunicación directa con el cliente

El mejor modo de recepcionar con eficacia los requerimientos y expectativas de un cliente es la comunicación directa. Hoy en día, la tecnología nos permite tener conferencias telefónicas o de video entre partes geográficamente distantes y con un costo muy bajo.
Se ha demostrado que la comunicación directa e interactiva, idealmente cara-a-cara es muchísimo más eficiente que los intercambio de documentación y correos electrónicos.
Las metodologías “pesadas” como CMMI y los destinos de outsourcing en zonas horarias que no permiten la comunicación directa se caracterizan por una comunicación muy protocolar, basada en documentación, muy estructurada y con énfasis en trazabilidad.
Las metodologías ágiles insisten en una comunicación directa, con la participación y presencia perpetua del cliente en el proyecto.

Iteraciones cortas que siempre terminan entregando software operativo

Las metodologías ágiles nos proponen iteraciones corta, con una duración de 1 a 3 semanas en promedio. Cada iteración debe finalizar con la entrega de software completamente operativo y al cual nuestro cliente pueda probar personalmente. Este ritmo trae numerosos beneficios pare el cliente y el proveedor:

• El equipo de desarrollo puede obtener un feedback real en un plazo mucho más corto que en el modelo de cascada tradicional, así se va mejorando la comunicación y entendimiento de los requerimientos y expectativas del cliente.
• En el caso de algún cambio en las condiciones o requerimientos del cliente, el proveedor es capaz de reaccionar en un tiempo muy corto, mejorando así la calidad del producto. El proveedor se convierte en el socio real del cliente capaz de apoyarlo frente a requerimientos y condiciones cambiantes del mercado. Esto es completamente opuesto en la práctica de “requerimientos congelados” típica para el modelo de cascada tradicional.
• Finalmente, las iteraciones corta permiten dar mayor transparencia al proyecto, ya que el cliente puede tener una visión clara del avance real del proyecto, no solamente promesas o cartas Gantt descolgadas de la realidad. Esto permite dar al cliente la tranquilidad y una información veraz en cada fase del proyecto.

Fuerte énfasis en calidad

Una de las practicas fundamentales de Lean Development es “Build quality in”, en donde las prácticas como desarrollo dirigido por pruebas (TDD) son fundamentales para tener un producto sin defectos y que cumple con los requerimientos del cliente. “La verificación final no debe encontrar defectos!” dicen los Poppendiecks. Los productos de calidad y sin defectos son mejor marketing para una empresa de software. Metodologias agiles aplicadas bien, permiten crear software con calidad de “estilo Japones”.

La agilidad es hoy en pleno apogeo y Chile tiene muchas posibilidades de utilizar agilidad a su favor en el area de nearshoring de productos TI.
Para discutir sobre el tema, etablar lazos e incluso buscar oportunidades de negocio, unete al grupo en LinkedIn:
Agile Outsourcing to Chile

Vínculos de interés:

• Artículo escrito por Martin Fowler
  Using an Agile Software Process with Offshore Development
• Video entrevista con Jeff Sutherland, fundador de Scrum:
  http://blog.jaoo.dk/2008/09/23/the-secrets-of-doing-agile-offshoring-with-succes/
• Análisis de tendencias en desarrollo de software en TechTarget
  “Our experts pretty much agree that agile will continue its push into the mainstream in 2009..Perhaps some companies that started shallow will go deeper, and we’ll see more focus on the technical [aspects of agile], in particular incrementalism.”
  http://searchsoftwarequality.techtarget.com/news/article/0,289142,sid92_gci1344072,00.html
  

Danijel Arsenovski
en> “Empowering your team for agile transition
es> “Facultando su equipo para transición ágil”
www.empoweragile.com

Los nombres de las personas mencionadas fueron cambiados para proteger su anonimato. Las opiniones expresadas en el artículo son responsabilidad del autor.

Actualizaciones:
14.08.2010 Versión 1.1: Se elimina la referencia a la pagina “Quality” de Chile-It.

Muchas gracias amigo Agustín, por brindarme el espacio para escribir este post … !!!

Estoy realmente muy contenta porque los próximos 9 y 10 de agosto estaré visitando Santiago para compartir el curso de Gestión de Proyecto con Scrum Manager.  Tengo un fantástico recuerdo de los momentos vividos en el AgileLean Day de noviembre 2009, y espero volver a encontrarme con muchas de las personas con las que compartirmos en aquella ocasión.

En este curso presentaremos el modelo evolutivo que transita el camino que va desde la tesis (reflejada en los modelos procedurales), pasando por la antítesis (modelos ágiles) a la síntesis de ambos (Scrum Manager). Desarrollaremos muchas actividades prácticas para reforzar los principales conceptos, y finalizaremos con una original simulación. Obviamente que todos los interesados en obtener la certificación profesional podrán hacerlo, realizando el examen al final del curso.

Entre los principales temas que se tratarán puedo mencionar:

• Alternativas en la gestión de Proyectos de Software
• Conviviendo con la Gestión Predictiva
• Documentación exhaustiva vs. software que funciona
• Caracteristicas del mercado actual
• Manifiesto ágil – Principios
• Ciclo de Desarrollo de Scrum
• Agilidad en toda la empresa: Scrum Manager
• Estimaciones y métricas

Gracias nuevamente y hasta agosto !!!

Claudia Ruata

Aunque les puede parecer extraño, ya que todos hablan de “certificación CMMI” (y no solamente en Chile), la verdad es que tal cosa no existe.

El Instituto de Ingeniería (SEI) de la Universidad Carnegie Mellon otorga lo que llaman el “informe de apreciación” (engl “appraisal”).

¿Bueno, pero aunque se utilice palabra diferente, se trata de la misma cosa, no cierto? Nada más que de una omisión de traductor..? Veamos que dice el SEI mismo:

The SEI does not certify the results of any appraisal nor is there an official accreditation body for CMMI. True certification of appraisal results would involve the ongoing monitoring of organizations’ capabilities, a shelf life for appraisal results, and other administrative elements. When an organization is appraised against the CMMI model, their Lead Appraiser’s findings may indicate that the organization is operating at a particular “maturity level.” The SCAMPI appraisal method maturity ratings are 1 through 5.

The SEI does not have a defined requirement for periodic follow-up after appraisals, nor does it accept legal responsibility for the performance of appraised organizations. All of these characteristics are required for a program that would provide certification of appraisal results. However, CMMI Appraisal results do expire after a period of three years.

Fuente: Sitio de SEI

La verdad es que la diferencia, aunque sutil, es importante, y se explica claramente en el mismo sitio de SEI. SEI no acepta responsabilidad legal para rendimiento de las empresas a cuales se otorgó informe de apreciación ni los directamente monitorea.

Veras, la selección de palabras no es casualidad. Entonces no sorprenden reportes (y aquí) donde las empresas que se “certifican” utilizan un solo departamento o equipo para obtener el sello, que luego vuelven a las antiguas prácticas, que el proceso se convierte a la generación de documentación, que la única motivación es ganar la licitación o un contrato etc. ¿Has escuchado de los LCPBCs? Lo puedes googlear, no quiero echarte perder la sorpresa

En fin, la siguiente pregunta surge sola: ¿Caerán las certificaciones agiles a la misma trampa?

Danijel Arsenovski

“Facultando su equipo para transición ágil”
www.empoweragile.com

Hay buenas señales en el mercado laboral nacional. Si bien estamos muy lejos del promedio mundial, se pueden observar las primeras señales positivas para la agilidad. Las empresas están empezando buscar el personal que tenga la experiencia con las metodologías ágiles.

Los requerimientos son todavía muy vagos: se mencionan las metodologías ágiles en general o alguna en particular, típicamente Scrum, pero todavía sin mencionar las practicas ágiles como el TDD o la refactorización. Algunos avisos dentro de los requerimientos estipulan el Inglés, posiblemente se trata de las empresas extranjeras con oficinas en Chile que están empezando traer esta “moda” a nuestro país.

La investigación fue hecha haciendo la bésqueda por términos relevantes para la agilidad en las bolsas de trabajos más importantes en el país. Ahora un poco de estadísticas:
Infoempleo

Un aviso menciona que el empleado “Reportará directamente al Scrum Master del proyecto, de la subgerencia de desarrollo.” ¿Se podrá sacar la conclusión que la la dicha empresa he avanzado en adopción de las practicas ágiles, tomando en cuenta que tienen roles como Scrum Master establecidas? El termino poco fortuito “reportará” seguramente se debe a un error de la traducción, ya que el aviso además menciona: “Responsable con sus horarios y actividades” lo que podría ser relacionado con el concepto ágil de equipos auto-organizados. Esperemos que no se trate  de interpretación Dilbertiana de esta metodología.

Laborum (Chile)

Laborum guarda los avisos hasta 60 días después de publicación. Interesante es que el aviso que menciona Scrum es para un para un cargo gerencial “Subgerente de Desarrollo Informático”.

Algunos avisos mencionan la agilidad conjunto con otras metodologías o procesos como RUP, CMMI etc. ¿Será para algún instituto o alguna universidad que esta haciendo estudio comparativos de las metodologías del desarrollo de software? Verdad es que no lo creo. De todos modos, poco sorprendente para las empresas de outsourcing (o headhunting como les gusta que las llamen ahora).

¿Y en mundo? Vamos a ver que dice.com, uno de los sitios mas conocidos portales para la búsqueda de trabajo en el área de tecnología:

¡1257 menciones de Scrum, 4128 de la palabra “Agile”, 199 avisos para el “Agile Coach”, 231 menciones del “TDD” y 130 del “refactoring” y 949 de “Continuous Integration”!

Finalmente, algunas “frases celebres” sacadas de los avisos que revisé durante esta investigación:

• “Se valorará conocimiento en metodologías Agile, RUP, MDA. “
• “Si estás en la búsqueda de un cambio en tu carrera, los objetos son tu pasión, si no sabes vivir sin patrones y solo piensas en saber más sobre AOP… tienes que ser parte de nuestro equipo”
• “CMMi-SOA- oSGI, BPM y ESB.”
• “Reportará directamente al Scrum Master del proyecto, de la subgerencia de desarrollo.”
• “Metodologías como RUP, SCRUM, CMMI y UML.”
• “Visual Basic.NET, FRMK’S 1.1, 2.0,3.0,3.5. “

La charla fue grabada y debería ser publicada en el Internet, por lo pronto mi presentación en SlideShare:

Para el Equipo:

Haz la cosa mas simple que pueda llegar a funcionar (Do the simplest thing that could possibly work)

Cuando piensen en agregar algo extra… No lo vas a necesitar (You aren’t gonna need it)

Para los Jefes de Proyecto:

Para convertirse en un Jefe de Proyecto, agrega conocimiento — para convertirse en Scrum Master, quítalo.

A veces la mejor forma de ser útil es no entorpecer el camino de otro (Sometimes the best way to be useful is to get out of somebody’s way)

Para los consultores:

No se puede estandarizar lo que no deja de cambiar

Para los stakeholders internos:

Stakeholder: Tenemos mas problemas ahora que antes de implementar esta metodología.

Consultor ágil: Asi es, lo llamamos transparencia.

Pueden ir agregando mas en los comentarios, para actualizar este post.