コミット: 1df4b86ee000468da2d608d07d3cc649f848af9b - MESS (hg)

コミットメタ情報

• リビジョン: 1df4b86ee000468da2d608d07d3cc649f848af9b (tree)
• 日時: 2024-03-21 23:40:36
• 作者: Albert Mietus < albert AT mietus DOT nl >
• コミッター: Albert Mietus < albert AT mietus DOT nl >

ログメッセージ

split '5 chapers' from index

変更サマリ

• modified: SystemEngineering/AgileSIA/demo/H3-exact.rst
• modified: SystemEngineering/AgileSIA/demo/H5-HowToChoose.rst
• modified: SystemEngineering/AgileSIA/goal/index.rst
• modified: SystemEngineering/AgileSIA/index.rst
• add: SystemEngineering/AgileSIA/goal/5chapters.rst

差分

diff -r 58506c7d7262 -r 1df4b86ee000 SystemEngineering/AgileSIA/demo/H3-exact.rst
--- a/SystemEngineering/AgileSIA/demo/H3-exact.rst	Fri Feb 23 16:13:52 2024 +0100
+++ b/SystemEngineering/AgileSIA/demo/H3-exact.rst	Thu Mar 21 15:40:36 2024 +0100
@@ -37,6 +37,7 @@
 * Roughly, we need 13 steps, with (on average) a week between
   |BR|
   Note: this is not applicable for :math:`{\alpha}`- and :math:`{\beta}`-versions; they are faster.
+
   * This option is scalable: more bumpers for many cars are possible.
 
 

diff -r 58506c7d7262 -r 1df4b86ee000 SystemEngineering/AgileSIA/demo/H5-HowToChoose.rst
--- a/SystemEngineering/AgileSIA/demo/H5-HowToChoose.rst	Fri Feb 23 16:13:52 2024 +0100
+++ b/SystemEngineering/AgileSIA/demo/H5-HowToChoose.rst	Thu Mar 21 15:40:36 2024 +0100
@@ -5,3 +5,72 @@
 ================
 5) How To Choose
 ================
+
+.. seealso:: This *last* chapter is a short overview and/or tips on “**How** to choose”.
+
+   .. Caution:: Don’t advise on which solution is best!
+
+      Plz, do not get trapped in the pitfall to advise which solution *is* the best-- all should be ‘great’.
+      But *‘great’*, for other (business) reasons. Some are cheaper, some are faster, etc.
+
+      You merely advise on how the PO (client/...) shall select one of the solutions. “When T2M is most important, ...”,
+      or “When you target the top market, ...”, etc.
+
+   -- :ref:`AgileSIA-5chapters`
+
+We have presented three completely different solutions, each with its pros & cons. All do fulfil all needs as
+given in the 1ste chapter [:ref:`SIA-demo-H1`].
+|BR|
+Now, it is time to decide which one you prefer to continue with -- as a polite reminder: [:need:`BUMPER_April1`]. So, hope
+for a quick decision.
+
+Therefore, we present some tips.
+
+Tips
+====
+
+Which requirements are most prominent
+-------------------------------------
+
+Even though all requirements are met in every solution, some needs might have a bit more weight. So, let’s go over the
+most relevant ones.
+
+.. rubric:: :need:`BUMPER_chrome` & :need:`BUMPER_SafetyImago`
+
+When we like to impress on looks, the “Oldsmobile fenders” [:ref:`SIA-demo-H2`] beets all other solutions. Whereas
+[:ref:`SIA-demo-H4`] is the most safe solution.
+
+The brand-new chrome solution [:ref:`SIA-demo-H3`] is a nice combination for both requirements: safe and shiny.
+
+.. rubric:: :need:`BUMPER_April1`
+
+Solution “:ref:`SIA-demo-H2`” involves finding a second-hand “Oldsmobile bumper”. This should be easy but has a risk on
+timing. So, whenever we like to minimize risk, this solution isn’t preferable.
+|BR|
+Whereas the high-volume [:ref:`SIA-demo-H4`] option is very, very fast and has no risk of meeting the deadline at all;
+therefore we even mentioned it as a backup scenario.
+
+.. rubric::  :need:`BUMPER_Green`
+
+As the bumper is important but not the most expensive part, you can also consider to play on safe. For example, use the
+cost-effective fast [:ref:`SIA-demo-H4`] solution as a backup, and select one of the other two as the main solution.
+|BR|
+This guarantees a good bumper on time. And enables a risk-free great option.
+
+.. tip:: Skip :need:`BUMPER_1is2`
+
+   It’s obvious, two bumpers are needed. All solutions are in harmony here. So the is no need to handle it here.
+
+Other factors
+-------------
+
+.. rubric:: scalable & future
+
+Although it, is not a need, this ‘first eco-friendly muscle car’ is a first. And we assume (many) more will
+follow. Therefore we spend a few words on that too.
+
+[:ref:`SIA-demo-H3`] & [:ref:`SIA-demo-H4`] are the most scalable. There is no upper limit on the number of bumpers we
+can deliver.
+|BR|
+Price-wise, the plastic solution is cheaper. However, the piece price of a (new, labour-intensive) chrome bumper will
+go down when volume rises.

