Extreme Programming (XP) - Revision history

Mmusij: /* See Also */

2018-12-21T22:39:54Z

Mmusij: /* See Also */

2018-12-21T22:37:54Z

Mmusij: /* Primary Practices */

2018-12-20T02:17:27Z

Primary Practices

← Older revision		Revision as of 02:17, 20 December 2018
Line 32:		Line 32:
	* '''Ten Minute Build''' – an efficient software build and compilation that can be done within ten minutes improves the probability that it will be done more often and there will be more frequency of feedback if there are any compilation issues in the code. For longer running build and compile times, then these are an indicator that it may not be as efficient and so some refactoring is needed.		* '''Ten Minute Build''' – an efficient software build and compilation that can be done within ten minutes improves the probability that it will be done more often and there will be more frequency of feedback if there are any compilation issues in the code. For longer running build and compile times, then these are an indicator that it may not be as efficient and so some refactoring is needed.
	* [[Test Driven Development (TDD)\|Test-First Programming]] – this automated testing approach where the test is written first, and then the software code is written to satisfy the test improves software quality with a defect prevention approach rather than using defect detection methods after the software has been built. The approach is more cost effective at resolving issues before they happen and improves cohesion in the code and a rolling horizon of confidence in the product.		* [[Test Driven Development (TDD)\|Test-First Programming]] – this automated testing approach where the test is written first, and then the software code is written to satisfy the test improves software quality with a defect prevention approach rather than using defect detection methods after the software has been built. The approach is more cost effective at resolving issues before they happen and improves cohesion in the code and a rolling horizon of confidence in the product.

	~~[[File:Test_Driven_Development_(TDD).jpg\|500px\|Test Driven Development (TDD)]]~~

	* [[Continuous Integration]] – the continual ability to test and integrate software components provides regular feedback on any issues with integration and the health of the software code. This approach is most often done on an automated infrastructure that works asynchronously as the code is written and checked into the code repository, which is then used by the build servers to autonomously compile and execute tests and provide feedback if there were any issues.		* [[Continuous Integration]] – the continual ability to test and integrate software components provides regular feedback on any issues with integration and the health of the software code. This approach is most often done on an automated infrastructure that works asynchronously as the code is written and checked into the code repository, which is then used by the build servers to autonomously compile and execute tests and provide feedback if there were any issues.
	* '''Incremental Design''' – using a proportion of the time to continually improve and address the software design needs in context and as the code is written helps to incorporate feedback and learning. This emergent approach to design allows for experimentation and evidence gathering to inform the correct approach to use rather than design up front practices, which can be full of assumptions.		* '''Incremental Design''' – using a proportion of the time to continually improve and address the software design needs in context and as the code is written helps to incorporate feedback and learning. This emergent approach to design allows for experimentation and evidence gathering to inform the correct approach to use rather than design up front practices, which can be full of assumptions.

Mmusij at 01:29, 20 December 2018

2018-12-20T01:29:31Z

Mmusij: /* References */

2018-12-20T01:26:58Z

References

← Older revision		Revision as of 01:26, 20 December 2018
Line 50:		Line 50:
	* '''Negotiated Scope Contract''' – the intention is to migrate away from fixed contracts, and instead, move towards an agreement that satisfies both customer and supplier with less specifics, more smaller agreements, and a move towards time and materials with constant collaboration.		* '''Negotiated Scope Contract''' – the intention is to migrate away from fixed contracts, and instead, move towards an agreement that satisfies both customer and supplier with less specifics, more smaller agreements, and a move towards time and materials with constant collaboration.
	* '''Pay Per Use''' – using customer revenue as a form of feedback for systems that charge for their usage helps to align relevant and useful features to the economics and the return on the investment		* '''Pay Per Use''' – using customer revenue as a form of feedback for systems that charge for their usage helps to align relevant and useful features to the economics and the return on the investment

			==See Also==
			* [[Continuous Delivery]]

	==References==		==References==
	# Extreme Programming Explained: Embrace Change, Beck K, Andres C, 2005		# Extreme Programming Explained: Embrace Change, Beck K, Andres C, 2005
	# [http://www.extremeprogramming.org http://www.extremeprogramming.org] accessed 03 January 2018		# [http://www.extremeprogramming.org http://www.extremeprogramming.org] accessed 03 January 2018

