Más de los 33 tips para mantenerse creativo.#3 ¡Canta en la ducha!
y para que no piensen que estoy loco, hago extensivo este tip con la siguiente pic relacionada. La imagen es de "the cool ruler"
Pueben, y después me cuentan...
Inicié una serie de entrevistas a diferentes personas con las que tengo el gusto de trabajar y que me han enseñado mucho. En este caso, entrevisté a Leandro Caniglia de Caesar Systems, con quién he trabajado en los últimos años como tester de PetroVR.
Germán Braun (GB): ¿Puede describir, en pocas palabras, qué es desarrollar software?
Leandro Caniglia (LC): Desarrollar software es capturar conocimiento. Y como ese conocimiento se captura siguiendo una metáfora uniforme (la de tu software), la captura dá rápidamente paso a la creación de nuevo conocimiento.
GB: El desarrollo de software es en sí, un proceso complejo. Sin embargo, ¿dónde radica la mayor complejidad?
LC: La complejidad del software radica en el conflicto que hay entre la tolerancia a fallas que caracteriza a los seres biológicos y la exacerbante precisión de las computadoras, que tiene que ser estricta. A partir de ahí la complejidad suele crecer cuando los programadores escriben código robusto para defenderse de posible errores.
GB: ¿Podría enunciar algunos tips que se deberían tener en cuenta para desarrollar software de calidad?
LC: Las reglas son pocas y sencillas. La dificultad estriba en aplicarlas todas todo el tiempo. Las más importantes son:
i) La partición del trabajo en tareas cortas y bien definidas cuya realización no lleve mas que unas pocas decenas de líneas de código.
ii) La revisión activa de cada change set. En esta práctica el revisor no le sugiere al autor cómo mejorar el código, lo modifica y produce mejor código siempre que pueda y sin importar si el cambio es insignificante o profundo.
iii) Todo change set debe tener al menos un test que ejercite la parte relevante de la tarea. Los tests unitarios debe correr en menos de 100 ms (cada uno).
iv) Integración continua, previo a correr todos los tests unitarios.
v) Testing manual a cargo de un equipo de testers profesionales independiente de los programadores.
vi) Refactoring permanente. Todos tocan todo, incluso lo que anda.
GB: Existen diferentes lenguajes de programación que implementan diferentes paradigmas. ¿Cuál es el lenguaje de programación que utiliza? ¿Por qué?
LC: Smalltalk. Lo utilizo porque es el mejor y en el mercado en el que compite Caesar el que dá ventaja pierde.
GB: ¿Cuál es su opinión sobre el uso de metodología ágiles?
LC: Opino que las metodologías ágiles han iluminado el panorama del desarrollo de software y lo han enriquecido. Hoy en día los buenos equipos de desarrolladores están mejor preparados para gerenciar cualquier tipo de proyecto (de software o de la industria que fuere) que sus clientes más encumbrados.
GB: ¿Es necesario el testing de software? ¿Aporta valor al producto final?
LC: El testing de software es esencial. Todo aquel que quiera producir software debería tener un equipo de testers profesionales de tamaño comparable al de programadores. Para desarrollar software se puede prescindir de todo el mundo, menos de los programadores y los testers.
Sobre Leandro Caniglia
Leandro es chief technologist en Caesar Systems. También es fundador y presidente de la FAST, la Fundación Argentina de Smalltalk.
¡Gracias Leandro!
Germán Braun (GB): ¿Puede describir, en pocas palabras, qué es desarrollar software?
Leandro Caniglia (LC): Desarrollar software es capturar conocimiento. Y como ese conocimiento se captura siguiendo una metáfora uniforme (la de tu software), la captura dá rápidamente paso a la creación de nuevo conocimiento.
GB: El desarrollo de software es en sí, un proceso complejo. Sin embargo, ¿dónde radica la mayor complejidad?
LC: La complejidad del software radica en el conflicto que hay entre la tolerancia a fallas que caracteriza a los seres biológicos y la exacerbante precisión de las computadoras, que tiene que ser estricta. A partir de ahí la complejidad suele crecer cuando los programadores escriben código robusto para defenderse de posible errores.
GB: ¿Podría enunciar algunos tips que se deberían tener en cuenta para desarrollar software de calidad?
LC: Las reglas son pocas y sencillas. La dificultad estriba en aplicarlas todas todo el tiempo. Las más importantes son:
i) La partición del trabajo en tareas cortas y bien definidas cuya realización no lleve mas que unas pocas decenas de líneas de código.
ii) La revisión activa de cada change set. En esta práctica el revisor no le sugiere al autor cómo mejorar el código, lo modifica y produce mejor código siempre que pueda y sin importar si el cambio es insignificante o profundo.
iii) Todo change set debe tener al menos un test que ejercite la parte relevante de la tarea. Los tests unitarios debe correr en menos de 100 ms (cada uno).
iv) Integración continua, previo a correr todos los tests unitarios.
v) Testing manual a cargo de un equipo de testers profesionales independiente de los programadores.
vi) Refactoring permanente. Todos tocan todo, incluso lo que anda.
GB: Existen diferentes lenguajes de programación que implementan diferentes paradigmas. ¿Cuál es el lenguaje de programación que utiliza? ¿Por qué?
LC: Smalltalk. Lo utilizo porque es el mejor y en el mercado en el que compite Caesar el que dá ventaja pierde.
GB: ¿Cuál es su opinión sobre el uso de metodología ágiles?
LC: Opino que las metodologías ágiles han iluminado el panorama del desarrollo de software y lo han enriquecido. Hoy en día los buenos equipos de desarrolladores están mejor preparados para gerenciar cualquier tipo de proyecto (de software o de la industria que fuere) que sus clientes más encumbrados.
GB: ¿Es necesario el testing de software? ¿Aporta valor al producto final?
LC: El testing de software es esencial. Todo aquel que quiera producir software debería tener un equipo de testers profesionales de tamaño comparable al de programadores. Para desarrollar software se puede prescindir de todo el mundo, menos de los programadores y los testers.
Sobre Leandro Caniglia
Leandro es chief technologist en Caesar Systems. También es fundador y presidente de la FAST, la Fundación Argentina de Smalltalk.
¡Gracias Leandro!
Estoy leyendo el libro "Agile Testing: A Practical Guide for Testers and Agile Teams" de Lisa Crispin y Janet Gregory. Es interesante, ya que plantean el Testing Agile como:
1) Un testing business-facing, es decir, un claro enfoque en las funcionalidades y características deseadas por los expertos del negocio, sin perder de vista el espíritu crítico y objetivo propio del testing.
2) Una práctica que involucra a todos los miembros de un equipo, trabajando con una clara orientación a la calidad y hablando en un lenguaje común. En este contexto, el rol del tester es importante desde el inicio del desarrollo, en contraposición a posturas más clásicas en las cuales el testing es hecho hacia el final de un largo ciclo de desarrollo, con poco injerencia en el producto final y enfocado, únicamente, en cumplir los requerimientos iniciales. Lisa y Janet definen este enfoque como Whole-Team.
Es claro que este nuevo concepto necesita de algunos cambios culturales y de nuevas skills de todas los involucrados en el proceso de desarrollo, managers, programadores, testers y clientes. Es un camino que puede ser largo o no según el contexto y las personas, sin embargo, podemos comenzar proveyendo soluciones prácticas que apliquen valores ágiles y promuevan sus principios.
Por último, Lisa y Janet proponen los siguientes 10 principios que son importantes para un tester agile y que voy a ir abordando en próximos posts:
(1) Provide continuous feedback
(2) Deliver value to the customer
(3) Enable face-to-face communication
(4) Have courage
(5) Keep it simple
(6) Practice continuous improvement
(7) Respond to change
(8) Self-organize
(9) Focus on people
(10) Enjoy
¡Hasta la próxima!
1) Un testing business-facing, es decir, un claro enfoque en las funcionalidades y características deseadas por los expertos del negocio, sin perder de vista el espíritu crítico y objetivo propio del testing.
2) Una práctica que involucra a todos los miembros de un equipo, trabajando con una clara orientación a la calidad y hablando en un lenguaje común. En este contexto, el rol del tester es importante desde el inicio del desarrollo, en contraposición a posturas más clásicas en las cuales el testing es hecho hacia el final de un largo ciclo de desarrollo, con poco injerencia en el producto final y enfocado, únicamente, en cumplir los requerimientos iniciales. Lisa y Janet definen este enfoque como Whole-Team.
Es claro que este nuevo concepto necesita de algunos cambios culturales y de nuevas skills de todas los involucrados en el proceso de desarrollo, managers, programadores, testers y clientes. Es un camino que puede ser largo o no según el contexto y las personas, sin embargo, podemos comenzar proveyendo soluciones prácticas que apliquen valores ágiles y promuevan sus principios.
Por último, Lisa y Janet proponen los siguientes 10 principios que son importantes para un tester agile y que voy a ir abordando en próximos posts:
(1) Provide continuous feedback
(2) Deliver value to the customer
(3) Enable face-to-face communication
(4) Have courage
(5) Keep it simple
(6) Practice continuous improvement
(7) Respond to change
(8) Self-organize
(9) Focus on people
(10) Enjoy
¡Hasta la próxima!
Seguimos con 33 tips para mantenerse creativo.
#2 "Lleva tu cuaderno a todas partes"
Es importante tomar notas, en conferencias, clases, reuniones, workshops o, simplemente, cuando una idea viene a nosotros. Uno nunca sabe cuando la inspiración puede apoderarse de nosotros y hay que estar preparados.
Sin embargo, tomar notas de manera efectiva puede no ser tan simple como parece. Nuestras notas deben ser legibles y, además, captar toda la información relevante para poder luego "seguirle el rastro".
Algunas sugerencias:
¡Hasta la pŕoxima!
#2 "Lleva tu cuaderno a todas partes"
Es importante tomar notas, en conferencias, clases, reuniones, workshops o, simplemente, cuando una idea viene a nosotros. Uno nunca sabe cuando la inspiración puede apoderarse de nosotros y hay que estar preparados.Sin embargo, tomar notas de manera efectiva puede no ser tan simple como parece. Nuestras notas deben ser legibles y, además, captar toda la información relevante para poder luego "seguirle el rastro".
Algunas sugerencias:
- Anota la fecha de la nota.
- Usa tus propias palabras.
- Revisa las notas tan pronto como puedas luego de la clase/conferencia/reunión, etc.
- Enfatiza aspectos relevantes.
- Anota nombres, fechas, libros y referencias.
- Tacha todo lo que no corresponda.
- Registra cualquier duda que surja sobre el contenido de tu nota para responderla a su debido tiempo.
- Incluye gráficos y/o mapas conceptuales para relacionar conceptos y/o palabras claves.
¡Hasta la pŕoxima!
Tantos rankings que se arman para fines de año y principios del siguiente, ¿cómo no va a haber uno especial para las aplicaciones Android?
Punto Geek publicó una lista con las mejores aplicaciones Android del 2012. Son las 10 siguientes:
Punto Geek publicó una lista con las mejores aplicaciones Android del 2012. Son las 10 siguientes:
- Evernote
- Grimm’s Snow White
- Expedia Hotels & Flights
- Ancestry
- Fancy
- Seriesguide Show Manager
- Pixlr Express
- TED
Hasta el momento sólo he probado Evernote, Pocket y TED que, a propósito, son altamente recomendables.
Por último, personalmente creo que la aplicación por excelencia para cualquier smartphone/tablet y que resiste cualquier clasificación, es Twitter. Sin dudas.
Otras apps interesantes: Google Reader (seguir y leer blogs), Quora (preguntas y respuestas), Dropbox (almacenamiento en la nube), LinkedIn (contactos) e Instagram (fotos).
¡Hasta la próxima!
Hace un tiempo encontré una lista de 33 tips para mantenerse creativo. Me pareció interesante, y por supuesto, me propuse seguirlos (por ahora parcialmente). Voy a comentarles cuales fueron mis elecciones para cada uno de los tips que pude implementar, por lo tanto, a partir de aquí, comienza una saga de posts con mis recomendaciones. Ustedes, ¿cómo se mantienen creativos?
Si les interesan los tips (en general), también estoy siguiendo los consultips de "Así no se hacen las cosas" y los retrotips de "el próximo paso". Muy interesantes para aplicar.
Comencemos...
Las listas, por ejemplo, son un pilar fundamental de cualquier implementación GTD ("Getting Things Done") propuesta por David Allen. Actualmente, estoy haciendo mi propia implementación GTD pero aún le falta madurar. Cuando esté aceitada, se las comparto.
¡Hasta la próxima!
Si les interesan los tips (en general), también estoy siguiendo los consultips de "Así no se hacen las cosas" y los retrotips de "el próximo paso". Muy interesantes para aplicar.
Comencemos...
1) "Haga listas"
Tan simple como eso. Pueden ser en papel o cualquier dispositivo digital más avanzado. No importa, hay que sacarse las cosas de la cabeza y explicitarlas de tal manera que podamos atenderlas una por una a su debido tiempo. Podemos hacer listas de nuestros proyectos, tareas de la semana, ideas...Las listas, por ejemplo, son un pilar fundamental de cualquier implementación GTD ("Getting Things Done") propuesta por David Allen. Actualmente, estoy haciendo mi propia implementación GTD pero aún le falta madurar. Cuando esté aceitada, se las comparto.
¡Hasta la próxima!
Suscribirse a:
Entradas (Atom)
