En realidad somos agiles?


Me encontre este interesante articulo en el Harvard Publishing  que me puso a pensar si todo nuestro merequetenge sobre los metodos agiles en realidad esta acotado por nuestra resistencia al cambio:

Es posible salvar el matrimonio entre la IT y el negocio?

“Si quieres expirimentar algo rapidamente, no pases por IT, ellos te diran que no y tardaran una eternidad en hacerlo.”

Gary Hammel

Guru de estrategia

Sera?

Anuncios

¿Quieres ser un arquitecto de software?


El Arquitecto de Software es visto hoy en día como un integrante fundamental de los equipos de desarrollo de software empresarial. Ante esta situación, es interesante conocer que se requiere para ser un buen arquitecto de software, por lo cual, basado en una petición de Oscar Galicia y una solicitud de linkedin, presento este artículo dinámico en base a mis experiencias y a las de otros arquitectos:

Lo primero que se requiere para ser un arquitecto de software es querer ser un buen arquitecto de software. Esto puede parecer obvio o irónico, pero para nada es así. Estoy siendo sincero y me baso en artículos de prestigiadas revistas e instituciones (véase mi post “Como ser el mejor programador del mundo”).

  • Haber participado directamente en al menos 2 proyectos de software grandes, donde existan requerimientos conflictivos entre si de parte de varios participantes (Stakeholders). Esto implica mas de 5 años de experiencia profesional, el buen vino toma su tiempo.
  • Amplio conocimiento de alguna de las plataformas empresariales (.Net, J2EE o ahora Ruby on Rails)
  • Conocimiento profundo de las características de los atributos de calidad y lo que implica conseguirlos y balancearlos (Escalabilidad contra sencillez por ejemplo)
  • Experiencia en todo el ciclo de vida del desarrollo de software (véase el peligro del non coding architect, aunque esto no significa que tenga que continuar codificando en una base diaria)
  • Saber trabajar en equipo, Habilidad para convencer y guiar al equipo.
  • Habilidad para mantenerse constantemente actualizado en los aspectos tecnológicos y de negocios de su industria.
  • Intensa empatía hacia los interesados en los proyectos en que participa, si solo piensa en su área esta frito. Debe de poder ponerse en los pies del resto de los participantes y entender sus preocupaciones. No existe arquitectura que sea buena si no es en función de las necesidades de sus interesados (stakeholders).

Lens sobre arquitectura de software

Como ser un programador experto


Leyendo la edición de este mes de una de las más prestigiosas revistas de negocios: HBR, encontré un artículo sobre un tema que me ha intrigado desde hace tiempo y que ya había tratado en este blog:

¿Como convertirse en el mejor en algo?

Pues resulta que los profesores de Harvard describen como los componentes para convertirse en un experto en un tema son los viejos conocidos: Dedicación, disciplina, y sobre todo practica.

Si queremos convertirnos en un desarrollador experto de software, debemos practicar constantemente (diariamente si se puede) el desarrollar software. Al menos unas 25-30 horas a la semana distribuidas en los 5 días laborables.

Nótese buen estoy diciendo desarrollar, no asistir diariamente a 3 reuniones de 3 horas sin haber desarrollado mas de 1 hora en total al día.

Presione clic aquí para leer articulo original en el HBR

 

 

Sun se vuelve agil


Tuve el privilegio de asistir el sabado pasado a una presentacion de Emilio Osorio de SUN sobre los metodos agiles.

Una vez mas me senti emocionado al extremo por el humanismo de estos metodos, ademas de que emilio sin duda es un convencido de dichos metodos y un gran difusor de los mismos (lo cual yo no he logrado hacer)

No tengo las laminas, pero encontre una entrevista a emilio en frecuencia cero : http://www.frecuenciacero.com.mx/eon45/index.php?option=com_content&task=view&id=38&Itemid=2

Sin duda esta conferencia hizo renacer en mi el deseo de difundir el uso de estos metodos y de la tendencia actual hacia la simplicidad.

Como NO realizar la reunion diaria de SCRUM


Un simpatico ejemplo de que situaciones evitar para poder contar con una reunion diaria de SCRUM que sea sana y productiva. Tambien es un ejemplo de como la Web 2.0 ya nos alcanza a todas las profesiones, puesto que empiezan a aparecer blogs/articulos visuales relacionados con el desarrollo de software nada menos que en youtube.

Video de como no realizar una reunion diaria de SCRUM