diff -r 58506c7d7262 -r 1df4b86ee000 SystemEngineering/AgileSIA/goal/5chapters.rst
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/SystemEngineering/AgileSIA/goal/5chapters.rst	Thu Mar 21 15:40:36 2024 +0100
@@ -0,0 +1,92 @@
+.. _AgileSIA-5chapters:
+
+The 5 chapter template
+======================
+
+It might help to use the following template to understand the goals of the SIA. And assist in writing a sound one.
+
+An SIA usually consists of only five chapters:
+
+1. The Problem Analyse
+----------------------
+
+This is a bit like a Requirements Gathering phase. Usually one has to communicate with all stakeholders (or read
+their inputs) to thoroughly understand and list their needs.  All the requirements and desires should be listed in
+natural language and presented in a logical manner [#NoInterview]_.
+|BR|
+There is no need to select or prioritise the demands at this stage.
+
+In many cases, the stakeholders have already expressed their input and one uses mainly other (“higher”) documents
+as input. Remember, however, it’s about what the stakeholders want, not about the documents themselves.
+|BR|
+Do not “copy” all those demands. Just mention them, link to the source and summarise them such that the document is
+readable.
+
+More often than not, this is a short chapter, maybe a few pages. The goal is that the PO and all stakeholders
+say: “Yes, that is exactly what we need” [#check]_.
+
+2.  Solution A
+--------------
+
+It gives a highlight of the first presented (design) option, without explaining the design. Just enough so that the
+PO (and other stakeholders) understand it -- there is no need that anybody can implement it already.
+
+Then, the cost, risk, duration and other relevant topics (for the stakeholders) are explained.
+|BR|
+Again, keep it simple and global. Don’t try to convince the PO; (s)he will (should) trust your analysis.
+
+Optionally you can present some sub-options. But don’t go into details. Only sub-options that are relevant for the
+PO are relevant.
+
+3. Solution B
+--------------
+
+Same as above, but (completely) different.
+|BR|
+Sometimes a feature can be split into several functional “slices” [#cake]_.
+
+Different solutions may come with different slices, but we can also have common ones. Then, introduce them early, and
+refer to them in the next solution(s).  Make it explicit which slices are (partially) common and which not.
+|BR|
+Despite that slices can be common, they may have other effects on investments (costs etc), risk or other business
+values Therefore, I prefer to write out those aspects in each solution. Often assisted with a phrase as *“a bit
+more/better/... than in ..”*
+
+4. Solution C
+-------------
+Again, another way for the same result [#cents]_.
+
+5. Summary/Overview
+-------------------
+
+This short chapter lists the relevant differences (for the PO/stakeholders) between the solutions, often in a table.
+
+It frequently also advice on **how** to select the best option. This is to guide the PO.
+|BR|
+By example:
+
+* *“Solution A has the shortest T2M, although it is twice as expensive”*.
+* *“When future extensibility is key, solution B offers the most flexibility”*.
+* *“Solution C has the main benefit that it has many slices, each can be realised independently in a series of
+  sprints”*.
+* *“For the same reason, solution C can be implemented in 10 concurrent teams, keeping them fully loaded*
+  |BR|
+  (especially as we have the risk that two teams run out of work).”
+
+-----
+
+.. rubric:: Footnotes & Links
+
+.. [#NoInterview] Plz, don’t make it a conversation report. Don’t use stakeholder order. And always use your own words.
+.. [#Check] Typically this 1st chapter is reviewed early. This chapter is also a check: When the team misunderstands the
+   feature, it is better to fail fast.
+
+.. [#cake] A cake is (typically) cooked bottom-up and consumed left-to-right. Even though the sum of the layers and the
+   sum of the slices are equal, the effect differs. I often use this analogy and will write a blog about it
+   “soon”. For now, plz just remember it does differ and get used to the term:-)
+
+.. [#cents] Be “`Pound Wise and Penny Foolish <https://www.dictionary.com/browse/penny-wise-and-pound-foolish>`__”!
+   |BR|
+   Nobody is (or should be) interested in a solution that differs only in a few (pre)cents. Not in an (upfront) SIA
+   document. Unless, of course, when that percentage is a relevant business topic.
+

diff -r 58506c7d7262 -r 1df4b86ee000 SystemEngineering/AgileSIA/goal/index.rst
--- a/SystemEngineering/AgileSIA/goal/index.rst	Fri Feb 23 16:13:52 2024 +0100
+++ b/SystemEngineering/AgileSIA/goal/index.rst	Thu Mar 21 15:40:36 2024 +0100
@@ -64,80 +64,15 @@
      In a typical lean, agile approach, those provisional designs are stored as a photo in a wiki, along with the
      notes.
 
-.. _AgileSIA-5chapters:
-
-The 5 chapter template
-======================
-
-It might help to use the following template to understand the goals of the SIA. And assist in writing a sound one.
-
-An SIA usually consists of only five chapters:
-
-1. The Problem Analyse
-----------------------
-
-This is a bit like a Requirements Gathering phase. Usually one has to communicate with all stakeholders (or read
-their inputs) to thoroughly understand and list their needs.  All the requirements and desires should be listed in
-natural language and presented in a logical manner [#NoInterview]_.
-|BR|
-There is no need to select or prioritise the demands at this stage.
-
-In many cases, the stakeholders have already expressed their input and one uses mainly other (“higher”) documents
-as input. Remember, however, it’s about what the stakeholders want, not about the documents themselves.
-|BR|
-Do not “copy” all those demands. Just mention them, link to the source and summarise them such that the document is
-readable.
-
-More often than not, this is a short chapter, maybe a few pages. The goal is that the PO and all stakeholders
-say: “Yes, that is exactly what we need” [#check]_.
-
-2.  Solution A
---------------
-
-It gives a highlight of the first presented (design) option, without explaining the design. Just enough so that the
-PO (and other stakeholders) understand it -- there is no need that anybody can implement it already.
-
-Then, the cost, risk, duration and other relevant topics (for the stakeholders) are explained.
-|BR|
-Again, keep it simple and global. Don’t try to convince the PO; (s)he will (should) trust your analysis.
+A SIA has 5 chapters
+====================
 
-Optionally you can present some sub-options. But don’t go into details. Only sub-options that are relevant for the
-PO are relevant.
-
-3. Solution B
---------------
-
-Same as above, but (completely) different.
+As we present in :ref:`AgileSIA-5chapters`, an (agile, lean) SIA has five chapters, only 5!
 |BR|
-Sometimes a feature can be split into several functional “slices” [#cake]_.
-
-Different solutions may come with different slices, but we can also have common ones. Then, introduce them early, and
-refer to them in the next solution(s).  Make it explicit which slices are (partially) common and which not.
-|BR|
-Despite that slices can be common, they may have other effects on investments (costs etc), risk or other business
-values Therefore, I prefer to write out those aspects in each solution. Often assisted with a phrase as *“a bit
-more/better/... than in ..”*
+However, it not the exact number that counts -- some prefer to combine the 3 “solutions chapters” is a single chapters,
+other may varie a bit on number of solutions, or the place of sub-chapters.
 
-4. Solution C
--------------
-Again, another way for the same result [#cents]_.
-
-5. Summary/Overview
--------------------
-
-This short chapter lists the relevant differences (for the PO/stakeholders) between the solutions, often in a table.
-
-It frequently also advice on **how** to select the best option. This is to guide the PO.
-|BR|
-By example:
-
-* *“Solution A has the shortest T2M, although it is twice as expensive”*.
-* *“When future extensibility is key, solution B offers the most flexibility”*.
-* *“Solution C has the main benefit that it has many slices, each can be realised independently in a series of
-  sprints”*.
-* *“For the same reason, solution C can be implemented in 10 concurrent teams, keeping them fully loaded*
-  |BR|
-  (especially as we have the risk that two teams run out of work).”
+Still, using that template (as used in :ref:`SIA-demo`) will typically result in a nice SIA.
 
 
 
@@ -163,16 +98,3 @@
    |BR|
    That kind of software is often written in “another language”. The risk that nobody can maintain it is absent.
 
-.. [#NoInterview] Plz, don’t make it a conversation report. Don’t use stakeholder order. And always use your own words.
-.. [#Check] Typically this 1st chapter is reviewed early. This chapter is also a check: When the team misunderstands the
-   feature, it is better to fail fast.
-
-.. [#cake] A cake is (typically) cooked bottom-up and consumed left-to-right. Even though the sum of the layers and the
-   sum of the slices are equal, the effect differs. I often use this analogy and will write a blog about it
-   “soon”. For now, plz just remember it does differ and get used to the term:-)
-
-.. [#cents] Be “`Pound Wise and Penny Foolish <https://www.dictionary.com/browse/penny-wise-and-pound-foolish>`__”!
-   |BR|
-   Nobody is (or should be) interested in a solution that differs only in a few (pre)cents. Not in an (upfront) SIA
-   document. Unless, of course, when that percentage is a relevant business topic.
-

diff -r 58506c7d7262 -r 1df4b86ee000 SystemEngineering/AgileSIA/index.rst
--- a/SystemEngineering/AgileSIA/index.rst	Fri Feb 23 16:13:52 2024 +0100
+++ b/SystemEngineering/AgileSIA/index.rst	Thu Mar 21 15:40:36 2024 +0100
@@ -55,6 +55,7 @@
    :maxdepth: 2
 
    goal/index
+   goal/5chapters
    demo/index
    notes/index