UNIT-2
Question :- What is Scrum?
Answer-----> Scrum is a framework that helps agile teams to work together. Using it, the team members can deliver and sustain the complex product. It encourages the team to learn through practice, self-organize while working on the problem. Scum is a work done through the framework and continuously shipping values to customers.
It is the most frequent software that is used by the development team. Its principle and lessons can be applied to all kinds of teamwork. Its policy and experiences is a reason of popularity of Scrum framework. The Scrum describes a set of tools, meetings, and roles that help the teams structure. It also manages the work done by the team.
Question :- What is The framework?
Answer-----> Scrum and agile are not the same thing because Scrum focused on continuous improvement, which is a core foundation of agile. Scrum framework focuses on ongoing getting work done.
Question :- What are sprints?
Answer----> With scrum, a product is built in a series of repetition called sprints. It breaks down big complex projects into bite-size pieces. It makes projects more manageable, allows teams to ship high quality, work faster, and more frequently. The sprints give them more flexibility to adapt to the changes.
Sprints are a short, time-boxed period for Scrum team that works to complete a set amount of work. Sprints are the core component of Scrum and agile methodology. The right sprints will help our agile team to ship better software.
Question :- What is sprint plan?
Answer---->Sprint plan is an action in Scrum that kicks off the sprint. The primary purpose of sprint plan is to define what can deliver in the sprint. It also focuses on how the work will be achieved. It is done in combination with the whole Scrum team members.
The sprint is a set of the period where all the work to be done. Before we start the development, we have to set up the sprint. We need to describe how long time is required to achieve the sprint goal and where we are going to start.
Question :- What are the Factors affecting Sprint planning?
Answer---->
o The What: The product owner describes the goal of the sprint and the backlog items which contribute to achieve that goal.
o The How: Agile development team plans its necessary work on how to achieve and deliver the sprint goal.
o The Who: The product owner defines the goal based on the value that the customers seek. And the developer needs to understand how they can or cannot deliver that goal.
o The Inputs: The product backlog provides the list of input stuff that could potentially be part of the current sprint. The team looks over the existing work done in incremental ways.
o The Outputs: The critical outcome of sprint planning is to meet described team goal. The product set the goal of sprint and how they will start working towards the goal.
Question :- What is the product backlog?
Answer----> A product backlog is a registered list of work for the development team. It is driven from the roadmap and its requirements. The essential task is represented at the top of the product backlog so that the team member knows what to deliver first. The developer team doesn't work through the backlog from the product owner's side and product owner doesn't push the work to the developer team. The developer team pulls work from the product backlog.
Backlog starts with the two "R"s
The fundamental product backlog is provided by a team's roadmap and requirements. Roadmap repetition breaks down into several epics, and each epic will have several requirements and user stories.
The product owner organizes each of the customer stories into a single list. This story is organized for the development team. The product owner chooses to deliver first complete epic.
Question :- What are the The factors that influence a product owner's prioritization?
Answer---->
o Priority of customer
o Importance of getting feedback
o Relative implementation difficulty
o Symbiotic relationships between work items
Question :- What is the Crystal Agile Framework?
Answer----> Crystal is an agile framework focusing on individuals and their interactions, as opposed to processes and tools. In other words, this framework is a direct outgrowth of one of the core values articulated in the Agile Manifesto.
The Crystal agile framework is built on two core beliefs:
• Teams can find ways on their own to improve and optimize their workflows
• Every project is unique and always changing, which is why that project’s team is best suited to determine how it will tackle the work.
Question :- Discuss the History of the Crystal Method?
Answer---> Alistair Cockburn, credited as one of the original popularizers of agile, developed the Crystal method for IBM in 1991. He decided to focus not on developing specific step-by-step development strategies that would work across the board for teams involved in any project, but instead to develop guidelines for team collaboration and communication. The traits of Cockburn’s Crystal method were therefore all based around the team itself:
• Human-powered (meaning the project should be flexible and tailored to the needs and the preferred work modalities of people involved)
• Adaptive (meaning the approach uses no fixed tools but can be altered to meet the team’s specific needs)
• Ultra-light (meaning this methodology does not require much documentation or reporting)
Question :- What are the Strengths and Weakness of Crystal?
Answer----->
Crystal’s strengths include:
• Allows teams to work the way they deem most effective
• Facilitates direct team communication, transparency and accountability
• The adaptive approach lets teams respond well to changing requirements
Crystal’s weaknesses include:
• Lack of pre-defined plans can lead to scope creep
• Lack of documentation can lead to confusion
Question :- Should You Use Crystal?
Answer----> The Crystal method is among the more flexible agile frameworks, because it is designed around a project’s people and is not dependent on any single set of processes or tools. In that sense, it can be a viable methodology for organizations that want to empower their teams to work however they deem most effective.
It is important to keep in mind, however, that because Crystal emphasizes direct team collaboration around the software they’re building—and de-emphasizes the importance of documentation and reporting—this could mean the other teams across the organization will have less visibility into the team’s progress.
Question :- Discuss the Feature Driven Development (FDD) and Agile Modeling?
Answer-----> Feature-Driven Development (FDD) is a client-centric, architecture-centric, and pragmatic software process. The term "client" in FDD is used to represent what Agile Modeling (AM) refers to as project stakeholders or eXtreme Programming (XP) calls customers.
FDD was first introduced to the world in 1999 via the book Java Modeling In Color with UML, a combination of the software process followed by Jeff DeLuca's company and Peter Coad's concept of features. FDD was first applied on a 15 month, 50-person project for a large Singapore bank in 1997, which was immediately followed by a second, 18-month long 250-person project. A more substantial description is published in the book A Practical Guide to Feature-Driven Development as well as the Feature Driven Development web site.
As the name implies, features are an important aspect of FDD. A feature is a small, client-valued function expressed in the form <action><result><object>. For example, "Calculate the total of a sale", "Validate the password of a user", and "Authorize the sales transaction of a customer". Features are to FDD as use cases are to the Rational Unified Process (RUP) and user stories are to Scrum - they're a primary source of requirements and the primary input into your planning efforts.
As you see in Figure 1 there are five main activities in FDD that are performed iteratively. The first is Develop An Overall Model, the initial result being a high-level object model and notes.
At the start of a project your goal is to identify and understand the fundamentals of the domain that your system is addressing, and throughout the project you will flesh this model out to reflect what you're building. The second step is Build A Features List, grouping them into related sets and subject areas. These first two steps map to the initial envisioning effort of AMDD (see Figure 2).
Next you Plan By Feature, the end result being a development, the identification of class owners (more on this in a minute), and the identification of feature set owners. The majority of the effort on an FDD project, roughly 75%, is comprised of the fourth and fifth steps:
Design By Feature and Build By Feature. These two activities are exactly what you'd expect, they include tasks such as detailed modeling, programming, testing, and packaging of the system.
FDD also defines a collection of supporting roles, including:
• Domain Manager
• Release Manager
• Language Guru
• Build Engineer
• Toolsmith
• System Administrator
• Tester
• Deployer
• Technical Writer
FDD's five steps are supported by several practices. The first is domain object modeling, the creation of a high-level class diagram and supporting artifacts that describes the problem domain. Developing by feature and individual class ownership are also good practices, as is having developers work together in feature teams.
Inspections are an important aspect of FDD. FDD also insists on regular builds, similar to XP, and configuration management. Finally, FDD promotes a best practice called reporting/visibility of results, similar to XP and AM's philosophy of open and honest communication.
How would Agile Modeling (AM) be applied on an FDD project? The principles and practices can be clearly applied to FDD's two modeling-oriented steps –
Develop an overall model and design by feature. The only apparent mismatch between the two processes is FDD's practice of class ownership and AM's practice of collective ownership, but I would argue that this isn't the case. FDD's practice pertains to coding but does not to modeling, on a FDD project people work together in teams to model, along the lines of AM's model with others practice, and therefore several people will be working on your shared collection of modeling artifacts.
Question :- Discuss the Agile Software Development vs. Waterfall Software
Development?
Answer----> There isn’t a single methodology that you can apply across all projects. However, many teams are moving toward an adaptive methodology, such as Agile, and moving away from the predictive, Waterfall methodology when developing software.
The conventional Waterfall development method follows strict phases, sticking to the original requirements and design plan created at the beginning of the project. A project manager spends time negotiating milestones, features, resources, working at length in the planning stages of a project, usually developing a full-blown project plan that details how the work will be moved through many gates to completion.
Customers finalize requirements before development begins and then a lengthy development process occurs, with the project manager tracking every movement of the project through each handoff and finally on to delivery.
If everything goes well, this process produces an on-time, on-budget release. The chief drawbacks to this approach are well-documented: it is not responsive to change and it takes a long time to deliver working software. When technology forms the field of play and drives every change, a six month (or longer) release cycle, with requirements chiseled in stone, does not meet the business need.
The history behind Agile software development is one of frustration with the traditional waterfall methodology. Agile is designed to accommodate change and the need for faster software development (as discussed in the Agile Manifesto's Values and Principles). The project leader typically facilitates the work of the development team, eliminates bottlenecks, and helps the team stay focused in order to deliver software iterations on a regular basis. It is less about milestones than it is about hours, feature selection, prioritization, and meetings.
Unlike the Waterfall model, the development team ultimately decides at the beginning of a sprint (or iteration) what can be accomplished in the timeframe and sets out to build a series of features, delivering working software that can be installed in a production environment at the end of the sprint. Since Agile software development methods (such as Dynamic Systems Development Method- DSDM) are flexible, most are suitable for method tailoring – where development teams can adapt the flow to meet the needs of the product.
Question :- Explain the the Agile Lifecycle?
Answer----->There are a variety of Agile software development (or system development) methodologies, including, but not limited to:
• Disciplined Agile Delivery (DAD)
• Adaptive Software Development
• Agile Modeling
• Kanban
• Scrum
• Scrumban
• Extreme Programming (XP)
• Dynamic Systems Development (DSDM)
• Feature Driven Development
• Lean Software Development
The overall goal of each Agile method is to adapt to change and deliver working software as quickly as possible. However, each methodology has slight variations in the way it defines the phases of software development.
Question :- What is The Agile Process Flow?
Answer---->
1. Concept - Projects are envisioned and prioritized
2. Inception - Team members are identified, funding is put in place, and initial environments and requirements are discussed
3. Iteration/Construction - The development team works to deliver working software based on iteration requirements and feedback
4. Release - QA (Quality Assurance) testing, internal and external training, documentation development, and final release of the iteration into production
5. Production - Ongoing support of the software
6. Retirement - End-of-life activities, including customer notification and migration
This view presents the full Agile lifecycle model within the enterprise. In any enterprise there may be projects operating simultaneously, multiple sprints/iterations being logged on different product lines, and a variety of customers, both external and internal, with a range of business needs.
Question :- What is The Agile Iteration Workflow?
Answer----> The Agile software development lifecycle is dominated by the iterative process. Each iteration results in the next piece of the software development puzzle - working software and supporting elements, such as documentation, available for use by customers - until the final product is complete. Each iteration is usually two to four weeks in length and has a fixed completion time. Due to its time-bound nature, the iteration process is methodical and the scope of each iteration is only as broad as the allotted time allows.
Multiple iterations will take place during the Agile software development lifecycle and each follows its own workflow. During an iteration, it is important that the customers and business stakeholders provide feedback to ensure that the features meet their needs.
A typical iteration process flow can be visualized as follows:
• Requirements - Define the requirements for the iteration based on the product backlog, sprint backlog, customer and stakeholder feedback
• Development - Design and develop software based on defined requirements
• Testing - QA (Quality Assurance) testing, internal and external training, documentation development
• Delivery - Integrate and deliver the working iteration into production
• Feedback - Accept customer and stakeholder feedback and work it into the requirements of the next iteration
For the duration of the project, while additional features may be fed into the product backlog, the rest of the process is a matter of repeating the steps over and over until all of the items in the product backlog have been fulfilled. As a result, the process flow is more of a loop and not a linear process.
Making the Agile Process Work for You
As with any methodology, there are advantages and disadvantages (Read about the advantages and disadvantages of Agile). The Agile method is more suitable in situations where customers and project stakeholders are available to provide input, functional portions of software are needed quickly, flexibility is desired to accommodate changing requirements, and the team is co-located and able to effectively collaborate. As with any change, integrating Agile processes into your business can be overwhelming. Below are four activities that will help support the adoption of Agile workflow:
• Daily Meetings - Host consistent or daily stand-up meetings to maintain open communication, hold workers accountable, and keep each iteration moving forward
• Live Demonstrations - Deliver live demonstrations of each iteration’s final product to show progress
• Share Feedback - Receive feedback from stakeholders and customers and share it with the entire team before the next iteration begins
• Remain Agile - Make changes to your process based on feedback to ensure each iteration improves the last
Using Smartsheet to Manage the Agile Lifecycle
Smartsheet is a powerful collaboration and project management tool. It’s ideal for prioritizing user stories and managing product and iteration backlogs. Easily switch between Grid, Gantt, and Calendar views to manage project details and track deadlines. Use the Card View to focus attention with rich cards, provide perspective with flexible views, and prioritize and adjust work more visually. Display information on cards including custom fields, images, and color-coding to better focus your team’s attention. Agile project managers can categorize cards into lanes to help organize what needs to happen in sprints and iterations.
Question :- What are the Work products?
Answer----> Test Plan is prepared at the time of Release Planning and is revised at every Sprint Planning. Test Plan acts as a guide to the testing process in order to have the complete test coverage.
Typical Contents of a Test Plan are −
• Test Strategy
• Test Environment
• Test Coverage
• Scope of Testing
• Test Effort and Schedule
• Testing Tools
In Agile Projects, all the Team Members are accountable for the quality of the product. Hence, everyone participates in test planning as well.
A testers’ responsibility is to provide necessary direction and mentor the rest of the team with their testing expertise.
User Stories
User Stories are not testing work products in principle. However, in Agile Projects, the testers participate in the User Stories Creation. Testers write User Stories that bring value to the customer and cover different possible behaviors of the system.
Testers also ensure that all the User Stories are testable and ensure the Acceptance Criteria.
Manual and Automated Tests
During the first run of Testing, Manual Tests are used. They include −
• Unit Tests
• Integration Tests
• Functional Tests
• Non-Functional Tests
• Acceptance Tests
The Tests are then automated for subsequent runs.
In Test Driven Development, Unit Tests are written first to fail, Code is developed and tested to ensure the Tests pass.
In Acceptance Test Driven Development, Acceptance Tests are written first to fail, Code is developed and tested to ensure the Tests pass.
In other Development methods, the Testers collaborate with the rest of the Team to ensure Test Coverage.
In all the types of methods, Continuous integration takes place, which includes continuous integration testing.
The team can decide when and what tests are to be automated. Even if automation of the tests requires effort and time, the resulting automated tests significantly reduce the repetitive testing effort and time during the iterations of the Agile Project. This in turn facilitates the team to pay more attention to the other required activities, such as new User Stories, Changes, etc.
In Scrum, the iterations are time-boxed. Hence, if a User Story testing cannot be completed in a particular Sprint, the tester can report in the daily standup meeting that the user story cannot reach the Done Status within that Sprint and hence needs to be kept pending to the next Sprint.
Test Results
As most of the Testing in Agile Projects is automated, the Tools generate the necessary Test Results Logs. Testers review the Test Results Logs. The test results need to be maintained for each sprint / release.
A Test Summary can also be prepared that contains −
• Testing Scope (What was tested and what was not tested)
• Defect Analysis along with Root Cause Analysis if possible
• Regression Testing Status after Defect Fixes
• Issues and the corresponding Resolution
• Pending Issues, if any
• Any modifications required in Test Strategy
• Test Metrics
Test Metrics Reports
In Agile Projects, the Test Metrics include the following for each Sprint −
• Test Effort
• Test Estimation Accuracy
• Test Coverage
• Automated Test Coverage
• No. of Defects
• Defect Rate (No. of Defects per User Story Point)
• Defect Severity
• Time to Fix a Defect in the same Sprint (It costs 24x as much to fix a bug that escapes the current sprint)
• No. of Defects fixed in the same Sprint
• Completion of Acceptance Testing by Customer within the Sprint
Sprint Review and Retrospective Reports
Testers also contribute to the Sprint Review and Retrospective Reports. The typical contents are −
• Test Metrics
• Test Result Logs review results
• What went right and what can be improved from Testing Point of View
• Best Practices
• Lessons Learned
• Issues
• Customer Feedback
UNIT -2 END.................
Written by- Salman Khan
0 Comments