Difference between revisions of "Talk:Agile"

From wiki
Jump to navigation Jump to search
 
(14 intermediate revisions by the same user not shown)
Line 4: Line 4:
 
DevSecOps stands for development, security, and operations. It's an approach to culture, automation, and platform design that integrates security as a shared responsibility throughout the entire IT lifecycle.  
 
DevSecOps stands for development, security, and operations. It's an approach to culture, automation, and platform design that integrates security as a shared responsibility throughout the entire IT lifecycle.  
 
[[File:Agile cycle.png|thumb|Agile-Devopscycle]]
 
[[File:Agile cycle.png|thumb|Agile-Devopscycle]]
 +
[[File:Overall cycle.png|thumb|overall_cycle_iterate]]
  
 
'''DevSecOps CI/CD''' (ref https://public.cyber.mil/devsecops/) CI/CD is a DevOps tactic, which makes use of the right automated testing tools to implement agile development. Continuous Integration is an engineering practice in which members of a development team integrate their code at a very high frequency, detection of errors in code in the early stages. Continuous Delivery is the practice of ensuring that code is always in a deployable state. All code changes – new features, bug fixes, experiments, configuration changes – are always ready for deployment to a production environment with the right CI/CD tools in place.  Scale accordingly (to the size, complexity, and criticality of your project/product development cycle) The right fit automating as much as possible.  See software factory.  
 
'''DevSecOps CI/CD''' (ref https://public.cyber.mil/devsecops/) CI/CD is a DevOps tactic, which makes use of the right automated testing tools to implement agile development. Continuous Integration is an engineering practice in which members of a development team integrate their code at a very high frequency, detection of errors in code in the early stages. Continuous Delivery is the practice of ensuring that code is always in a deployable state. All code changes – new features, bug fixes, experiments, configuration changes – are always ready for deployment to a production environment with the right CI/CD tools in place.  Scale accordingly (to the size, complexity, and criticality of your project/product development cycle) The right fit automating as much as possible.  See software factory.  
Line 16: Line 17:
 
And, lets talk about '''requirements'''.  Everyone thinks that - we're Agile! we don't need requirements cause the client/SME/stakeholder is right beside us every step of the way.  But, we all know in reality getting the time/resources at the time you need key SMEs/stakeholders can be a challenge. (ref https://www.modernanalyst.com/Resources/Articles/tabid/115/ID/5832/A-Business-Analysts-Experience-With-Scrum.aspx )
 
And, lets talk about '''requirements'''.  Everyone thinks that - we're Agile! we don't need requirements cause the client/SME/stakeholder is right beside us every step of the way.  But, we all know in reality getting the time/resources at the time you need key SMEs/stakeholders can be a challenge. (ref https://www.modernanalyst.com/Resources/Articles/tabid/115/ID/5832/A-Business-Analysts-Experience-With-Scrum.aspx )
 
[[File:Req analysis.png|thumb|req_analysis]]
 
[[File:Req analysis.png|thumb|req_analysis]]
I have been on many many projects.  Sure some don't require elaborate requirements depending upon the size, complexity, criticality, scope, costs, resources, experience/wisdom/knowledge etc...  but many do - at least a baseline of SMART requirements which evolve. The best projects I have been on have been iterative, incremental and integrated in approach involving key SMEs/stakeholders producing prototypes and proof of concepts with a SMART baseline of requirements which evolve with time to manage scope, costs, resources, schedule, quality, risks...  
+
I have been on many many projects.  Sure some don't require elaborate requirements depending upon the size, complexity, criticality, scope, costs, resources, experience/wisdom/knowledge etc...  but many do - at least a baseline of SMART (specific, measurable, attainable, realistic, testable) requirements which evolve. The best projects I have been on have been iterative, incremental and integrated in approach involving key SMEs/stakeholders producing prototypes and proof of concepts with a SMART baseline of requirements which evolve with time to manage scope, costs, resources, schedule, quality, risks... with traceability and validation/verification meeting the needs of the organization and of the clients needs.  
Without requirements where will you start? Requirements allow you to prioritize, categorize, trace, realize, measure/monitor/correct accordingly and continuously and risk assess.  I've been on projects where scope was all over the place, so were costs and resources were heading in every direction.  Requirements were no place to be found. A baseline of requirements that evolve provides direction.   
+
Without requirements where will you start? A baseline of requirements that evolve and that are managed well, allows one to prioritize, categorize, trace, assess impact of change, realize, measure/monitor/correct accordingly continuously and risk assess.  I've been on projects where scope was all over the place, so were costs and resources were heading in every direction.  Requirements were no place to be found. A baseline of requirements that evolve provides direction.   
 
[[File:Technology overview.png|thumb|Needs_analysis]]
 
[[File:Technology overview.png|thumb|Needs_analysis]]
Then comes the '''organization's culture, people, process, governance and tools''' https://www.compact.nl/en/articles/continuously-improve-your-agility/ which is important.  Are we meeting the client's needs and organizational mandates/objectives/vision/goals?
+
Then comes the '''organization's culture, people, process, governance and tools''' https://www.compact.nl/en/articles/continuously-improve-your-agility/ which is important.  Are we meeting the client's needs and organizational mandates/objectives/vision/goals? Are we able/willing to adapt to change? right fit? right tools? right training? mentorship/mindset/knowledge sharing and growth? direction and management? risk taking or risk adverse? SWOT analysis and know the organization... capability and capacity willing to change.
 
[[File:Devsecops culture.png|thumb|Organization_culture_fit]]
 
[[File:Devsecops culture.png|thumb|Organization_culture_fit]]
  
 
{| class="wikitable" style=width:40em
 
{| class="wikitable" style=width:40em
 
|+ The software factory:
 
|+ The software factory:
 +
|-
 +
|  [[File:DevSecOps ecosystem.png|frameless|center]]
 
|-  
 
|-  
 
|  [[File:Swfact2.png|frameless|center]]
 
|  [[File:Swfact2.png|frameless|center]]
Line 33: Line 36:
  
 
Projects I have been on that were a success:
 
Projects I have been on that were a success:
https://ottawacitizen.com/news/national/defence-watch/canadian-surveillance-satellite-system-now-operational Evolving 600 user stories (around 3000 derived requirements see page 75 https://buyandsell.gc.ca/cds/public/2013/05/29/be189bb4f50d214783a7d94d19a1364d/ABES.PROD.BK__XL.B100.E25308.EBSU000.PDF )  from key SMEs/stakeholders using focus groups, surveys, and continuous feedback.
 
https://ottawacitizen.com/news/national/rcmp-unveils-massive-border-security-project Evolving key scenarios to prove the concepts working with the field units empowering staff, adhering to the laws of each province, building small correcting mistakes quickly iteratively with prototypes  (Boeing failed https://www.zdnet.com/article/boeing-virtual-fence-30-billion-failure/)
 
https://www.defenseindustrydaily.com/canada-holland-order-17-sirius-shipboard-longrange-irst-sensors-updated-02183/ building iteratively with many prototypes/proof of concepts, with key SMEs in the loop and a good baseline of requirements (from defense research), with good
 
people, tools, process (achieved CMMI level 5) with direction, commitment, goals, small builds. 
 
I have been on failed projects as well, mostly due to lack of SMART requirements as scope, costs, direction, quality and risks all over the place.  Requirements are critical, especially for mission-critical projects that evolve as a baseline. Build incrementally, iteratively and integrated in approach building prototypes/proof of concepts with key SMEs/stakeholders in the loop with a SMART baseline of requirements that are categorized, risk analyzed, prioritized managing scope, costs, schedule/resources, risks, quality and direction.
 
  
ref (diagrams are copies from ref)
+
1) https://ottawacitizen.com/news/national/defence-watch/canadian-surveillance-satellite-system-now-operational The data collection system -evolving 600 user stories (around 3000 derived requirements see page 75 https://buyandsell.gc.ca/cds/public/2013/05/29/be189bb4f50d214783a7d94d19a1364d/ABES.PROD.BK__XL.B100.E25308.EBSU000.PDF )  from key SMEs/stakeholders using focus groups, surveys, and continuous feedback.
 +
 
 +
2) https://ottawacitizen.com/news/national/rcmp-unveils-massive-border-security-project Evolving key scenarios to prove the concepts working with the field units empowering staff, adhering to the laws of each province, building small correcting mistakes quickly iteratively with prototypes  (Boeing failed https://www.zdnet.com/article/boeing-virtual-fence-30-billion-failure/)
 +
 
 +
3) https://www.defenseindustrydaily.com/canada-holland-order-17-sirius-shipboard-longrange-irst-sensors-updated-02183/ building iteratively with many prototypes/proof of concepts, with key SMEs in the loop and a good baseline of requirements (from defense research), with good
 +
people, tools, process (achieved CMMI level 5) with direction, commitment, goals, small builds. 
 +
 
 +
Plus others...
 +
 
 +
I have been on failed projects as well, mostly due to lack of SMART requirements as scope, costs, direction, quality and risks all over the place.  Requirements are critical, especially for mission-critical projects that evolve as a baseline. Build incrementally, iteratively and integrated in approach building prototypes/proof of concepts with key SMEs/stakeholders in the loop with a SMART baseline of requirements that are categorized, risk analyzed, traceable, and prioritized.  Managing scope, costs, schedule/resources, risks, quality and direction.
 +
Is there one size fits all, probably not.  It really depends upon the size, scope, complexity, the resources capability and capacity along with wisdom/experience/knowledge.  '''''''A bit of trial and error in some regards but learn well continuously.  No right answers just many answers.  It really depends really.''''''
 +
 
 +
ref (all diagrams are copies from ref materials)
 
https://www.pmi.org/learning/library/requirements-management-planning-for-success-9669
 
https://www.pmi.org/learning/library/requirements-management-planning-for-success-9669
 
https://www.modernanalyst.com/Resources/Articles/tabid/115/ID/5624/Requirements-Life-Cycle-Management-with-Azure-DevOps.aspx
 
https://www.modernanalyst.com/Resources/Articles/tabid/115/ID/5624/Requirements-Life-Cycle-Management-with-Azure-DevOps.aspx

Latest revision as of 16:04, 26 June 2023

What is Agile (ref https://agilemanifesto.org/principles.html ) Agile is a collection of methodologies. An iterative approach to project management and software development that focuses on collaboration, customer feedback, and rapid releases.

What is DevSecOps (ref https://www.devsecops.org/ ) DevOps is an approach to software development that enables teams to build, test, and release software faster. In a DevOps environment, developers and operations teams work side by side throughout the entire process of developing, deploying, and managing applications. Build small, fix fast, fail fast and learn well continuously. DevSecOps stands for development, security, and operations. It's an approach to culture, automation, and platform design that integrates security as a shared responsibility throughout the entire IT lifecycle.

Agile-Devopscycle
overall_cycle_iterate

DevSecOps CI/CD (ref https://public.cyber.mil/devsecops/) CI/CD is a DevOps tactic, which makes use of the right automated testing tools to implement agile development. Continuous Integration is an engineering practice in which members of a development team integrate their code at a very high frequency, detection of errors in code in the early stages. Continuous Delivery is the practice of ensuring that code is always in a deployable state. All code changes – new features, bug fixes, experiments, configuration changes – are always ready for deployment to a production environment with the right CI/CD tools in place. Scale accordingly (to the size, complexity, and criticality of your project/product development cycle) The right fit automating as much as possible. See software factory.

devsecops
CICDpipeline

DORA https://www.devops-research.com/research.html are we there yet? where are we now and what are we aiming for? thus, Agile maturity models are important. Minimize chasing chaos, fighting fires, with massive silos (knowledge sharing/growth limited), and a heroes welcome https://www.performancemagazine.org/five-levels-of-organizational-maturity-performance-management-perspective https://kulkarniprasadp.medium.com/advancing-the-agile-maturity-assessment-model-fed2e8d9cb63 https://info.thoughtworks.com/rs/thoughtworks2/images/agile_maturity_model.pdf

AgileMaturityModel

How do you know where to go if you don't even know where you are now... need a sense of direction and strategy/map. Thus, a maturity model helps one aim towards some goal. Continuous improvement, continuous learning with knowledge growth with a client focus development and process improvement towards an objective/goal/mandate to improve the organization and meet client needs.

AgileMaturityModel

And, lets talk about requirements. Everyone thinks that - we're Agile! we don't need requirements cause the client/SME/stakeholder is right beside us every step of the way. But, we all know in reality getting the time/resources at the time you need key SMEs/stakeholders can be a challenge. (ref https://www.modernanalyst.com/Resources/Articles/tabid/115/ID/5832/A-Business-Analysts-Experience-With-Scrum.aspx )

req_analysis

I have been on many many projects. Sure some don't require elaborate requirements depending upon the size, complexity, criticality, scope, costs, resources, experience/wisdom/knowledge etc... but many do - at least a baseline of SMART (specific, measurable, attainable, realistic, testable) requirements which evolve. The best projects I have been on have been iterative, incremental and integrated in approach involving key SMEs/stakeholders producing prototypes and proof of concepts with a SMART baseline of requirements which evolve with time to manage scope, costs, resources, schedule, quality, risks... with traceability and validation/verification meeting the needs of the organization and of the clients needs. Without requirements where will you start? A baseline of requirements that evolve and that are managed well, allows one to prioritize, categorize, trace, assess impact of change, realize, measure/monitor/correct accordingly continuously and risk assess. I've been on projects where scope was all over the place, so were costs and resources were heading in every direction. Requirements were no place to be found. A baseline of requirements that evolve provides direction.

Needs_analysis

Then comes the organization's culture, people, process, governance and tools https://www.compact.nl/en/articles/continuously-improve-your-agility/ which is important. Are we meeting the client's needs and organizational mandates/objectives/vision/goals? Are we able/willing to adapt to change? right fit? right tools? right training? mentorship/mindset/knowledge sharing and growth? direction and management? risk taking or risk adverse? SWOT analysis and know the organization... capability and capacity willing to change.

Organization_culture_fit
The software factory:
DevSecOps ecosystem.png
Swfact2.png
Sw fact3.png
Swfact1.png

Projects I have been on that were a success:

1) https://ottawacitizen.com/news/national/defence-watch/canadian-surveillance-satellite-system-now-operational The data collection system -evolving 600 user stories (around 3000 derived requirements see page 75 https://buyandsell.gc.ca/cds/public/2013/05/29/be189bb4f50d214783a7d94d19a1364d/ABES.PROD.BK__XL.B100.E25308.EBSU000.PDF ) from key SMEs/stakeholders using focus groups, surveys, and continuous feedback.

2) https://ottawacitizen.com/news/national/rcmp-unveils-massive-border-security-project Evolving key scenarios to prove the concepts working with the field units empowering staff, adhering to the laws of each province, building small correcting mistakes quickly iteratively with prototypes (Boeing failed https://www.zdnet.com/article/boeing-virtual-fence-30-billion-failure/)

3) https://www.defenseindustrydaily.com/canada-holland-order-17-sirius-shipboard-longrange-irst-sensors-updated-02183/ building iteratively with many prototypes/proof of concepts, with key SMEs in the loop and a good baseline of requirements (from defense research), with good people, tools, process (achieved CMMI level 5) with direction, commitment, goals, small builds.

Plus others...

I have been on failed projects as well, mostly due to lack of SMART requirements as scope, costs, direction, quality and risks all over the place. Requirements are critical, especially for mission-critical projects that evolve as a baseline. Build incrementally, iteratively and integrated in approach building prototypes/proof of concepts with key SMEs/stakeholders in the loop with a SMART baseline of requirements that are categorized, risk analyzed, traceable, and prioritized. Managing scope, costs, schedule/resources, risks, quality and direction. Is there one size fits all, probably not. It really depends upon the size, scope, complexity, the resources capability and capacity along with wisdom/experience/knowledge. ''A bit of trial and error in some regards but learn well continuously. No right answers just many answers. It really depends really.'

ref (all diagrams are copies from ref materials) https://www.pmi.org/learning/library/requirements-management-planning-for-success-9669 https://www.modernanalyst.com/Resources/Articles/tabid/115/ID/5624/Requirements-Life-Cycle-Management-with-Azure-DevOps.aspx https://www.pmi.org/learning/library/identify-factors-cause-project-failure-2442 https://www.pmi.org/learning/library/seven-causes-project-failure-initiate-recovery-7195 https://www.proofhub.com/articles/reasons-why-projects-fail https://kulkarniprasadp.medium.com/advancing-the-agile-maturity-assessment-model-fed2e8d9cb63 https://www.clearavenue.com/agile-devops.html