Get the Rebtel app so we don't have to pay for our calls anymore.
Calls between Rebtel users are free, and if you want to call other people who don't have Rebtel installed, international calls are up to 98% cheaper than calling with your carrier. So it's worth trying it.
Download here: http://www.rebtel.com/u/5492615773726?utm_campaign=taf&utm_source=taf_android&utm_medium=email
| Probando Milestone 3 Probando Milestone 3 - Argentina - @alesfrede Performance - Banchmark antutu Root - Milestone 3 bootstrap | |
 © |
| What's in the box? |  | | What you need: |
Recientemente vi un video de Kent Beck, Software G Forces: The Effects of Acceleration, comentado por Mary Poppendieck en How Cadence Predicts Process.
Kent analiza como cambian los procesos y buenas prácticas según aumenta la frecuencia de entregas (Anual, Trimestral, Mensual, Semanal, Diaria, Horas). Comenta como algunas prácticas son buenas con cierta frecuencia de entrega y son malas en otras.
Plantea la relevancia de este análisis debido a que, según su percepción, la frecuencia de entrega de los equipos de software tiene a acelerarse.
Mi intensión es hacer un resumen, pero recomiendo ver el video que, aunque dura 90 min, es mucho más rico que este post.
Prácticas que se agregan: Test de aceptación automatizados, refactoring, Integración continua
Justificación: No se puede solo reducir los tiempos, hay que cambiar los procesos. No puedo tener un mes de integración y corrección de bug, con una o dos semanas de pruebas manuales para hacer regresiones. Entonces aparece Integración continua, y Pruebas de Aceptación Automatizada. No puedo tener uno o dos meses de diseño, aparece la necesidad de avanzar aún sin tener todo el diseño hecho o cerrado. Estoy seguro que tendré que cambiar el diseño, por lo tanto, tengo la necesidad de refactoring.
Cambios en el negocio: Suscripción.
Justificación: No se pueden vender 4 versiones por año. Necesito bajar el costo de transacción (tanto para la empresa como para los clientes).
Prácticas que se agregan: prueba por parte de los desarrolladores, reuniones diarias, tarjetas en las paredes.
Prácticas que se quitan: Departamente de QA, soporte a múltiples versiones, Documento de diseño, Control de cabios, equipo de análisis, equipo de build.
Justificación: no hay tiempo para el ida y vuelta con un grupo separado de QA. La mayoría del testing y la reducción del defectos deben ser hechos por el mismo grupo, y probablemente por la misma personas (testers en el equipo y pruebas por los programadores), en el plazo de horas, no de días. La comunicación debe ser mucho más rápida, no podemos sincronizarnos y detectar problemas una vez por semana o mensualmente. Tenemos que estar al tanto cada día, solo tenemos 20 días para entregar (reuniones diarias), tenemos que planificar y re-planificar en forma barata y rápida (tarjetas en las paredes, dejar de usar control de cambios formales). No podemos dedicar mucho tiempo para escribir las decisiones detalladas de diseño antes de usarlas (Documentos de diseño).
Al aumenta la cantidad de entregas, el costo de soporte de muchas versiones se vuelve prohibitivo, y debemos mantener una o pocas versiones del producto (soporte de múltiples versiones). Necesitamos iniciar el diseño y el desarrollo, no podemos esperar una fase de análisis o el ida y vuelta en paralelo con un grupo de análisis (mismo problema que con QA).
Cambios en el negocio: Pagar por el uso.
Justificación: la suscripción no nos da suficiente feedback. Con pagar por el uso, sabemos realmente que funcionalidad que estamos desarrollando les interesa a los clientes.
Prácticas que se agregan: migración de datos en vivo, cero defecto, ramas temporarias, dovela clave (keystoning), kanban.
Prácticas que se quitan: equipos de test, migración en un sólo sentido, ramas de release, parches, diseño de usabilidad al inicio, venture capitals
Justificación: para poder cambiar las estructuras de datos en sitios con grandes volúmenes de datos y cantidad de usuarios, se debe hacer procesos de migración en dos o tres fases, de manera de cambiar la estructura sin nunca dejar de dar el servicio (migración de datos en vivo).
Como los tiempos son cortos, algunas funcionalidades se comienzan a agregar sin hacerlas visibles. Solo cuando está todo dispobible, se agrega la última parte (como la dovela clave de un arco de medio punto), y queda dispobible para los usuarios. Siendo que las entregas son tan rápidas, cualquier cambio, por más urgente que sea, puede incluirse en la próxima entrega. Se elimina la necesidad de procesos de emergencia (parches).
Cambios en el negocio: Bootstrap financing.
Justificación: La financiación de Venture Capitals necesita mayor predecibilidad en los planes, e impone restricciones a desarrollo de productos (a esta velocidad).
Prácticas que se agregan: inmunización, A/B testing
Prácticas que se quitan: staging, equipo de operaciones, reuniones diarias.
Justificación: algunos de los releases van a ser malos. Tenemos que tener formas muy sencillas de volver atrás o formas muy rápidas de corregir y continuar. No hay mucho tiempo para discusciones sobre diseño de interfase, se pude simplemente dar las alternativas y ver como lo usan los usuarios (A/B testing). Para hacer entregas rápidas, no podemos pasar por tantos pasos (ambientes) intermedios. Simplemente no hay tiempo para usarlos (staging), lo que se puede hacer es hacer instalaciones en distintos servidores de producción, que se va midiendo y obteniendo feedback. Todo esto lleva a que la operación debe ser parte de la responsabilidad del equipo (equipo de operaciones). La comunicación en el grupo tiene que ser tan continua y rápida, que no tiene mucho sentido para las reuniones diarias.
 |
