1. First of all I will determine Power-Interest position of the stakeholder in the matrix and keep them: Closely managed, Satisfied, Informed, Monitored.

1. Power/interest - Closely manage
2. Power/non-interest - Keep satisfied
3. Non power/Interest - Inform
4. Non-power/Non-interest - Monitor

2. Second I will adjust my communication style according to 4 types of people:

1. ET - Controllers. Need quick updates, can't tolerate long meeting and details.
2. IT - Analysts. Need detailed answers and lists.
3. EF - Enthusiasts. They need the pitch to be motivating and fun.
4. IF - Nice people. They need emotional rapport and connection.

3. Third, I will use 'Stakeholder Engagement Asessment Matrix'. We have here 2 points: current position, desired position, and 5 states of stakeholder:

1. Unaware
2. Resistant
3. Neutral
4. Supportive
5. Leading

The task is to plan and transfer stakholder from current position to desired.

No matter which framework you use, the process flow is as follows: initiation, planning, execution, monitor and control, closing.

1. Expert judgment: This involves seeking the advice of experts in the field to help you understand the requirements.
2. Brainstorming: This is a group activity where participants generate ideas about a particular topic.
3. Interviews: This is a one-on-one conversation with a user or stakeholder to gather information about their needs and expectations.
4. Voting: This is a method for making decisions by having participants rank or vote on a set of options.
5. Multicriteria decision analysis: This is a more complex method for making decisions that takes into account multiple factors, such as cost, time, and quality.
6. Mind mapping: This is a technique for visualizing information by creating a diagram that shows the relationships between different concepts.
7. Context diagram: This is a diagram that shows the relationship between the system and its environment.
8. User journey mapping: This is a technique for understanding the user's experience with a system by mapping out their steps and interactions.

1. Defining what should not be done as well with scope.
2. Independent observers will be better to see the scope creep and gold plating.

1. Define activities
2. Sequence activities
3. Estimate activity durations (determine critical path)
4. Develope schedule
5. Control schedule

1. Defining scope
2. Create WBS (work breakdown structure)
3. Monitor and control scope
4. ---
5. Define activities
6. Create schedule
7. Monitor and control schedule
8. ---
9. Define budget
10. Track expenses
11. Adjust budget

Here are some main technical quality metrics often used in software development:

1. Production incidents
2. Time to restore the service
3. Cyclomatic Complexity: Assesses the complexity of code by counting the number of independent paths through a function, helping identify potentially complex and hard-to-maintain areas.
4. Code Coverage: Measures the percentage of code that is covered by automated tests, indicating the effectiveness of test suites in validating the codebase.
5. Code Duplication: Identifies duplicated code segments within a codebase, highlighting potential maintenance issues and opportunities for code reuse and refactoring.
6. Change failure rate
7. Defect rate - Stories vs Defects
8. Detected bugs vs Resolved bugs
9. Broken builds
10. Deployment frequency

DoR stands for 'Definition of Ready' in Scrum. It is a set of criteria that a product backlog item must meet before it is deemed ready to be worked on by the development team.

It should comply with INVEST.

Every Product Backlog item should comply with DoR. This is done during Product Backlog Refinement. Product Backlog Refinement is an ongoing process during the sprint.

1. A clear and concise description of the product backlog item.
2. Acceptance criteria that define what needs to be done to consider the item complete.
3. A prioritization of the item within the product backlog.
4. Any dependencies or prerequisites that must be met before the item can be worked on.
5. A clear understanding of the business value that the item delivers.

1. Finalize release scope.
2. Build and package.
3. Deployment planning.
4. User acceptance testing (UAT).
5. Deployment.
6. Post-release validation.

Kanban is a visual framework used for managing and optimizing workflow. It originated from the manufacturing industry but has been widely adopted in software development and project management.

The key principles of Kanban are:

1. Visualize Work: Represent work items on a Kanban board to provide visibility and transparency.
2. Limit Work in Progress (WIP): Set explicit limits on the number of items allowed in each workflow stage to optimize flow and prevent overburdening the team.
3. Manage Flow: Focus on achieving a smooth and continuous flow of work by identifying and addressing bottlenecks and inefficiencies.
4. Make Policies Explicit: Clearly define and communicate the rules, policies, and procedures governing the workflow to ensure consistency and shared understanding.
5. Improve Collaboratively, Evolve Experimentally: Encourage continuous improvement through collaboration and experimentation, seeking opportunities to refine processes and practices.

