Showing posts with label scrum. Show all posts
Showing posts with label scrum. Show all posts

Monday 20 October 2014

Why Agile Can Be A Popular Software Development Framework

Agile A Popular Software Development Framework

Software products penetrate almost every aspect of human existence today. They manifest themselves in a multitude of manner, and remain omnipresent in a host of devices ranging from washing machines and smartphones to automobiles and computers. Owing to a consistent usage of different types of digital devices by people across the world, software applications and utilities have to evolve as and when consumer requirements change and “strive” to fulfill the new set of requirements demanded by end users. It is, therefore, essential to develop newer versions of existing software products more frequently, in the shortest time possible, and in a manner such that end users do not face any problems while using the products in the upcoming months. Stiff market competitions and an ever-increasing consumer “appetite” for feature-rich products have created a special need to implement a reliable and sustainable product development methodology, or a framework, which can aid in developing sophisticated software products in a relatively short time. Moreover, the methodology should also help in reducing the developmental overheads so investment returns can be increased. As on today, a reliable project development methodology is very much required to fulfill the business goals on a consistent basis, and earn large profits from the products manufactured by IT companies.

Over the decades, IT stalwarts have introduced many software development frameworks and project management methodologies. While many of these methodologies have proved to be useless and non-productive, a large number of them have been, in fact, successful in delivering the desired results – with varying levels of acceptance. With the passage of time, two software development frameworks have managed to dominate the field of software development. The frameworks are:

1. Waterfall

It is a traditional software development framework typically featuring “staged” development processes which have to be “carried out” one after the other. A unique aspect about this framework is that product development starts from the “topmost” stage and “flows” towards the “bottommost” stage. Once started, the product development cycle cannot reverse itself – it is unidirectional in nature. The framework is widely used, and is very popular amongst software development companies, primarily because the framework has “been around” for a long time and used by a large number of software developers and IT firms. It is easy to understand and use. Therefore, it is also used for teaching the software development process to engineering students. Even though it is a much sought after development framework, a large number of individuals and companies traditionally using Waterfall methods for developing their software products are now finding it increasingly difficult to meet the changing global software trends, and developing state-of-the-art applications and utilities, which are so much in vogue today.

2. Agile

A comparatively new “entrant” Agile has managed to find a special niche for itself in the IT development field over the years. The Agile framework was originally envisioned, and developed, to overcome the defects of traditional software project management methodologies and frameworks, which had failed to evolve “in the desired direction”, could not adapt themselves to the changing market trends, and offer reduced turnaround times. There are many reasons why “lightweight” Agile frameworks have become popular development platforms:
  • They support product development through “short bursts” of programming/development activity, generally lasting from two weeks up to one month. It is much easier to develop, test, and document smaller “pieces” of code, features, and functionality rather than entire projects. Individually developed features are later integrated to form the “complete” product. The frameworks primarily focus upon rapid delivery of “shippable” products and business value.
  • The client is actively involved with the team and the development process. Each feature is checked and “cleared” by the stakeholders before it is accepted as “Done”. This leads to increased customer satisfaction and enhanced user experience.
  • Potential pitfalls are identified well in advance, at a micro level, so it is much easier to control regression and reduce technical debt. Agile software projects generally help to earn good profit margins.
  • Agile frameworks support error detection and error correction processes. Technical errors are discovered early during the product development process, and dealt with effectively.
  • The frameworks provides an opportunity to carry out “retrospective” thinking, reflect in terms of where the project is heading, and what “more” could be done to improve the product development process.

Agile and the scope of software development

Individuals associated with the software industry generally prefer using the term “software development” to describe their particular line of work. The words are indiscriminately used to describe a host of development related activities, including testing, documentation, debugging, deployment, and maintenance of software applications. It is normal to explain one’s profession as “software development” while the individual may be working as a VBScript or Java web developer, an application programmer, an iOS or Android mobile apps creator, or even developing specialized scripts for WordPress themes.

One of the commonest doubt prevailing amongst most individuals new to the Agile process is whether Agile is “applicable” to their particular field of work. And if so, how? In what manner? How can they possibly benefit through Agile? The questions are many. First of all, it is important to know where Agile is applicable, and whether it “covers” your particular field of work. Please read to know more about Agile “applicability”. The list provides a rough idea regarding the scope of Agile software development.

1. Clients and stakeholders engagement