Mmusij: Mmusij moved page EXtreme Programming (XP) to Extreme Programming (XP)

2018-11-28T06:42:04Z

Mmusij moved page EXtreme Programming (XP) to Extreme Programming (XP)

← Older revision	Revision as of 06:42, 28 November 2018
(No difference)

Mmusij: Mmusij moved page EXtreme Programming to EXtreme Programming (XP)

2018-11-28T06:41:39Z

Mmusij moved page EXtreme Programming to EXtreme Programming (XP)

← Older revision	Revision as of 06:41, 28 November 2018
(No difference)

Mmusij: /* References */

2018-11-28T06:41:14Z

References

← Older revision		Revision as of 06:41, 28 November 2018
Line 53:		Line 53:
	==References==		==References==
	# Extreme Programming Explained: Embrace Change, Beck K, Andres C, 2005		# Extreme Programming Explained: Embrace Change, Beck K, Andres C, 2005
			# [http://www.extremeprogramming.org http://www.extremeprogramming.org] accessed 03 January 2018

Mmusij: /* Corollary Practices */

2018-11-27T05:29:36Z

Corollary Practices

Mmusij: /* Primary Practices */

2018-11-27T05:28:36Z

Primary Practices

← Older revision		Revision as of 22:39, 21 December 2018
Line 51:		Line 51:
	* [[Continuous Delivery]]		* [[Continuous Delivery]]
	* [[Behaviour Driven Development (BDD)]]		* [[Behaviour Driven Development (BDD)]]
			* [[Mob Programming]]

	==References==		==References==
	# Extreme Programming Explained: Embrace Change, Beck K, Andres C, 2005		# Extreme Programming Explained: Embrace Change, Beck K, Andres C, 2005
	# [http://www.extremeprogramming.org http://www.extremeprogramming.org] accessed 03 January 2018		# [http://www.extremeprogramming.org http://www.extremeprogramming.org] accessed 03 January 2018

← Older revision		Revision as of 22:37, 21 December 2018
Line 50:		Line 50:
	==See Also==		==See Also==
	* [[Continuous Delivery]]		* [[Continuous Delivery]]
			* [[Behaviour Driven Development (BDD)]]

	==References==		==References==
	# Extreme Programming Explained: Embrace Change, Beck K, Andres C, 2005		# Extreme Programming Explained: Embrace Change, Beck K, Andres C, 2005
	# [http://www.extremeprogramming.org http://www.extremeprogramming.org] accessed 03 January 2018		# [http://www.extremeprogramming.org http://www.extremeprogramming.org] accessed 03 January 2018

