jueves, 27 de septiembre de 2012

Trabajo en equipo (desde mi perspectiva)




El trabajo en equipo, consiste en realizar una tarea específica, por medio de un grupo de personas, que conforman, a su vez, un grupo de trabajo. Es primordial en el trabajo en equipo, la unión y empatía entre los integrantes. Ya que en más de una oportunidad, será necesario comprender a otro integrante y, asimismo, apoyar las distintas ideas que vayan naciendo con el desarrollo de la tarea en cuestión.(http://www.misrespuestas.com/que-es-el-trabajo-en-equipo.html)

Con esta definicion la cual me gusto mucho viene acompañado lo siguiente:

Objetivos
Todas la personas que trabajan como equipo deberían tener claro los objetivos, en muchas partes lei que las metas son lo más importante a un integrante del equipo, para mí la verdad es como decir el equipo es importante pero si pasa algo con un integrante de mi equipo no me importa ya que tengo que llegar a mi meta, a primera vista para mí no es un equipo (repito para  mi perspectiva) . Si bien pasa algo con una persona de mi equipo como equipo que somos todos debemos llegar a la meta.

Cuando se refleja un trabajo en equipo me hace recordar a varias cosas por ejemplo cuando un equipo militar sale a a una misión  todos saben cuál es su objetivo, pero también saben que para lograr el objetivo deben estar juntos apoyándose, cuidándose porque si  solo una  personas del equipo sobrevive no hará nada acá no hay personajes tipo rambo que matan a todo un ejército por si mismos. Ahora si por x o y razón una persona del equipo cae  el alguna misión el equipo tiene el deber y responsabilidad de llegar al objetivo pero siempre tratando de que todos lleguen juntos a la meta.  

El trabajo en equipo es la habilidad de trabajar juntos hacia una visión común. Es el combustible que le permite a la gente común obtener resultados poco comunes.”
-Andrew Carnegie

Compromiso
El compromiso es la responsabilidad que un equipo tiene para lograr un objetivo. Cada miembro se compromete a aportar lo mejor de si mismo, a poner todo su empeño en sacar el trabajo adelante 
Como pueden ver hay dos tipos de compromiso uno a nivel personal donde la persona da la palabra para poder realizar tareas (principios de la persona).Luego se tiene compromiso a nivel de equipo el cual fue aceptado en un momento dado ya sea de manera forzosa o libre.

Porque indico forzosa, todos sabemos que hay en los lugares de trabajo una asignación y no así una elección. Pero ya sea que sea obligatorio o libre  al llegar a ser un equipo se tiene el compromiso hacia las personas de tu equipo, un ejemplo que muchas veces me encuentro es trabajar sobre horas días feriados, etc  en las cuales un equipo se queda siendo uno como parte del equipo aunque no se tengan tareas adicionales tendría que quedarme por compromiso. Muchas veces este caso de quedarse nunca seda, la gente dice yo termino mis tareas y me voy, esto está mal ya que no se esta trabajando en equipo y la mayoría de los casos de los cuales vi los que se van son los propios managers, team leaders los de arriba esto aunque no lo crean causa una baja impresión al equipo y además en consecuencia sale  el decir  por qué me quedo yo si el responsable como tal no está entonces se pierde el compromiso de equipo.

“La super-estrella no puede ganar el juego solo.”
-En Working Together By James P. Lewis

Comunicación 
Esto es algo muy muy importante ya que en muchos casos siendo equipo y estando juntos en un lugar de trabajo casi a lado prefieren abrir el skipe  u otra herramienta para poder hablar. Me parece un tonto pero hay varias de esas personas (perdón a las personas que se sienten aludidas) .

Sabemos que la comunicación en un equipo es muy importante para los objetivos y tareas que se realizan, en muchos de los equipos solo los de managers, team leaders  tiene la información  que no es compartida a los equipos, con esto no quiero decir que los equipos deban saber todo pero si deberían saber todo de los proyectos en que ellos se encuentran, durante los años de trabajo que tengo he visto que al tener esa información solamente los de arriba pueden pensar que tienen más control, he visto casos en los cuales una persona manager o team leader  va a reuniones en las cuales se alcanza a definir cosas las cuales no son compartidas  después de un tiempo llega un correo en el cual se indica cómo se defino antes……. Como el equipo no tiene esa información porque no fue compartida se presentan problemas que al final pueden ser sub- sanadados pero al ocurrir eso se pierde mucho como equipo.



Una mala comunicación es igual a pérdida

Confianza
Cada persona confía en el buen hacer del resto de sus compañeros. Esta confianza le lleva a aceptar anteponer el éxito del equipo al propio lucimiento personal. Cada miembro trata de aportar lo mejor de si mismo, no buscando destacar entre sus compañeros sino porque confía en que estos harán lo mismo; sabe que éste es el único modo de que el equipo pueda lograr su objetivo.

Al trabajar juntos pueden existir diferencias personales y conflictos inevitables. Construir confianza depende en que los miembros del equipo tengan el coraje de hablarle directamente a la persona que los "molesta", en vez de ir a un jefe para comunicar sus preocupaciones, o incluso no sacar a la luz estos problemas.

Muchas veces como persona que trabaja en un equipo hay que tener el coraje de decir lo que pensamos. Si estamos en desacuerdo, decir "no". Por supuesto, es necesario hacerlo de manera constructiva para que sea efectivo. Cuando alguien en un equipo se guarda su opinión o preocupaciones sobre un tema que está siendo discutido, y luego más tarde viene y dice "Sabía que era una mala idea desde el principio", el resto de los miembros del equipo dice por qué no lo dijiste más antes lo cual en un momento dado es malo.

“Un equipo de trabajo no funcionará si todos sus miembros no son positivos y colaborativos, dispuestos a animar a los demás miembros del equipo cuando sea preciso.”
-Juan Martínez en ¿Sabemos trabajar en equipo?


bueno espero que les guste la imagen de arriba me deespido con el siguiente refran

Al escalar una gran montaña nadie deja a un compañero para alcanzar la cima solo. Tenzing

saludos.




lunes, 24 de septiembre de 2012

Cosas que hay que tomar en cuenta al reportar un BUG


Un tema que está asociado  al campo de quality control  es el reporte de bugs.  En muchos lugares no hay un estándar o en casos más extremos no se tiene el conocimiento de como realizar esta tarea y simplemente  se reporta en base a una explicación vaga que se ve a primera vista, lo cual puede causar muchos problemas en el lado de desarrollo para poder entender lo que el tester quiso decir al reportar el bug. Muchas veces esto puede causar molestias por parte de dev team  y lógicamente puede causar problemas dentro de un equipo y adicionalmente causar retrasos posiblemente estos retrasos no sean de tiempo largo, pero al momento de tener tiempos cortos esto puede llegar a ser algo incomodo y perjudicial para el equipo. Supongo que este escenario pude ser más común en los equipos distribuidos. Ya que se contaría con idas y vueltas y hasta en muchos casos sería necesario realizar una reunión para poder clarificar que quiso informar  el tester al reportar el bug.

Por otra parte muchas de las empresas pueden contar con el software necesario para poder realizar el seguimiento de los bugs reportados, pero tenemos que tomar en cuenta que estos sistemas si bien son útiles  posiblemente no cuenten con los campos necesarios para poder explicar de manera correcta un bug o en el peor de los casos se tengan los campos pero solo se llenen los que el usuario vea útiles por que no se tienen normas definidas o por alguna otra razon.

Hablando con un amigo Dante Villarroel  alias (dantecillo y otro alias mas).Compañero de trabajo sobre el tema le pregunte que campos crees que es necesario en un bug.

El me contesto lo siguiente:

  • Titulo
  • Descripción 
  • Requerimientos (son por ejemplo el ambiente (OS), despues el tipo de instalacion (distributed, full), otras configuraciones adiconales, como ser (User is not a member of domain admins.. etc etc.)
  • Severidad
  • Build
  • Pasos
  • Resultado obtenido
  • Resultados esperado
  • En alguna caso prioridad a lo que enfatizo que el equipo de dev es el que coloca este valor


También investigué más del tema en encontré lo siguiente:


  • Reporter (llenado automaticamente)
  • Producto: 
  • Version: 
  • Componente: 
  • Platform (‘PC’, ‘MAC’, ‘HP’, ‘Sun’ etc.)
  • Operating system ( Windows NT, Windows 2000, Windows XP etc.)
  • Prioridad:
  • Severidad:
  • Estado (llenado automaticamente)
  • responsable: 
  • URL:
  • Resumen:
  • Descripcion:
  • Pasos: 
  • Resultado esperado
  • Resultado actual


Y bueno desde mi perspectiva pienso que tanto Dante como la página amiga en la cual encontré la información tienen datos muy similares lo único que varia serian los datos auto llenados que sino estoy mal Dante también los toma en cuenta pero como algo que ya es automático y que comúnmente no se llena en un formulario por un tester pero que si debería estar.

Recordar también al momento de reportar un bug todo tester debería saber  "Que el desarrollador tiene que ser capaz de reproducir los bugs en su ordenador sin ayuda del tester", una ves que este lo haga entonces como tester sabras que esta realizando un buen trabajo 


Ahora bien como dicen que una imagen vale más que mil palabras y navegando en internet encontré una imagen muy interesante la cual describe todo lo anterior.


 bueno hasta la proxima saludos a todos...............

viernes, 21 de septiembre de 2012

Quality assurance y Quality control

Desde hace mucho tiempo atrás y bueno hasta el momento muchas empresas de mi ciudad y bueno en realidad en varios lugares veo QA (Quality assurance) para poder referirse a las tareas de testing. Y bueno personalmente también puedo decir que conocía QA como tareas de testing ;| .

Después de un buen tiempo entrando a unos cursos se hablo de manejo de equipos y todo el tema entonces en una de esas preguntas salió la palabra Quality assurance .cuando salió la palabra el instructor que daba el curso indico que él conocía Quality assurance pero en otro contexto tambien indico que en su país o en su conocimiento se denominaba Quality Control.

Después pasado un tiempo conseguí material de certificación ISTQB donde se hacía referencia a la diferencia de los mismos términos. Ya después de ver y escuchar esto  me puse a buscar  información sobre el tema  para no quedar mal con migo mismo ejejej.

Ya bueno basta de blablá….

Quality Assurance (QA)
En español aseguramiento de la calidad consiste en monitoreo de proceso de ingeniería de software y los métodos para asegurar la calidad. QA es proactivo ya que trata sobre los procesos y cómo prevenir defectos (por ej.: definición de procesos, entrenamiento, auditorías, etc.)

Concepto 2
El aseguramiento de la calidad (QA), se puede definir como el esfuerzo total para plantear, organizar, dirigir y controlar la calidad en un sistema de producción con el objetivo de dar al cliente productos con la calidad adecuada.

Quality Control (QC)
En español control de calidad es un conjunto de actividades diseñadas para evaluar un producto, la principal tarea es identificar defectos de un producto antes de que esta sea liberada. QC es reactivo, ya que trata sobre los productos y como encontrar defectos (por ej.: testing, revisiones por pares, inspecciones, etc.).

Concepto 2
El control de calidad (QC) son todos los mecanismos, acciones y herramientas que se utilizan para detectar la presencia de errores.

Podría ingresar  varios conceptos pero me parece que estos dan a entender el término en pocas y sencillas palabras.

Por ultimo una imagen que me gusto ya que refleja todo lo comentado:


y por si la dudas la siguiente tabla:

Quality Assurance (QA) y Quality Control (QC)
Criterio Software Quality Assurance (SQA) Software Quality Control (SQC)
Definicion Es un grupo de actividades para asegurar la calidad en el proceso de ingeniería de software, son actividades para evaluar el proceso que produce productos Es un grupo de actividades para asegurar la calidad en el software, estas actividades están orientadas a identificar errores en el producto
Orientacion orientado a la prevencion Orientado a la deteccion
Ejecucion En toda la organizacion Product/proyecto especifico
Actividades
  • Proceso de definicion
  • Proceso de implementacion
  • Auditoria
  • Entrenamiento
  • Revision
  • Ejecucion de test

hasta la proxima

martes, 29 de noviembre de 2011

Certified Scrum Developer

Hola a todos,

hace un tiempo tome el curso de Certified Scrum Developer (CSD) este curso fue dado por Kleer y bueno como representante del mismo estaba "Martin alaimo" http://www.martinalaimo.com/es del cual puedo decir que estuvo muy bueno claro y siempre queriendo mostrar experiencias.

Bueno entrando mas en el tema del curso Certified Scrum Developer la primera parte se hablo de todo el framework de scrum un poco de teoria como :
  • Filosofía de Scrum, Atributos de Scrum,
  • Scrum Framework,
  • Beneficios de Scrum,Roles de Scrum
  • El Product Owner,
  • El Scrum Master,
  • El Equipo,
  • Historias de Usuario,
  • Release Plan,
  • Product BackLog,
  • Sprint BackLog
  • Sprint Planning,
  • Daily Standup Meeting,
  • Sprint Review,
  • Retrospectiva

Metodología de desarrollo secuencial / waterfall

Principio de pareto 80/20 y el manifiesto agil

Scrum

El segundo dia personalmente es el que mas me gusto ya que se enfoco a:
Técnicas de identificación de User Stories, El Product Backlog, User Stories, Estimaciones de Alto Nivel, Release Planning, Taller de Identificación de User Stories ,Técnicas de estimación de Historias, Velocidad, Release Planning, Actividad de Release Planning

Por que me gusto? ya que muchas veces cuando se esta a cargo de un equipo o en su caso se tiene un proyecto es necesario estimar de la mejor manera los tiempos para asi tener un ritmo sostenible lo cual no se toma en cuenta muchas veces.


Introduccion a User story mapping
La técnica de Story Mapping, desarrollada por Jeff Patton


y bueno los 3 ultimos dias se hablo de :
Desarrollo de Software Ágil, programacion en pares, integracion continua,getion visual mediante taskboard,
ATDD / TDD.

ciclo TDD

ciclo atdd

bueno como veran solo queria hacer referencia al curso CSD y los diferentes puntos que se tomaron en cuenta, mas adelante dare una explicacion de todo el proceso Scrum desde mi perspectiva

hasta la proxima. saludos Rudy


sábado, 9 de mayo de 2009

HyperLinkField con 2 parametros

hola a todos,

bueno ultimamente estoy trabajando con asp.net 2005 y bueno tu be un problema para pasar dos parametros por un Hyperlink que se encuentra dentro de un gridveiew, busque en internet y me tope con soluciones chafaz (opciones que no me gustaban mucho) y encontre en otro foro indicando que solo se podia mandar un parametro en fin........., bueno despues encontre una pagina en la cual me dan la clave de como hacer eso sin mas comentarios aqui esta un ejemplo :

primero mostrare lo mas facil pasar un solo parametro :

DataNavigateUrlFields="Idalgo" DataNavigateUrlFormatString="~/formularioweb.aspx?idalgo={0}" HeaderText="Editar"/>


Suponiendo que el valor de Idalgo sea "15": al mostrar wl formularioweb.aspx se mandara en el URL el valor 32 y bueno si quieres lo recuperas o haces algo con ese valor.

formularioweb.aspx?idalgo=15

Hasta ahí todo muy lindo, pero que pasa si quisieramos indicar 2 o más parametros en el mismo link?

para el caso de mandar 2 parametros se hace lo siguiente:

Se debe indicar los nombres de las propiedades en DataNavigateUrlFields, separados por una coma sin espacios, y luego vamos incrementando el indice en la propiedad DataNavigateUrlFormatString.

DataNavigateUrlFields="Idalgo, Idalgo2" DataNavigateUrlFormatString="~/formularioweb.aspx?idalgo={0}&idalgo2={1}" HeaderText="Editar" />

entonces:
Suponiendo que el valor de Idalgo sea "15"
Suponiendo que el valor de Idalgo2 sea "5"
formularioweb.aspx?idalgo=15&idalgo2=5"

espero que les sirva esto bye

viernes, 20 de marzo de 2009

hola,

Despues de tanto tiempo jejeej bueno no actualize las cosas como devia pero ahora lo are talves no con mucha informacion tecnoloagica pero tratare de no perder la frecuencia.

miércoles, 26 de septiembre de 2007

WINDOWS 2008 code name LONGHORN

Consegui la version de windows 2008 beta 3, la instale y me parecio que se instalo rapido y no me pidio mucho requerimiento de harware (bueno eso es por que es para sevidores) pero bueno ... asi como eles contaba empece a probarlo mo hice mucho pero vi muchos cambios.



Bueno no me alcanso el tiempo (trabajo) y para poder ver mas cosas como me baje las guias para leerlas despues. asi que apague mi maquina y la deje nome acuero cuanto tiempo pero cuando la volvia prender ya no me dejaba hacer nada yme mostraba solo dos ventanas la de activacion y creo que de configuracion del server nada de menu inicio nada solo esas dos ventanas. bueno en todo caso me pedia que lo activace pues su tiempo de prueba (30 dias) habia expirado y como no tenia el KEY pense en instalarlo de nuevo busque el key en internet pero no encontre nada asi que vi algunas cosas (entradas) pense en activarla yo mismo busque mas informacion de como activar pero sin resultados finalmente encontre informacion relacionada con windows vista y bueno me ayudo lograr mi objetivo.....
Creo que muchos lo sabran pero aqui les va:
Cuando te aparesca la pantalla de activacion al final de la ventana microsoft te pone un link para ir a la pagina de microsoftlo que tines que hacer es hacer un click en ese link, luego te aparecera una pagina de explorer 7, en direccion coloca c:\windows\system32 esso te permitira ir a la ventana donde se encuentra el DOS.
cscript.exe slmgr.vbs -rearm
en caso de que no puedas abrir el dos y te salga un mensage como
"no enough quota is abailable to process this comand"
dale full permisos al usuario con el que estes es lo mismo con el CSCRIPT.exe
espero que les sirva pucha ya tengo que ir a trabajar nos vemos
Bueno aqui le dejo unos links

Guias step by step (ingles) http://go.microsoft.com/fwlink/?LinkID=90856
Virtual labs de windows http://go.microsoft.com/fwlink/?LinkId=90855