¿Empleado o Emprendedor?

Llamarse emprendedor en la web es un especie de moda en la que te sientes parte de por el hecho de tener un blog, cuentas en redes sociales, escribes sobre ello y promueves el emprendimiento. Pero en la realidad muchos actuamos como empleados devengando un sueldo mensual y dejando nuestro emprendimiento en segundo plano.

Muchas personas en la web me sirven de referencia pero muy pocas me inspiran por lo que escriben desde el “yo pienso”. Está semana fue de gran inspiración leer el artículo de Emplear Empleados, Asociar Emprendedores de Damian Voltes en donde realiza un análisis sobre el perfil del empleado y el emprendedor. Además, el cuchillo en los dientes me hizo reflexionar sobre la probabilidad de éxito de un Startup.

Perfil del empleado

Dialogando con el artículo de Damian saco algunos puntos para definir el perfil del empleado en este medio. Dejo claro que faltarán muchos aspectos para crear un perfil completo porque depende mucho de la empresa y el trabajo.

• Personas que buscan trabajar para una empresa y desarrollar su carrera profesional.
• Establecen una relación de dependencia que garantice un sueldo mensual.
• Buscan aumentos salariales a través de bonos y crear carrera profesional para su curriculum.
• Les gusta tener horarios establecidos y que les den instrucciones específicas de cómo hacer las cosas.
• Puede demostrar lealtad por años siempre y cuando se sienta cómodo con el sueldo, ambiente de trabajo e incentivos.

Perfil del emprendedor

Hemos hablado que trabajar en una Startup requiere un cambio de actitud y que existen diferencias entre los trabajos normales y el emprendimiento de crear tu propia empresa. Para comprenderlo mejor también debemos reflexionar en el perfil del emprendedor que crea la empresa y el emprendedor que se asocia a ella.

• Personas que desean tener su propia empresa.
• 
  
• Amantes de la libertad, lo flexible y obsesionados por dar a conocer sus ideas.
• Les interesa el incremento del valor de sus acciones si forman parte de una empresa.
• Buscan reconocimiento social y que sus ideas sean respetadas.
• Toman riesgos todo el tiempo y se lanzan a lo incierto.
• No les importa integrar personas a su equipo y compartir sus ideas con ellas si eso ayuda en sus propósitos de alcanzar sus metas y desarrollo de proyectos.
• Si trabaja en una empresa en cualquier momento se puede ir porque no le importa cambiar de dinámica. Necesitan cambiar el rumbo hasta sentirse satisfechos.

Las aspiraciones personales

Considero que todos tenemos aspiraciones personales y que trabajamos en pos de ellas, sin embargo aveces perdemos el rumbo o simplemente no somos congruentes con lo que deseamos y hacemos. En lo personal tengo muchas cosas para mejorar, soy una persona que necesita cambios constantes y desarrollarme en el campo creativo.

Pero debemos aceptar que el emprendimiento requiere mucho valor, empuje, positivismo, dinamismo y disponibilidad. Es por ello que es fácil dejarse seducir por la estabilidad financiera que nos brinda una empresa. Sin embargo, lo que les recomiendo a los emprendedores que trabajan en una empresa es revisar las posibilidades de ser parte de ella y seguir trabajando en lo que les gusta. ¿empleado o emprendedor?

Original: MaestrosDelWeb

Gmail no es más beta

Después de más de cinco años en versión Beta, GMail de Google dejó de ser Beta.

Google afirma que su servicio de mail y otras tres aplicaciones de la suite de Google Apps, ahora son productos oficialmente terminados. En tanto, eso no significa que Google va a parar de perfeccionar las herramientas, ni que las actualizó en esta fecha.

En verdad salir de Beta significa poco en la práctica. ¿Por qué el cambio entonces? Para Google la novedad es más para atraer nuevos usuarios corporativos mas que una evolución de los aplicativos. La versión principal de Google Apps cuesta U$S 50 por usuario para clientes corporativos, los cuales tienen derecho a herramientas como acceso offline y soporte de 24horas los siete días de la semana.

"Muchas empresas que analizaron las aplicaciones las consideraron terminadas", dice Rajen Sheth, gerente de produto del gigante de las búsquedas. "Aunque había un factor abstracto de percepción en relación a la versión Beta que hacía que algunos clientes corporativos quedaran afuera".

Google Calendar, Google Docs y Google Talk no son mas programas en versión beta. Otras aplicaciones no incluidas en la suite de Apps - como o Google Scholars -va a permanecer en beta.

