From 3ee41c47704e37cf18e908d931efea39fe6bb71a Mon Sep 17 00:00:00 2001 From: Nick Yeates Date: Wed, 30 Nov 2016 14:02:28 -0500 Subject: [PATCH 1/7] from Wiki try 2 I did this wrong the first time, trying again, now with work done in a branch Info taken from existing wiki file at https://github.com/paypal/InnerSourceCommons/wiki/Common-Requirements --- common-requirements.md | 22 ++++++++++++++++++++++ 1 file changed, 22 insertions(+) create mode 100644 common-requirements.md diff --git a/common-requirements.md b/common-requirements.md new file mode 100644 index 000000000..f157af95e --- /dev/null +++ b/common-requirements.md @@ -0,0 +1,22 @@ +**Title: Common Requirements** + +**Context:** Many projects are trying to use common code. There is a shared repository that all the projects access. This pattern applies if there is a Strong Code Owner [pattern to be written] or if there is weak code ownership, or no Benevolent Sponsor [pattern to be written]. Someone (or some project) wrote the code in the first place and contributed it to the repository. The common code is a small percentage of the overall deliverable from any of the projects. Each project has its own delivery schedule, set of deliverables and customers. +Statement of Problem: The common code in the shared repository isn’t meeting the needs of all the projects that want to use it. + +**Statement of Problem:** The common code in the shared repository isn’t meeting the needs of all the projects that want to use it. + +**Forces:** +The project that made the code available has one set of needs. Its needs are similar to what some of the receiving organization wants, but not quite the same. +Requirements on code should be derivable from real customer needs. +The needs of different customers are generally quite similar; however they might be expressed differently or weighted differently between customers. +Many customers want the supplier to help them know what they need. +The company has many “Systems Engineers” writing requirements for the products. These requirements are supposed to be a distillation of customer needs to guide development of the product. +Reusing code is an important goal to save the company time and money. + +**Resolution:** Align the requirements of the projects so that the code that meets the requirements for one project also meets the needs for the other projects. Decompose the code into smaller pieces for which the many using projects can agree upon requirements. + +**Resulting Context:** This might require negotiating requirements changes with the customer. It might also require other involvement by the sales teams and product managers to get alignment on the requirements. + +**Author:** Robert Hanmer, 22 Aug 2016, 20 Sept 2016 + +**Status:** Draft pattern \ No newline at end of file From 4c2c73e28881a80e3b3f57bbb67bd857fd03226f Mon Sep 17 00:00:00 2001 From: Nick Yeates Date: Wed, 30 Nov 2016 14:05:18 -0500 Subject: [PATCH 2/7] formatting to match template (try 2) template, for now, is at https://github.com/paypal/InnerSourceCommons/wiki/InnerSource%20Patterns %20template --- common-requirements.md | 23 +++++++++++++++-------- 1 file changed, 15 insertions(+), 8 deletions(-) diff --git a/common-requirements.md b/common-requirements.md index f157af95e..115b36835 100644 --- a/common-requirements.md +++ b/common-requirements.md @@ -1,11 +1,14 @@ -**Title: Common Requirements** +## Title +Common Requirements -**Context:** Many projects are trying to use common code. There is a shared repository that all the projects access. This pattern applies if there is a Strong Code Owner [pattern to be written] or if there is weak code ownership, or no Benevolent Sponsor [pattern to be written]. Someone (or some project) wrote the code in the first place and contributed it to the repository. The common code is a small percentage of the overall deliverable from any of the projects. Each project has its own delivery schedule, set of deliverables and customers. +## Context +Many projects are trying to use common code. There is a shared repository that all the projects access. This pattern applies if there is a Strong Code Owner [pattern to be written] or if there is weak code ownership, or no Benevolent Sponsor [pattern to be written]. Someone (or some project) wrote the code in the first place and contributed it to the repository. The common code is a small percentage of the overall deliverable from any of the projects. Each project has its own delivery schedule, set of deliverables and customers. Statement of Problem: The common code in the shared repository isn’t meeting the needs of all the projects that want to use it. -**Statement of Problem:** The common code in the shared repository isn’t meeting the needs of all the projects that want to use it. +## Problem Statement +The common code in the shared repository isn’t meeting the needs of all the projects that want to use it. -**Forces:** +## Forces The project that made the code available has one set of needs. Its needs are similar to what some of the receiving organization wants, but not quite the same. Requirements on code should be derivable from real customer needs. The needs of different customers are generally quite similar; however they might be expressed differently or weighted differently between customers. @@ -13,10 +16,14 @@ Many customers want the supplier to help them know what they need. The company has many “Systems Engineers” writing requirements for the products. These requirements are supposed to be a distillation of customer needs to guide development of the product. Reusing code is an important goal to save the company time and money. -**Resolution:** Align the requirements of the projects so that the code that meets the requirements for one project also meets the needs for the other projects. Decompose the code into smaller pieces for which the many using projects can agree upon requirements. +## Solution +Align the requirements of the projects so that the code that meets the requirements for one project also meets the needs for the other projects. Decompose the code into smaller pieces for which the many using projects can agree upon requirements. -**Resulting Context:** This might require negotiating requirements changes with the customer. It might also require other involvement by the sales teams and product managers to get alignment on the requirements. +## Resulting Context +This might require negotiating requirements changes with the customer. It might also require other involvement by the sales teams and product managers to get alignment on the requirements. -**Author:** Robert Hanmer, 22 Aug 2016, 20 Sept 2016 +## Author +Robert Hanmer, 22 Aug 2016, 20 Sept 2016 -**Status:** Draft pattern \ No newline at end of file +## Status +Draft pattern \ No newline at end of file From 1c69700016702a37993b876ead5cd8a7f82c1ccf Mon Sep 17 00:00:00 2001 From: Nick Yeates Date: Thu, 15 Dec 2016 00:07:23 -0500 Subject: [PATCH 3/7] removed typo --- common-requirements.md | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/common-requirements.md b/common-requirements.md index 115b36835..3709be514 100644 --- a/common-requirements.md +++ b/common-requirements.md @@ -2,8 +2,7 @@ Common Requirements ## Context -Many projects are trying to use common code. There is a shared repository that all the projects access. This pattern applies if there is a Strong Code Owner [pattern to be written] or if there is weak code ownership, or no Benevolent Sponsor [pattern to be written]. Someone (or some project) wrote the code in the first place and contributed it to the repository. The common code is a small percentage of the overall deliverable from any of the projects. Each project has its own delivery schedule, set of deliverables and customers. -Statement of Problem: The common code in the shared repository isn’t meeting the needs of all the projects that want to use it. +Many projects are trying to use common code. There is a shared repository that all the projects access. This pattern applies if there is a Strong Code Owner [pattern to be written] or if there is weak code ownership, or no Benevolent Sponsor [pattern to be written]. Someone (or some project) wrote the code in the first place and contributed it to the repository. The common code is a small percentage of the overall deliverable from any of the projects. Each project has its own delivery schedule, set of deliverables and customers. ## Problem Statement The common code in the shared repository isn’t meeting the needs of all the projects that want to use it. From 5d4a893c32b725542b1f67555ade195a6682549c Mon Sep 17 00:00:00 2001 From: Nick Yeates Date: Thu, 15 Dec 2016 00:39:03 -0500 Subject: [PATCH 4/7] Added idea on using cust. req. negotiation Added @gruetter idea on using customer requirements elucidation/negotiation --- common-requirements.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/common-requirements.md b/common-requirements.md index 3709be514..382c010b6 100644 --- a/common-requirements.md +++ b/common-requirements.md @@ -16,7 +16,9 @@ The company has many “Systems Engineers” writing requirements for the produc Reusing code is an important goal to save the company time and money. ## Solution -Align the requirements of the projects so that the code that meets the requirements for one project also meets the needs for the other projects. Decompose the code into smaller pieces for which the many using projects can agree upon requirements. +Align the requirements of the projects so that the code that meets the requirements for one project also meets the needs for the other projects. Decompose the code into smaller pieces for which the many using projects can agree upon requirements. + +Additionally, take advantage of customers expecting the supplier to help elucidate requirements. Bring about the alignment of requirements during the customer requirements negotiations and change the customers requirements rather than changing the component. ## Resulting Context This might require negotiating requirements changes with the customer. It might also require other involvement by the sales teams and product managers to get alignment on the requirements. From 7627259639b44943f82729bce104b14e820e4416 Mon Sep 17 00:00:00 2001 From: Nick Yeates Date: Thu, 15 Dec 2016 03:40:12 -0500 Subject: [PATCH 5/7] Small reword --- common-requirements.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/common-requirements.md b/common-requirements.md index 382c010b6..aad1a85e9 100644 --- a/common-requirements.md +++ b/common-requirements.md @@ -18,7 +18,7 @@ Reusing code is an important goal to save the company time and money. ## Solution Align the requirements of the projects so that the code that meets the requirements for one project also meets the needs for the other projects. Decompose the code into smaller pieces for which the many using projects can agree upon requirements. -Additionally, take advantage of customers expecting the supplier to help elucidate requirements. Bring about the alignment of requirements during the customer requirements negotiations and change the customers requirements rather than changing the component. +Additionally, take advantage of customers expecting the supplier to help elucidate requirements. Bring about the alignment of requirements during the customer negotiations and influence the customers requirements rather than changing the component. ## Resulting Context This might require negotiating requirements changes with the customer. It might also require other involvement by the sales teams and product managers to get alignment on the requirements. From 9d7ef82728ad904d7deaeb30ca26bf9e041ba2cf Mon Sep 17 00:00:00 2001 From: NewMexicoKid Date: Mon, 23 Jan 2017 13:46:05 -0600 Subject: [PATCH 6/7] Fixed typo: isn't --- common-requirements.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/common-requirements.md b/common-requirements.md index aad1a85e9..dbe98f197 100644 --- a/common-requirements.md +++ b/common-requirements.md @@ -5,7 +5,7 @@ Common Requirements Many projects are trying to use common code. There is a shared repository that all the projects access. This pattern applies if there is a Strong Code Owner [pattern to be written] or if there is weak code ownership, or no Benevolent Sponsor [pattern to be written]. Someone (or some project) wrote the code in the first place and contributed it to the repository. The common code is a small percentage of the overall deliverable from any of the projects. Each project has its own delivery schedule, set of deliverables and customers. ## Problem Statement -The common code in the shared repository isn’t meeting the needs of all the projects that want to use it. +The common code in the shared repository isn't meeting the needs of all the projects that want to use it. ## Forces The project that made the code available has one set of needs. Its needs are similar to what some of the receiving organization wants, but not quite the same. @@ -27,4 +27,4 @@ This might require negotiating requirements changes with the customer. It might Robert Hanmer, 22 Aug 2016, 20 Sept 2016 ## Status -Draft pattern \ No newline at end of file +Draft pattern From 2faad148afc93f18d021d4ee42b654e48f9abced Mon Sep 17 00:00:00 2001 From: Robert Hanmer Date: Thu, 31 Aug 2017 15:05:04 -0500 Subject: [PATCH 7/7] Align with PLoP 2017 draft. --- common-requirements.md | 26 +++++++++++++++++++------- 1 file changed, 19 insertions(+), 7 deletions(-) diff --git a/common-requirements.md b/common-requirements.md index dbe98f197..3d6b202d7 100644 --- a/common-requirements.md +++ b/common-requirements.md @@ -8,23 +8,35 @@ Many projects are trying to use common code. There is a shared repository that The common code in the shared repository isn't meeting the needs of all the projects that want to use it. ## Forces -The project that made the code available has one set of needs. Its needs are similar to what some of the receiving organization wants, but not quite the same. +The project that made the code available has one set of needs. Its needs are similar to what some of the receiving organization wants, but not quite the same. Requirements on code should be derivable from real customer needs. -The needs of different customers are generally quite similar; however they might be expressed differently or weighted differently between customers. -Many customers want the supplier to help them know what they need. -The company has many “Systems Engineers” writing requirements for the products. These requirements are supposed to be a distillation of customer needs to guide development of the product. + +The needs of different customers are generally quite similar; however they might be expressed differently or weighted differently between customers. An example might be how some customers want some result presented in one way while others want it presented in the reverse order---it's simple to do the translation between them, but requires additional coding for one of the cases and the as a result the module that computes the result can't be reused by both customers. + +Many customers want the supplier to help them know what they need. The company has many “Systems Engineers” writing requirements for the products. These requirements are supposed to be a distillation of customer needs to guide development of the product. Reusing code is an important goal to save the company time and money. ## Solution -Align the requirements of the projects so that the code that meets the requirements for one project also meets the needs for the other projects. Decompose the code into smaller pieces for which the many using projects can agree upon requirements. +There are two aspects to solving this problem which should be done in parallel: +- Align the requirements of the projects so that the code that meets the requirements for one project also meets the needs for the other projects. +- Refactor the code into smaller pieces for which the many using projects can agree upon requirements. Additionally, take advantage of customers expecting the supplier to help elucidate requirements. Bring about the alignment of requirements during the customer negotiations and influence the customers requirements rather than changing the component. +In the example presented above, the supplier helps both customers realize that they want the same thing, and it will save everyone effort (and money) if they agree to accept the result in the same format. + +Common Requirements + ## Resulting Context -This might require negotiating requirements changes with the customer. It might also require other involvement by the sales teams and product managers to get alignment on the requirements. +This might require negotiating requirements changes with the customer. The changes might also require involvement by the sales teams and product managers to get alignment on the requirements. The customer might need incentives, such as discounts, to agree to the changes. + +A related pattern (to be written) is a circular story-writing exercise reported at one company employing Inner Sourcing. +The developers write a story to solve a problem in one way. + +The program managers rewrite the story to better express their needs---keeping the essence the same. By the time it returns to developers though they don't recognize it as what they wanted to do in the first place and so balk at implementing it. The solution to this pattern is to have more seats around the planning table so that story modifications are understood across the project not just in the developer or program manager camps. ## Author Robert Hanmer, 22 Aug 2016, 20 Sept 2016 ## Status -Draft pattern +Shepherded pattern