CS代考 CSIT314 Software Development Methodologies

CSIT314 Software Development Methodologies
Kanban and Extreme Programming (XP)
Acknowledgement: Materials used in the following lecture slides are adapted from http://www.extremeprogramming.org and https://www.atlassian.com/agile/kanban/

Copyright By PowCoder代写 加微信 powcoder

Agile Manifesto – recap
Individuals and interactions
Working software
Process and tools
Customer collaboration
Comprehensive documentation
Contract negotiation
Following a plan
Responding to change
over Source: www.agilemanifesto.org

Kanban – history
 Kanban (meaning “billboard” or “signboard” in Japanese)
 Kanban was originally developed by Toyota for manufacturing
 Adapted to software development in 2010
Watch this video

 Kanban has become a popular agile software development methodology/framework
 Real-time team communication
 Full transparency of work
 Visually tracking progress

Kanban board
 Represents the overall project
 Has 5 components:
 Visual signals
 Work-in-progress limits
 Commitment point
 Delivery point

Kanban board (cont.)
 Visualsignals:
 Visual cards representing work
items or user stories
 These cards help all team members quickly see what the team is working on
 Columns:
 Each column represents different “stage” in the workflow.
 Cards go through each stage in the workflow.
 Workflows can be customized:  “ToDo”,“InProgress”,
“Complete”
 “To Do”, “In Progress”, “Code Review”, “Done”

Kanban board (cont.)
 Work In Progress (WIP) Limits:
 Maximum number of cards in one column at any given time
 When the maximum number of cards is reached, the team needs to focus on the work in those cards to move them to the next stage.
 Once this is resolved, new cards can be moved into that column.
 This is a quick way to identify bottlenecks

Kanban board (cont.)
 Commitment point:
 The time point when an item is selected from the backlog and moved into the Kanban board.
 Signifies that work for this item is now started
 Delivery point:
 The end of a Kanban
team’s workflow
 Product is delivered to the clients
 Lead time = Delivery point – Commitment point

Kanban physical board

Kanban virtual board

Kanban tool support
 Trello https://youtu.be/l3F3l3psqXY  JIRA

Kanban benefits
 Easy to use, simplicitiy
 Visual interface
 Instantly see what everyone is working on
 Visibility to task progress and bottlenecks (e.g. a specific task is holding up the project)

Kanban vs. Scrum
Release methodology
Key metrics Change philosophy
Regular fixed length sprints (ie, 2 weeks)
At the end of each sprint
Product owner, scrum master, development team
Teams should not make changes during the sprint.
Continuous flow Continuous delivery
No required roles
Lead time, cycle time, WIP
Change can happen at any time
Source: https://www.atlassian.com/agile/kanban/kanban-vs-scrum

Let’s discuss this case study
 https://resources.kanban.university/wp- content/uploads/2016/04/Mobile.de-Final- Case-Study.pdf

Extreme programming
 Started in 1996, developed primarily by .
 Extreme programming is one several popular agile methods
 Key characteristics:
 Stress customer satisfaction
 Empower developers to confidently respond to changing requirements
 Strong emphasis on teamwork and peers
 Deliver as early as possible and obtain early feedback from customers.

The Values of Extreme Programming
 Simplicity:
 We will do what is needed and asked
for, but no more.
 We will take small simple steps to our goal and mitigate failures as they happen.
 We will create something we are proud of and maintain it long term for reasonable costs.

The Values of Extreme Programming
 Communication:
Everyone is part of the team and
we communicate face to face daily.
We will work together on everything from requirements to code.
We will create the best solution to our problem that we can together.

The Values of Extreme Programming
 Feedback:
 We will take every iteration commitment seriously by delivering working software.
 We demonstrate our software early and often then listen carefully and make any changes needed.
 We will talk about the project and adapt our process to it, not the other way around.

The Values of Extreme Programming
 Respect:
 Everyone gives and feels the respect they
deserve as a valued team member.
 Everyone contributes value even if it’s simply enthusiasm.
 Developers respect the expertise of the customers and vice versa.
 Management respects our right to accept responsibility and receive authority over our own work.
Source: http://www.extremeprogramming.org

The Values of Extreme Programming
 Courage:
 We will tell the truth about progress and
estimates.
 We don’t document excuses for failure because we plan to succeed.
 We don’t fear anything because no one ever works alone.
 We will adapt to changes when ever they happen.
Source: http://www.extremeprogramming.org

Extreme Programming Process

Extreme Programming Process
 Release planning
 User stories are written.
 Each user story represents a desired feature and all stories represent the specification of the system.
 Customers prioritize user stories based on business value (e.g. essential, highly valuable or good idea).
 Estimate each user story in terms of ideal days.

Extreme Programming Process Planning
 Release planning (cont.)
 Together developers and customers create a set of stories to be implemented as the first (or next) release.
 Make frequent small releases.
 A useable, testable system that makes good business
