viernes, 24 de mayo de 2013

Diferencias entre Product Owner y/o Scrum Master y Project Manager



En realidad el rol como tal de Project Manager no está considerado dentro de Scrum. Lo que reemplazaría al rol de Project Manager seria en todo caso el Scrum Master y el Product Owner, por su parte el scrum master tiene como principal función el de identificar y mitigar los impedimentos del trabajo del equipo, en vez de tener un perfil directivo mantiene un perfil colaborativo, se asegura que todo el equipo siga de forma adecuada todas las ceremonias y directrices que conlleva Scrum y por ultimo asegura que todos tengan buena comunicación y los entregables se terminen a tiempo. Por su parte el Product owner se encarga de crear el product backlog con todos los requerimientos ordenados y priorizados, trabaja al lado de los stakeholders para poder aceptar y aprobar los entregables de cada sprint. El Project Manager por su esencia abarca más áreas donde controla todo el tiempo riesgos, alcance, costos, adjudicaciones, etc. Recuerden que en Project Management se enfoca más en la planificación mientras que en Scrum se tiene más en cuenta la respuesta al cambio constante donde se trabaja de cerca con el cliente para poder acelerar la entrega final del producto (en mi opinión una gran ventaja en especial en el área de desarrollo de software).

Mi consejo para las personas de desempeñan el rol de Scrum Master es que traten de hacer un mix en sus proyectos, teniendo en cuenta la buena planificación así como implementar Scrum para tener una respuesta al cambio eficiente, con personas comprometidas en su trabajo (Autogestionados).
Si alguien tiene un aporte no dude en escribirme o dejar sus comentarios, todos serán bienvenidos para así poder enriquecer el conocimiento conjunto con experiencias rescatadas en el mundo real.

miércoles, 6 de marzo de 2013

Scrum Bolivia Day 2013 Coming Soon

Segunda versión del Bolivia Scrum Day a llevarse a cabo el 30 de Marzo, en el Hotel Camino Real en la ciudad de Santa Cruz de la Sierra. Acá les dejo el contenido de las presentaciones y los nombres de los expositores:



Programa
Sábado 30 de marzo de 2013

8:00-8:30 Acreditación
8:30-9:30 Desafíos del manager en la era ágil - Federico Zuppa
9:30-10:30 Los 10 mandamientos de TDD – Hernan Wilkinson

10:30-11:00 Break
11:00-12:00 Good Practices in Software Test Automation – Camilo Ribeiro

 12:00-14:30 Break
14:30-15:30 Craftsmanship – Desarrolladores ágiles, profesionales y responsables - Carlos Peix
15:30-16:30 Why do we use Scrum? – Juliano Ribeiro

16:30-17:00  Break
17:00-18:00 Disfunctions of Scrum: how to avoid them and extract the most from Scrum – Samuel Crescêncio
18:00-19:00 ¡No estimarás!  – Thomas Wallet

A todas las personas que puedan asistir les recomiendo que sean puntuales. Solo un día al año podemos contar con la experiencia de profesionales con vasta experiencia en empresas de software en el exterior.

Para mayor información dirigirse al link http://scrumbolivia.com/

viernes, 1 de junio de 2012

Consejos sobre testing de aplicaciones


Cuando se desarrolla un proyecto de software nunca se debe subestimar el plan de pruebas. Este apartado es crucial, tanto para ofrecer la calidad que espera el cliente bajo los criterios que se acordaron en la definición del proyecto como para ofrecer un software robusto libre de errores. Como desarrolladores tenemos que procurar que nuestro código esté libre de bugs y cumpla los requisitos funcionales.

Cuando definamos un plan de testing o QA es importante recordar algunas de la lecciones que prácticamente todos los desarrolladores que hemos participado en un plan de pruebas hemos aprendido de forma práctica incluyendo algún quebradero de cabeza en su momento.

Un punto clave que también debe tener muy presente es el de hacer pruebas de TDD (Test driven development) para la creación de unit tests; para más información visitar el siguiente enlace http://en.wikipedia.org/wiki/Test-driven_development.
 