← Older revision		Revision as of 01:29, 20 December 2018
Line 25:		Line 25:
	* '''Informative Workspace''' – using the workspace to provide information about the project and the work, such as card walls for example, as well as a workspace that caters for human needs such as collaboration, social interaction as well as privacy and quiet		* '''Informative Workspace''' – using the workspace to provide information about the project and the work, such as card walls for example, as well as a workspace that caters for human needs such as collaboration, social interaction as well as privacy and quiet
	* '''Energized Work''' – provisioning for a sustainable working practice that includes periods of high intensity as well as periods of rest time. The intention here is to respect the human body and mind in order to be more efficient rather than working for extended periods of time with mediocre results		* '''Energized Work''' – provisioning for a sustainable working practice that includes periods of high intensity as well as periods of rest time. The intention here is to respect the human body and mind in order to be more efficient rather than working for extended periods of time with mediocre results
	* ~~'''~~Pair Programming~~'''~~ – pair programming provides a highly collaborative interaction that yields high quality code and propels teams forwards with new ideas and creativity, however, personal space must also be respected		* [[Pair Programming]] – pair programming provides a highly collaborative interaction that yields high quality code and propels teams forwards with new ideas and creativity, however, personal space must also be respected
	* ~~'''~~Stories~~'''~~ – using conversation reminders to interact with the team and understand the needs and context rather than relying on requirements and written documents to replace conversations		* [[User Stories\|Stories]] – using conversation reminders to interact with the team and understand the needs and context rather than relying on requirements and written documents to replace conversations
	* '''Weekly Cycle''' – in XP the working cycles are set to a weekly rhythm to provide high intensity and opportunities for feedback and adaptation		* '''Weekly Cycle''' – in XP the working cycles are set to a weekly rhythm to provide high intensity and opportunities for feedback and adaptation
	* '''Quarterly Cycle''' – as a form of release planning, the quarterly cycle sets a project horizon as a longer rhythm that supports interactions with suppliers and stakeholders		* '''Quarterly Cycle''' – as a form of release planning, the quarterly cycle sets a project horizon as a longer rhythm that supports interactions with suppliers and stakeholders
	* '''Slack''' – providing some slack time e.g. 20% of the working week to provide opportunities for learning and thinking can be invaluable and has indirect benefits for the product as more improved and efficient ways of doing things are allowed to emerge		* '''Slack''' – providing some slack time e.g. 20% of the working week to provide opportunities for learning and thinking can be invaluable and has indirect benefits for the product as more improved and efficient ways of doing things are allowed to emerge
	* '''Ten Minute Build''' – an efficient software build and compilation that can be done within ten minutes improves the probability that it will be done more often and there will be more frequency of feedback if there are any compilation issues in the code. For longer running build and compile times, then these are an indicator that it may not be as efficient and so some refactoring is needed.		* '''Ten Minute Build''' – an efficient software build and compilation that can be done within ten minutes improves the probability that it will be done more often and there will be more frequency of feedback if there are any compilation issues in the code. For longer running build and compile times, then these are an indicator that it may not be as efficient and so some refactoring is needed.
	* ~~'''~~Test-First Programming~~'''~~ – this automated testing approach where the test is written first, and then the software code is written to satisfy the test improves software quality with a defect prevention approach rather than using defect detection methods after the software has been built. The approach is more cost effective at resolving issues before they happen and improves cohesion in the code and a rolling horizon of confidence in the product.		* [[Test Driven Development (TDD)\|Test-First Programming]] – this automated testing approach where the test is written first, and then the software code is written to satisfy the test improves software quality with a defect prevention approach rather than using defect detection methods after the software has been built. The approach is more cost effective at resolving issues before they happen and improves cohesion in the code and a rolling horizon of confidence in the product.

	[[File:Test_Driven_Development_(TDD).jpg\|500px\|Test Driven Development (TDD)]]		[[File:Test_Driven_Development_(TDD).jpg\|500px\|Test Driven Development (TDD)]]

	* ~~'''~~Continuous Integration~~'''~~ – the continual ability to test and integrate software components provides regular feedback on any issues with integration and the health of the software code. This approach is most often done on an automated infrastructure that works asynchronously as the code is written and checked into the code repository, which is then used by the build servers to autonomously compile and execute tests and provide feedback if there were any issues.		* [[Continuous Integration]] – the continual ability to test and integrate software components provides regular feedback on any issues with integration and the health of the software code. This approach is most often done on an automated infrastructure that works asynchronously as the code is written and checked into the code repository, which is then used by the build servers to autonomously compile and execute tests and provide feedback if there were any issues.
	* '''Incremental Design''' – using a proportion of the time to continually improve and address the software design needs in context and as the code is written helps to incorporate feedback and learning. This emergent approach to design allows for experimentation and evidence gathering to inform the correct approach to use rather than design up front practices, which can be full of assumptions.		* '''Incremental Design''' – using a proportion of the time to continually improve and address the software design needs in context and as the code is written helps to incorporate feedback and learning. This emergent approach to design allows for experimentation and evidence gathering to inform the correct approach to use rather than design up front practices, which can be full of assumptions.