Original: DosIdeas

Google anuncia su propio sistema operativo

Ayer Google anunció que está desarrollando un sistema operativo para PC, fuertemente ligado a su navegador web Chrome. Con el nombre "Google Chrome Operating System", el sistema está pensando para computadoras portables pequeñas (las llamadas "netbooks"), que se están vendiendo cada vez más. Google dice que su software también podría servir para PC de escritorio completas.

El anuncio oficial de Google

Han pasado nueve meses desde el lanzamiento del navegador web Google Chrome. Ya hay más de 30 millones de personas que lo usan a diario. Diseñamos Google Chrome para las personas que viven en la web - buscando información, bajando emails, leyendo noticias, realizando compras o manteniéndose en contacto con amigos. Sin embargo, el sistema operativo sobre el que funcionan los navegadores fueron diseñados en una época donde no existía la web. Entonces hoy estamos anunciando un nuevo proyecto que es una extensión natural a Google Chrome - el Sistema Operativo Google Chrome. Es nuestro intento de re-pensar cómo deberían ser los sistemas operativos.

Google Chrome OS es un sistema de código abierto liviano que inicialmente estará enfocado a las netbooks. Más tarde este año estaremos liberando el código, y ya en la segunda mitad del 2010 habrá netbooks en el mercado funcionando con Google Chrome OS. Como ya estamos hablando con socios sobre este proyecto, y pronto estaremos trabajando con la comunidad de código abierto, queríamos compartir nueva visión hoy, para que todos comprendan lo que intentamos lograr.

Velocidad, simplicidad y seguridad son aspectos clave en Google Chrome OS. Estamos diseñando el OS para que sea rápido y liviando, que inicie y deje disponible la web en unos segundos. La interfaz de usuario es mínima para que no interfiera, y la mayor parte de la experiencia del usuario ocurre en la web. Como hicimos con el navegador Google Chrome, estamos volviendo a las bases y rediseñando completamente la arquitectura subyacente de seguridad del OS, para que los usuarios no tengan que preocuparse por los virus, malware y actualizaciones de seguridad. Simplemente debería funcionar.

Google Chrome OS funcionará tanto en chips x86 y ARM, y estamos trabajando con múltiples OEMs para que el año próximo ya estén disponibles varias netbooks en el mercado. La arquitectura de software es simple - Google Chrome funcionará con un nuevo sistema de ventanas sobre un kernel Linux. Para los desarrolladores de aplicaciones, la web es la plataforma. Todas las aplicaciones basadas en la web funcionarán automáticamente, y se pueden escribir nuevas aplicaciones usando las tecnologías web favoritas. Y por supuesto, estas aplicaciones no sólo funcionarán en Google Chrome OS, sino también en cualquier navegador basado en estándares sobre Windows, Mac y Linux, dándole a los desarrolladores la mayor base de usuarios de cualquier plataforma.

Google Chrome OS es un proyecto nuevo, independiente de Android. Android fue diseñado para funcionar sobre varios dispositivos, desde teléfonos a netbooks. Google Chrome OS está siendo creado para personas que pasan la mayor parte de su tiempo en la web, y está diseñado para funcionar en distintas computadoras, desde pequeñas netbooks hasta sistemas de escritorio completos. Aunque hay algunas áreas en donde Google Chrome OS y Android se solapan, creemos que la posibilidad de elegir generará innovación con beneficios para todos, incluyendo a Google.

Escuchamos mucho a nuestros usuarios y su mensaje es claro - las computadoras necesitan mejorar. La gente quiere recibir instantáneamente sus emails, sin perder tiempo esperando que sus computadoras inicien y luego lanzar el navegador web. Quieren que sus computadoras siempre funcionen igual de rápido que cuando las compraron. Quieren que sus datos estén accesibles sin importar si pierden la computadoras o se olvidan de hacer copias de seguridad. Más importante aún, no quieren gastar varias horas configurando sus computadoras para que funcionen con cada nueva pieza de hardware, o preocuparse por las constantes actualizaciones de seguridad. Y cada vez que nuestros usuarios tienen una mejor experiencia con sus computadoras, Google se beneficia por tener usuarios más contentos que están más dispuestos a pasar tiempo en la Internet.