Otro punto muy importante es el manejo de subversión , el cual ayuda a tener todo el código sincronizado; la posibilidad de que varias personas puedan modificar y administrar el mismo conjunto de datos desde sus respectivas maquinas fomenta la colaboración. Y puesto que el trabajo se encuentra bajo el control de versiones, no hay motivo para temer por que la calidad se vea afectada, si se hizo un cambio incorrecto, simplemente deshaga el cambio, una muy buena interfaz es la de TortoiseSVN.

A continuación unos puntos claves que todo desarrollador debería tener en cuenta al momento de implementar una aplicación:

  • Aunque el proyecto vaya mal en tiempo o en costes, nunca hay que recortar el tiempo de pruebas. Nos tenemos que asegurar siempre que el proyecto que entreguemos esté libre de errores, si recortamos en pruebas y además vamos apurados estaremos cometiendo muchos más errores de los habituales.
  • Lo más importante que tenemos que probar son los requisitos funcionales que definen el alcance del proyecto. En definitiva, esto es lo que conforma la parte del negocio que fijamos con el cliente y los usuarios como entregable y tiene que satisface sus necesidades.
  • Hay que probar el desempeño de la aplicación sea el esperado por el cliente un punto a medir son las pruebas de carga, es la única forma de que probemos al 100% que toda la parte técnica funciona correctamente.
  • También es muy importante antes de lanzar el producto realizar la fase de pruebas de regresión donde se revise que cada componente funcione correctamente (después de haber corregido todos los errores encontrados previamente) 
  • La gestión de configuraciones y versiones es un apartado fundamental del alcance y la gestión de cambios. No debemos descuidar este apartado ya que nos podrá acarrear problemas a corto/medio plazo.
  • Siempre que corrijamos un error debemos volver a testear todo. Es fundamental asegurarnos que no se haya roto nada por otro lado.
  • Aunque parezca obvio, nunca hagas pruebas en el entorno de producción. Invierte lo que haga falta en un entorno de pre-producción sólido y lo más parecido posible. Es una inversión que te salvará de muchos apuros y te permitirá asegurar que no habrá diferencias entre las pruebas y cuando se suba definitivamente a producción.
  • Es recomendable tener especialistas en testing o un equipo dedicado al QA en tu empresa. Testear no se debe tomar a la ligera ni ser un mero tramite burocrático para declarar la tarea como finalizada. Es fundamental que se haga un trabajo completo probando cada funcionalidad. Si no es posible tener un equipo sólo dedicado a eso, es conveniente que los encargados en ese momento de testear sólo se dediquen a probar y reportar errores.
  • Es muy recomendable involucrar a los usuarios claves que han participado en la definición de los requisitos de la aplicación. Mientras se prueba pueden obtenerse un importante feedback de usabilidad. Para lo cual uno debe presentar entregables a los clientes para recibir el Ok y poder seguir avanzando en el desarrollo, es una práctica muy importante que aconseja la metodología ágil.
  • Es recomendable tener herramientas que nos aporten a la comunicación de desarrolladores con gente de calidad. Para agilizar la corrección y que no se nos pase ningún bug. Ej. Xplanner, V1, etc. Ya que cuando solo usamos el envió de mails corremos el riesgo de omitir información muy importante para la corrección de errores.
Referencias:
http://www.genbetadev.com/trabajar-como-desarrollador/lecciones-aprendidas-del-testing-de-aplicaciones-software

lunes, 21 de mayo de 2012

Agile Open Bolivia

Para los que tengan la oportunidad de asistir a este gran evento a realizarse el día Sábado 2 de Junio a hrs. 08:00 AM en nuestra querida ciudad Cochabamba. El lugar es la Universidad Católica Boliviana ‘San Pablo’.
Es bueno estar en contacto con la comunidad Ágil de Bolivia, les recomiendo que asistan para poder compartir experiencias y seguir aportando a nuestra comunidad.

Para más información referirse a la siguiente página: http://agileopenbolivia.eventbrite.es

martes, 15 de mayo de 2012

Lo que realmente necesitan los proyectos


Leí un interesante artículo titulado ‘Los proyectos requieren liderazgo no administración’ acerca de la necesidad de contar con líderes más que administradores dentro de los proyectos. En el artículo habla de una marcada diferencia entre el rol de un gerente funcional y un Project manager.

