Para eliminar una rama de nuestro repositorio local ejecutaremos el siguiente comando:

$ git branch -d nombre_rama

En el caso de que esa rama contenga trabajos sin fusionar, el comando anterior nos devolverá el siguiente error:

error: The branch 'nombre-rama' is not an ancestor of your current HEAD.
If you are sure you want to <span class="operator"><span class="keyword">delete</span> it, run <span class="string">'git branch -D nombre-rama'</span>.
</span>

Si aún así queremos eliminar esa rama, se puede forzar el borrado de la siguiente manera:

$ git branch -D nombre-rama

En el caso de querer eliminar una rama del repositorio remoto, la sintaxis será la siguiente:

$ <span class="tag expanded">git</span> <span class="tag expanded">push</span> <span class="tag expanded">origin</span> <span class="pseudo">:nombre-rama</span>

Y de esta forma, desaparecerá la rama nombre-rama del servidor.

Fuente:

vabadus.es

Ya os comenté en un artículo anterior que la productividad está de moda. Existen infinidad de aplicaciones que te pueden ayudar a ello. Pero no es menos cierto que no hace falta gastarse un montón de euros en aplicaciones, ni mucho menos. Con papel y lápiz puedes usar la metodología GTD, pero puedes comenzar a usarla de forma gratuita si eres usuario de productos Apple. Aprovéchate de la aplicación Recordatorios de iOS y macOS.

Si bien Recordatorios es una aplicación bastante sencilla para gestionar tareas y listas, nos ofrece una serie de características interesantes de manera gratuita:

• Sincronización de todos nuestros dispositivos Apple través de iCloud.
• Tareas basadas en la localización.
• Compartir las listas y las tareas con otras personas, sean compañeros de trabajo o nuestra pareja.
• Repetición de tareas/recordatorios.

En general, la gestión de nuestras tareas, nuestras obligaciones y compromisos, en la vida es algo más que el uso de recordatorios.

Configuración de recordatorios para GTD

Esta configuración no te llevará más de 10 o 15 minutos. Pero una cosa sí he de decirte, conviene que antes te hayas leído el libro Getting Things Done de David Allen. Si te interesa mi opinión, te digo que la lectura de ese libro no es algo opcional si realmente te interesa conocer y hacer GTD. Otro libro que a mí me ha gustado mucho y que siempre recomiendo es Productividad personal: Aprende a liberarte del estrés con GTD de José Miguel Bolívar.

Pero vayamos al lio. Abre tu aplicación de Recordatorios, ya sea en macOS o en iOS, y comienza a crear las listas. Ya sabes que si estás en Mac solo has de pulsar ?L, y si estás en iOS el icono +. De este modo crearemos las listas que necesitemos. Yo te recomiendo comenzar con una serie de listas GTD estándar, que son estas:

• Bandeja de entrada: En esta lista recopilaremos todas nuestras tareas, las que nos lleguen por mail, teléfono, etc. Aquí es donde cae todo.
• Proyectos/Resultados deseados: Esta lista contendrá todos nuestros proyectos. Te recuerdo que en la definición de GTD, todo lo que necesita de más de 2 acciones para ser completado es un protector, un conjunto de tareas.
• Próximas acciones: Aquí es donde se capturan las acciones siguientes, las tareas que necesitas completar para llegar al resultado deseado.
• @En espera: Esta lista comienza con @, eso es porque es un contexto. Esto es muy importante, ya que muchas tarea se las delegamos a otras personas, o simplemente las ponemos en modo de espera porque no podemos hacer nada con ella de momento, hasta que ocurra algo: que nos llame el taller para recoger el coche, esperar que nos llegue un paquete de Amazon, o que un compañero nos envié un documento.
• Algún día / Tal vez: En esta lista guardaremos acciones o proyectos (conjunto de acciones), que o bien no tenemos nada claros aun, o que no deseamos realizar de momento. Más adelante, en las revisiones, valoraremos si nos ponemos con ellas o no.
• Recordatorios: Cierto es que la mayoría de la gente no usa esta lista, pero a veces viene muy bien para establecer recordatorios de tareas futuras que nos quedan lejos en el tiempo. Por ejemplo los vencimientos de los seguros, pagos de impuestos, etc. Es un modo muy cómodo de que la función de recordatorios nos avise de cuando ponernos con ellas.