Tenemos mucho trabajo por hacer, y definitivamente vamos a necesitar mucha ayuda de la comunidad de código abierto para lograr esta visión. Estamos entusiasmados por lo que viene y esperamos que también lo estén ustedes. Estén atentos a más novedades en el invierno, y pasen un excelente verano.

Original: DosIdeas

Ágil expone los problemas para escalar

Uno de los primeros temas que suele aparecer en cualquier discusión sobre Ágil es "¿Qué tanto se puede escalar Ágil?". A veces se pregunta de forma explícita, pero a menudo se parte del supuesto de que Ágil no puede escalar muy bien. Cuando me encontré con Ágil por primera vez, mi primera impresión fue que Ágil no escalaba más allá de equipos chicos, digamos de 12 personas.

Intentaba resolver este tema desde el principio, pero luego me di cuenta que había algo más detrás. Veamos el escenario completo. ¿Qué estamos asumiendo del desarrollo tradicional? Creo que todos llegamos a esta discusión pensando en equipos de 100 ingenieros, 500 ingenieros, incluso 2000 ingenieros trabajando con desarrollo tradicional, y que por lo tanto el desarrollo tradicional funciona de manera probada en cuanto a poder escalar. Pero primero respondamos esta pregunta: "¿Qué tan bien escala el desarrollo tradicional?".

Para responder a este pregunta primero deberemos definir el término "escalar". Una buena definición es que al agregar nuevos recursos, ocurrirá un incremento lineal en la salida efectiva, si casi ninguna disminución de la eficiencia. Para el software, la salida y la eficiencia se traducen en nueva funcionalidad y en productividad. Esto significa que si tenemos un equipo de 50 ingenieros y añadimos 50 ingenieros más obtendremos el doble de la salida. ¿Pero cuándo fue la última vez que vieron ocurrir eso? ¿Lo vieron ocurrir alguna vez? En mi experiencia, después de hablar con cientos de organizaciones que usaban un desarrollo tradicional de software, al agregar nuevos recursos cae la productividad y por lo tanto la salida no tiene un incremento lineal. De hecho, en muchos casos la salida disminuye al agregar más recursos.

¿Qué hacés para "escalar" tu organización de desarrollo? ¿Actualizás meticulosamente los Gantt y las estimaciones? ¿Planificás montones de reuniones? ¿Pasás mucho tiempo asegurándote que los requerimientos y los diseños sean los adecuados? ¿Reservás el 30% de desarrollo para testing (y arreglo de errores)?

En mi experiencia, después de hablar con cientos de organizaciones, la respuesta a la pregunta "¿Qué tan bien escala el proceso de desarrollo tradicional?" es un "No muy bien". Hace rato que sufrimos este problema, en gran medida porque aunque teníamos el problema, las causas raíces eran dificil de encontrar, y más aún solucionar.

El punto es que si estás implementando Ágil en una organización grande, no te desalientes cuando encuentres problemas para escalar. Los problemas siempre estuvieron ahí, sólo que no eran obvios. Ahora, en vez de preguntarnos porqué las cosas no están funcionando como esperábamos al final de un proyecto, podemos darnos cuenta de problemas concretos, como por ejemplo que nuestra organización no tiene una política para coordinar los cambios en las API que usan múltiples equipos. Como Ágil expone estos problemas, podemos comenzar a tomar medidas para resolver y así crear un proceso de desarrollo más escalable, que también forma parte del desarrollo Ágil.

Original: DosIdeas

NoSQL

Una reunión en San Francisco fue la inauguración de la comunidad de NoSQL, un grupo de personas que comparten la idea de destronar la tiranía de las bases de datos relaciones, costosas y lentas, en favor de una alternativa mucho más eficiente y barata para manipular datos.

"Las bases de datos relaciones nos ofrecen demasiado. Nos fuerzan a adaptar nuestros objetos para adaptarlos a una RDBMS (sistema de gestión de bases de datos relacional)", dice Jon Travis, uno de los principales ingenieros en SpringSource, y uno de los 10 presentadores en la reunión de NoSQL.

Las alternativas basadas en NoSQL "te ofrecen sólo lo que necesitás", dice Travis.
Surge el código abierto

Los primeros precursores son desarrolladores Web y Java, muchos de los cuales aprendieron a llevar adelante sus iniciativas (ajustadas en presupuesto) sin usar Oracle. Para esto construyeron sus propias soluciones para almacenar datos (emulando lo que hicieron Google y Amazon), y luego las publicaron como código abierto.