El gerente funcional se maneja más en un organigrama o matriz de roles que se encuentran subordinados a los gerentes funcionales donde cada gerente funcional solo trata directamente con sus pares en los otros departamentos. En mi experiencia personal vi este caso en más de una empresa dedicada a TI en Bolivia y me atrevo a asegurar que en el caso de un gerente funcional es mucho más fácil el manejo del proyecto, pero también el éxito del mismo se ve afectado en cuanto al alcance y tiempo de finalización. Al no contar con un contacto directo con todo el equipo (todos los interesados del proyecto: clientes, patrocinadores, sponsors, equipo de trabajo, etc.) no se tiene una visión clara del estado actual del proyecto, además que los equipos involucrados no cuentan con la confianza ni comunicación necesaria para poder manejar con mayor fluidez sus tareas cotidianas, se genera un cuello de botella donde los requerimientos se van escalando uno a la vez y en ese trayecto se va perdiendo información valiosa así como se va mal interpretando la mayor parte de la información.  

 Lo ideal es que el Project Manager pueda llegar a cada una de las personas participantes del proyecto sin ningún tipo de burocracia y también otra característica es que lidera personas mucho más allá de administrarlas.
También habla de que el Project Manager debe enseñar a los patrocinadores acerca de sus deficiencias, debe enseñarles (si es que el caso lo amerita) todo lo necesario que se necesita de parte de ellos para que el proyecto tenga el éxito esperado, tales como las aclaraciones de los requerimientos, delimitar el alcance del proyecto, adquirir expertos para el soporte del proyecto y el de aportar dinero extra en caso de que el proyecto lo amerite (casi la mayor parte del tiempo).

La parte final que me agrado es que define que el éxito es contagioso en los proyectos. Siendo un líder ayudaras a la organización entera, al final influyes en el cambio de cultura de dicha organización. Tres puntos en los cuales debemos concentrarnos principalmente para asegurar el éxito dentro el proyecto: Necesito que me ayudes en…, Necesito un maestro en…, Necesito que me aclares…

En cuanto más rápido encontremos la solución a algún problema dentro el proyecto, estaremos más cerca de cumplir con el objetivo dentro el cronograma establecido.
Los mejores líderes de proyectos son aquellos que más que dirigir, se identifican con el equipo entero, son moderadores a la hora de tomar decisiones y logran encontrar soluciones eficaces a todo riesgo que se presente (mejor prever antes que corregir).

Para los que deseen revisar el artículo: http://ecaminc.com/index.php/blog/59-generalblog/313-2012-05-14?goback=%2Egde_69301_member_115068587

lunes, 14 de mayo de 2012

Nadie es profeta en su tierra


Otro claro ejemplo es la nueva incursión de nuestro amigo potosino (supongo que como yo casi nadie lo sospechaba ;)) nacionalizado cochabambino Daniel Calbimonte ‘’El paladín tecnológico’’  en el área de BI en el que viene trabajando hace ya varios años, pero que desafortunadamente no se le dio la  oportunidad de aplicarlo al 100% en nuestra llajta querida, por lo que recibió la invitación directa de la empresa multinacional Iprojects la cual arranco sus proyectos para Bolivia hace poco menos de un mes. Iproject  Partners, una prestigiosa multinacional del área de IT con diferentes proyectos y clientes alrededor del mundo. Más datos de la empresa en el siguiente link: http://iprojectpartners.com/index.html
Ya había escuchado rumores del traslado del paladín dejando el paraíso boliviano Cochabamba; para la ciudad de Santa Cruz de la Sierra, que por cierto es la misma ciudad donde me encuentro radicando hace  poco menos de 2 años (también por motivos laborales deje Cochabamba).
Pequeña bio de Daniel:
Tiene más de 10 años de experiencia en proyectos de software, trabajando varias veces como consultor, gerente de calidad de software, desarrollador, instructor para software internacional exportado alrededor del mundo. Trabajó mucho con Servidores Windows Server 2000, 2003 y 2008. Constantemente trabaja en Internet Information Services, SQL Server, Business Intelligence y aplicaciones en visual studio .net, Reporting Services, Minería de datos, Analysis Services.