1. Kanban Board
2. Kanban Cards
3. WIP Limit
4. Kanban Metrics
5. Service Level Agreements (SLAs)
6. Classes of Service (CoS)
7. Policies and Feedback Loops
8. Kanban System Design
9. Kanban at Scale
10. Kanban Maturity Model

Here are some main technical quality metrics often used in software development:

1. Production incidents
2. Time to restore the service
3. Cyclomatic Complexity: Assesses the complexity of code by counting the number of independent paths through a function, helping identify potentially complex and hard-to-maintain areas.
4. Code Coverage: Measures the percentage of code that is covered by automated tests, indicating the effectiveness of test suites in validating the codebase.
5. Code Duplication: Identifies duplicated code segments within a codebase, highlighting potential maintenance issues and opportunities for code reuse and refactoring.
6. Change failure rate
7. Defect rate - Stories vs Defects
8. Detected bugs vs Resolved bugs
9. Broken builds
10. Deployment frequency

The cost of maintaining and improving code that has been developed quickly and without following best practices.

1. Refactoring: Allocate time and resources to refactor the codebase, improving its structure, readability, and maintainability. This involves identifying and addressing areas of poor design, code duplication, and outdated technologies.
2. Prioritization: Prioritize technical debt items based on their impact on the project, considering factors such as business value, customer impact, and risk. This helps determine which areas should be addressed first to maximize the benefits of debt reduction.
3. Prevention: Implement practices and processes to prevent the accumulation of new technical debt. This includes emphasizing code reviews, automated testing, and following coding standards to ensure that code is clean, efficient, and meets quality criteria.

SDLC (Software Development Life Cycle) is a systematic process used in software development to design, develop, test, and deploy high-quality software applications. It provides a structured approach for managing and controlling the software development process, ensuring that software projects are completed efficiently and effectively.

1. Planning: Defining the project scope, goals, and requirements, and creating a roadmap for the development process.
2. Analysis: Gathering and analyzing user requirements, studying the existing system (if applicable), and identifying any potential risks or challenges. Getting client approved requirements.
3. Design & Prototype: Creating a detailed design specification, including the software architecture, database structure, and user interface. Developing prototypes to validate the design and gather feedback.
4. Development: Writing the actual code, implementing the software based on the design specifications, and integrating various components and modules.
5. Testing: Conducting comprehensive testing, including unit testing, integration testing, system testing, and user acceptance testing, to identify and fix any defects or issues.
6. Launch (Deployment): Releasing the software application to end-users or customers, including installation, configuration, and final deployment.
7. Maintenance: Providing ongoing support, bug fixes, updates, and enhancements to the software to ensure its optimal performance and functionality throughout its lifecycle.

Deployment should be done through the following steps:

1. Build and package: Create a build of the software and package it into a deployable format, such as a binary or container image.
2. Configure environments: Set up and configure the target deployment environments, including servers, databases, and any necessary infrastructure components.
3. Automate deployment: Implement an automated deployment process using tools like continuous integration and continuous deployment (CI/CD) pipelines. This ensures consistent and repeatable deployments.
4. Test in staging: Deploy the software to a staging or pre-production environment and perform thorough testing to validate its functionality and compatibility.
5. Monitor and rollback: Monitor the deployed application in the production environment, gathering metrics and monitoring for any issues. If necessary, be prepared to rollback to a previous version in case of problems.
6. Document and communicate: Document the deployment process, including any specific steps or configurations, and communicate them to the team. This helps ensure consistency and facilitates future deployments.

Test-Driven Development (TDD) is a software development approach that emphasizes writing tests before writing the actual code.

To get accurate estimates, you can follow these steps:

1. Break down the task or project into smaller, more manageable components. And perform bottom-up estimation.
2. Consider rought estimates first -25/+75
3. Use Beta Distribution analysis
4. Use analogous and parametric estimation from the historical data
5. Account for potential risks and estimate 15% percent contingency resevere
6. Regularly update estimates when new information becomes available