sense delivered early is desired.
 You may plan by time or by scope:
 how many stories can be implemented before a given date (time), or
 how long a set of stories will take to finish (scope)

Extreme Programming Process Planning
 Iteration Planning

Extreme Programming Process Planning
 Iteration planning
 Iteration planning takes place before each
iteration.
 Unimplemented user stories are selected from the iteration plan for the upcoming iteration.
 User stories implemented in the previous iterations but did not pass acceptance tests are also selected.
 The total user stories selected should have the total estimates up to the project velocity from the last iteration.

Extreme Programming Process Planning
 Planning (cont.)
 Project velocity is often used to measure how much work is getting done on your project.
 simply adding up the estimates of the user stories that were finished during the iteration.
 The user stories and failed tests are broken down into the developing tasks
 While user stories are in the customer’s language, tasks are in the developer’s language (design, coding, etc.)

Extreme Programming Process Planning

Extreme Programming Process Designing
 Simplicity in design
 Testable, Understandable, Browsable, and
Explainable
 Use Class Responsibilities and Collaboration (CRC) cards for design sessions.
Source: http://agilemodeling.com/artifacts/crcModel.htm

Extreme Programming Process Designing
Source: http://agilemodeling.com/artifacts/crcModel.htm

Extreme Programming Process Designing
 Create spike solutions to reduce risk.
 spike solution is a very simple program to
explore potential solutions.
 Build the spike to only addresses the problem under examination and ignore all other concerns.
 Most spikes are not good enough to keep, so expect to throw it away.
 Refactor whenever and wherever possible

Extreme Programming Coding
 Code must be written to agreed coding standards.
 E.g. http://www.oracle.com/technetwork/java/code convtoc-136057.html
 https://google.github.io/styleguide/javaguide. html

Extreme Programming Coding
 Code the unit test first (Test Driven Development)
 See https://youtu.be/O-ZT_dtlrR0
 All production code is pair programmed.  https://youtu.be/fQ-x-T34z9w
 https://youtu.be/5ySLQ5_cQ34
 Code review
 https://youtu.be/HW0RPaJqm4g
 Integrate often.

The rules of Extreme Programming
 All code must have unit tests.
 All code must pass all unit tests before it can be released.  When a bug is found, tests are created.
 Acceptance tests are run often
 Acceptance tests are created from user stories.
 The customer specifies scenarios to test when a user story
has been correctly implemented.
 A story can have one or many acceptance tests, what ever it takes to ensure the functionality works.
 Acceptance tests are black box system tests. Each acceptance test represents some expected result from the system => see the lecture notes on Testing for example of system test cases.
 A user story is not considered complete until it has passed its acceptance tests.

Extreme Programming Proess Managing
 Managing
 Give the team a dedicated open work space.  Set a sustainable pace.
 A stand up meeting starts each day.
 Move people around.

Scrum vs. XP
 There are many similarities between Scrum and XP.  A few important differences:
 Scrum teams do not allow changes into their sprints. XP teams allows for user stories to be removed or added in an ongoing iteration.
 Extreme Programming teams work in a strict priority order. By contrast, the Scrum product owner prioritizes the product backlog but the team determines the sequence in which they will develop the backlog items.
 Scrum doesn’t prescribe any engineering practices. XP does, e.g. test-driven development, pair programming, etc.
Source: https://www.mountaingoatsoftware.com/blog/differences-between-scrum-and-extreme- programming

Recap quiz
 1. Incremental development in Extreme Programming (XP) is supported through a system release once every month.
2. In XP, as soon as the work on a task is complete, it is integrated into the whole system.
Source: http://www.sanfoundry.com/software-engg-mcqs-extreme-programming/

Recap quiz
 3. In XP Increments are delivered to customers every _______ weeks.
c) Three d) Four
 4. User requirements are expressed as __________ in Extreme Programming. a) implementation tasks
b) functionalities
c) scenarios
d) none of the mentioned

Recap quiz
 5. Is a customer involved test development and validation in XP ?
c) It may vary from Customer to Customer d) None of the mentioned
 6. Programmers prefer programming to testing and sometimes they take short cuts when writing tests. For example, they may write incomplete tests that do not check for all possible exceptions that may occur.
a) True b) False

Recap quiz
 7. Tests are automated in Extreme Programming.
 8. In XP an automated unit test framework is used to write tests for a new piece of functionality before that functionality itself is implemented.

Recap quiz
 9. Developers work individually on a release and they compare their results with other developers before forwarding that release to customers.
 10. Which four framework activities are found in the Extreme Programming(XP) ?
a) analysis, design, coding, testing
b) planning, analysis, design, coding
c) planning, design, coding, testing d) planning, analysis, coding, testing

程序代写 CS代考 加微信: powcoder QQ: 1823890830 Email: powcoder@163.com