Motivation:<\/strong> This pattern will be used for representing the state of the tasks of a project when the state of each task to be done and the amount of task in each state is relevant: for managing the correct evolution\/rithm of the project, to manage the resources needed in each state, etc. In addtion, some projects also require to perform several steps to finish a task, being the state of the tasks relevant for the reasons shown previously. <\/p>\n\n\n\n One of the most frequent uses of this pattern is the collaborative management of the tasks of a project. Depending on the complexity of the tasks, it\u2019s probable that they go through different phases before completing the process. The minimum of this is having three state: \u201cto do\u201d, \u201cdoing\u201d and \u201cdone\u201d, but there may be intermediate stages, as \u201cdesign\u201d, \u201ccode review\u201d or \u201ctesting\u201d. With a kanban pattern the user will have a global vision of the project, letting the user know how many tasks are in each state. It could be useful for applying effort balancing techniques and reduce bottlenecks, controlling the maximum number of tasks at each phase.<\/p>\n\n\n\n Solution and graphic representation:<\/strong>\u202fEach list represent a possible state (phases, steps…) of a task in the context of our problem. We will have as many lists as different states. Tasks will be represented by cards. Initially, cards are storaged in the first bucket (usually called \u201cto do\u201d) as tasks are storaged in a backlog. Tasks will flow through the lists as long as they are in progress or finished in real life. Kanban board will represent in this way the state of every task at any given moment.<\/p>\n\n\n\n Related Patterns:<\/strong><\/p>\n\n\n\n Kanban pattern differs from \u201cAssigned Tasks<\/a>\u201d only in the presence or absence of order between lists. This will make you to choose one or another depending on if you want to have a view of the status of the tasks of the project, or if you prefer to focus on who is the responsible of doing it.<\/p>\n\n\n\n In addition, Kanban differs from \u201cProcess Tasks<\/a>\u201d in the presence or absence of card flow. This means that in the first pattern we will represent the process to know in real time the status of each task, while with the second pattern we will have an static view of the tasks that we should do to complete the process, as in a recipe.<\/p>\n\n\n\n Kanban is usually combined with \u201cCategorized Information<\/a>\u201d pattern. It enhances the usability of the pattern, because it adds extra information or some resources of the project, allowing the user to better understand the whole process than if we have only the tasks, without explanation.<\/p>\n\n\n\n Example:<\/strong><\/p>\n\n\n\n In this template we have a linear and conventional Kanban pattern, with the peculiarity that it has multiple intermediate phases, as \u201cdesign\u201d, \u201ccode review\u201d or \u201ctesting\u201d. Tasks will advance linearly as they go through these states in real life and they complete the whole process.<\/p>\n\n\n\n Trello Templates<\/strong> Examples:<\/strong><\/p>\n\n\n\n Problem:<\/strong>\u202fSituations or projects in which we need to manage tasks, handling how they evolve, and monitoring them. In this way, we need a full vision of the tasks that make up a project and we need to know at each moment which is the status of each task.<\/p>\n\n\n\n Motivation:<\/strong> This pattern will be used for representing the state of the tasks of a project when the state of each task to be done and the amount of task in each state is relevant: for managing the correct evolution\/rithm of the project, to manage the resources needed in each state, etc. In addtion, some projects also require to perform several steps to finish a task, being the state of the tasks relevant for the reasons shown previously. <\/p>\n\n\n\n One of the most frequent uses of this pattern is the collaborative management of the tasks of a project. Depending on the complexity of the tasks, it\u2019s probable that they go through different phases before completing the process. The minimum of this is having three state: \u201cto do\u201d, \u201cdoing\u201d and \u201cdone\u201d, but there may be intermediate stages, as \u201cdesign\u201d, \u201ccode review\u201d or \u201ctesting\u201d. With a kanban pattern the user will have a global vision of the project, letting the user know how many tasks are in each state. It could be useful for applying effort balancing techniques and reduce bottlenecks, controlling the maximum number of tasks at each phase.<\/p>\n\n\n\n Solution and graphic representation:<\/strong>\u202fEach list represent a possible state (phases, steps...) of a task in the context of our problem. We will have as many lists as different states. Tasks will be represented by cards. Initially, cards are storaged in the first bucket (usually called \u201cto do\u201d) as tasks are storaged in a backlog. Tasks will flow through the lists as long as they are in progress or finished in real life. Kanban board will represent in this way the state of every task at any given moment.<\/p>\n\n\n\n Related Patterns:<\/strong><\/p>\n\n\n\n Kanban pattern differs from \u201cAssigned Tasks<\/a>\u201d only in the presence or absence of order between lists. This will make you to choose one or another depending on if you want to have a view of the status of the tasks of the project, or if you prefer to focus on who is the responsible of doing it.<\/p>\n\n\n\n In addition, Kanban differs from \u201cProcess Tasks<\/a>\u201d in the presence or absence of card flow. This means that in the first pattern we will represent the process to know in real time the status of each task, while with the second pattern we will have an static view of the tasks that we should do to complete the process, as in a recipe.<\/p>\n\n\n\n Kanban is usually combined with \u201cCategorized Information<\/a>\u201d pattern. It enhances the usability of the pattern, because it adds extra information or some resources of the project, allowing the user to better understand the whole process than if we have only the tasks, without explanation.<\/p>\n\n\n\n Example:<\/strong><\/p>\n\n\n\n In this template we have a linear and conventional Kanban pattern, with the peculiarity that it has multiple intermediate phases, as \u201cdesign\u201d, \u201ccode review\u201d or \u201ctesting\u201d. Tasks will advance linearly as they go through these states in real life and they complete the whole process.<\/p>\n\n\n\n Trello Templates<\/strong> Examples:<\/strong><\/p>\n\n\n\n Problema<\/strong>: Situaciones o proyectos en los que necesitamos gestionar tareas, manejar c\u00f3mo evolucionan y monitorearlas. De esta forma, tendremos una visi\u00f3n completa de las tareas que componen un proyecto y podremos saber en cada momento cu\u00e1l es el estado de cada tarea.<\/p>\n\n\n\n Motivaci\u00f3n<\/strong>: Este patr\u00f3n se utilizar\u00e1 para representar el estado de las tareas de un proyecto, cuando el estado de cada tarea o la cantidad de tareas en cada estado sea relevante. As\u00ed, podremos gestionar la correcta evoluci\u00f3n \/ ritmo del proyecto, los recursos necesarios en cada estado, etc. Adem\u00e1s, algunos proyectos tambi\u00e9n requieren realizar varios pasos para finalizar una tarea, siendo el estado de las tareas relevante para saber en qu\u00e9 etapa se encuentran.<\/p>\n\n\n\n Uno de los usos m\u00e1s frecuentes de este patr\u00f3n es la gesti\u00f3n colaborativa de las tareas de un proyecto. Dependiendo de la complejidad de las tareas, es probable que pasen por diferentes fases antes de completar el proceso. El m\u00ednimo generalmente es tener tres estados: \"To-do\", \"Doing\" y \"Done\", pero puede haber etapas intermedias, como \"dise\u00f1o\", \"revisi\u00f3n\" o \"prueba\". Con un patr\u00f3n Kanban el usuario tendr\u00e1 una visi\u00f3n global del proyecto, permitiendo al usuario saber cu\u00e1ntas tareas hay en cada estado. Podr\u00eda ser \u00fatil para aplicar t\u00e9cnicas de equilibrio de esfuerzos y reducir cuellos de botella, controlando el n\u00famero m\u00e1ximo de tareas en cada fase.<\/p>\n\n\n\n Soluci\u00f3n y representaci\u00f3n gr\u00e1fica:<\/strong> Cada lista representa un posible estado (fases, pasos, etapas\u2026) de una tarea en el contexto de nuestro problema. Tendremos tantas listas como estados diferentes. Esas tareas estar\u00e1n representadas por cartas. Inicialmente, las cartas se almacenan en la primera lista (generalmente llamado \"To-do\") almacen\u00e1ndose como un backlog de tareas. Posteriormente, las tareas fluir\u00e1n a trav\u00e9s de las listas, seg\u00fan est\u00e9n en progreso o finalizadas en la vida real. El tablero Kanban representar\u00e1 de esta manera el estado de cada tarea en un momento dado concreto.<\/p>\n\n\n\n Patrones relacionados:<\/strong><\/p>\n\n\n\n El patr\u00f3n Kanban se diferencia de \"Assigned Tasks<\/a>\" solo en la presencia o ausencia de orden entre las listasdel tablero. Esto har\u00e1 que elijamos uno u otro en funci\u00f3n de si necesitamos tener una visi\u00f3n del estado de las tareas del proyecto, o si es preferible centrarse en qui\u00e9n es el responsable de realizarla.<\/p>\n\n\n\n Adem\u00e1s, Kanban se diferencia de \"Process Tasks<\/a>\" en la presencia o ausencia de flujo de cartas. Esto quiere decir que, con Kanban representaremos el proceso para conocer en tiempo real el estado de cada tarea, mientras que, con el segundo patr\u00f3n tendremos una vista est\u00e1tica de las tareas que debemos realizar para completar el proceso, como los pasos de una receta.<\/p>\n\n\n\n Por \u00faltimo, Kanban generalmente se combina con el patr\u00f3n \"Categorized Information<\/a>\". Dicha combinaci\u00f3n mejora la usabilidad del patr\u00f3n, ya que agrega informaci\u00f3n extra o algunos recursos del proyecto. Esto permite al usuario comprender mejor todo el proceso, en lugar de si tuvi\u00e9ramos las tareas \u00fanicamente, sin explicaci\u00f3n.<\/p>\n\n\n\n Ejemplo:<\/strong><\/p>\n\n\n\n En esta plantilla tenemos un ejemplo convencional y lineal del patr\u00f3n Kanban, con la \u00fanica peculiaridad de que consta de m\u00faltiples fases intermedias (\"design\", \"code review\" o \"testing\"). Las tareas avanzar\u00e1n linealmente (de izquierda a derecha) seg\u00fan evolucionen y pasen por dichos estados en la vida real hasta completar el proceso al completo.<\/p>\n\n\n\n Ejemplos de Plantillas de Trello:<\/strong><\/p>\n\n\n\n Problem:<\/strong>\u202fSituations or projects in which we need to manage tasks, handling how they evolve, and monitoring them. In this way, we need a full vision of the tasks that make up a project and we need to know at each moment which is the status of each task.<\/p>\n\n\n\n Motivation:<\/strong> This pattern will be used for representing the state of the tasks of a project when the state of each task to be done and the amount of task in each state is relevant: for managing the correct evolution\/rithm of the project, to manage the resources needed in each state, etc. In addtion, some projects also require to perform several steps to finish a task, being the state of the tasks relevant for the reasons shown previously. <\/p>\n\n\n\n One of the most frequent uses of this pattern is the collaborative management of the tasks of a project. Depending on the complexity of the tasks, it\u2019s probable that they go through different phases before completing the process. The minimum of this is having three state: \u201cto do\u201d, \u201cdoing\u201d and \u201cdone\u201d, but there may be intermediate stages, as \u201cdesign\u201d, \u201ccode review\u201d or \u201ctesting\u201d. With a kanban pattern the user will have a global vision of the project, letting the user know how many tasks are in each state. It could be useful for applying effort balancing techniques and reduce bottlenecks, controlling the maximum number of tasks at each phase.<\/p>\n\n\n\n Solution and graphic representation:<\/strong>\u202fEach list represent a possible state (phases, steps...) of a task in the context of our problem. We will have as many lists as different states. Tasks will be represented by cards. Initially, cards are storaged in the first bucket (usually called \u201cto do\u201d) as tasks are storaged in a backlog. Tasks will flow through the lists as long as they are in progress or finished in real life. Kanban board will represent in this way the state of every task at any given moment.<\/p>\n\n\n\n Related Patterns:<\/strong><\/p>\n\n\n\n Kanban pattern differs from \u201cAssigned Tasks<\/a>\u201d only in the presence or absence of order between lists. This will make you to choose one or another depending on if you want to have a view of the status of the tasks of the project, or if you prefer to focus on who is the responsible of doing it.<\/p>\n\n\n\n In addition, Kanban differs from \u201cProcess Tasks<\/a>\u201d in the presence or absence of card flow. This means that in the first pattern we will represent the process to know in real time the status of each task, while with the second pattern we will have an static view of the tasks that we should do to complete the process, as in a recipe.<\/p>\n\n\n\n![\"kanban\"\/](\"https:\/\/user-images.githubusercontent.com\/47741431\/110808758-96122e80-8284-11eb-9d0b-9b7a12452d2c.png\")
<\/a><\/figure><\/div>\n\n\n\n<\/figure><\/div>\n\n\n\nPattern:\u202fKANBAN<\/h1>\n\n\n\n
<\/a><\/figure><\/div>\n\n\n\n<\/figure><\/div>\n\n\n\nPatr\u00f3n:\u202fKANBAN<\/h1>\n\n\n\n
<\/a><\/figure><\/div>\n\n\n\n<\/figure><\/div>\n\n\n\nPattern:\u202fKANBAN<\/h1>\n\n\n\n
<\/a><\/figure><\/div>\n\n\n\n