Creo que esta es una configuración básica, pero muy eficaz. A través del servicio de iCloud que nos facilita Apple, tendremos siempre nuestras listas y tareas sincronizadas en todos nuestros dispositivos. Incluso si estamos trabajando en un ordenador con Windows, podremos acceder a iCloud.com y gestionar desde allí nuestros flujos de trabajo para ir completando tareas.

Ya os dije al principio del artículo que para poner en practica GTD no era necesario mucho. Ahora bien, si tras probar este sistema ves que te va bien y comienzas a necesitar más funcionalidad o comodidades, quizás sea el momento oportuno para pasarte a aplicaciones más avanzadas como Things o Omnifocus. Mi consejo es que primero te pongas a trabajar, que veas que realmente te interesa esta metodología GTD, y cuando llegues al límite, dar el siguiente paso adquiriendo una aplicación que te costará el dinero. Puedes ir directamente a por ella, claro que sí, pero en ese caso estarás suponiendo que llegarás a ese límite de tu gestión, y lo mismo te aburres, te quedas a medio camino y habrás malgastado tu dinero. Elige libremente.

Mis recomendaciones

Otro consejo que me gustaría darte, creo que es el que te dará cualquier persona que trabaje con GTD, es que una de las partes más importante de todo este sistema es la revisión, que es la que te permite mantener el sistema ordenado y fiable. Así que tómate al menos una hora a la semana para revisar tu bandeja de entrada, tus listas, tus calendarios y los resultados a los que quieres llegar (proyectos).

Por último, recordarte que la aplicación Recordatorios te permite realizar búsquedas básicas, por lo que puedes filtrar tareas etiquetadas. Así que, por ejemplo, si has decidido en tu revisión del final del día, ponerte mañana a primera hora con tres tareas, etiquétalas con #hoy, y después tan solo tendrás que filtrar por ellas y realizarlas. ¿Sencillo verdad?

Como ves, los recordatorios pueden ayudarte a comenzar en el mundo del GTD, así que no le des más vueltas, léete alguno de los dos libros que te he recomendado, te explicarán y aclararán muchas cosas, y comienza a gestionar tu vida de una forma eficaz.

Fuente:

medium.com/@primiumcm

Explicando Scrum a mi abuela

Introducción

El otro día me encontraba hablando con un compañero de trabajo a través del teléfono móvil, cuando mi abuela me escuchó nombrar palabras raras en la conversación.
Una de esas palabras era Scrum, y por la forma en la que hablaba fue lo que más atención la llamó, así que cuando colgué, lo primero que me preguntó fue con quién hablaba, de qué hablaba, y que era eso de Scrum.
Imaginaros la cara que se me quedó, porque… ¿cómo explicar Scrum a mi abuela?.
Aunque mi abuela es muy avanzada para la mayoría de la gente de su edad, la verdad es que no es fácil explicarla muchos de los aspectos tecnológicos emergentes, pero bueno, es mi abuela y tenía que intentar explicárselo de forma convincente.
Aquí, os transcribo aquella inverosímil conversación.

La conversación y sus explicaciones

¿De que hablabas?, parecía interesante eso que decías de Scrum. ¿Qué es exactamente?
¡Ah sí! Scrum es una metodología.

¿Y para que se utiliza?
Se utiliza en mi profesión, en el desarrollo del Software concretamente, aunque hay gente por ahí que la usa o la quiere usar en otras profesiones y áreas.

¿Y para eso del desarrollo del Software tenéis que usar ese tal Scrum?
En realidad no. No es estrictamente necesario.
Scrum por sus características no es válido para cualquier proyecto ni para cualquier persona o equipo de personas. Es más, Scrum según muchos especialistas de esta metodología, es óptima para equipos de trabajo de hasta 8 personas, aunque hay empresas que han utilizado Scrum con éxito con equipos más grandes.
Yo diría que para el 90% de los proyectos y empresas, es una metodología válida, pero no es una metodología válida al 100%. Es más, no hay metodología mejor que otra ni válida al 100% para todas las personas y empresas.
Scrum es por lo tanto, una metodología más de las muchas que hay, y ésta en concreto, se basa en la filosofía del desarrollo ágil que fue expuesto por dos japoneses alrededor del año 1986.