Es también escritor de varios artículos sobre tecnologías Google, Microsoft, control de calidad de software y desarrollo de aplicaciones, tutor, consultor sobre tecnologías de Microsoft y conferencista.

Trabajó en consultorías, artículos tecnológicos, clases, conferencias, tutoriales, alianzas y outsorcing para empresas nacionales como internacionales.


Certificaciones obtenidas:
  • Microsoft Certified Professional
  • Microsoft Certified Technology Specialist
  • Microsoft Certified Database Administrator
  • Microsoft Certifed Trainer
  • Microsoft Technology Associate
  • Microsoft Certified IT Professional

Reconocido por Microsoft como Microsoft Most Valuable Professional

Hace poco menos de una semana tuve la oportunidad de reunirme con Daniel y realizar una muy interesante entrevista, por desgracia no venía preparado con una reportera, por lo que no me queda de otra que resumir el contenido de dicha entrevista a continuación:
Introducción previa a la entrevista.
Amistad forjada en el transcurso de los años:
Tuve el grato placer de trabajar con él en dos  ocasiones en diferentes empresas, por lo que forjamos un grupo muy lindo de amistad entre todos los ex trabajadores de ambas empresas.
Trayectoria de sus últimos años:
A continuación resumiré sus últimas actividades en Cochabamba.
Cinco años de trabajo en una de las empresas más grandes  de Outsorcing en Bolivia, Jala Industries donde se forman prestigiosos profesionales bolivianos en el área de Ingeniería de Calidad, contando con un diplomado en la Universidad Simón y Patiño, así como también un instituto tecnológico de preparación en las diferentes tecnologías Microsoft.(En total estuvo 10 años en esta empresa ya que él fue uno de los primeros trabajadores cuando se inició en Cochabamba).
También formo su blog sobre diferentes artículos geeks de tecnologías de la información que aporta bastante a la comunidad boliviana y por qué no decirlo al mundo entero, una muy importante página que va creciendo a pasos gigantescos, recomiendo que le den una mirada. http://elpaladintecnologico.blogspot.com
En el ínterin de Jala trabajo un par de años en una empresa nacional de consultoría de sistemas llamada Intersoft, para conocer un poco de esta empresa pinchar en el siguiente link www.intersoft.com.bo
A parte de destacarse en el mundo de Quality Assurance por varios años, dio clases en diferentes instituciones conocidas como Tekhne e  ITA (Parte de la fundación de Jala industries)
Ahora se dedica de lleno al área que lo apasiona Business Intelligence (El mundo oscuro del DW especializado en Microsoft--SQL), trabajando como consultor de Iporject Partners en la ciudad de Santa Cruz de la Sierra con uno de sus primeros clientes , una de las más renombradas empresas de telecomunicaciones TIGO.
Resumen de la Entrevista:
*Nota.- El contenido de esta entrevista no está narrada literalmente con las palabras y frases que se utilizaron en dicho momento; cuenta tan solo con el resumen de todos los puntos que se tocaron.

-          Edward: Dani realmente me sorprende verte (estoy seguro que no soy el único al que le sorprendió de sobremanera) en Santa Cruz, no creía que te animaras a dejar a tu familia y amigos en Cochabamba donde te veía muy arraigado, más aun cuando no hace mucho contrajiste nupcias, te preguntare lo primero que me da mucha curiosidad, como así te animaste a dejar Jala?.
-           
      Daniel: Jalasoft es una excelente empresa donde aprendí muchísimo y no me canso de agradecer sus conocimientos y su trato. Pero yo necesitaba trabajar full time en BI y tuve que cambiar de rumbo. En Jala el fuerte es la Ingeniería de calidad, y como en casi ninguna empresa de TI en Bolivia existe el  desarrollo de BI como tal, yo quería meterme a fondo en esa área y como no habían proyectos de ese tipo en Jala, tome la decisión de retirarme; creo que eso fue mi principal motivo
-           
      Edward: Sé que te mudaste para ejercer lo que tanto te gusta y vienes enseñando hace tiempo atrás, el mundo oscuro de BI, como es que elegiste formarte en esta área siendo que practicabas una totalmente diferente, la de QA.