Line 43:		Line 43:
	* '''Incremental Deployment''' – releasing often will small amounts of risk seems to be better than releasing infrequently with large amounts of risk, as the team get more practice at releasing and each release can be rolled back instantly. The impact to customers and users is also reduced with more frequent releases reducing the need for training and other modes of knowledge transfer.		* '''Incremental Deployment''' – releasing often will small amounts of risk seems to be better than releasing infrequently with large amounts of risk, as the team get more practice at releasing and each release can be rolled back instantly. The impact to customers and users is also reduced with more frequent releases reducing the need for training and other modes of knowledge transfer.
	* '''Team Continuity''' – working with long running persistent teams avoids the ramp up and ramp down between projects, and preserves a well running team rather than disbanding them after a project. A positive side effect is the longer running teams develop some deep skills and domain knowledge, and after a while evolve into product teams rather than project teams.		* '''Team Continuity''' – working with long running persistent teams avoids the ramp up and ramp down between projects, and preserves a well running team rather than disbanding them after a project. A positive side effect is the longer running teams develop some deep skills and domain knowledge, and after a while evolve into product teams rather than project teams.
	* ~~'''~~Root Cause Analysis~~'''~~ – determining the root cause rather than the superficial cause can yield a deeper understanding of the issues and uncover deep dysfunctions. Arguably it is more cost effective to fix the underlying issues rather than apply the short term workaround.		* [[Root Cause Analysis]] – determining the root cause rather than the superficial cause can yield a deeper understanding of the issues and uncover deep dysfunctions. Arguably it is more cost effective to fix the underlying issues rather than apply the short term workaround.
	* '''Shared Code''' – shared code ownership is intended to encourage a Development Team to collaborate to create the software assets, improve their quality and resolve issues as and when they are detected rather than depending upon single individuals to “own” parts of the code until completion.		* '''Shared Code''' – shared code ownership is intended to encourage a Development Team to collaborate to create the software assets, improve their quality and resolve issues as and when they are detected rather than depending upon single individuals to “own” parts of the code until completion.
	* '''Code and Tests''' – the intention is to only produce artefacts that contribute to what the system does today and what the system will do tomorrow, with everything else being waste[16]. Hence, the code and the associated tests are intended to be the long living artefacts which can then be used to regenerate other artefacts, such as documentation.		* '''Code and Tests''' – the intention is to only produce artefacts that contribute to what the system does today and what the system will do tomorrow, with everything else being waste[16]. Hence, the code and the associated tests are intended to be the long living artefacts which can then be used to regenerate other artefacts, such as documentation.