Siempre estos japoneses… has dicho desarrollo ágil varias veces… ¿que es eso exactamente?, a mí eso sí que me suena a japonés o a chino
El desarrollo ágil pone de manifiesto básicamente lo siguiente:

El mercado actual es altamente competitivo y la tecnología es muy cambiante. En el desarrollo del Software se pide básicamente rapidez, calidad y reducción de costes, pero para asumir estos retos, es necesario tener agilidad y flexibilidad.

Los ciclos de desarrollo por otro lado, acostumbran a ser largos, y lo que se exige por otra parte, es que esos ciclos sean lo más cortos posibles.

El desarrollo ágil aboga por estas premisas principalmente.
Hay más detalles, pero no los voy a abordar ahora para no marearte con información que nos desvíe la atención de la propia explicación de Scrum.

Información adicional

Empiezo a entender algo más esto…pero… ¿en qué consiste exactamente eso de Scrum?
Scrum es como decía antes, una metodología ágil.
Obedece a las necesidades anteriormente citadas, y no responde a ninguna moda, sino a una necesidad realmente demandada en el desarrollo del Software.
Scrum no es ni la mejor metodología ni la única, antes te decía que hay muchas, pero sí, es una metodología que está empujando muy fuerte por la facilidad de implantación y por su agilidad en cuanto a cambios y lo que propiamente aporta en comparación con otras metodologías.
Por un lado, Scrum evita la burocracia y la generación documental. No es que con Scrum no se deba o no se pueda documentar, si no que con Scrum no se exige documentar nada para iniciar un proyecto, algo que en otras metodologías es impensable.
Con Scrum por otro lado, la idea principal es la de ponerse a trabajar prácticamente desde el primer momento y empezar a sacar frutos de ese trabajo para que el cliente vaya viendo los avances y se quede satisfecho con lo que se está haciendo y cómo se está haciendo.

Sí sí, vale… pero ¿cómo muestras al cliente esos progresos en el trabajo?.
Bien bien, no te he contado aún mucho sobre Scrum, sólo el cascarón que lo envuelve, pero ya que preguntas y te veo realmente interesada, te voy a contar todo lo que hay con más detalle.
De forma resumida y global, en Scrum vamos a diferenciar dos aspectos importantes, los actores y las acciones.

Vaya, esto se pone interesante, sigue sigue que me está empezando a gustar esto del Scrum.
¡Ja!, pues espera a que te cuente, que esto no ha hecho nada más que comenzar.
Te decía que hay dos aspectos fundamentales a diferenciar, los actores y las acciones.
Los actores son los que ejecutarán obviamente las acciones.
Estos de forma general, serán:

Product Owner

Scrum Master

Scrum Team

Usuarios o Clientes

Algo que no te he dicho aún, es que para que un proyecto Software tenga éxito, el Usuario o Cliente, debe involucrarse sí o SÍ.
Esto vale para todos TODOS los proyectos, aunque no todos los Usuarios y Clientes lo entienden así, pero nuestra misión es también hacérselo ver.
Prosigo.
El Product Owner conoce y marca las prioridades del proyecto o producto.
El Scrum Master es la persona que asegura el seguimiento de la metodología guiando las reuniones y ayudando al equipo ante cualquier problema que pueda aparecer. Su responsabilidad es entre otras, la de hacer de paraguas ante las presiones externas.
El Scrum Team son las personas responsables de implementar la funcionalidad o funcionalidades elegidas por el Product Owner.
Los Usuarios o Cliente, son los beneficiarios finales del producto, y son quienes viendo los progresos, pueden aportar ideas, sugerencias o necesidades.

