Difference between revisions of "CNM Agile"

From CNM Wiki
Jump to: navigation, search
 
(18 intermediate revisions by the same user not shown)
Line 1: Line 1:
−
[[CNM Agile]] (hereinafter, the ''Framework'') is a [[product development framework]] that represents an adaption of the [[Agile methodology]] to the learning and testing needs of the [[CNM Cyber Team]] (hereinafter, the ''Team'').
+
[[CNM Agile]] (hereinafter, the ''Framework'') is a [[product development framework]] that represents an adaption of the [[Agile methodology]] to the learning and testing needs of the [[CNMCyber Team]] (hereinafter, the ''Team'').
  
  
−
==Comparisons with other frameworks==
+
==The Framework vs others==
−
In comparison with [[Agile Scrum]], the ''Framework'' emphasizes weekly, not daily meetings and allows for virtual, not only physical co-working. In comparison with [[The Manifesto for Agile Software Development]], the ''Framework'' values comprehensive documentation over working products.
+
 
 +
===Similarities===
 +
 
 +
===Dissimilarities===
 +
In comparison with [[Agile Scrum]], the ''Framework'' emphasizes weekly, not daily meetings and allows for virtual, not only physical co-working. In comparison with [[The Manifesto for Agile Software Development]], the ''Framework'' values comprehensive documentation as a [[work product]].
  
 
==Projects==
 