Hoy estas soluciones gestionan terabytes e incluso petabytes de datos para la Web 2.0, y ya no es factible volver atrás, por motivos técnicos, económicos e incluso ideológicos.

"Las empresas Web 2.0 pueden tomar riesgos y necesitan escalabilidad", dice Johan Oskarsson, el organizador de la reunión NoSQL y, como la mayoría de los participantes, un desarrollador Web (del sitio Last.fm). "Cuando se combinan estas dos cosas, hace que NoSQL sea una muy buena alternativa".

Muchos, dice Oskarsson, dejaron de usar la base de datos MySQL, una favorita de la Web 2.0 por mucho tiempo, en favor de una alternativa NoSQL porque las ventajas eran demasiado grandes para ignorar.

Por ejemplo, Facebok creó su almacen de datos Cassandra para soportar una nueva búsqueda en su sitio web, en vez de usar su base de datos MySQL existente. De acuerdo a la presentación del ingeniero de Facebook Avinash Lakshman, Casandra puede escribir hasta 50GB de datos en disco en tan sólo 0.12 milisegundos, más de 2500 veces más rápido que MySQL.
¿Y qué es NoSQL? (técnicamente hablando)

Los nombres de los proyectos son tan diversos como extraños: Hadoop, Voldemort, Dynomite, y otros. Pero suelen estar unificados por algunos puntos en común, incluyendo:

No llamarlos "bases de datos". Werner Vogels, CTO de Amazon, se refiere a su sistema Dynamo como "un almacenamiento de clave-valor de alta disponibilidad". Google llama a su BigTable, otro de los modelos para muchos simpatizantes de NoSQL, "un sistema de almacenamiento distribuido para gestionar datos estructurados".

Pueden manejar enormes cantidades de datos. Hypertable, una implementación de código abierto basada en BigTable, se usa dentro del motor de búsqueda Zvents para escribir 1000 millones de celdas de datos por día, según cuenta el ingeniero Doug Judd en su presentación.

A su vez, BigTable, en conjunto con su tecnología hermana MapReduce, procesa hasta 20 petabytes de datos por día.

"Definitivamente la cantidad de datos es tan grande que las personas están buscando otras tecnologías", dice Travis de SpringSource, que con su tecnología VPork ayuda a los usuarios de NoSQL a realizar benchmarks de rendimiento de sus bases de datos alternativas.

Se ejecutan en clusters de servidores de PC baratas. Los clusters de PC se pueden expandir de forma facil y barata sin la complejidad y el costo del "data sharding", que involucra recortar una base de datos en múltiples tablas para ejecutarse en grandes clusters o grillas.

Google cuenta que uno de sus clusters de BigTable más grande gestiona 6 petabytes de datos sobre miles de servidores.

"Oracle te va a decir que con el hardware y la configuración adecuada de Oracle RAC (Real Application Clusters) y algún otro software mágico pueden lograr la misma escalabilidad. ¿Pero a qué costo?", pregunta Javier Soltero, CTO de SpringSource.

Superan los cuellos de botella de rendimiento. Al no tener que realizar la traducción de datos hacia un formato amigable para SQL, las arquitecturas NoSQL son mucho más rápidas.

"SQL es un enfoque extraño para el código procedural, y casi todo el código es procedural", dice Curt Monash, un analista independiente de bases de datos y blogger. "El costo de mapear los datos a SQL puede valer la pena para los casos en que estos datos tengan que manipularse extensivamente... pero cuando la estructura de la base de datos es muy simple, SQL no parece ayudar".

Raffaele Sena, de Adobe Systems, dice que Adobe relanzó su servicio colaborativo ConnectNow Web hace un año y medio, y decidió no usar una base de datos por los motivos explicados por Monash.

Adobe usa Terracotta, un software Java para clustering, para gestionar los datos en formato Java. Sena explica que este enfoque es la clave por la cual el rendimiento de ConnectNow es dos a tres veces superior a la versión anterior. "El sistema hubiera sido mucho más complejo y dificil de desarrollar con una base de datos", dice.

Otro proyecto, MongoDB, se llama a si mismo "base de datos orientada a documentos" por su almacenamiento nativo de datos de tipo objeto.

Sólo lo necesario. Quienes impulsan NoSQL admiten que las bases de datos tienen características únicas y una reputación sólida para la integridad de datos, pero explican que todo esto puede resultar demasiado para sus necesidades.