Scrum
Agile emphasizes upon client engagement. The stakeholders “own” the project and sponsor it. Their objective is to develop successful software projects, and generate higher sources of revenue out of them. In practice, the client remains conversant with the current market trends, and possesses a fair idea as to “what” is likely to score in the market in terms of a feature rich application or utility that can satisfy the end user requirements. When the client is closely associated with the day-to-day development activity, he or she can decide whether the productivity offered by the development team can satisfy user related requirements, and how much of business value the product features possess. Client participation leads to meaningful and successful project development and completion.

Waterfall does not encourage or support client participation. The project is developed, and subsequently presented to the client after it is totally completed. Since the client does not participate in the development process, Waterfall projects may fail to offer the exact features so desired, and, in addition, do not “guarantee” any business value for the project. There is a certain risk involved regarding the product’s saleability. 

2. Transparency and collaboration

scrum tool
The Agile framework makes it possible to increase the transparency levels while working, and facilitates the actual product development process by increasing the collaboration amongst team members. Information pertaining to the entire project is shared equally with all team members, and each decision undertaken by the senior team members – the product owner and the scrum master – is freely discussed. The seniors “act” as mentors, and many a times employ a servant-leader role to increase team participation. The team members have the authority to accept or reject the tasks taken up for development. Moreover, the developers have the right to allocate or distribute development tasks amongst themselves. Seniors do not allocate work to the development team members. All these factors create a healthy working environment. A conductive Agile work-related atmosphere leads to meaningful development and timely completion of product features.

The Waterfall framework primarily concentrates upon delegation of authority and direct allocation of work. Unlike Agile, the development process is pre-decided, and in many cases, even decided as to which resource should be used for developing a particular product feature. Waterfall is rigid as far as sharing of information is concerned. The project related documentation is created at the project’s onset, and apart from technical information, nothing else is generally shared with the team. The seniors have the final “say” and junior team members cannot argue with any of the decisions undertaken by the seniors.

3. Quick and predictable delivery

free scrum tool
Apart from the actual development activity, Agile supports several events and activities which constitute the actual Agile process. Each activity is time-boxed and has to be completed within a stipulated time. It is one of the most important framework features. Quick and sustained delivery of shippable products through periodic product incremental cycles known as “sprints” comprise the main heart of all Agile frameworks. The deadlines are stringently adhered to and rarely compromised upon.

One of the biggest drawbacks of Waterfall is that projects, in many instances, extend well beyond their stipulated deadlines, and rarely get completed in time. It is an inherent drawback which actually inspired the “birth” of Agile and Lean frameworks. Traditional development methods are rigid, and it is very difficult to control the rate at which productivity is offered by the team. That is not the case with Agile. Each Agile sprint is dynamic, and “monitored” on a daily basis through the daily scrum meetings so it can be “made” effective. Agile concentrates upon quick and timely delivery of product features and functionality through daily development activity known as “daily sprints”.

4. Predictable costs and work schedule

online scrum tool
It becomes possible to predict the amount of work done, or productivity offered, by time boxing the daily sprint iterations. The development carried out can be frequently and easily monitored since each “daily sprint” has to result into something “significant” with regards the development of product features, and the same has to be exhibited to the product owner and the stakeholders in special Agile events known as the “sprint review” and “sprint retrospective” meetings. The “velocity”, or the rate at which actual development is carried out, is used for estimation purposes i.e. the total number of tasks developed by the team during a particular sprint provides an idea about how much work was carried within a specified time. The estimation makes it possible to predict how much time and financial resources will be required to complete the project. A reliable project release date can be subsequently stated.

It is very difficult to estimate how much time a Waterfall project will need to complete. Deadlines are generally “set up” based upon predictions and project related experience, rather than on actual project dynamics and production pattern. It is one of the primary reasons why Waterfall fails to deliver time bound projects.

5. Support for “change”

scrum planning tool
Agile is based upon “inspect” and “adapt” principles. The Agile framework dynamically supports changes, and is capable of adapting itself to changing market related conditions and client demands – even late during the development process. New features can be introduced to enhance the product’s business value, and redundant functionality can be safely “removed” from the production plan without affecting the productivity levels.

Waterfall does not support, nor advocate, any types of changes once the documentation process is carried out, and the project commences. The framework is rigid and there is no scope of changing the functionality stated in the documentation process – even if the client so demands.

6. Focusing upon the business value