← Older revision		Revision as of 05:29, 27 November 2018
Line 40:		Line 40:
	===Corollary Practices===		===Corollary Practices===
	The corollary practices also include:		The corollary practices also include:
	* Real Customer Involvement – having access to real customers that can provide accurate and meaningful feedback will have a dramatic effect on the end product, its usefulness and the trade-offs needed when working to timelines		* '''Real Customer Involvement''' – having access to real customers that can provide accurate and meaningful feedback will have a dramatic effect on the end product, its usefulness and the trade-offs needed when working to timelines
	* Incremental Deployment – releasing often will small amounts of risk seems to be better than releasing infrequently with large amounts of risk, as the team get more practice at releasing and each release can be rolled back instantly. The impact to customers and users is also reduced with more frequent releases reducing the need for training and other modes of knowledge transfer.		* '''Incremental Deployment''' – releasing often will small amounts of risk seems to be better than releasing infrequently with large amounts of risk, as the team get more practice at releasing and each release can be rolled back instantly. The impact to customers and users is also reduced with more frequent releases reducing the need for training and other modes of knowledge transfer.
	* Team Continuity – working with long running persistent teams avoids the ramp up and ramp down between projects, and preserves a well running team rather than disbanding them after a project. A positive side effect is the longer running teams develop some deep skills and domain knowledge, and after a while evolve into product teams rather than project teams.		* '''Team Continuity''' – working with long running persistent teams avoids the ramp up and ramp down between projects, and preserves a well running team rather than disbanding them after a project. A positive side effect is the longer running teams develop some deep skills and domain knowledge, and after a while evolve into product teams rather than project teams.
	* Root Cause Analysis – determining the root cause rather than the superficial cause can yield a deeper understanding of the issues and uncover deep dysfunctions. Arguably it is more cost effective to fix the underlying issues rather than apply the short term workaround.		* '''Root Cause Analysis''' – determining the root cause rather than the superficial cause can yield a deeper understanding of the issues and uncover deep dysfunctions. Arguably it is more cost effective to fix the underlying issues rather than apply the short term workaround.
	* Shared Code – shared code ownership is intended to encourage a Development Team to collaborate to create the software assets, improve their quality and resolve issues as and when they are detected rather than depending upon single individuals to “own” parts of the code until completion.		* '''Shared Code''' – shared code ownership is intended to encourage a Development Team to collaborate to create the software assets, improve their quality and resolve issues as and when they are detected rather than depending upon single individuals to “own” parts of the code until completion.
	* Code and Tests – the intention is to only produce artefacts that contribute to what the system does today and what the system will do tomorrow, with everything else being waste[16]. Hence, the code and the associated tests are intended to be the long living artefacts which can then be used to regenerate other artefacts, such as documentation.		* '''Code and Tests''' – the intention is to only produce artefacts that contribute to what the system does today and what the system will do tomorrow, with everything else being waste[16]. Hence, the code and the associated tests are intended to be the long living artefacts which can then be used to regenerate other artefacts, such as documentation.
	* Single Code Base – avoiding making additional versions of the code and increasing the complexity, but instead, focus on fixing underlying design issues on a single version of the code base instead. Some code repositories use a branching approach, however, these are intended to be short lived and temporary before being merged back to the main “trunk” and back into the single code base.		* '''Single Code Base''' – avoiding making additional versions of the code and increasing the complexity, but instead, focus on fixing underlying design issues on a single version of the code base instead. Some code repositories use a branching approach, however, these are intended to be short lived and temporary before being merged back to the main “trunk” and back into the single code base.
	* Daily Deployment – evolving to a point where the software assets can be deployed into production every day reduces the impact of change and risk, and enhances the software development practice into a constant refinement activity, rather than delivering an impactful change.		* '''Daily Deployment''' – evolving to a point where the software assets can be deployed into production every day reduces the impact of change and risk, and enhances the software development practice into a constant refinement activity, rather than delivering an impactful change.
	* Negotiated Scope Contract – the intention is to migrate away from fixed contracts, and instead, move towards an agreement that satisfies both customer and supplier with less specifics, more smaller agreements, and a move towards time and materials with constant collaboration.		* '''Negotiated Scope Contract''' – the intention is to migrate away from fixed contracts, and instead, move towards an agreement that satisfies both customer and supplier with less specifics, more smaller agreements, and a move towards time and materials with constant collaboration.
	* Pay Per Use – using customer revenue as a form of feedback for systems that charge for their usage helps to align relevant and useful features to the economics and the return on the investment		* '''Pay Per Use''' – using customer revenue as a form of feedback for systems that charge for their usage helps to align relevant and useful features to the economics and the return on the investment

	==References==		==References==
	# Extreme Programming Explained: Embrace Change, Beck K, Andres C, 2005		# Extreme Programming Explained: Embrace Change, Beck K, Andres C, 2005