Tomemos por ejemplo a ConnectNow que, incluso sin una base de datos, hace tres copias de los datos de la sesión del usuario mientras está online - datos que luego son borrados cuando el usuario se desconecta, dice Sena. "No necesitamos una base de datos, ya que la mejor representación de los datos ya están en memoria", dice.
Soporte de la comunidad

Por ser de código abierto, las alternativas de NoSQL no suelen tener el mismo soporte que otros proveedores tradicionales. Para la mayoría de los entusiastas de NoSQL esto no es un problema, ya que están acostumbrados a trabajar con enfoques alternativos.

Pero algunos admiten que puede causar miedo trabajar sin "un cuello para ahorcar" cuando las cosas salen mal, especialmente para los gerentes.

"Tuvimos que salir a vender la propuesta", admite Sena de Adobe. "Pero básicamente, después de ver que nuestro primer prototipo funcionaba, pudimos convencer a la alta gerencia que este era el camino correcto".

A pesar de todo el potencial, la mayoría de las organizaciones todavía no necesitan preocuparse por lo que se pierden, dice Monash.

"La mayoría de las organizaciones grandes ya tienen una forma de hacer OLTP (procesamiento de transacciones online), probablemente a través de sistemas de bases de datos. ¿Por qué cambiar?", dice. MapReduce y otros proyectos "puede ayudar a las organizaciones. Pero probablemente debería integrarse a una DBMS analítica".

Incluso Orkarsson, el organizador de NoSQL, admite que su compania, Last.fm, todavía no migró a una alternativa NoSQL, y en cambio usa bases de datos de código abierto. Por ahora, la revolución está esperando.

"Es verdad que hoy NoSQL no es muy relevante para la mayoría de las organizaciones", dice Orkarsson. "Pero esto podría cambiar en los próximos dos años".

Original: DosIdeas

La magia del "Ritmo Sustentable"

¿Qué es un ritmo sustentable? Significa trabajar a un ritmo que podamos sostener con comodidad y ocasionalmente acelerar cuando sea necesario. El Ritmo Sustentable es fácil de definir y difícil de lograr en la práctica.

Básicamente, detrás del Ritmo Sustentable está la pregunta "¿Qué tan bueno soy cuando estoy cansado?".

Y no soy nada bueno cuando estoy cansado. Aunque puedo terminar cosas cuando estoy cansado, no trabajo ni con eficiencia ni con eficacia. Pierdo el tiempo. Hago las cosas con desgano, y mi trabajo no tiene mucha calidad.

Si me acostumbro a trabajar consistentemente a un ritmo no-sustentable, gasto varias horas no-productivas por día haciendo poquito. Mi atención se va hacia páginas web, la ventana del chat, el teléfono, el e-mail, alguna revista. Y sin embargo este tiempo perdido no es lo que Tom DeMarco llama "Holgazanear". Holgazanear, distraerse, es saludable, es algo bueno. Cuando trabajo demasiadas horas, el tiempo que gasto alejándome de mi trabajo es el resultado de mi mente y mi cuerpo que se rebelan en contra de un ritmo no sustentable.

La eficiencia es el enemigo de la efectividad - Tom DeMarco en Slack.

Jerry Weinberg dejó algo muy en claro en su charla en una conferencia Ágil: para ser un profesional debemos cuidarnos a nosotros mismos. "Cuidarse a uno mismo", dijo jerry, "significa cuidarse de forma completa - cuerpo y mente".

Quizás eso necesite de coraje. Si tu organización valora a las personas que definitivamente no trabajan a un ritmo sustentable, podrías necesitar coraje para trabajar a un ritmo sustentable. Podrías perder el trabajo. O, podrías ser tan productivo que nadie cuestione tu dedicación o tus logros.

Cuando trabajo a un ritmo sustentable tengo energías para trabajar de forma eficiente y efectiva, tengo tiempo para pasarlo con mis amigos y familia, tiempo para ejercitarme, incluso tengo tiempo para reflexionar sobre mi trabajo y logro una genuina satisfacción por mi productividad.

Cuando me comprometo a trabajar a un ritmo sustentable, soy consciente que no voy a divagar durante las horas de trabajo, ya que no voy a tener más horas a la tarde para compensar el tiempo perdido. Comprometerse a esta práctica significa enfocarse durante las horas de trabajo, y para mi (y muchos otros) la forma más fácil de enfocarse es trabajar en parejas con otra persona. Después de varias horas de trabajar de a pares, generalmente termino contento con mi productividad y me voy contento a casa, a tiempo.

