Scrum Methodology in Agile Software Development - Revision history

Tkokotas at 15:13, 18 December 2018

2018-12-18T15:13:54Z

← Older revision		Revision as of 15:13, 18 December 2018
Line 1:		Line 1:
			''Developed by Giacomo Montagner''


	Today market is affected by uncertainly and sudden changes, in these conditions most of the models used in the 20th century to develop software are not still appropriate.[[Wikipedia:Waterfall model \| Waterfall model]] , probably the most famous between them, is characterized by a stiff structure which can’t cope with the turbulent needs of the actual market.		Today market is affected by uncertainly and sudden changes, in these conditions most of the models used in the 20th century to develop software are not still appropriate.[[Wikipedia:Waterfall model \| Waterfall model]] , probably the most famous between them, is characterized by a stiff structure which can’t cope with the turbulent needs of the actual market.
	In recent years many innovations are been enhanced in software engineering with a particular focus on the flexibility of these methods in order to cope with the customers' and markets' needs; surely [[Wikipedia: Agile Software Development \|Agile Software Development (ASD)]] is between them.		In recent years many innovations are been enhanced in software engineering with a particular focus on the flexibility of these methods in order to cope with the customers' and markets' needs; surely [[Wikipedia: Agile Software Development \|Agile Software Development (ASD)]] is between them.

S150821: /* Team self-organization */

2015-09-28T22:06:33Z

Team self-organization