Actualmente, el proyecto Google+ está tratando de resolver todos los pequeños fallos mediante un grupo reducido de prueba. Si no puedes acceder a Google+, vuelve a intentarlo pronto.
|
 |
Ésta es la vida real.
Los problemas son lo que hacen que el cliente nos llame. Los problemas son los que hacen girar la rueda del intercambio comercial entre clientes y empresas de productos y servicios. Sin los problemas no tendríamos trabajo.
Muchos de los lectores seguramente son personas versadas en las técnicas de administración de proyectos, unos a nivel introductorio y otros avanzado, pero ambos, a su propio nivel, se encuentran diariamente con una serie de problemas que los hace aplicar las diversas técnicas aprendidas ya sea experimentalmente o formalmente para conseguir una solución favorable.
Mi proyecto no fue la excepción. Desde su propio origen nos encontramos con el problema de balancear las variables tiempo, alcance y calidad.
Pensando en esto, en las técnicas y herramientas que hay para resolver problemas de administración de proyectos, me puedo dar cuenta que hay mucho escrito sobre administración de proyectos. Constantemente recibo correos que me invitan a visitar un sitio, a comprar un template, a adquirir una metodología de administración de proyectos, a inscribirme en un curso que me enseñará "lo que nadie en el mercado está enseñando sobre administración de proyectos", a asistir a la reunión mensual en la que tratarán "temas de relevancia para los administradores de proyectos en estos agitados tiempos",… la lista continúa interminablemente.
He revisado decenas de metodologías, asistido a más de cien seminarios web, leído miles de páginas, visitado centenares de sitios web sobre administración de proyectos y descargado innumerables formatos y templates para su uso en mis proyectos. Además hice un diplomado en administración de proyectos que resultó en mi certificación como PMP, sin embargo ninguno de estos esfuerzos, algunos gratuitos y otros muy bien cobrados, me dieron las habilidades para resolver los problemas de mis proyectos.
Y es que no solamente se trata de conocimientos y metodologías, se trata de muchas cosas más. Desde luego que los conocimientos adquiridos trabajan a nuestro favor cuando nos enfrentamos a un miembro del equipo ocioso, o cuando balanceamos cargas de trabajo, o cuando necesitamos apresurar la entrega de un paquete de trabajo, o cuando el cliente pide un cambio. Hay suficientes páginas escritas sobre cómo lidiar con estos y otros problemas, pero siempre el nuestro parece algo diferente a lo que dice en el libro de texto.
He observado que hay tres actividades que podemos llevar a cabo para incrementar nuestras habilidades en la resolución de problemas y son las siguientes:
1. Enfrentar el problema. No se trata de darle la vuelta, evitarlo o buscar alternativas, se trata de reconocer que existe y emprender el camino hacia su resolución. Necesitas exponerte a los problemas. Quizás necesites tus habilidades más recientemente adquiridas en el mega-seminario de administración de proyecto o simplemente usar tu sentido común, pero lo importante aquí es concentrar tu atención en la búsqueda de la mejor solución al problema y no en evadirlo.
2. Documentar los resultados de tus esfuerzos por resolver el problema. Esto es algo así como las lecciones aprendidas parciales de tu proyecto. Es tu experiencia. Esto es el legado que vas a dejar al mundo de la administración de proyectos. Es el manual de resolución de problemas que le estás heredando a aquellos que están al inicio, en medio o al final de la carretera que representa la administración exitosa de un proyecto de cualquier naturaleza. Este registro es invaluable. Es lo que todas las compañías deberían estar ofreciendo dentro de sus capacitaciones. No ha habido seminarios más interesantes a los que yo haya asistido que a aquellos en los que se relatan lecciones aprendidas de un proyecto en específico. Es experiencia en acción, es valor agregado en toda su expresión.
3. Buscar problemas por resolver. Ya encontramos problemas en nuestro proyecto, ya los resolvimos, ya registramos las lecciones aprendidas y el problema quedó resuelto. La única manera para practicar la resolución de problemas es exponiéndonos a ellos de manera regular. Si no tienes problemas en tu proyecto seguramente es porque no has observado bien. Si no ves problemas seguramente es porque no has buscado en el lugar correcto. Los problemas están allí, tienen un reloj haciendo tic-tac, a punto de explotar cuando menos nos lo esperamos. Si no buscamos los problemas ellos nos encontrarán a nosotros pero quizás nos encuentren con la guardia baja.
Un proyecto se trata de resolver problemas. El trabajo se trata de resolver problemas. La vida se trata de resolver problemas. Aprende a vivir con ellos, a buscarlos, a identificarlos, a reconocerlos hasta que se vuelva tu segunda naturaleza, aprende a enfrentarlos, aprende a olfatearlos a lo lejos, aprende a prevenirlos antes de que ocurran… esto te dará un altísimo nivel de empleabilidad.
Los mejores administradores de proyectos con los que he tenido el privilegio de trabajar no estaban certificados en Project Management, los mejores no tenían cientos de horas de capacitación en administración de proyectos. Los mejores que yo he conocido sabían identificar problemas, resolverlos, anticiparlos y los enfrentaban agresivamente, inteligentemente y, como una osa que sentía la amenaza de un extraño, embestían el problema hasta dejarlo fuera de combate para siempre.
¿Qué hay de ti y de mí, que nos reunimos virtualmente para compartir esta lección, que buscamos seminarios y lecturas interesantes para afilar nuestras armas para la batalla en el campo de la administración de proyectos?, ¿no deberíamos tener un mejor desempeño?
Así es mi amigo lector, sal, busca y enfrenta tus problemas, pelea la buena batalla, la batalla que está ganada, la batalla de la profesionalización y aplicación de mejores prácticas en el campo de tu experiencia y cuando tengas la victoria documenta, comparte y aprende… y prepárate para el siguiente round.
Te deseo éxito.
| |||||||
Entradas
Comentarios
Círculos
Hangouts
Sparks