← Older revision		Revision as of 05:28, 27 November 2018
Line 21:		Line 21:
	===Primary Practices===		===Primary Practices===
	The Primary Practices underpin the toolbox of both primary and corollary practices and include:		The Primary Practices underpin the toolbox of both primary and corollary practices and include:
	* Sit Together – the whole team can interact and work much more efficiently when they can communicate and collaborate in high bandwidth intensity, which naturally happens when they are simply collocated together. For remote teams, this could also be interpreted as the ability to mentally sit together within a virtual eco-system that fosters instant collaboration and interaction with others.		* '''Sit Together''' – the whole team can interact and work much more efficiently when they can communicate and collaborate in high bandwidth intensity, which naturally happens when they are simply collocated together. For remote teams, this could also be interpreted as the ability to mentally sit together within a virtual eco-system that fosters instant collaboration and interaction with others.
	* Whole Team – a cross-functional team of highly skilled people with all perspectives necessary to produce the work with a sense of “wholeness” rather than partial representation		* '''Whole Team''' – a cross-functional team of highly skilled people with all perspectives necessary to produce the work with a sense of “wholeness” rather than partial representation
	* Informative Workspace – using the workspace to provide information about the project and the work, such as card walls for example, as well as a workspace that caters for human needs such as collaboration, social interaction as well as privacy and quiet		* '''Informative Workspace''' – using the workspace to provide information about the project and the work, such as card walls for example, as well as a workspace that caters for human needs such as collaboration, social interaction as well as privacy and quiet
	* Energized Work – provisioning for a sustainable working practice that includes periods of high intensity as well as periods of rest time. The intention here is to respect the human body and mind in order to be more efficient rather than working for extended periods of time with mediocre results		* '''Energized Work''' – provisioning for a sustainable working practice that includes periods of high intensity as well as periods of rest time. The intention here is to respect the human body and mind in order to be more efficient rather than working for extended periods of time with mediocre results
	* Pair Programming – pair programming provides a highly collaborative interaction that yields high quality code and propels teams forwards with new ideas and creativity, however, personal space must also be respected		* '''Pair Programming''' – pair programming provides a highly collaborative interaction that yields high quality code and propels teams forwards with new ideas and creativity, however, personal space must also be respected
	* Stories – using conversation reminders to interact with the team and understand the needs and context rather than relying on requirements and written documents to replace conversations		* '''Stories''' – using conversation reminders to interact with the team and understand the needs and context rather than relying on requirements and written documents to replace conversations
	* Weekly Cycle – in XP the working cycles are set to a weekly rhythm to provide high intensity and opportunities for feedback and adaptation		* '''Weekly Cycle''' – in XP the working cycles are set to a weekly rhythm to provide high intensity and opportunities for feedback and adaptation
	* Quarterly Cycle – as a form of release planning, the quarterly cycle sets a project horizon as a longer rhythm that supports interactions with suppliers and stakeholders		* '''Quarterly Cycle''' – as a form of release planning, the quarterly cycle sets a project horizon as a longer rhythm that supports interactions with suppliers and stakeholders
	* Slack – providing some slack time e.g. 20% of the working week to provide opportunities for learning and thinking can be invaluable and has indirect benefits for the product as more improved and efficient ways of doing things are allowed to emerge		* '''Slack''' – providing some slack time e.g. 20% of the working week to provide opportunities for learning and thinking can be invaluable and has indirect benefits for the product as more improved and efficient ways of doing things are allowed to emerge
	* Ten Minute Build – an efficient software build and compilation that can be done within ten minutes improves the probability that it will be done more often and there will be more frequency of feedback if there are any compilation issues in the code. For longer running build and compile times, then these are an indicator that it may not be as efficient and so some refactoring is needed.		* '''Ten Minute Build''' – an efficient software build and compilation that can be done within ten minutes improves the probability that it will be done more often and there will be more frequency of feedback if there are any compilation issues in the code. For longer running build and compile times, then these are an indicator that it may not be as efficient and so some refactoring is needed.
	* Test-First Programming – this automated testing approach where the test is written first, and then the software code is written to satisfy the test improves software quality with a defect prevention approach rather than using defect detection methods after the software has been built. The approach is more cost effective at resolving issues before they happen and improves cohesion in the code and a rolling horizon of confidence in the product.		* '''Test-First Programming''' – this automated testing approach where the test is written first, and then the software code is written to satisfy the test improves software quality with a defect prevention approach rather than using defect detection methods after the software has been built. The approach is more cost effective at resolving issues before they happen and improves cohesion in the code and a rolling horizon of confidence in the product.

	[[File:Test_Driven_Development_(TDD).jpg\|500px\|Test Driven Development (TDD)]]		[[File:Test_Driven_Development_(TDD).jpg\|500px\|Test Driven Development (TDD)]]

	* Continuous Integration – the continual ability to test and integrate software components provides regular feedback on any issues with integration and the health of the software code. This approach is most often done on an automated infrastructure that works asynchronously as the code is written and checked into the code repository, which is then used by the build servers to autonomously compile and execute tests and provide feedback if there were any issues.		* '''Continuous Integration''' – the continual ability to test and integrate software components provides regular feedback on any issues with integration and the health of the software code. This approach is most often done on an automated infrastructure that works asynchronously as the code is written and checked into the code repository, which is then used by the build servers to autonomously compile and execute tests and provide feedback if there were any issues.
	* Incremental Design – using a proportion of the time to continually improve and address the software design needs in context and as the code is written helps to incorporate feedback and learning. This emergent approach to design allows for experimentation and evidence gathering to inform the correct approach to use rather than design up front practices, which can be full of assumptions.		* '''Incremental Design''' – using a proportion of the time to continually improve and address the software design needs in context and as the code is written helps to incorporate feedback and learning. This emergent approach to design allows for experimentation and evidence gathering to inform the correct approach to use rather than design up front practices, which can be full of assumptions.

	===Corollary Practices===		===Corollary Practices===