← Older revision		Revision as of 22:06, 28 September 2015
Line 72:		Line 72:
	*members can gauge the group’s progress;		*members can gauge the group’s progress;
	*members can observe each other’s contribution;		*members can observe each other’s contribution;
	*members feel safe to give each other unvarnished feedback.<ref name='James'>M. James,2010,Scrum Reference Card~~, Michael James,~~[[http://scrumreferencecard.com/]]</ref>		*members feel safe to give each other unvarnished feedback.<ref name='James'>M. James,2010,Scrum Reference Card[[http://scrumreferencecard.com/]]</ref>

S150821: /* Application */

2015-09-28T22:01:38Z

Application

← Older revision		Revision as of 22:01, 28 September 2015
Line 44:		Line 44:
	Basically Scrum consists in a sequence of fixed-length iterations called '''Sprint''' that are the fundamental units in which the whole project is divided. As the picture shows Scrum framework is really simple: it starts from a vision like all projects. This idea is converted into a plan during the preliminary meetings where customers and developers identifies the main software requirements and defines the Product Backlog. This represents the entire amount of work that has to be done in order to develop the software. In the next step Product Backlog is divided into several Sprint Backlogs that define which tasks have to be done during the following Sprint. During these iterations the product experiences an incremental development at the end of which it is potentially shippable.		Basically Scrum consists in a sequence of fixed-length iterations called '''Sprint''' that are the fundamental units in which the whole project is divided. As the picture shows Scrum framework is really simple: it starts from a vision like all projects. This idea is converted into a plan during the preliminary meetings where customers and developers identifies the main software requirements and defines the Product Backlog. This represents the entire amount of work that has to be done in order to develop the software. In the next step Product Backlog is divided into several Sprint Backlogs that define which tasks have to be done during the following Sprint. During these iterations the product experiences an incremental development at the end of which it is potentially shippable.

	Every Sprint is managed by one or more '''cross-functional and self-organizing teams''' each composed by seven people. There are also other two actors whose task is to be supportive of the software development. One is the '''Product Owner''' who mainly handles customers contacts, and the other is the '''Scrum Master''' whose main task is to ensure that development team can work without obstacles.		Every Sprint is managed by one or more '''cross-functional and self-organizing teams''' each composed by seven people. There are also other two actors whose task is to be supportive of the software development. One is the '''Product Owner''' who mainly handles customers' contacts, and the other is the '''Scrum Master''' whose main task is to ensure that development team can work without obstacles.

	Each sprint usually lasts from 2 to 4 weeks, in this period there are at least one meeting between the Product Owner and Development Team in order to define the main objectives; then there are also short daily meetings held every morning to enhance communication, inform customers, developers, and managers on the status of the project, identify any problems encountered, and keep the entire team focused on a common goal.<ref name='Cohen'></ref>		Each sprint usually lasts from 2 to 4 weeks, in this period there are at least one meeting between the Product Owner and Development Team in order to define the main objectives; then there are also short daily meetings held every morning to enhance communication, inform customers, developers, and managers on the status of the project, identify any problems encountered, and keep the entire team focused on a common goal.<ref name='Cohen'></ref>

S150821: /* Manifesto for the Agile Software development */

2015-09-28T22:00:43Z

Manifesto for the Agile Software development

← Older revision		Revision as of 22:00, 28 September 2015
Line 33:		Line 33:


	*'''“Individuals and interactions”''': with these words founders want to remark the power of human being creativity and also the ability of each man to collaborate with his other ~~similars~~. The stiffness of Waterfall model is instead represented by “processes and tools” where people was used to follow only what the plan required.		*'''“Individuals and interactions”''': with these words founders want to remark the power of human being creativity and also the ability of each man to collaborate with his other similar. The stiffness of Waterfall model is instead represented by “processes and tools” where people was used to follow only what the plan required.
	*'''“Working software“''': here there is a clear reference to the new way of developing software where at every iteration a working program is realised. This is different from the previous model in which a working program couldn’t be seen until the end of the project. This feature is put over the “comprehensive documentation” which characterizes especially Waterfall model.		*'''“Working software“''': here there is a clear reference to the new way of developing software where at every iteration a working program is realised. This is different from the previous model in which a working program couldn’t be seen until the end of the project. This feature is put over the “comprehensive documentation” which characterizes especially Waterfall model.
	*'''“Customer collaboration”''': it means that there must be a straight relationship between customer and developer in order to define time by time the projects requirements and evaluate every realise.		*'''“Customer collaboration”''': it means that there must be a straight relationship between customer and developer in order to define time by time the projects requirements and evaluate every realise.
	*'''“Responding to change over following a plan”''' : this sentence encloses the essence of Agile software Development that is to cope with turbulent markets by being flexible and by responding quickly to change. This concept was remarked by the founders in one of the twelve principles which follow the manifesto which says “Welcome changing requirements, even late in development […]”.<ref name='Manifesto'></ref>		*'''“Responding to change over following a plan”''': this sentence encloses the essence of Agile software Development that is to cope with turbulent markets by being flexible and by responding quickly to change. This concept was remarked by the founders in one of the twelve principles which follow the manifesto which says “Welcome changing requirements, even late in development […]”.<ref name='Manifesto'></ref>

	=Application=		=Application=

S150821 at 21:56, 28 September 2015

2015-09-28T21:56:46Z

← Older revision		Revision as of 21:56, 28 September 2015
Line 26:		Line 26:

	===Manifesto for the Agile Software development===		===Manifesto for the Agile Software development===
	A few years before Poppoendieck’s publication, on February 2001,a group of seventeen software developers published in a work called “Manifesto for the Agile Software Development”<ref name='Manifesto'>K. Beck et ~~all~~., 2001, Manifesto for Agile Software Development[http://www.agilemanifesto.org/]</ref> the main principles of Agile Software development.		A few years before Poppoendieck’s publication, on February 2001,a group of seventeen software developers published in a work called “Manifesto for the Agile Software Development”<ref name='Manifesto'>K. Beck et al., 2001, Manifesto for Agile Software Development[http://www.agilemanifesto.org/]</ref> the main principles of Agile Software development.

S150821: /* Sprint Planning Meeting */

2015-09-28T21:51:00Z

Sprint Planning Meeting

← Older revision		Revision as of 21:51, 28 September 2015
Line 95:		Line 95:
	Meetings are the fundamental tool used during the whole Scrum process. Usually they are facilitated by the Scrum master who however has no decision-making authority over them. There are different typologies of meetings according to the different phase of the process in which we are.		Meetings are the fundamental tool used during the whole Scrum process. Usually they are facilitated by the Scrum master who however has no decision-making authority over them. There are different typologies of meetings according to the different phase of the process in which we are.
	===Sprint Planning Meeting===		===Sprint Planning Meeting===
	At the beginning of each Sprint, the Product Owner and team hold a Sprint Planning Meeting to define on which '''Product Backlog Items (PBIs)''' they will go to work during the next Sprint. During this meeting "The Product Owner is responsible for declaring which items are the most important to the business" instead "the team is responsible for selecting the amount of work they feel they can implement" (''M. James, 2010'')<ref name='James'></ref>.In this phase in perfect Lean perspective ~~the~~ team “pulls” work from the Product Backlog to the Sprint Backlog. At the end of the meeting the selected items are broken into a provisional list of Sprint task. The maximum time that can be used to do Planning meeting, known as '''timebox''', is of eight hours.		At the beginning of each Sprint, the Product Owner and team hold a Sprint Planning Meeting to define on which '''Product Backlog Items (PBIs)''' they will go to work during the next Sprint. During this meeting "The Product Owner is responsible for declaring which items are the most important to the business" instead "the team is responsible for selecting the amount of work they feel they can implement" (''M. James, 2010'')<ref name='James'></ref>.In this phase in perfect Lean perspective Scrum team “pulls” work from the Product Backlog to the Sprint Backlog. At the end of the meeting the selected items are broken into a provisional list of Sprint task. The maximum time that can be used to do Planning meeting, known as '''timebox''', is of eight hours.

	===Daily Scrum and Sprint Execution===		===Daily Scrum and Sprint Execution===

S150821: /* Sprint */

2015-09-28T21:48:57Z

Sprint

← Older revision		Revision as of 21:48, 28 September 2015
Line 89:		Line 89:

	==Sprint==		==Sprint==
	As it is already explained before Sprint (or iteration) is the fundamental unit in which the whole project is divided. It is characterized by a fixed length of 2 weeks or 30 days and by a goal to achieve. At the beginning of each sprint Scrum team , Product Owner , Scrum Master and sometimes also stakeholders hold a meeting, called Sprint Planning meeting. During this encounter it is defined the Sprint Backlog which states what are the goals and requirements of the next Sprint. After this further meetings inside development team will be held in order to define in more detail how achieving the common goals stated in the previous meetings.		As it is already explained before Sprint (or iteration) is the fundamental unit in which the whole project is divided. It is characterized by a fixed length of 2 weeks or 30 days and by a goal to achieve. At the beginning of each sprint Scrum team , Product Owner , Scrum Master and sometimes also stakeholders hold a meeting, called Sprint Planning meeting. During this encounter it is defined the Sprint Backlog which states what are the goals and requirements of the next Sprint. After this, further meetings inside development team will be held in order to define in more detail how achieving the common goals stated in the previous meetings.

	==Scrum Meetings==		==Scrum Meetings==
	[[File:Scrum_meetings.png\|350px\|thumb\|right\|Scrum Meetings<ref name='James'></ref>]]		[[File:Scrum_meetings.png\|350px\|thumb\|right\|Scrum Meetings<ref name='James'></ref>]]

S150821: /* Team self-organization */

2015-09-28T21:47:00Z

Team self-organization

← Older revision		Revision as of 21:47, 28 September 2015
Line 66:		Line 66:
	====Team self-organization====		====Team self-organization====
	Team self-organization is a crucial point in the scrum methodology. This new concept is well explained in the sentence “it is told developer what needs to be done not how to do it”<ref name='Cohen'></ref>. It means that they can autonomously choose the way to reach commitments.		Team self-organization is a crucial point in the scrum methodology. This new concept is well explained in the sentence “it is told developer what needs to be done not how to do it”<ref name='Cohen'></ref>. It means that they can autonomously choose the way to reach commitments.
	Furthermore, as it is explained previously, during Sprint execution team members develop an intrinsic interest in shared goals in this way self-organizing teams can radically outperform larger than traditionally managed teams. It has to be specified that an optimal self-organization takes time: it may be possible that for the first few sprints developers perform worse than when they work in the traditional way.		Furthermore, as it is explained previously, during Sprint execution team members develop an intrinsic interest in shared goals, in this way self-organizing teams can radically outperform larger than traditionally managed teams. It has to be specified that an optimal self-organization takes time: it may be possible that for the first few sprints developers perform worse than when they work in the traditional way.

	Some requirements are necessary to gain a good team self-organization:		Some requirements are necessary to gain a good team self-organization:

S150821: /* Team self-organization */

2015-09-28T21:46:17Z

Team self-organization

← Older revision		Revision as of 21:46, 28 September 2015
Line 66:		Line 66:
	====Team self-organization====		====Team self-organization====
	Team self-organization is a crucial point in the scrum methodology. This new concept is well explained in the sentence “it is told developer what needs to be done not how to do it”<ref name='Cohen'></ref>. It means that they can autonomously choose the way to reach commitments.		Team self-organization is a crucial point in the scrum methodology. This new concept is well explained in the sentence “it is told developer what needs to be done not how to do it”<ref name='Cohen'></ref>. It means that they can autonomously choose the way to reach commitments.
	Furthermore, as it is explained previously, during Sprint execution, team members develop an intrinsic interest in shared goals in this way self-organizing teams can radically outperform larger than traditionally managed teams. It has to be specified that an optimal self-organization takes time: it may be possible that for the first few sprints developers perform worse than when they work in the traditional way.		Furthermore, as it is explained previously, during Sprint execution team members develop an intrinsic interest in shared goals in this way self-organizing teams can radically outperform larger than traditionally managed teams. It has to be specified that an optimal self-organization takes time: it may be possible that for the first few sprints developers perform worse than when they work in the traditional way.

	Some requirements are necessary to gain a good team self-organization:		Some requirements are necessary to gain a good team self-organization:

S150821: /* Team self-organization */

2015-09-28T21:45:30Z

Team self-organization

← Older revision		Revision as of 21:45, 28 September 2015
Line 65:		Line 65:

	====Team self-organization====		====Team self-organization====
	Team self-organization is a crucial point in the scrum methodology. This new concept is well explained by the sentence “it is told developer what needs to be done not how to do it”<ref name='Cohen'></ref>. It means that they can autonomously choose the way to reach commitments.		Team self-organization is a crucial point in the scrum methodology. This new concept is well explained in the sentence “it is told developer what needs to be done not how to do it”<ref name='Cohen'></ref>. It means that they can autonomously choose the way to reach commitments.
	Furthermore, as it is explained previously, during Sprint execution, team members develop an intrinsic interest in shared goals in this way self-organizing teams can radically outperform larger than traditionally managed teams. It has to be specified that an optimal self-organization takes time: it may be possible that for the first few sprints developers perform worse than when they work in the traditional way.		Furthermore, as it is explained previously, during Sprint execution, team members develop an intrinsic interest in shared goals in this way self-organizing teams can radically outperform larger than traditionally managed teams. It has to be specified that an optimal self-organization takes time: it may be possible that for the first few sprints developers perform worse than when they work in the traditional way.