28 de septiembre de 2012
26 de septiembre de 2012
19 de septiembre de 2012
18 de septiembre de 2012
Primera Edición del Curso Online de la UTN de Preparación a la Certificatión PMI-ACP
Después del éxito de nuestro curso online de la UTN sobre Metodologías Ágiles para el Desarrollo de Software, con Ulises Martin y Hernán Ricchio lanzamos un nuevo eLearning:
El próximo 15 de Octubre del 2012 iniciaremos la primera edición del curso online de la UTN de Preparación a la certificación Agile Certified Practitioner (PMI-ACP) del Project Management Institute (PMI).
El PMI ha reconocido el crecimiento de los enfoques ágiles en la gestión de proyecto e introdujo en el 2011 una nueva certificación (PMI-ACP), que está tomando cada vez más fuerza en la comunidad profesional. En mi opinión está certificación permite realizar un recorrido amplio y contundente de las practicas ágiles más interesantes hasta el momento.
El curso está diseñado para repasar las practicas, herramientas, conocimientos y habilidades ágiles alcanzados por la certificación y entender los principios y valores subyacentes. Se complementa con referencias seleccionadas para profundizar temas de interés y ayuda practica para el proceso de certificación.
Más información e inscripciones en este link.
Los esperamos!
El próximo 15 de Octubre del 2012 iniciaremos la primera edición del curso online de la UTN de Preparación a la certificación Agile Certified Practitioner (PMI-ACP) del Project Management Institute (PMI).
El PMI ha reconocido el crecimiento de los enfoques ágiles en la gestión de proyecto e introdujo en el 2011 una nueva certificación (PMI-ACP), que está tomando cada vez más fuerza en la comunidad profesional. En mi opinión está certificación permite realizar un recorrido amplio y contundente de las practicas ágiles más interesantes hasta el momento.
El curso está diseñado para repasar las practicas, herramientas, conocimientos y habilidades ágiles alcanzados por la certificación y entender los principios y valores subyacentes. Se complementa con referencias seleccionadas para profundizar temas de interés y ayuda practica para el proceso de certificación.
Más información e inscripciones en este link.
Los esperamos!
14 de septiembre de 2012
La cultura del gran proyecto de desarrollo (Q.E.P.D.): ¿Cómo derribar sus 6 excusas?
Aviso al lector: Con este post me estoy postulando para el Premio Bin Laden del festival de la polémica y a la vez para el Premio Ghandi del festival del idealismo. Para eso escribo...
Compañeros, ya empezó la lucha!
Veo muchas preguntas en los medios ágiles sobre como hacer convivir el agilismo frente al paradigma de grandes licitaciones de desarrollo, gestión de proyectos largos con desarrollos de alcance fijo, estimaciones gigantescas al inicio, etc. Crece cada vez más mi creencia de que no hay que convivir sino tratar de cambiar el paradigma. Creo que hay esperanza y que hay que armarse de coraje para intentar cambiar las cosas, quizás de a poco, a veces con violencia.
Así que estoy luchando, a veces con timidez, a veces con más violencia, a veces me sale y a veces no. Estoy luchando contra la Cultura del Gran Proyecto de Desarrollo.
¿Que es la Cultura del Gran Proyecto de Desarrollo?
Escucho y veo una fuerte tendencia en empaquetar desarrollos de software en proyectos enormes (mayor a un año de duración). Muchas veces es la única forma de desarrollar algo en estas empresas. Y para mi genera muchos riesgos y problemas comparado con sus pocas ventajas. Los problemas generados por esta cultura son muchos, como por ejemplo:
- Pasamos meses/años antes de iniciar el desarrollo, y eso sale caro.
- Cuando más largo es el proyecto, mayor chances tiene de cancelarse y/o de desviarse de sus estimaciones.
- El contrato inicial con el proveedor elegido nos obliga a terminar el proyecto como fue pensado inicialmente, aunque surgieron nuevas necesidades y cambios importantes.
- No podemos cortar el desarrollo antes del final, cuando quizás el costo/beneficio del resto del proyecto no rinde.
- Se dimensiona al inicio una infraestructura, que luego se vuelve inadecuada a medida que se avanza, por los descubrimiento que se hacen en el camino y/o los cambios que surgen.
- Sale mucho más caro de lo que se estimo al inicio con la poca información que estaba disponible.
¿Porque esta Cultura del Gran Proyecto de Desarrollo? ¿Cómo podemos luchar?
No tengo una respuesta muy elaborada a la primera pregunta. Sin embargo relevé algunas excusas comunes para gestionar los desarrollos como grandes proyectos. A continuación enumero las excusas más comunes y aporto algunas ideas o contra-argumentos para derribarlas:
Excusa 1
"Los altos costos de infraestructura hacen que debamos tomar antes de empezar una decisión de go o no go sobre el gran proyecto de desarrollo."
Mi pequeño aporte extremista: en el 2012 eso no puede ser una excusa. Existen variadas soluciones de hosting, virtualización y cloud para poder montar una infraestructura casi sin gastos y luego hacerla escalar a medida que se necesita. Y si la infraestructura actual no se banca eso, quizás antes de pensar en desarrollar algo nuevo habría que pensar en modernizarla...
Excusa 2
"Deployar la solución es costoso/complicado, por las siguientes razones: hay que instalar en muchas maquinas, capacitar a muchas personas, hacer un cambio importante en la forma de trabajar, etc. Eso hace que preferimos armar un gran proyecto para deployar una sola vez."
Mi pequeño aporte extremista: dos ideas: 1/ Toma un porción pequeña de la organización como equipo piloto donde se puede trabajar en proyecto chicos (iteraciones), y después de un tiempo razonable se podrá hacer el deploy completo, aprovechando la experiencia del piloto. 2/ Justamente el problema del gran proyecto es que el cambio final es muy importante/violento. Hacer proyectos más chicos permite minimizar este cambio, y quizás simplificar el deploy, la capacitación, los cambios organizacionales, etc.
Excusa 3
"Necesitamos definir al inicio la arquitectura de toda la solución del gran proyecto, porque sino los cambios arquitectónicos posteriores van a ser muy costosos."
Mi pequeño aporte extremista: en general no coincido, y en varias oportunidades pude observar exactamente el contrario: el big up front design donde se trata de pensar toda la arquitectura para poder sostener una cantidad impresionante de requerimiento lleva mucho tiempo y sale caro, y luego a medida que avanza el proyecto cambian los requerimientos. Y ya no podemos volver atrás en la arquitectura y seguimos desarrollando para una arquitectura no adecuada, lo cual trae muchos problemas al final.
Excusa 4
Los usuarios tenemos muy pocas oportunidades de pedir (y lograr) algo de software, entonces cuando aparece una posibilidad de proyecto intentamos sumar todos los posibles requerimientos que quizás nos podrían ser de utilidad de acá a 10 años.
Mi pequeño aporte extremista: es una consecuencia misma de la cultura del gran proyecto. Trabajar con proyectos chicos permite manejar mejor la ansiedad de los usuarios y darles varias oportunidades de pedir soluciones a sus verdaderas necesidades a intervalos periódicos (iteraciones).
Excusa 5
Cuesta mucho dividir un gran proyecto en pequeños proyectos de valor para el negocio, y poder definir el costo/beneficio de estos pequeños proyectos. Por eso mejor gestionar proyectos grandes.
Mi pequeño aporte extremista: En este caso dudo que el proyecto grande sea exitoso, y tendría muchas dudas sobre un eventual análisis de costo/beneficio del gran proyecto. Si no se puede dividir, es probable que estemos sufriendo las consecuencias de varias de las otras excusas, pero quizás antes de meterse en un gran proyecto de desarrollo sería conveniente dedicarle tiempo en entender mejor los pequeños problemas o necesidades que se busca resolver para el negocio, y organizarlo en pequeñas unidades en lugar de un solo gran proyecto ambiguo.
Excusa 6
Para poder desarrollar tenemos que contratar a un proveedor. Y nos conviene más contratar un solo proveedor por proyecto grande (para negociar descuentos, no tener que cambiar de proveedor todo el tiempo, etc.).
Mi pequeño aporte extremista: dos cosas: 1/ Si el proceso de contratación hace que así sea, quizás convenga mejorarlo antes de pensar en contratar nuevos desarrollos. 2/ Hay mucho riesgo en contratar un solo proveedor para un proyecto grande, y necesito tener mucha confianza en este proveedor para estar seguro que va a funcionar bien. También el contrato grande se vuelve una limitación en muchos casos a cambiar el alcance del proyecto, terminarlo antes, etc. Y finalmente escuché de varias subastas de desarrollos para elegir proveedores, donde seguramente se consiguió muy buen descuento para el gran proyecto, pero al final no funciono para nada, se cancelo el proyecto, se fundió el proveedor,o se entrego algo de mala calidad o que no sirve, y eso hace que al final sale mucho más caro con un alcance entregado menor a lo planificado.
Te enfrentaste también a estas excusas? Encontraste otras?
Animo compañeros: ¡Muerte a la Cultura del Gran Proyecto de Desarrollo!
11 de septiembre de 2012
Séptima Reunión de la Comunidad Ágil de Neuquén
Tema: ¡No estimarás!
Cuándo: Martes 18 de Septiembre del 2012, a las 17h45
Dónde: Salón Azul del la Biblioteca Central - Universidad Nacional del Comahue - Buenos Aires 1400, Neuquén
Facilitador: Thomas Wallet
Descripción:
Estimación: Mecanismo esotérico que se solía usar hasta mitad del siglo XXI para intentar predecir con técnicas pseudocientíficas tiempos y esfuerzos en la construcción de software. Cuestionado a final del siglo XX por el movimiento revolucionario agile, el uso de este mecanismo fue decayendo con la aparición de metodologías agiles de segunda generación como Kanban y erradicado definitivamente en las posteriores metodologías agiles de tercera generación.
Los enfoques predictivos han dado a las estimaciones un lugar preponderante en los proyectos de desarrollo de software. Existen supuestos beneficios de las estimaciones, como elegir y priorizar requerimientos, organizar el tiempo, etc. Por otro lado, estimar lleva mucho tiempo, las estimaciones son altamente sensibles a los cambios y la productividad misma del equipo se ve afectada cuando la estimación es impuesta o irreal.
¿Qué sucedería si no estimáramos? ¿Es tanta la diferencia entre una estimación pobre y ninguna? ¿El esfuerzo adicional en mejorar una estimación justifica los beneficios?
Esta charla invita a los asistentes a animarse a patear el tablero… ¿podemos reducir el esfuerzo asignado a estimaciones o incluso trabajar sin estimar?
La reunión es gratuita, solo hay que inscribirse a través del siguiente link.
7 de septiembre de 2012
Suscribirse a:
Entradas (Atom)