project management tool
In Agile, development is carried out by splitting the actual product into smaller developable parts known as “user stories” or product items. Right from the project conception stage, each user story is segregated and arranged depending upon its importance and business value. User stories having a greater business value or importance in the project are developed first, followed by less important ones. Thus during the Agile process, only important product features are developed at all times, thereby increasing the business value linked with the project currently underway.

Waterfall does not have features that can account for or take into consideration the current business value linked with the project. The concept does not exist. Projects are developed in a traditional manner, and no efforts are made to determine what they are currently worth in the market.

Subscribe to the permanent free version of the Quickscrum project management scrum tool to get an idea about how the tool works and what it has to offer.

Sunday 12 October 2014

Main Differences Between Agile Scrum And XP Framework

Of all Agile frameworks, scrum is the most popular one. Scrum framework is highly recommended for developing IT projects and it is so widely recommended for it that it is often confused with Extreme Programming or “XP” Agile framework, which is synonymous with software development. Both the frameworks are much similar, and to a person not conversant with Agile, both might appear to be the same at a first glance. While most Agile processes and events remain the same, there are some subtle differences between the two frameworks.

Sprint durations

Typically, in scrum, the sprint iteration can last from two weeks up to one month. In XP, the duration is much shorter, and generally lasts from one to two weeks. The sprint duration does not exceed two weeks in XP.  

Committing the sprint backlog

One of the major differences, and an important one too, is how user stories are committed in the sprint backlog while implementing scrum and XP. In scrum, the sprint backlog is “owned” by the development team. Once the team accepts the sprint backlog, all the user stories in the backlog are “committed” for development purposes. The team is required to complete all the user stories stated in the backlog. Moreover, once committed, the sprint backlog cannot be “changed” while implementing scrum. If any new user story is required to be developed, it can only be included in the next sprint after a new sprint planning meeting is conducted. This is not the case with XP. The sprint backlog does not become “static” even after it is accepted by the team and the user stories are taken up for development. If required, based upon the feedback received from the stakeholders, a user story taken up for development can be replaced with another one having the same estimation in terms of story points. Therefore, the sprint backlog is not “committed” at any time in XP. New stories can be replaced in lieu of those currently existing in the sprint backlog – something that is impossible in scrum. However, it is important to know that such a “replacement” of user story is only possible in XP before the particular user story is taken up for execution in the daily sprint. Once the development of a user story starts in XP, it cannot be replaced.     

Determining the sequence while developing user stories

The role of the product owner remains common in both scrum and XP. The PO prioritizes the product backlog in accordance to the importance of user stories based upon the business values.  Feedback is availed from the stakeholders as to which of the user stories are more important and pertinent from the development point of view, and the PO categorizes the product backlog based upon the business values of the user stories. The similarity, however, ends there. In scrum once the user stories are prioritized and taken up for development during the daily sprints, the development team enjoys the autonomy of deciding how the user stories should be actually taken up for development during the daily sprints. The team can decide the order, or the sequence, in which it desires to develop the user stories. This does not occur in XP framework. The development team in XP has to strictly adhere to the priority of the user stories as decided by the PO and carry out the development in the same order of priority. In XP, the team cannot choose the order in which the user stories should be developed. It is decided beforehand by the PO or the client. The team is required to stringently follow the priority as stated in the sprint backlog.     

In scrum framework, it is highly common for the team to start with the second-most-important user stories rather than the most important ones during the daily sprints. Larger user stories or “epics” are generally developed subsequently since they consume more development time. This is generally done to maintain the velocity during the scrum process, which is depicted in the burn down charts. It is important for the team to remain close to the “ideal” line so that the velocity is maintained at all times. Taking up easier user stories generally helps the team to remain consistent with the projected velocity. This is not possible to do in XP.
 
Subscribe to the permanent free version of the Quickscrum project management scrum tool to get an idea about how the tool works and what it has to offer.

Thursday 24 July 2014

Agile Scrum para desarrollo de software