Se necesita tiempo y práctica para dominar al Ritmo Sustentable. Dense tiempo para aprender este práctica. Observense mientras experimentan. Seguramente encontrarán que son mejores profesionales cuando su ritmo es sustentable.

Original: sustainablePace

HTML 5 y Multimedia

Una de las novedades más destacadas de la nueva especificación del lenguaje de marcado para la web es el soporte nativo de elementos de vídeo. Probablemente HTML 5 dará lugar a una batalla entre los formatos multimedia en Internet afectando a tecnologías existentes como Flash, Silverlight o Java FX. Uno de los objetivos de HTML 5 es, precisamente, rellenar el hueco que los plugins propietarios están intentando cubrir. De esta forma se dispondría de un estándar abierto capaz de acabar con la dependencia de plugins de terceros o propietarios que, por ejemplo, han tardado más tiempo en implementarse para GNU/Linux.

¿Ustedes que opinan?

Articulo Original: Barrapunto

3 Maneras de Reducir el alcance

La forma más común para que los equipos entreguen productos más rápido es reduciendo el alcance de cada producto. Sin embargo, esto no puede hacerse de manera arbitraria. Hay motivos de negocio reales para cada una de los requerimientos que se piden (¡o al menos eso esperamos!).

Bob Hartman nos cuenta 3 formas básicas por las cuales los equipos pueden reducir el alcance de manera exitosa.

Cómo reducir el alcance

Para lograr que un equipo entregue 50% más rápido se puede:

1. Entregar 50% menos de requerimientos.
2. Entregar todos los requerimientos pero con un 50% menos de detalles en cada requerimiento.
3. Entregar todos los requerimientos con distinto nivel de detalle en cada requerimiento.

Veamos en detalle de qué se trata cada estrategia.

Entregar 50% menos de requerimientos

La explicación es obvia, y es la más facil de implementar. Como las metodologías ágiles usando un backlog priorizado de trabajo, el Dueño del Producto puede hacer que el equipo trabaje en órden de prioridad hasta que se haya entregado el suficiente valor para hacer una entrega razonable. El peligro acá es no ser lo suficientemente agresivo sobre cuánto es suficiente. La mayoría de los Dueños de Producto todavía caen en la trampa y agregan más características al producto aunque el mismo ya pueda entregarse. Supongo que esto ocurre porque los Dueños de Producto son conservadores por naturaleza.

Nuevamente, este método es simple y efectivo, excepto cuando los equipos de ventas y marketing "prometieron" características que están con baja prioridad en la lista. Si un equipo entrega 25 de las 26 características prometidas, el cliente podría enojarse. Si entrega estas mismas 25 características cuando se habían prometido sólo 20 van a ser felicitados como héroes. ¡Hay que ser muy cuidadoso con los compromisos externos para poder cumplirlos!

Entregar todos los requerimientos pero con un 50% menos de detalles en cada requerimiento

Esta es un poquito diferente. Evita el problema del método anterior porque se entregan todos los requerimientos. Este método se basa en el hecho de que el 64% de las características se usan poco o nada (según el estudio de Standish Group). Para poder entregar un 50% más rápido, se debería eliminar en promedio el 50% de cada requerimiento, e igualmente no dañaríamos el "núcleo" del software, el cual será usado la mayor parte del tiempo.

La desventaja es que se trata por igual a cada requerimiento, y es probable que recortemos demasiado en algunos requerimientos, y no lo suficiente en otros. Lo que nos lleva al método final...

Entregar todas los requerimientos con distinto nivel de detalle en cada requerimiento

Con este método se desarrollan por completo los requerimientos de mayor prioridad, mientras que los menos importantes se construyen sólo lo suficiente como para poder decir que funcionan bien. Los requerimientos en el medio de los extremos van teniendo cada vez menos características y detalles a medida que disminuye su prioridad. Esto permite que los requerimientos más importantes sean más útiles, y las características menos importantes terminan siendo las menos útiles. Esto salva el problema del primer método ya que se entregan todos los requerimientos, y también supera los problemas del segundo método porque se entrega el máximo valor para los elementos de mayor prioridad.

Conclusión