==Projects==
−
Generally speaking, a [[project]] is a development [[#Endeavors|Endeavor]] or a set of [[enterprise effort]]s undertaken to produce a unique [[deliverable]], functional features of which are identified or can be identified before the ''efforts'' start. Those deliverables are those new and modified products that are produced during those developments. Indeed, the aim of ''Cyber's'' developments is to produce new or modify existing [[CNM Cyber product]]s. At the ''Cyber'', former and current projects are listed in the [[:Category:CNM Cyber endeavors|"CNM Cyber endeavors" category]].  
+
Generally speaking, a [[project]] is a development [[#Endeavors|Endeavor]] or a set of [[enterprise effort]]s undertaken to produce a unique [[deliverable]], functional features of which are identified or can be identified before the ''efforts'' start. Those deliverables are those new and modified products that are produced during those developments. Indeed, the aim of ''Cyber's'' developments is to produce new or modify existing [[CNMCyber product]]s. At the ''Cyber'', former and current projects are listed in the [[:Category: CNMCyber endeavors|"CNMCyber endeavors" category]].  
  
 
===Cycles of cycles===
 
===Cycles of cycles===
Line 19: Line 23:
 
:* A contractor submitted more products than the contract had required. If they are further deployed, those additional products would be by-products of this project.
 
:* A contractor submitted more products than the contract had required. If they are further deployed, those additional products would be by-products of this project.
 
:* Contractor's performance demonstrated advanced competencies in something unrelated to the project. The updated records are by-products of this project.  
 
:* Contractor's performance demonstrated advanced competencies in something unrelated to the project. The updated records are by-products of this project.  
−
:* While organizing a meeting, the ''Coord'' encountered the problem of the policy's incompleteness. [[CNM Cyber Customer]] agreed to fund the policy's updates. The updated policy is a by-product of the project
+
:* While organizing a meeting, the ''Coord'' encountered the problem of the policy's incompleteness. [[CNMCyber Customer]] agreed to fund the policy's updates. The updated policy is a by-product of the project
  
−
===Durations===
+
===DREPD pattern===
−
: The ''Coords'' work on one project, usually up to three and, in exceptional cases, up to five weeks.
+
: ''Main wikipage: [[DREPD]]''
−
:# In the first week, they shall get familiarized with the project. At the end of the familiarization, the ''Coord'' should be able to explain what is described on the relevant wikipages and be ready to discuss its [[Sprint Zero]] with [[CNM Cyber Customer]].
 
−
:# From the second week to the penultimate week, they facilitate the project work in accordance with the [[#What Coords do|What Coords do]] section.
 
−
:# In the final week, they close the project or project part, documenting their work and the data that was uncovered during that work.
 
−
: Projects can overlap. For example, the last week of work on one project may be the first week of work on another project. For senior ''Coords'', there are no restrictions.
 
  
−
===Patterns===
 
 
: Although no single straightforward pattern of project advancement exists, some patterns can be found in various developments. As an example, letters in the [[DREPD]] pattern represent five phrases:
 
: Although no single straightforward pattern of project advancement exists, some patterns can be found in various developments. As an example, letters in the [[DREPD]] pattern represent five phrases:
−
:# '''D''' for "discover the need".
+
:# '''D''' for "discover the wills".
−
:# '''R''' for "research the background".
+
:# '''R''' for "research the grounds".
 
:# '''E''' for "envision the deliverable".
 
:# '''E''' for "envision the deliverable".
 
:# '''P''' for "plan the production".
 
:# '''P''' for "plan the production".
Line 38: Line 37:
 
: This pattern can be found in the whole development, in every group of processes, every process and every part of processes where ever anything new is or is going to be developed.
 
: This pattern can be found in the whole development, in every group of processes, every process and every part of processes where ever anything new is or is going to be developed.
  
−
===Project deliverables===
+
===Durations===
−
: Projects are undertaken to create project deliverables. [[CNM Cyber Customer]] funds projects in order to get something in return. Normally, customers fund projects because of its expected deliverables. Any project is expected to deliver some outputs. In other words, project deliverables are those products for which development the project exists.
+
: The ''Coords'' work on one project, usually up to three and, in exceptional cases, up to five weeks.
−
 
+
:# In the first week, they shall get familiarized with the project. At the end of the familiarization, the ''Coord'' should be able to explain what is described on the relevant wikipages and be ready to discuss its [[Sprint Zero]] with [[CNMCyber Customer]].
−
: For instance, when a contractor is hired to produce a particular thing, that very thing should be the deliverable of that project. Literally, the contractor is expected to ''deliver'' the deliverable to complete the project.
+
:# From the second week to the penultimate week, they facilitate the project work in accordance with the [[#What Coords do|What Coords do]] section.
−
 
+
:# In the final week, they close the project or project part, documenting their work and the data that was uncovered during that work.
−
: At the ''Cyber'', former, current, and expected deliverables are listed in the [[:Category:CNM Cyber products|"CNM Cyber products" category]]. Project deliverables exist in various [[#Product states|Product states]] and belong to various [[#Product areas|Product areas]]. In addition, one project rarely produces one single deliverable. For instance, the [[HAProxy for CNM Farms]] project is expected to deliver high-availability capabilities for [[CNM Campus Farm]] and [[Campus Farm Lab]], as well as related presentations on various media resources, updates to the [[CNM Cyber Orientation]] course, and a bundle of exercises for the learners.
+
: Projects can overlap. For example, the last week of work on one project may be the first week of work on another project. For senior ''Coords'', there are no restrictions.
−
 
 
−
: Finally, project deliverables and ''Coords<nowiki>'</nowiki>'' deliverables are not the same things. Any development can be represented as [[#Cycles of cycles|Cycles of cycles]]. Just few ''Coords<nowiki>'</nowiki>'' deliverables, for instance, records, become a part of project deliverables. Normally, [[#What Coords produce|the ''Coords'' deliver]] to the project something like [[#Meetings|Meetings]], [[#Documents|Documents]], [[#Records|Records]], and [[#Communications|Communications]] to be consumed in the project activities as [[project scrap]]s.
 
  
 
===Project results===
 
===Project results===
 
: [[Project result]]s or results of the projects may be classified in four levels:
 
: [[Project result]]s or results of the projects may be classified in four levels:
−
:# '''[[Project scrap]]s''', which are intermediate products that either become parts of the [[CNM Cyber product]]s or have been decommissioned before the end of the project. Nevertheless, the outputs cannot be produced without those scraps. As they say, sausage making is messy, but no sausage can be produced without that mess.
+
:# '''[[Project scrap]]s''', which are intermediate products that either become parts of the [[CNMCyber product]]s or have been decommissioned before the end of the project. Nevertheless, the outputs cannot be produced without those scraps. As they say, sausage making is messy, but no sausage can be produced without that mess.
 
:# '''[[Project output]]s''' are the things that are produced during the project and kept after its end. Besides the [[#Project deliverables|Project deliverables]], the outputs may include other-than-the-project [[#Records|Records]] such as publications and [[#Documents|Documents]] such as blueprints that have been developed and commissioned in order to produce the [[#Project deliverables|Project deliverables]].
 
:# '''[[Project output]]s''' are the things that are produced during the project and kept after its end. Besides the [[#Project deliverables|Project deliverables]], the outputs may include other-than-the-project [[#Records|Records]] such as publications and [[#Documents|Documents]] such as blueprints that have been developed and commissioned in order to produce the [[#Project deliverables|Project deliverables]].
 
:# '''[[Project outcome]]s'''. On the ''Coord's'' side, the outcomes are those [[KSA]]s that the ''Coord'' has obtained during the project coordination. On the other stakeholders' side, the outcomes are something for which the [[#Project deliverables|Project deliverables]] have been produced.
 
:# '''[[Project outcome]]s'''. On the ''Coord's'' side, the outcomes are those [[KSA]]s that the ''Coord'' has obtained during the project coordination. On the other stakeholders' side, the outcomes are something for which the [[#Project deliverables|Project deliverables]] have been produced.
Line 55: Line 52:
  
 
===Status reports===
 
===Status reports===
−
: While working on the deliverable, the ''Coords'' are expected to report their project status. In [[CNM Agile]] framework, these statuses are reported at the product line wikipage, [[CNM Cloud Usable]], using the following readiness levels for each [[#Product states|Product state]] and [[#Devices of certainty|Device of certainty]]:
+
: While working on the deliverable, the ''Coords'' are expected to report their project status. In [[CNM Agile]] framework, these statuses are reported at the product line wikipage, [[CNMCyber Usable]], using the following readiness levels for each [[#Product states|Product state]] and [[#Devices of certainty|Device of certainty]]:
 
:* '''[[Not started status|Not started]]'''. Project work on the corresponding [[#Product states|Product state]] and [[#Devices of certainty|Device of certainty]] hasn't started yet.
 
:* '''[[Not started status|Not started]]'''. Project work on the corresponding [[#Product states|Product state]] and [[#Devices of certainty|Device of certainty]] hasn't started yet.
 
:* '''[[In progress status|In progress]]'''. Project work on the corresponding [[#Product states|Product state]] and [[#Devices of certainty|Device of certainty]] has been started, but the state/device has not yet been submitted for the approval.
 
:* '''[[In progress status|In progress]]'''. Project work on the corresponding [[#Product states|Product state]] and [[#Devices of certainty|Device of certainty]] has been started, but the state/device has not yet been submitted for the approval.
 
:* '''[[Cancel status|Cancel]]'''. Project work on the corresponding [[#Product states|Product state]] and [[#Devices of certainty|Device of certainty]] has been cancelled.
 
:* '''[[Cancel status|Cancel]]'''. Project work on the corresponding [[#Product states|Product state]] and [[#Devices of certainty|Device of certainty]] has been cancelled.
 
:* '''[[Submitted status|Submitted]]'''. Project work on the corresponding [[#Product states|Product state]] and [[#Devices of certainty|Device of certainty]] has been submitted for the approval.
 
:* '''[[Submitted status|Submitted]]'''. Project work on the corresponding [[#Product states|Product state]] and [[#Devices of certainty|Device of certainty]] has been submitted for the approval.
−
:* '''[[Done status|Done]]'''. Project work on the corresponding [[#Product states|Product state]] and [[#Devices of certainty|Device of certainty]] has been approved. With exceptions of the [[state of certainty]], [[CNM Cyber Customer]] approves the status. With regard to the [[state of certainty]], its approval also requires the developer's consent.
+
:* '''[[Done status|Done]]'''. Project work on the corresponding [[#Product states|Product state]] and [[#Devices of certainty|Device of certainty]] has been approved. With exceptions of the [[state of certainty]], [[CNMCyber Customer]] approves the status. With regard to the [[state of certainty]], its approval also requires the developer's consent.
  
−
==Product states==
+
==Work products==
−
For the purposes of this very wikipage, [[product state]]s refer to sets of conditions that ''Cyber'' products acquire during their development and service. The ''Coords'' work to bring the products into one or more of their states.
+
[[Work product]]s
  
−
===State definitions===
+
===Project deliverables===
−
:# '''[[State of acknowledgment]]'''. In this state, the future deliverable exists in the form of a noticed and documented idea.
+
: Projects are undertaken to create project deliverables. [[CNMCyber Customer]] funds projects in order to get something in return. Normally, customers fund projects because of its expected deliverables. Any project is expected to deliver some outputs. In other words, project deliverables are those products for which development the project exists.
−
:# '''[[State of certainty]]'''. In this state, the future deliverable exists as a validated [[product specification]].
 
−
:# '''[[State of capability]]'''. In this state, the functional deliverable has already been produced in accordance with all the requirements that have been approved for it.
 
−
:# '''[[State of applicability]]'''. In this state, the deliverable is not only functional, but can also be used for the purpose for which it was produced in ways that are described by a validated [[standing operational procedure]] ([[standing operational procedure|SOP]]).
 
−
:# '''[[State of manageability]]'''. In this state, the deliverable is not only used for the purpose for which it was produced, but also controlled, that is, the product undergoes periodic revisions and is either improved and its characteristics are improved, or withdrawn from service.
 
  
−
===Hierarchy===
+
: For instance, when a contractor is hired to produce a particular thing, that very thing should be the deliverable of that project. Literally, the contractor is expected to ''deliver'' the deliverable to complete the project.
−
: In practice, [[product state]]s do not always represent a hierarchy of five levels, in which the higher level includes the states of the lower levels. However, the ''Coords'' should strive for this ideal, for example, it is impossible to fully talk about applicability without capacity, manageability without certainty, and so on.
 
  
−
===Thresholds===
+
: At the ''Cyber'', former, current, and expected deliverables are listed in the [[:Category:CNM Cyber products|"CNMCyber products" category]]. Project deliverables exist in various [[#Product states|Product states]] and belong to various [[#Product areas|Product areas]]. In addition, one project rarely produces one single deliverable. For instance, the [[HAProxy for CNM Farms]] project is expected to deliver high-availability capabilities for [[CNM Campus Farm]] and [[Campus Farm Lab]], as well as related presentations on various media resources, updates to [[EmployableU Concepts]] course, and a bundle of exercises for the learners.
−
:{|class="wikitable" width=100%
 
−
!Product state!!Threshold
 
−
|-
 
−
|[[State of acknowledgment]]||A record is added to the [[idea management system]].
 
−
|-
 
−
|[[State of certainty]]||A [[product specification]] is approved.
 
−
|-
 
−
|[[State of capability]]||[[Acceptance criteria]] are met.
 
−
|-
 
−
|[[State of applicability]]||A [[standing operational procedure]] ([[standing operational procedure|SOP]]) is approved.
 
−
|-
 
−
|[[State of manageability]]||Periodic reviews find that [[standing operational procedure]]s ([[standing operational procedure|SOP]]s) are both sound and followed.
 
−
|}
 
  
−
==Devices of certainty==
+
: Finally, project deliverables and ''Coords<nowiki>'</nowiki>'' deliverables are not the same things. Any development can be represented as [[#Cycles of cycles|Cycles of cycles]]. Just few ''Coords<nowiki>'</nowiki>'' deliverables, for instance, records, become a part of project deliverables. Normally, [[#What Coords produce|the ''Coords'' deliver]] to the project something like [[#Meetings|Meetings]], [[#Documents|Documents]], [[#Records|Records]], and [[#Communications|Communications]] to be consumed in the project activities as [[project scrap]]s.
−
For the purposes of this very wikipage, a ''device of certainty'' refers to an instrument or tool that ensures:
 
−
* Product certainty, which their development shall deliver. When [[CNM Cyber Customer]] agrees, products shall not necessarily possess their [[state of certainty]] for the beginning of their development, but this state shall be achieved during that development.
 
−
* Project certainty, which suggests the scope of product development. Project certainty cannot be reached unless product certainty is reached. Clearly, no one can know what to do unless they know what needs to be done. The scope of work depends on the scope of work product. Moreover, the overwhelming majority of ''Cyber'' projects cannot be fully predicted and, therefore, achieve their complete certainty only with their closure.
 
−
 
 
−
===General certainty===
 
−
: For the purposes of this very wikipage, a ''general certainty'' refers to those devices that may combine product and project certainties.
 
−
:# '''[[Business requirement]]s'''. Description of the needs for which the development of the deliverable is undertaken.
 
−
:# '''[[#Funded demands|Demands of Team funded by Customer]]'''. Description of what [[CNM Cyber Team]] needs and, possibly, when and how it needs expressed when [[CNM Cyber Customer]] has funded satisfaction of those needs. Those demands are expressed in either [[acceptance criteria]] or [[standing operating procedure]] ([[standing operating procedure|SOP]]).
 
−
:# '''[[Stakeholder requirement]]s'''. Description of the future deliverable made on behalf of various types of its stakeholders.
 
−
 
 
−
===Product only certainty===
 
−
: A few devices ensure certainty of product deliverables:
 
−
:# '''[[Product depiction]]s'''. Representation in images, layouts, mockup models, outlines, [[prototype]]s, sketches, wireframes, and/or words of a deliverable to be created. [[Prototype]]s (from the Greek "prōtos" meaning "first", "original" and "typos" meaning "imprint", "pattern"). Instances, samples or models, following the example of which others are made or finalized. Prototypes of the deliverable are often built to test a perception, concept, or process. Prototypes can either be selected from existing products or produced during a project.
 
−
:# '''[[Product  specification]]s'''. Set of tasks for developers of a deliverable regarding its required characteristics.
 
−
 
 
−
: [[Business requirement]]s, [[stakeholder requirement]]s, and [[acceptance criteria]] clarify [[product scope]]s, but may also clarify scopes of their production, delivery, and/or other elements of [[project scope]]s.
 
−
 
 
−
===Project only certainty===
 
−
: [[Project scope]]s depend on their [[product scope]]s, so any [[project document]] can get some glimpse into its product certainty. A few devices ensure certainty of project processes and product delivery:
 
−
:# '''[[Project scope baseline]]'''. The combination of project work requirements that [[CNM Cyber Customer]] has approved and that are used as the base to compare with actual results. For complex projects, the baseline normally includes a [[project scope statement]], [[work breakdown structure]] ([[Work breakdown structure|WBS]]), and [[WBS dictionary]].
 
−
:#* [[Project scope statement]]. General description of the project work and its desired results, as well as assumptions, constraints and other project requirements.
 
−
:#* [[Work breakdown structure]] ([[Work breakdown structure|WBS]]). Hierarchical decomposition of the complete project work.
 
−
:#* [[WBS dictionary]]. Detailed deliverable, activity, and scheduling data for each component in the [[work breakdown structure]] ([[work breakdown structure|WBS]]).
 
−
:# '''[[Project schedule baseline]]'''. The combination of project schedule requirements that [[CNM Cyber Customer]] has approved and that are used as the base to compare with actual results.
 
−
:# '''[[Project cost baseline]]'''. The combination of project cost requirements that [[CNM Cyber Customer]] has approved and that are used as the base to compare with actual results.
 
  
−
: [[Business requirement]]s, [[stakeholder requirement]]s, and [[acceptance criteria]] may or may not clarify [[project scope]]s in addition to clarifications of [[product scope]]s.
+
===States of work products===
 +
: ''Main wikipage: [[Work-product state]]''
  
 
==See also==
 
==See also==

Latest revision as of 22:20, 29 October 2023

CNM Agile (hereinafter, the Framework) is a product development framework that represents an adaption of the Agile methodology to the learning and testing needs of the CNMCyber Team (hereinafter, the Team).


The Framework vs others

Similarities

Dissimilarities

In comparison with Agile Scrum, the Framework emphasizes weekly, not daily meetings and allows for virtual, not only physical co-working. In comparison with The Manifesto for Agile Software Development, the Framework values comprehensive documentation as a work product.

Projects

Generally speaking, a project is a development Endeavor or a set of enterprise efforts undertaken to produce a unique deliverable, functional features of which are identified or can be identified before the efforts start. Those deliverables are those new and modified products that are produced during those developments. Indeed, the aim of Cyber's developments is to produce new or modify existing CNMCyber products. At the Cyber, former and current projects are listed in the "CNMCyber endeavors" category.

Cycles of cycles

To coordinate endeavors, the Coords shall accomplish cycles of efforts that consists of several steps. Similar procedures are normally needed to produce project scraps and by-products. That means that the Coords are expected to follow the same cycle to create What Coords produce.
Furthermore, the most of projects may be viewed as sets of smaller developments. Among the Coords' outputs, Meetings, Documents, and Communications usually belong to project scraps. Indeed, Project results and results of the Coords' work are different phenomena.
Project deliverables normally utilize outputs from other projects as its scrap. A CNM app development, for example, requires documents that describe its requirements, and drawing up those requirements requires meeting events. If we consider the Coords' work as micro-projects, we can say that outputs of micro-projects tend to become scraps for small projects and, furthermore, outputs of small projects tend to become scraps for macro-projects.

Deliverables vs by-products

Those project outputs that are not Project deliverables may be called project by-products. Their range is huge; there are some imaginary scenarios:
  • A contractor submitted more products than the contract had required. If they are further deployed, those additional products would be by-products of this project.
  • Contractor's performance demonstrated advanced competencies in something unrelated to the project. The updated records are by-products of this project.
  • While organizing a meeting, the Coord encountered the problem of the policy's incompleteness. CNMCyber Customer agreed to fund the policy's updates. The updated policy is a by-product of the project

DREPD pattern

Main wikipage: DREPD
Although no single straightforward pattern of project advancement exists, some patterns can be found in various developments. As an example, letters in the DREPD pattern represent five phrases:
  1. D for "discover the wills".
  2. R for "research the grounds".
  3. E for "envision the deliverable".
  4. P for "plan the production".
  5. D for "do what is planned and discover what hasn't been expected". This discovery is supposed to start a new cycle; new data shall emerge while doing and/or after getting something done.
This pattern can be found in the whole development, in every group of processes, every process and every part of processes where ever anything new is or is going to be developed.

Durations

The Coords work on one project, usually up to three and, in exceptional cases, up to five weeks.
  1. In the first week, they shall get familiarized with the project. At the end of the familiarization, the Coord should be able to explain what is described on the relevant wikipages and be ready to discuss its Sprint Zero with CNMCyber Customer.
  2. From the second week to the penultimate week, they facilitate the project work in accordance with the What Coords do section.
  3. In the final week, they close the project or project part, documenting their work and the data that was uncovered during that work.
Projects can overlap. For example, the last week of work on one project may be the first week of work on another project. For senior Coords, there are no restrictions.

Project results

Project results or results of the projects may be classified in four levels:
  1. Project scraps, which are intermediate products that either become parts of the CNMCyber products or have been decommissioned before the end of the project. Nevertheless, the outputs cannot be produced without those scraps. As they say, sausage making is messy, but no sausage can be produced without that mess.
  2. Project outputs are the things that are produced during the project and kept after its end. Besides the Project deliverables, the outputs may include other-than-the-project Records such as publications and Documents such as blueprints that have been developed and commissioned in order to produce the Project deliverables.
  3. Project outcomes. On the Coord's side, the outcomes are those KSAs that the Coord has obtained during the project coordination. On the other stakeholders' side, the outcomes are something for which the Project deliverables have been produced.
  4. Project impacts, which are consequences of the project, its outputs and outcomes on a society. Beyond the Coord's work, some projects, for instance, may initiate further meetings, documents, actions, and changes.

Status reports

While working on the deliverable, the Coords are expected to report their project status. In CNM Agile framework, these statuses are reported at the product line wikipage, CNMCyber Usable, using the following readiness levels for each Product state and Device of certainty:

Work products

Work products

Project deliverables

Projects are undertaken to create project deliverables. CNMCyber Customer funds projects in order to get something in return. Normally, customers fund projects because of its expected deliverables. Any project is expected to deliver some outputs. In other words, project deliverables are those products for which development the project exists.
For instance, when a contractor is hired to produce a particular thing, that very thing should be the deliverable of that project. Literally, the contractor is expected to deliver the deliverable to complete the project.
At the Cyber, former, current, and expected deliverables are listed in the "CNMCyber products" category. Project deliverables exist in various Product states and belong to various Product areas. In addition, one project rarely produces one single deliverable. For instance, the HAProxy for CNM Farms project is expected to deliver high-availability capabilities for CNM Campus Farm and Campus Farm Lab, as well as related presentations on various media resources, updates to EmployableU Concepts course, and a bundle of exercises for the learners.
Finally, project deliverables and Coords' deliverables are not the same things. Any development can be represented as Cycles of cycles. Just few Coords' deliverables, for instance, records, become a part of project deliverables. Normally, the Coords deliver to the project something like Meetings, Documents, Records, and Communications to be consumed in the project activities as project scraps.

States of work products

Main wikipage: Work-product state

See also

Related lectures

Retrieved from "https://pravka.bskol.com/w/index.php?title=CNM_Agile&oldid=122158"