El ámbito de desarrollo en el campo del software / IT
Las personas y los individuos asociados con el desarrollo de software y el campo de las TI les gusta usar el término "desarrollo de software" para describir su campo particular de trabajo y participación profesional. El término "desarrollo" es muy utilizado para describir una serie de actividades que atienden al campo de TI. Puede ir desde el desarrollo de código para aplicaciones y sistemas, para el desarrollo de aplicaciones móviles para los sistemas operativos móviles como Android, iOS, Symbian, Windows OS, etc (visita http://en.wikipedia.org/wiki/Mobile_operating_system), "fabricación de "software de juego utilizando lenguajes de script como Ruby, AGSScript, Lua, Marathon lenguaje de marcas, Ada, C ++, C #, D, Lisp, Mercury, Pascal, Perl, Python, Scheme, JavaScript, Java, VBScript, EDL, etc, (visite http://en.wikipedia.org/wiki/List_of_programming_languages​​) llevar a cabo el desarrollo web utilizando HTML, CSS, PHP, Joomla, DotNetNuke, Java, etc, e incluso el desarrollo de sistemas operativos completos para tablets y PCs (visite http://en.wikipedia.org/wiki/List_of_operating_systems para saber más acerca de los sistemas operativos).

El hecho es que en la actualidad, la terminología "desarrollo de software" se utiliza ampliamente para mencionar casi cualquier tipo o actividad asociada con la programación y el desarrollo de código "computerizable" de cualquier tipo, de cualquier manera, o forma. Cuando se utiliza una metodología o marco determinado para desarrollar código computerizable y crear proyectos de software, es importante determinar si el ámbito de desarrollo incluye la actividad específica que está actualmente involucrado o asociado. Marcos de desarrollo de software y gestión de proyectos, tales como Agile tienen el potencial para desarrollar con éxito proyectos de TI relacionado a la gran mayoría de las plataformas de desarrollo y sistemas operativos.

¿Qué es el marco Agile?  
Al explicar Agile de una manera sencilla y directa, puede ser mejor entendido como un conjunto de metodologías de desarrollo de proyectos y los marcos, de los cuales cualquier marco o metodología se puede utilizar de una manera exitosa para desarrollar de forma dinámica los proyectos de casi cualquier tipo y naturaleza, incluyendo proyectos de desarrollo de software. El marco se basa en el desarrollo iterativo e incremental, en el cual los equipos auto-organizados y desarrollo autogestionario comprender, planificar y desarrollar proyectos bajo la supervisión de un jefe de proyecto, y ofrecen la productividad en forma de ráfagas cortas de los ciclos de desarrollo (iterativo desarrollo), conocido como sprints. Una característica única de todos los marcos ágiles es que el desarrollo llevado a cabo por el equipo es "entregable" en la naturaleza es decir, el código desarrollado durante el ciclo de desarrollo del producto es independiente, comprobable y verificable, documentable y listo para su despliegue después de que está rigurosamente comprobado por cualquier defecto de fabricación "."

Una segunda característica, muy importante de desarrollo ágil es que los individuos "que poseen" el proyecto están estrechamente vinculados con la aprobación del desarrollo llevado a cabo por el equipo. Un "código" o "pieza" particular de funcionalidad se comprueba la regresión después de que se desarrolla, y posteriormente presentado a las partes interesadas y los responsables de los proyectos. Averiguan el desarrollo llevado a cabo, y claro como "OK" para su futura integración en el producto real. Esto conduce a un desarrollo exitoso de proyectos de software, ya que la gestión es siempre consciente de lo que la funcionalidad está siendo desarrollado por el equipo, y hasta qué punto satisface los objetivos del proyecto. Si los propietarios del proyecto sienten la productividad que ofrece el equipo no es hasta a la marca, o no se satisface en términos de valor de negocio (qué cantidad importante el código o funcionalidad es desde el punto de vista del mercado, y la cantidad de vale la pena desde el punto de vista financiero) que ofrece la funcionalidad, pueden rechazar toda la funcionalidad e instruir al director del proyecto para reconstruir la secuencia de comandos o el código particular, sobre la base de un nuevo conjunto de entradas y requisitos recomendados por ellos. Esto asegura que el proyecto de software siempre "mantiene" su valor de negocio en todo momento, incluso cuando el producto se está desarrollando actualmente.

Una tercera característica importante de marco Agile es que todas las actividades del proyecto son "tiempo en caja", y por lo tanto, tienen que ser completado dentro de un período de tiempo predeterminado. En un proyecto Agile, cada actividad es de duración determinada. Todas las actividades de desarrollo relacionadas están "configurados" para satisfacer las necesidades de los proyectos únicos, y una duración "adheridas" a ellos para que puedan ser completadas dentro de un tiempo estipulado. Esto garantiza que el proyecto no "Drag-On" y se extienden indefinidamente. Los costos de desarrollo incurridos mientras el proyecto se está desarrollando correctamente y pueden ser "rentable" controlada, de modo que el proyecto no se convierta en "demasiado" caro y difícil de pagar financieramente.

Principios y características ágiles  
Marco Agile difiere drásticamente en comparación con los tradicionales lineal o metodología de cascada. En Agile, el desarrollo del proyecto se lleva a cabo en las explosiones cortas de actividades más que en etapas que tienen que ser "completado" una después de la otra.

Las características principales incluyen Agile:
  • Los equipos de desarrollo de funciones cruzadas consisten de desarrolladores, programadores, probadores, personal de control de calidad, redactores técnicos, analistas de sistemas, etc todos trabajan juntos como un solo equipo compuesto a través de esfuerzos de colaboración, ofrecer y compartir ideas y ayudarse unos a otros durante el proceso de desarrollo.
  • El trabajo en los ciclos de desarrollo cortos, de ritmo rápido, con objetivos precisos - El desarrollo iterativo.
  • Productividad Envíos al final de los ciclos de desarrollo iterativos - El desarrollo incremental. La funcionalidad sigue "creciendo" a través de los ciclos de desarrollo hasta que se desarrolla toda la aplicación, sistema o producto.
  • Comunicaciones humanos y la participación tiene prioridad sobre la autoridad de gestión y la delegación de trabajo.
  • Total transparencia y visibilidad del progreso del equipo a los propietarios, las partes interesadas y los usuarios finales del proyecto.
  • Comentarios y sugerencias ayudan a autocorregirse y ofrecen nuevas formas y medios para llevar a cabo más rápido, un desarrollo más eficiente y confiable.
Una característica importante de todos los marcos ágiles es que los marcos son independientes de la naturaleza del proyecto a desarrollar es decir, el marco no es dependiente de la plataforma o entorno utilizado para desarrollar el proyecto de software en particular. La arquitectura o el diseño pueden variar, y podría ser cualquier cosa. El aspecto importante es que un marco Agile tiene que ser implementado en el proyecto primero, y sus beneficios se acogió posteriormente. Por favor, visite
http://en.wikipedia.org/wiki/Agile_software_development

¿Qué es el scrum Agile?  
Scrum, en pocas palabras, es un "peso ligero" marco Agile, que se utiliza ampliamente para el desarrollo y distribución de productos de software "viables", muy a menudo, y sobre una base consistente. Los productos de software pueden ir desde el desarrollo de nuevos procesos y sistemas web, soluciones de juegos, plugins, aplicaciones móviles, sitios web de comercio electrónico, portales corporativos, desarrollo de temas de WordPress, RAD proyectos (Desarrollo Rápido de Aplicaciones), OOPS (Programación Orientada a Objetos) Proyectos, soluciones CAD / CAM de redacción, programación y configuración de puerto de servicios públicos, el desarrollo web y la plataforma de interfaz soluciones, etc Scrum se adhiere a todos los principios y características que se describen más arriba ya que el marco es "heredada" de la propia Agile Agile.

Scrum ofrece una nueva y mejor forma de gestionar proyectos de software. Hay muchas razones técnicas por Scrum es popular y por qué muchas empresas Fortune 500 prefieren utilizar el marco para sus fines de desarrollo del proyecto. Mientras está siendo introducido a Agile Scrum, una pregunta que sin querer llega a la mente de uno es por qué es Scrum tan popular? ¿Por qué hay tanto "hype" sobre Scrum? ¿Ofrece Scrum una fórmula mágica, que puede hacer maravillas para su proyecto y el desarrollo de software? ¿Por qué debe una organización que ha estado siguiendo una metodología de desarrollo en particular, y se siente cómodo haciéndolo, debe cambiar a Scrum? Hay un artículo separado que se ocupa por completo con el por qué usted debe optar por Scrum. El punto es que este artículo se centra en explicar Scrum a las personas que son nuevos en el tema, y que tienen la menor idea de lo que el marco es sobre todo, y lo que puede "hacer" para usted. Se han realizado esfuerzos para explicar que Agile Scrum es aplicable a casi cualquier tipo de desarrollo de software, y posee ciertas características que hacen que el marco muy popular, así como "de gran alcance".

¿Cómo funciona Scrum?  
El proceso real de Scrum puede llegar a ser difícil de entender, al principio, para los principiantes de Scrum. A pesar de que la implementación de Scrum no es difícil, la gente necesita entender y familiarizarse sobre lo que es la subasta del producto, y cómo lo que realmente ocurre durante el proceso de Scrum. El segundo aspecto es llegar a conocer acerca de los eventos de Scrum. Las reuniones especiales, conocidos como "eventos" son importantes para el control de la actividad de desarrollo, y el análisis de la fiabilidad y la eficacia de la función desarrollada por el equipo. También ayudan a solicitar la opinión de los miembros del equipo, así como los propietarios de los proyectos de manera que el valor de negocio del proyecto no se ve afectada, y se mantiene en todo momento - incluso cuando el producto está siendo desarrollado. Vale la pena tener una "visión general" del proceso de primera.
   
Scrum 
 1. Concepción del proyecto - una idea!
Todos los proyectos, ya se trate de desarrollo de software, o de otro modo, comienzan con una "idea". Los proyectos se desarrollaron a partir de las necesidades. Un proyecto está previsto para cumplir con un requisito específico o lograr un objetivo determinado. Además, cada proyecto se traduce en "algo" dentro de un marco de tiempo específico - un proyecto no puede extenderse indefinidamente. Aquí es importante diferenciar entre un "proyecto" y un "programa". Los programas se denominan generalmente largo, e incluso puede durar años, a diferencia de los proyectos que tienen una vida útil relativamente corta y duran por un breve período, que van desde un par de meses y hasta un año.

Por lo general, una persona o un grupo de individuos se dan cuenta de que vale la pena poner en los esfuerzos y recursos, y desarrollar "algo" para que "otra cosa" puede cumplirse o servir fácilmente. Ese "algo" es el producto, y la "otra cosa" es la solución que el proyecto se supone que debe proporcionar. Esta etapa del desarrollo del proyecto implica una gran cantidad de sesiones de tormenta de ideas de debate y el cerebro, donde el producto se concibe y "aunque con el".

Scrum no figura en esta etapa. Sin embargo, la visión que los propietarios de los proyectos, puede, o puede afectar a la forma en que Scrum se implementa en el proyecto, en el futuro. Esto se debe a la naturaleza de producto a desarrollar puede requerir Scrum para ser configurado de una manera determinada para obtener resultados positivos del proyecto.

2. libere Project - Primeros pasos con el proyecto de software
Una vez que el proyecto está "pensado" el siguiente paso lógico es trabajar en el meollo de la cuestión relativa a la dinámica del proyecto - el objetivo del proyecto, la definición del producto, como el proyecto ideal es que la entrega del producto, de qué manera, lo que se debe ser la "fuerza" del equipo, ¿cuántos miembros del equipo, etc.

Proceso de desarrollo de Scrum no entra en la imagen, incluso en esta etapa. La documentación relativa al proyecto se crea y "todo" en relación con el producto a desarrollar se finaliza - en blanco y negro. Scrum no aboga por una extensa documentación. Usted no tiene que preparar a los diagramas de flujo del sistema de desarrollo y estructuras extensas de diseño para comenzar con el desarrollo de Scrum. Una idea básica será suficiente, y sólo se debe gastar tanto tiempo y esfuerzo que le permitirá empezar a "comenzar" con la actividad de desarrollo real. Lo suficiente información y las especificaciones para desarrollar algunas de las características más importantes del producto.

El lanzamiento del proyecto es atendido por el "propietario del producto" - la persona que funciona como un director de proyecto en el proyecto Scrum, el Scrum Master que el extranjero que Scrum se aplique correctamente y seguido por el equipo, mientras que el proyecto se está desarrollando, y las partes interesadas o propietarios de los proyectos que en realidad patrocinan el proyecto.

3. Creación de la cartera de producto (características del producto Lista) - Definición de las características del producto y funcionalidad  
El proceso de desarrollo de Scrum se inicia con la creación de una lista principal que contiene todas las características y funciones necesarias para crear el producto en su totalidad. En términos simples, todo el producto, que existe actualmente en el papel como "imaginario" por las partes interesadas y los responsables de los proyectos, se "descompone" en sus partes constituyentes, que consta de características y funcionalidades individuales. El producto es cuidadosamente y sistemáticamente, desglosado de manera que cada componente individual puede ser desarrollado, sometido a ensayo, y, finalmente, integrarse con otros componentes de software o funciones desarrolladas por el equipo durante los días. Características y funcionalidades desarrolladas individualmente con el tiempo puede "dar a luz" a un producto de trabajo cuando se integra o ensamblados más adelante.

Cada función o la lista artículo individual se conoce como una "Pila de Producto Item" o una "historia de usuario" en un lenguaje sencillo. Por lo tanto, la Pila de Producto o la lista maestra está fundamentalmente compuesto por elementos del backlog del producto o historias de usuario. La historia de usuario representa una característica del producto, y se desarrolla de forma individual por los miembros del equipo durante el proceso de desarrollo - los sprints diarias. Cada historia puede ser minuciosamente definido. La descripción, criterios de aceptación (Puntos que deben ser "cumplido" o satisfechas antes de que la historia puede ser considerada como desarrolló con éxito), su importancia en el proyecto, y la manera en que se supone que debe ser integrado en el producto final, etc se mencionan para cada historia de usuario.

Una vez creada la lista de características, se dispone en función de la importancia de cada historia de usuario de la cartera de productos. Historias de usuario importantes se disponen en la parte "superior" de la lista, historias menos importantes en el medio, y las características menos importantes y funcionalidad en la parte inferior.

4. reunión de planificación de Sprint - Planificación de la forma de desarrollar las características del producto  
Las funciones del backlog de ​​producto como el principal "columna vertebral" de todas las actividades de desarrollo relacionadas en Scrum. Una vez que se "desarrolla" por el dueño del producto y las partes interesadas, la actividad de desarrollo real puede comenzar. Una reunión especial conocido como "Planificación del Sprint"La reunión se llevó a cabo para iniciar la actividad de desarrollo. La reunión con la asistencia de todo el equipo de desarrollo, además del dueño del producto "PO" y el scrum master "SM".

La reunión se llevó a cabo en dos partes. En la primera parte, el dueño del producto selecciona algunas de las historias de los usuarios más importantes o las características del producto a partir de la parte superior de la pila de producto, y los transfiere a una lista temporal conocido como "Sprint Backlog" para fines de desarrollo. Durante la reunión, el propietario del producto tiene la oportunidad de explicar cada historia de usuario en detalles a los miembros del equipo - como historias de usuario se deben desarrollar idealmente, y cuáles son las actividades que el equipo debe llevar a cabo de manera que cada historia puede ser marcado como completado con éxito.

Durante la segunda mitad de la reunión, el equipo de desarrollo se analiza el trabajo pendiente del sprint y distribuye cada historia a los miembros individuales del equipo. En la práctica, los miembros del equipo deciden por unanimidad en cuanto a quién debe asumir que la historia en función de sus habilidades de desarrollo y niveles de experiencia. Elementos simples y fácilmente desarrollables se dan a los menos experimentados o "fresco", mientras que las historias difíciles, o más complejas son tomados para el desarrollo por los programadores o desarrolladores más experimentados y de alto nivel.

5. Los sprints diarios -. Desarrollar las funciones del producto
Esta es el área principal de actividad en Scrum. Todo el producto se desarrolla en "bits" y "piezas" a través de los ciclos de velocidad diarias. Un ciclo de sprint no es más que una colección de trabajo o días de "desarrollo" durante la cual los miembros del equipo en realidad se sientan delante de un PC y se desarrollan las características de funcionalidad o de productos. El ciclo del sprint es el momento en caja y que no se debe extender su plazo.
 
 
 
 
 
 
 

Cada elemento incluido en el sprint backlog durante la reunión de planificación de Sprint debe desarrollarse mientras el sprint está actualmente en curso. Una breve reunión conocida como "Reunión de Scrum Diario" se mantiene durante un máximo de 15 minutos cada día antes de que los miembros del equipo comienzan con su trabajo. El propósito de la reunión es para tener una idea en cuanto a la cantidad de trabajo se ha completado por cada miembro el día antes, y lo que cada miembro se propone hacer "hoy". Si un miembro del equipo se enfrenta a algún problema o problemas, se puede mencionar en la reunión, y el maestro scrum se asegurará de que el problema se resuelve rápidamente.

En Scrum, los sprints diarias normalmente pueden durar desde 2 semanas hasta un máximo de un mes. La duración de la carrera se decidió en la segunda etapa - la liberación del proyecto - y no debería extenderse, en ningún caso - incluso si cualquiera de las historias de usuario en el sprint backlog no se han desarrollado, o cuyo desarrollo es incompleto.

6. Sprint review -. Comprobación y verificación de la productividad (Es el desarrollo de acuerdo?)
Scrum hace hincapié en el desarrollo de la funcionalidad "entregable" al final del ciclo de Sprint diaria. Cada historia de usuario desarrollado durante el sprint diaria está marcada por el dueño del producto y verificado por su fiabilidad, los niveles de aceptación, y si es "libre de errores". En Scrum, es muy importante para desarrollar unas funciones sin errores - cada historia de usuario debe ser probado adecuadamente para cualquier regresión, y si cumple los criterios de aceptación relacionados con su desarrollo.

Justo después de que termine el ciclo de sprint diario, se realiza una reunión de inmediato para revisar el desarrollo llevado a cabo por el equipo. Es importante diferenciar entre los sprints del día y el ciclo de sprint. El sprint diario es la actividad de desarrollo llevado a cabo por todo el equipo en un día de trabajo en particular. Muchos de esos "sprints diarios" se combinan para formar el "Daily Sprint Ciclo", también conocido como el "ciclo de incremento del producto" en Agile. La reunión se celebró en el final del ciclo de incremento del producto - el ciclo del sprint diario. Es atendido principalmente por el dueño del producto, el scrum master, y los miembros del equipo. No es obligatorio para las partes interesadas a asistir a esta reunión. Ellos pueden optar por asistir a la misma, si así lo desean.

El objetivo principal de este evento, o más bien el encuentro, es comprobar si las características se han desarrollado por el equipo de acuerdo con el plan de producción, y si la funcionalidad tiene algún defecto de "fabricación". Cada característica debe ser plenamente probado por cualquier defecto por el equipo antes de presentarlo en la reunión. El dueño del producto verifica si la función está libre de errores y comprueba si cumple los criterios de aceptación relacionados con ella. Es una especie de "final" control efectuado antes de presentar el desarrollo de las partes interesadas y los responsables de los proyectos en la siguiente reunión retrospectiva del sprint. Durante la reunión, el dueño del producto indica al equipo cómo se puede mejorar su funcionamiento y ofrecer aún mejor la productividad mediante el empleo de prácticas y estándares de programación más eficientes.

7. Sprint retrospectiva - Finalización de la funcionalidad del producto y la contemplación sobre nuevas mejoras  
Agile Scrum aboga por la participación del cliente. El cliente es una entidad muy importante en Scrum, y tiene la última palabra en cuanto al desarrollo de las características del producto se refiere. El manifiesto ágil hincapié principalmente en la participación del cliente y la entrega de los incrementos de productos de duración limitada, ya que estos dos aspectos son muy importantes para el desarrollo de proyectos exitosos. Un cliente "satisfecho" con frecuencia "regresa" para desarrollar más proyectos ya proyectos exitosos ayudan al cliente a ganar mayores márgenes de beneficio.

La retrospectiva ofrece una oportunidad para que todo el equipo para demostrar su productividad frente a las partes interesadas y clientes. Además del dueño del producto, scrum master, el equipo de desarrollo, la reunión también podrán asistir a los usuarios finales, el personal del equipo técnico, proveedores, distribuidores, e incluso otros empleados ya que el propósito principal de la reunión es aprovechar la retroalimentación de los individuos y entidades estrechamente vinculadas con el mercado, y que tienen un buen conocimiento sobre cuáles productos son propensos a "marcar" en el mercado una vez que se lanzó el producto, y lo que puede ayudar al producto en la "venta" características.

La retrospectiva también ofrece una oportunidad para todo el equipo, así como el cliente de reflexionar sobre el proceso de desarrollo, y descubrir qué más se podría hacer para mejorar el producto. Las discusiones se llevan a cabo para determinar la velocidad a la que las historias de usuario en la actualidad se están desarrollando por el equipo, y qué nuevos procesos o métodos deben introducirse para acelerar el proceso.

Suscríbete a la versión permanente y gratuita de la herramienta de gestión de proyectos Quickscrum para tener una idea de cómo funciona la herramienta y lo que tiene que ofrecer. Para las personas que son nuevos en el proceso de scrum puede ser que sea difícil de entender cómo se implementa marco Agile en proyectos reales. Si quieres saber más sobre scrum y su aplicación, y el deseo de desarrollar proyectos de software dinámicas y rentables, por favor envíenos un correo electrónico a support@quickscrum.com - podemos enviarle documentación de formación scrum para ayudarle a saber más acerca de scrum .