El primer método se encarga de "cortar" el alcance de manera horizontal (una línea horizontal a través del backlog, mostrando el último requerimiento que se desarrollará). El segundo método corta de forma vertical (una línea vertical por el backlog, mostrando cuánto se desarrollará comparado con el máximo). El tercer método corta de forma diagonal (una línea diagonal hacia la derecha, mostrando cuánto se va a desarrollar de cada elemento del backlog). El primer método es el más común, pero es muy real el problema de dejar afuera características ya prometidas. El último método es superior, pero también el más dificil de lograr.

El último método puede lograrse creando una pequeña parte de cada requerimiento durante las primeras iteraciones. De esta manera el Dueño del Producto sabe que se podrían entregar todas las características en algún momento futuro, si los detalles no importaran. En ese punto el Dueño del Producto puede priorizar cuánto tiempo y esfuerzo quiere aplicarle a cada requerimiento, y así va creando el nivel de detalle apropiado - y como siempre, con la libertad de cambiar prioridades si así conviene.

Es común caer en la trampa de pensar que se necesitan todos los requerimientos para entregar el producto. Si se logramos establecer las expectativas de manera correcta, podremos ver que es muy raro que ese sea nuestro caso.

Articulo Original: DosIdeas

Incursionando en el inhóspito mundo de Ajax el boom de la web 2.0

Conoces sobre esta herramienta o tecnica moderna pero no nueva en el mundo web. Para los curiosos, les dejo una breve introducción.

AJAX, acrónimo de Asynchronous JavaScript And XML

JavaScript asíncrono y XML : es una tecnica para el desarrollo de aplicaciones web mas interactivas lo cual permite tener mejor velocidad y usabilidad de aplicaciones web. Se trata de interactuar mas con el cliente de forma que teniendo una comunicacion en segundo plano con el servidor y asi poder recargar o actualizar parte de nuestra web (modulos, bloques, consultas, etc) sin necesidad de que el navegador o cliente refresque toda la pagina.

Ajax aunque recibe dicho nombre en el 2005 tiene antecendes un tanto historicos se remonta a 1993 cuando el nevegador iexplorer 3.0 implementa el elemento iframe y el netscape 4.0 implementara el elemento Layer, por que se dice que podian lograr efectos tipo ajax con estos elementos? simple los dos poseen el atributo src lo que permitia capturar cualquier url externa y a su ves ejecutar codigo javascript dandole un toque de efectos ajax.

Elemento importante en el entorno Ajax es la interfaz XMLHttpRequest, Creada por microsoft cuando por primera ves se uso mediante un objeto ActiveX, seguido en el 2002 Mozilla implemente en la V1.0 de su navegador dicha interfaz es usada de enviar o hacer peticiones HTTP y HTTPS a un determinado servidor web y asu ves para la codificacion de los datos enviados pueden usar cualquiera basada en texto, incluyendo: texto plano, XML, JSON, HTML.

Luego les contare mejor mis experiencias con ajax, por los momentos estoy trabajando en la integracion de joomla con ajax pero mi intencion basicamente no es integrar al 100% joomla(CMS) con interaccion ajax debido a que una web totalmente bajo dicha interfaz podria ser un tanto confusa dependiendo de la manera como se implemente.

Referencias: Wikipedia

blooper : Wikipedia Say: Encarta no te llevo nada.
Encarta Say: Ya me ganastes lo admito T_T.

JSON vs XML

Cual de estos dos Formatos crees que es mejor para el intercambio de datos al momento de usar XMLHttpRequest y Ajax.?




! uno no nace con la ignoracia, uno la desarrolla y despues tu mismo culpas a otros por lo q tu mismo desarrollastes piensa asi no tengas idea. Razonar es bueno para la salud xD ¡

¿Cómo hacer para ser más atractivo para las empresas en estos tiempos de crisis?

Nuestra vocación profesional es una de las variables que más debemos tener en cuenta a la hora de pensar en ideas para mejorar. Y es que en nuestro trabajo pasamos la mayor cantidad de horas del día, es la fuente de nuestros recursos económicos, pero más importante aun, es también fuente de satisfacción o insatisfacción de muchos que se sienten que han triunfado o también fracasado según sea el caso.

Es por ello que conviene estar siempre atentos de cómo trabajar mejor, como ser más productivos. De esto dependerán nuestros ascensos, nuestra línea de carrera y en algunos casos nuestro nivel de recompensa personal y económico.

Las empresas se han vuelto más exquisitas para reclutar personal, antes bastaba con terminar en una universidad o instituto de cierto prestigio y tener experiencia, pero ahora el factor crucial para tomar la decisión de contratación ya no será su formación académica o su experiencia sino sus capacidades relaciones.