¿Y lo de las acciones?
Te veo con hambre de conocimiento, eso está bien.
Las acciones tienen relación directa con los actores. Sin ellas, todo sería un caos.
En Scrum se indican claramente las acciones a acometer y como acometerlas. Nuestra responsabilidad es hacerlo siempre de una forma adecuada y algo rígida para impedir que se aplique erróneamente esta metodología.
Las acciones de Scrum forman parte de un ciclo iterativo repetitivo, por lo que el mecanismo y forma de trabajar que a continuación se indica, tiene como objetivo minimizar el esfuerzo y maximizar el rendimiento en el desarrollo.
Las acciones fundamentales de Scrum son:

Product Backlog

Sprint Backlog

Daily Scrum Meeting

El Product Backlog corresponde con todas las tareas, funcionalidades o requerimientos a realizar. Antes decía que el Product Owner es la persona que se encarga de marcar las prioridades, y es al fin y al cabo, la persona que mantiene y actualiza dado el caso, la lista de tareas.
El Sprint Backlog corresponde con una o más tareas que provienen del Product Backlog. Es decir, del Product Backlog se saca una o más tareas que van a formar parte del Sprint Backlog. Las tareas del Sprint Backlog se deben acometer (recomendado) en unas 2 semanas ó 4 semanas. Hay Sprint Backlogs de 2 semanas y hay Sprint Backlogs de 4 semanas. Eso debe de ser marcado antes de iniciar el Sprint Backlog, de hecho, del Product Backlog se sacará la tarea o tareas realistas para acometer el Sprint Backlog. Una norma fundamental es que mientras un Sprint Backlog se inicia, éste NO puede ser alterado o modificado. Hay que esperar a que concluya el Sprint Backlog para realizar la correspondiente modificación o alteración cuya tarea, formaría parte de otro Sprint Backlog.
El Daily Scrum Meeting es una tarea iterativa que se realiza todos los días que dure el Sprint Backlog con el equipo de desarrollo o de trabajo. Se trata de una reunión operativa, informal y ágil, de un máximo de 30 minutos, en la que se le hace 3 preguntas a cada integrante del equipo.

Qué tareas ha realizado desde la última reunión (que he hecho).

Sobre qué va a trabajar en el día actual (que voy a hacer hoy).

Identificación de obstáculos o riesgos que impiden o pueden impedir el normal avance (que ayuda necesito). El Scrum Master, debe eliminar aquí cualquier obstáculo que encuentre.

Una pregunta más… has dicho que del Product Backlog se sacan tareas que van al Sprint Backlog, pero entiendo que no todas las tareas del Product Backlog van a la vez al Sprint Backlog, así que… ¿que se hace cuando una tarea del Sprint Backlog se finaliza?
Bien, esta es una pregunta típica.
Quizás no me he explicado bien, pero el Sprint Backlog, una vez que se inicia, ni se toca.
Es decir, que una tarea se acaba, y punto.
Se continúa con otra tarea del Sprint Backlog y así hasta que se acaben.
Lo que debemos tener claro, es que al finalizar un Sprint Backlog (ya sea de 2 semanas ó de 4 semanas), debemos haber acabado las tareas del Sprint Backlog.
Reitero que las tareas del Sprint Backlog deben de ser realistas.
Así que cuando se ha finalizado un Sprint Backlog, deberíamos tener algo, un entregable o algo que se pueda mostrar y que enseñe los avances acometidos en el Sprint.
En el Product Backlog tendremos más tareas, y es posible incluso que hayan salido nuevas tareas o que otras hayan desaparecido, por lo que es cuando se acaba el Sprint Backlog, cuando debemos hacer varias cosas importantes y que te indico a continuación.

Esto me está gustando muchísimo…
Me alegro, a mí me parece interesantísimo, y es más, Scrum es de sentido común, tanto, que yo sin saberlo ya lo utilizaba hace algunos años sin saber que era realmente Scrum.
Bueno, prosigo con esta explicación.
Como te decía, adicionalmente a las acciones anteriormente comentadas encontramos otras acciones más.
Antes para no saturarte, no te dije que entre el Product Backlog y el Sprint Backlog, hay algo, una reunión concretamente, que se denomina Sprint Planning Meeting.