-           
      Daniel: En Jala tuve la oportunidad de participar en un proyecto donde teníamos que realizar consultas a un DW por lo que me abrió más la curiosidad yo no solo quería explotar la BD del DW también quería entender y crear por mi propia cuenta un DW, así es como comenzó todo.
-           
      Edward: Que fue lo primero que querías hacer después de dejar Jala, que proyecto tenías?
-           
      Daniel: Comencé realizando proyectos en forma independiente, como cuento con el reconocimiento de MVP, me contactaron los chicos de Microsoft para los que me ofrecieron ayudar a escribir un artículo sobre BI, además de continuar dando cursos y seminarios tanto en Santa Cruz, Potosí  y Cochabamba, y unos cuantos otros proyectos referentes  al paladín tecnológico.
-           
      Edward: Cuan difícil es para ti separarte de toda tu familia y círculo de amistades en Cochabamba?
-         
            Daniel: Extraño muchísimo a mi esposa. También fue difícil el dejar a mis padres, ya que soy por el momento el único hijo que se encontraba con mis padres en Cochabamba, todos mis hermanos se encuentran radicando en el exterior, a mí personalmente no me atrae mucho el tema de vivir fuera del país; pienso que acá tenemos más posibilidad de vivir en mejores condiciones, como ejemplo una vez un taxista me comento que vivió muchos años en España, al retornar a Bolivia a lo mucho con todos sus ahorros se pudo comprar una casa medianamente humilde y dos taxis uno de los cuales el mismo lo trabaja. 
     
      Edward: Escuche que tenías planes de ser independiente, como te animaste a formar parte de IProjects Partners?

-          Daniel: Al dejar Jala comencé a trabajar en forma independiente, pero me di cuenta que el lograr mis objetivos de forma independiente costaba demasiado tiempo por lo que pienso que con ellos cortare camino, cumpliré mis objetivos en menos tiempo.


Éxitos Dani en tu nuevo emprendimiento!!. Es bueno acrecentar cada vez un poco más la colonia cochabambina en la ciudad de las oportunidades, Santa Cruz de la Sierra.


jueves, 15 de marzo de 2012

Técnicas de Estimaciones

Algunos tips para realizar las estimaciones que me parecen de mucha ayuda en los equipos de desarrollo:
Consiste en estimar sacando la media de los valores mas pesimistas y optimistas del esfuerzo que conlleva una determinada tarea, acontinuación la descripción de la formula PERT.
  • Más probable (tM). Es la duración de la actividad, en función de los recursos que probablemente se asignarán, de su productividad, de las expectativas realistas de disponibilidad para la actividad, de las dependencias de otros participantes y de las interrupciones. 
  • Optimista (tO). La duración de la actividad está basada en el análisis del mejor escenario posible para esa actividad. 
  • Pesimista (tP). La duración de la actividad está basada en el análisis del peor escenario posible para esa actividad.
El análisis según el método PERT calcula una duración Esperada (tE) de la actividad utilizando un promedio de estas tres estimaciones:
                                                              tE = (tO + 4tM + tP) /6

Otra de mis tecnicas favoritas de Agile es el "planning poker" el cual se basa en la estimación del equipo en su conjunto, donde se ponderan las tareas con la serie de fibonaci: 1,2,3,5,8,13
Cada miembro realiza la votación correspondiente a cada una de las tareas del sprint planning, donde se toma el valor que tenga mas coincidencias por el equipo si es que este valor discrepara mucho, entonces se defienden los valores mas bajos con los valores mas altos cada miembro defiende su punto de vista con los argumentos necesarios para su estimación, de esta forma se llega a un consenso para poder tener una estimación lo mas realista posible.

Un ultimo meto que me aconsejaron recientemente es el de el de la tarea que se lleva al centro de la mesa. Consiste en ir elijiendo una tarea al azar y ver uno tras otra de las tareas comparadas con la inicialmente elejida, con el fin de ponderar sus esfuerzos, esto tambien haciendo uso de la serie de fibonaci.

Espero que estos metodos le sea util al momento de estimar y ponderar las tareas en cada ceremonia de planificacion dentro su proyecto (Una de las  mas polemicas tareas dentro un proyecto :) ).

Suerte!!