¿Qué se exige en los profesionales hoy en día?

Que el profesional tenga habilidades o competencias y valores. En cuanto a las competencias, las hay de muchos tipos, pero para efectos prácticos las clasificaré en dos, las personales y las sociales. Dentro de las personales están incluidas el orden, pero no el orden para tener el escritorio ordenado, sino el orden mental para priorizar las cosas en tu vida, a qué le da uno mayor importancia, saber cuando hacer primero lo importante y cuando lo urgente, cuando adaptarse a la realidad (muy útil en tiempos de crisis). Otra de las competencias es la capacidad de las personas para tomar decisiones, saber negociar, liderazgo y pensamiento estratégico (ver el panorama completo, a mediano y largo plazo). Los exitosos lo son porque no sólo están en “el aquí” y “el ahora”. Están pacientemente dando pasos firmes en la dirección correcta.

En relación a las competencias sociales, las más importantes son la red de contactos que hayamos tejido, la capacidad para manejar eficazmente conflictos, trabajo en equipo e inteligencia emocional (capacidad para conocer tus emociones, desarrollarlas y controlarlas y conocer las de tu interlocutor, entenderlas y actuar en consecuencia). La relación con los demás es muy importante, ya sea con compañeros de trabajo, subordinados o jefes. Se debe tener la capacidad para generar empatía con los demás a pesar de problemas internos. Muchas veces se tiende a pensar que el jefe tiene que tratar como capataces al equipo que tiene a cargo para imponer respeto. Nada más falso. Un jefe que dice que es el jefe es una mala señal, implica que el liderazgo en ese jefe ya está por los suelos. Debe ser capaz de gestionar la impopularidad de decisiones correctas pero a veces difíciles de tomar. Debe utilizar un liderazgo sustentado en la intuición y creatividad.

Otro de los valores principales que debe tener es la humildad, valor que maneja bien el fracaso y maneja bien el éxito. Humildad para pasar la página del éxito con rapidez y de igual forma, en tiempos de crisis, tener la automotivación para ver oportunidades. Cuando cometen errores, aprenden de ellos, alzan el vuelo y siguen caminando. Y cuando parece que les van bien las cosas no se lo creen demasiado. El torpe es el que cree que nunca se equivoca. El inteligente es el que se da cuenta cuando se equivoca, pero más inteligente cuando lo corrige, y más aun cuando pide disculpas. No se “comparan con”, sino que “quieren aprender de”.

También buscan gente optimista, sobre todo en estos tiempos en los que la mayoría se lamenta de la crisis. Es ahora cuando hay que ver el vaso medio lleno. Normalmente este tipo de gente tiene muy buen humor. El humor es el que te evita caer en la desesperanza. El humor realmente te salva de la depresión. No se trata de contar chistes, sino de tener la capacidad de reirse de si mismo, de no creerse superman, de reconocer que es capaz de todos los errores y los horrores posibles, porque interiorizando eso, estarán alertas para no cometerlos.

Se busca también una persona que tenga claras sus prioridades y metas en la vida. Que tenga un plan de vida definido. Si bien es cierto dicen que el hombre propone y Dios dispone. Sin embargo, nos encontramos a veces con gente que tiene planificada al milímetro su vida, y cualquier giro lo hace angustiarse demasiado. Por el contrario, otros van por donde se los lleve el viento. Miguel de Unamuno decía: “Nada de plan previo, que no eres edificio. No hace el plan a la vida, sino que ésta la traza viviendo. No te creas más, ni menos, ni igual que otro cualquiera, que no somos los hombres cantidades. Cada cual es único e irrepetible, en serlo a conciencia pon tu principal empeño.”

En el fondo, creo que es muy importante tener un Norte, un plan de vida definido, pero a la vez tener la flexibilidad para adaptarse a los tiempos. ¿Por ejemplo, quién se iba a imaginar hace un año que el mundo estaría como está hoy en día sumido en la peor crisis financiera en más de 70 años? Ayudará bastante que el hoy lo aprovechemos el máximo. Hay una corriente muy fuerte de aprovechamiento del tiempo, que le llaman “Time Management”. En la medida que aproveches al máximo tu tiempo hoy, te estarás asegurando el éxito del mañana. Ten en cuenta que los días perdidos no vuelven, y al final del trayecto los echaremos de menos.

Artículo Original: DosIdeas