Beginning to see that Scrum is a Platonic ideal. It cannot exist in its perfect form in the real world.
— Tobias Mayer (@tobiasmayer) December 3, 2013
"Scrum: learn from a new start. Kanban: learn from where we are now".
Si queremos transicionar de una esquema "más Waterfall" a un entorno ágil y no estamos del todo preparados, es recomendable empezar por Kanban. Si bien ya he hablado de esta herramienta en varias ocasiones, me parece importante definir qué debemos tener en cuenta a la hora de aventurarnos en la agilidad desde cero.
¿Se puede combinar Kanban con mi proceso actual?
Si, y podemos empezar de la siguiente manera.
Si, y podemos empezar de la siguiente manera.
- Tablero: comenzamos visualizando nuestro trabajo. ¿Dónde están nuestros cuellos de botella?
- WIP (Work in Progress): ¿cuánto trabajo podemos tomar en cada etapa de nuestro proceso?
Así comienza el camino...
[Entradas relacionadas]
- Lean
[Referencias]
- Kanban: Successful Evolutionary Change for Your Technology Business
Germán
Hace un tiempo encontré este Kanban Maturity Chart que me pareció muy piola para mediar a nuestro equipo y usarlo en retrospectivas.
Visualize Work: How well does the team consistently use visualization tools to make the flow of work through the system visible?
Limit WIP: Does the team set WIP limits and use them as a tool for managing flow? Do they review WIP limits, adjust them, and respect them (which is not the same as blindly obeying them)
Manage Flow: How well does the team consistently observe the flow of work using relevant measures as guides in a continuing process of reducing waste, variability, and improving the flow of work through the system?
Explicit Policies: Does the team make policies relevant to the handling of tasks clear and explicit and review those policies as needed?
Improve Collaboratively: How well does the team use models and experiments to test ideas in order to introduce improvements to the process?
Feedback Loops: How well does the team create feedback loops to give both the team and individuals actionable feedback on quality and process?
¿Ya lo probaron? ¿Lo conocían? Espero los comentarios.
Germán
Visualize Work: How well does the team consistently use visualization tools to make the flow of work through the system visible?
Limit WIP: Does the team set WIP limits and use them as a tool for managing flow? Do they review WIP limits, adjust them, and respect them (which is not the same as blindly obeying them)
Manage Flow: How well does the team consistently observe the flow of work using relevant measures as guides in a continuing process of reducing waste, variability, and improving the flow of work through the system?
Explicit Policies: Does the team make policies relevant to the handling of tasks clear and explicit and review those policies as needed?
Improve Collaboratively: How well does the team use models and experiments to test ideas in order to introduce improvements to the process?
Feedback Loops: How well does the team create feedback loops to give both the team and individuals actionable feedback on quality and process?
¿Ya lo probaron? ¿Lo conocían? Espero los comentarios.
Germán
LEAN = Menos desperdicios / Más aprendizajes / Decidir al final / Entregar rápido / Potenciar al equipo / Hacer con calidad / Ver el todo
— Andres Schuschny (@schuschny) November 27, 2013
A menudo sucede que me encuentro hablando con gente que piensa que hacer algo agile es implementar un tablero y con eso ya está (me ha pasado mucho en los últimos 3 o 4 meses). Verdaderamente, están haciendo algo: visualizando su trabajo en curso, sus lista de tareas y sus desvíos. Lo cual no es poco, pero...
El furor por las metodologías ágiles es tal que por momentos algunas organización necesitan aplicarlas a cualquier precio, cómo sea. Quizás sea un problema de "vacío metodológico" en dichas organizaciones, potenciado por el hecho de que algunos frameworks tiene pocas reglas, son "relativamente simple" y el tiempo de aplicación es corto. También, muchas veces existe una especie de "bajada de línea" de las gerencias sin permitir a sus equipo madurar y hacer crecer organicamente su necesidad de trabajar en un esquema colaborativo, iterativo y con todo lo que eso significa.
En conclusión, las metodologías ágiles son fáciles de aprender (son frameworks con pocas reglas) pero difíciles de aplicar correctamente. Sin embargo, pienso que también se han vuelto populares debido a que las organizaciones (no todas, pero bastantes) tienen este "vacío" que muchas veces atenta contra su buen uso.
Germán
Germán
Uso Feedly para gestionar los post de los blogs que sigo. Diariamente, hago una selección de artículos para leer en el momento y otros los guardo para chusmearlos luego. Esta selección la hago por categoría, nombre de autor (algunos leo con más frecuencia que otros) y también hago selección por título.
En este contexto, todos los días me encuentro con que aún se sigue escribiendo (bastante) sobre la "rivalidad", "diferencia", importancia de los testers por sobre los developers o viceversa. A esta altura del partido, creo que este debería ser ya un tema superado. Por esta razón, es que he decidido no leer más artículos con estos contenidos. Títulos tales como "Developers vs. Testers", "¿Por qué los programadores 'odian' a los testers?", "El espíritu destructivo de los testers" están para mi obsoletos. Opino que ambos (devs y testers) deberían estar bajo un mismo rótulo: software makers, o simplemente software developers. Ya no tiene mucho sentido volver sobre lo mismo y debería ser un tema superado en la comunidad del software. Hay que pasar al siguiente nivel de la discusión.
Germán
El post anterior sobre este tema hizo bastante ruido. Recibí muchos comentarios/opiniones al respecto y me pareció interesante dar "otra vuelta". En realidad, esta vez es para dividir en un par de tracks los comentarios que recibí y "generar más conocimiento":
1. Testing Agile: hace un tiempo escribí sobre los principios propuestos en este libro, y efectivamente, de alguna manera, la idea expuesta en el post tiene implícitos estos principios.
2. Cualquiera puede hacer Testing: sinceramente, me cuesta creer en esto. He trabajado con gente que no es del palo y han tenido un excelente desempeño. Sin embargo, hay cuestiones técnicas, de análisis, gestión, etc. en las cuales hay una clara ventaja del informático. Seguramente en testing funcional es más factible, pero si queremos ir en esta dirección deberíamos apuntar a gente informática, sin dudas. En otro momento, retomaré el tema.
3. El Testing no puede automatizarse completamente: No puedo estar más de acuerdo con esta afirmación. No hay dudas. Lo que sí surge aquí es, ¿qué automatizar y qué no?, ¿qué herramientas son las adecuadas?
4. Un fail como puerta de entrada hacia más conocimiento: Un bug permite a los developers explorar escenarios, situaciones, y código aún no explorado y con un fuerte impacto (potencial) en la funcionalidad de software. La forma operativa de capturar conocimiento en testing es a través de un bug.
Para terminar, no deja de sorprenderme la cantidad de comentarios y de gente que tiene las mismas inquietudes. Los lectores son como los testers que ayudan a generar más conocimiento en este blog!
Les dejo unos links a los comentarios que recibí -> 1, 2, 3, 4
Para terminar, no deja de sorprenderme la cantidad de comentarios y de gente que tiene las mismas inquietudes. Los lectores son como los testers que ayudan a generar más conocimiento en este blog!
Les dejo unos links a los comentarios que recibí -> 1, 2, 3, 4
Hace unos días, en mi trabajo, estuve presenciando una charla interesante sobre NoSQL. El orador era Cristobal Pedregal Martín. Sinceramente, no conocía mucho sobre el tema y, por lo tanto, no voy a entran mucho en detalle sobre el concepto en este post. Más allá del tema en cuestión (del cuál podemos tener una vaga idea o no saber nada al respecto), estas exposiciones son oportunidades para abrirse a nuevos conocimientos y relacionarlos con otros ya existentes. Personalmente, en estas charlas me fijo mucho en cómo está estructura la presentación, qué ejemplos se usan para explicar los conceptos y cómo el orador se dirige a la audiencia. Cómo hacer una buena presentación no es un tema que esté en condiciones de abordar profundamente, sin embargo, creo que hay que entrenarse al respecto para saber hablar delante de una audiencia.
Volviendo a la charla, y a lo que motivó esta entrada, quería mencionar lo que Pedragal Martín nombró como Talent Pool. La traducción es simple. Sin embargo, me interesó el contexto en el cuál lo comentó. Promediando la presentación, Martín repasaba algunos riesgos asociados a implementar un sistema NoSQL. Decía que es necesario tener en cuenta el costo capital (Capex), el costo operativo (Opex), si el sistema es propietario o si es Open Source y, por último, si existe gente capacitada en esta tecnología o si es necesario atraer a jóvenes promesas para capacitarlas. Inmediatamente, relacioné esto último a un tema actual, complejo y crítico, y que tiene que ver con la poca gente especializada que existe en el ámbito de la Informática. Lo digo en relación a la necesidad actual de profesionales informáticos y cómo de ellos depende el desarrollo de una "identidad tecnológica" como país. Claramente, esto no es algo nuevo y en estos enlaces hay algunas muestras de ello:
Estudiar Computación,
Las posiciones de trabajo más dificiles de cubrir,
La escasez de profesionales, y
Hay que estudiar informática
Como conclusión, está claro que para desarrollar nuevas tecnologías e innovar, es necesario tener este talent pool impulsado por la "profesionalización" de la Informática como disciplina y por la necesidad de definir esta "identidad tecnológica". Es también nuestra responsabilidad promover esta especialización.
Imagen: http://www.insightfororganisations.co.uk/talent-management/
Estudiar Computación,
Las posiciones de trabajo más dificiles de cubrir,
La escasez de profesionales, y
Hay que estudiar informática
Como conclusión, está claro que para desarrollar nuevas tecnologías e innovar, es necesario tener este talent pool impulsado por la "profesionalización" de la Informática como disciplina y por la necesidad de definir esta "identidad tecnológica". Es también nuestra responsabilidad promover esta especialización.
Imagen: http://www.insightfororganisations.co.uk/talent-management/
Suscribirse a:
Entradas (Atom)