El Sprint Planning Meeting es una reunión que tiene por objetivo, planificar el Sprint a partir del Product Backlog. El objetivo de esta reunión es la de mover las tareas del Product Backlog al Sprint Backlog. En esta reunión, suelen participar el Product Owner que es como te dije antes quien prioriza las tareas, el Scrum Master y el Scrum Team.

Del Sprint Planning Meeting, sale también el Sprint Goal, que es un pequeño documento o una breve descripción que indica lo que el Sprint intetará alcanzar.

En el Sprint Review se revisa en unas 2 horas como máximo el Sprint finalizado. Al llegar a este punto, debemos tener “algo” que el Cliente o el Usuario pueda ver y tocar. En esta reunión, suelen asistir el Product Owner, el Scrum Master, el Scrum Team y personas que podrían estar involucradas en el proyecto. El Scrum Team es quién muestra los avances realizados en el Sprint.

Al finalizar un Sprint Backlog y el Sprint Review, se inicia el Sprint Retrospective. El Product Owner revisará con el equipo los objetivos marcados inicialmente en el Sprint Backlog concluido, se aplicarán los cambios y ajustes si son necesarios, y se marcarán los aspectos positivos (para repetirlos) y los aspectos negativos (para evitar que se repitan) del Sprint.

Mira, te pintaré un diagrama que espero te ayude a entender todas las acciones de Scrum.

¿Y porque es eso de las 2 ó 4 semanas?. ¿No sería más fácil que cada equipo pusiera su franja de tiempo?

Sí claro, cada equipo, cada empresa, cada proyecto, puede poner la franja horaria y frecuencia temporal que considere oportuno así como cambiar aspectos de Scrum, pero te voy a poner un sencillo ejemplo con el cuál entenderás que es mejor hacer esto así que de otra forma.
Supongamos el caso de la construcción de un rascacielos o de un edificio.
Si con el fin de controlar el proyecto y que no se te escape nada ni metamos la pata en algo, me preguntas cada día en varias ocasiones como estoy haciendo las cosas, como lo llevo y cuales son mis avances, te aseguro que no terminaremos la construcción del edificio en el tiempo planificado ni de broma. Además, seguro que querrás cambiar o modificar algo cada día o incluso varias veces en el mismo día.
Si me preguntas cada 6 meses por ejemplo, avanzaré mucho sin interrupciones, pero a buen seguro que el riesgo de desviaciones es mucho mayor y seguramente si ocurren, reajustar esas desviaciones al proyecto tendrá costes elevados asociados.
Un término medio es el ajuste temporal de 2 ó 4 semanas que está basado en la experiencia de muchas personas en muchos proyectos. No es lo mismo reconducir el proyecto perdiendo 2 ó 4 semanas, que reconducirlo perdiendo 6 meses por ejemplo.
La idea de la metodología ágil es fundamentalmente que adopte los cambios, que se pueda reconducir el proyecto en un momento dado, y que afecte lo menos posible a los costes, los tiempos y al equipo de trabajo.
No es la metodología ideal. Yo siempre digo que si hubiera algo ideal, todo el mundo lo usaría, pero sí te digo, que Scrum se acerca bastante a esa idea general de la gestión ideal de proyectos.
A mí personalmente es la que más me gusta y la que por experiencia, mayor satisfacción suele dar, tanto al cliente o al usuario final como al equipo de trabajo.

Y no te creas que hay mucho más que saber de Scrum, esta es la filosofía o idea general que espero te haya quedado clara y te haya servido para entender lo que hablaba con mi compañero de trabajo.

Sin duda que me ha parecido muy interesante. Muchas gracias.

Fuente:

Explicando Scrum a mi abuela

Desde las 12:25 estan enviando mails con una supuesta actualizacion de datos que solo es la forma de los atacantes para acceder a la informacion de clientes de este banco.

Tomar precauciones, esta es una captura del mail que envian:

Si desean mirar las urls comprometidas son:

http://librerialosgurises.com.ar/20b9f8306a28cd7b97ddd8614cd16e34

http://ferabu.com/ec/BancamiggpvirtualirpizPersonas/EasyfLogin/