• Save
Agile Project Management
Upcoming SlideShare
Loading in...5
×

Like this? Share it with your network

Share

Agile Project Management

  • 4,663 views
Uploaded on

Embracing Change with Agile

Embracing Change with Agile

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
4,663
On Slideshare
4,183
From Embeds
480
Number of Embeds
3

Actions

Shares
Downloads
0
Comments
0
Likes
9

Embeds 480

http://www.agile66.com 463
http://www.slideshare.net 16
http://aroi.in.th 1

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide
  • Brain product includes creativity and talent Brain = complex
  • Barry Boehm ในปี 1981
  • Advocates ชอบให้เกิดการโปร่งใส One of the key ideas behind agile software development is providing information as early as possible to allow the business to best make decisions .
  • Absolute estimation จะขึ้นอยู่กับมุมมองของแต่ละคน junior, senior developer จะเอาเครื่องวัดไปนั่งวัดก็ได้ แต่ก็คงใช้เวลานาน คล้ายๆกับใช้เวลา plan project 3 เดือน แทนที่จะเอาเวลาไปทำงานจริงๆ แต่ถ้าให้คาดเดาแล้วล่ะก็ relative estimation เหมาะกับมนุษย์มากกว่า
  • Management มักจะบอกว่า ทีมมี 4 คน ใช้เวลา 2 เดือน ถ้าใส่เข้าไปอีก 4 คนก็ต้องเหลือเดือนเดียวสิ งานบางอย่าง share ไม่ได้ communication & process overhead - งานไม่จบถ้า test ไม่เสร็จ จากครั้งที่แล้ว dev & test คิดต่างกัน แต่ point เท่ากัน possibility ที่จะเกิดอย่างนั้นมีได้หน่อย ก็แค่ estimate ผิดพลาดก็คือการเรียนรู้ เมื่อเทียบกับการที่มีคนที่ไม่ได้ทำงานจริง estimate มาให้ โอกาสที่จะได้คุยกันในแบบนี้มีมากกว่า
  • ไม่ใช่การคาดเดา แต่เป็นการค้นพบ Customer defines the scope เราจะเอาทรายใส่แค่ไหน ถังใหญ่แค่ไหน
  • ณ วันที่เริ่ม project ใช้ velocity จากโปรเจคเก่า ที่มีลักษณะใกล้เคียงกัน หรือ เลือก stories ที่อยู่ใน highest priorities ที่คาดว่าน่าจะทำเสร็จได้ใน iteration แรก แล้วเอา story point ตรงนั้นมาเป็น estimated velocity
  • Burndown chart ก็คงจะไม่ราบเรียบเหมือนชีวิตคนเรา ที่ขึ้นก็คือ requirements ที่เพิ่มเข้ามา เห็นชัดเจน transparent
  • highest priorities from the Release (after customer has re-prioritized if it’s the later release) Switching task takes more time than you think Stories ไม่ควรจะข้ามพาด iteration เพราะนานเกิน ไม่ได้ test ไม่ได้ feedback
  • Duration estimate is harder to match  ยากที่จะทำให้ได้ตามนั้น ถ้ากำหนดเป็นวันที่ Plans are made at different levels: Project, Release, Iteration เราเห็นภาพของแต่ละ level อย่างชัดเจน และสามารถย้อนจาก level ที่แคบกว่า ขึ้นไปมอง level ที่กว้างกว่าได้ ให้เห็นความสัมพันธ์ e.g. burndown chart is a must because sometimes can lose track State Uncertainty in no Uncertain terms ใน agile เราบอกไปตรงๆเลยว่า แน่นอน project นี้มันมีความไม่แน่นอน ทุกคนต้องยอมรับความจริงในจุดนี้ Plans are by Features, not Tasks We want the features not the tasks Tracking is at the Team level, not Individual ตัดปัญหา ถ้ามีคนป่วย ลาออก
  • People who make the product happens participate
  • Testers can write tests while developers write code มี tool ช่วยเยอะนะ เดี๋ยวนี้ สามารถแปลง user story exit criteria มาเป็น test cases ได้เลย ถ้าเกิดส่งนี้ใน state นี้ของโปรแกรม จะต้องได้สิ่งนี้ออกมา exit criteria เป็น functional tests Junior developer can make changes to old code  encourage growth Technical debt may appear faster at first, but things that hidden underneath the carpet will creep back at you later ทำแล้วไม่ผิด แต่ไปตามเก็บด้วยนะเออ
  • the developer MUST fix it immediately  ถ้าไม่ทำอย่างนี้ก็ไม่มีประโยชน์ ไม่ว่าจะเป็น test ใดๆ ถ้าต้องทำซ้ำๆ automation is the key ไม่งั้นก็ไม่มีวันทันต่อการเปลี่ยนแปลง
  • บางทีม เปิดเพลงเมื่อ success เปิดเสียงหวอ เมื่อ fail Fail นี่ต้องบอกอยู่แล้ว แต่อาจจะมี success notification ใน step ย่อยๆได้ เพื่อให้คนที่เกี่ยวข้องสบายใจ หรือจะเลือก test เป็น set set เพื่อให้ test เสร็จเร็วช้า แล้วแต่ต้องการ
  • Burndown chart ก็คงจะไม่ราบเรียบเหมือนชีวิตคนเรา ที่ขึ้นก็คือ requirements ที่เพิ่มเข้ามา เห็นชัดเจน transparent สีแดงคือ worst case สีน้ำเงิน คือ best case สีดำคือ average ใช้ average velocity
  • Learn from mistakes, Learn from success – ไม่ได้ learn from failure อย่างเดียวนะ อะไรที่ทำแล้วดี ก็ควรทำต่อ แต่ถ้าบางทีเราไม่หยุดมาดู เราจะไม่รู้ ว่าอะไรทำแล้วดี ช้าไป ทุกอย่างอาจจะสายเกินแก้ Time for improvement ถ้าเราหยุดอยู่กับที่ ก็เท่ากับเดินถอยหลัง Stop to Breathe ไม่หยุดมันเหนื่อย
  • Define Improvement Goals – only a few because we want to be able to see progress in the next retrospective
  • สรุป ก็จะเห็นว่า มีหลายอย่างที่มีประโยชน์ และเอามาเลือกใช้ได้ แล้วแต่ nature ของ project ของคุณ ในแต่ละอันก็มี technique ย่อยๆ ลงไปอีก
  • มีเป้าหมายก่อนว่าจะทำ practice เหล่านั้นเพื่อมาแก้ปัญหาอะไร

Transcript

  • 1. Agile Project Management: Embracing Change Sinaporn Suebvisai Agile Evangelist
  • 2. Speaker’s Background
    • Bachelor Degree in Computer Engineering from Chulalongkorn University in 2001
    • Master Degree from School of Computer Science, Carnegie Mellon University, in 2004
    • Joined Thomson Reuters as Software Engineer
    • Became Development Group Leader in 2007
    • Led the effort to adopt Agile process into the team
    • One of the main Agile advocates in Thomson Reuters Collaboration Team
    • Joined Proteus Technologies as Agile Evangelist late 2008
    [email_address]
  • 3. What is Agile?
    • The Agile Manifesto – Utah 2001
      • Individuals and interactions over processes and tools
      • Working software over comprehensive documentation
      • Customer collaboration over contract negotiation
      • Responding to change over following a plan
  • 4. What is Software Project Management?
    • Software Project Management   is the art and science of planning and leading software projects . It is a sub - discipline of   project management   in which   software   projects are planned, monitored and controlled . [wikipedia]
    • We will control four variables in our projects — cost, time, quality, and scope . Of these, scope provides us the most valuable form of control. [“E xtreme Programming Explained: Embrace Change”, Kent Beck]
    • Without management, project teams may pursue the wrong project, may not include the right mix of personalities or skills, may be impeded by organizational dysfunctionality, or may not deliver as much value as possible . [“The Need for Agile Project Management”, Mike Cohn and Ken Schwaber ]
  • 5. Why are there changes?
    • Software is a brain product only (from Philosophy of the Course, Software Project Management course at SEI).
    • We’re implementing things that have never been done before.
    • Project uncertainties
      • Budget changes
      • Market changes
      • Resource changes
    • We can’t predict the future
  • 6. Cost of Change Curve http :// www . ambysoft . com / essays / whyAgileWorksFeedback . html
  • 7. Why Agile Maybe Your Solution
    • Agile allows you to make changes by utilizing Best Practices
      • Evolutionary Delivery vs. All at Once
        • Barry Boehm’s Spiral Model
      • User Stories
        • Kent Beck’s Xtreme Programming
      • Short, Focused, Meetings of Cross Functional Teams
        • Jeff Sutherland, et al, SCRUM
    • Agile advocates Transparency
      • Always provide information as early as possible which allows making decision faster
    • Agile is completely Value Driven
    • Agile focuses on Working Software at all time
    • Agile Estimating & Planning automatically embodies uncertainties
  • 8. Agile Techniques
    • User Stories
    • Estimating & Planning
    • Scrum
    • Test Driven Development
    • Continuous Integration
    • Iteration Close-down and Demo
    • Retrospective
  • 9. Agile Techniques
    • User Stories
    • Estimating & Planning
    • Scrum
    • Test Driven Development
    • Continuous Integration
    • Iteration Close-down and Demo
    • Retrospective
  • 10. User Stories
    • A User Story is a Brief statement of Functionality but told from the User’s perspective.
    • INVEST in User Stories
      • Independent
      • Negotiable
      • Valuable
      • Estimable
      • Small
      • Testable
    As a <stakeholder> , I want to <goal> so that <reason> .
  • 11. Story Card User Story Description http :// www . agilemodeling . com / images / models / userStoryFormal . jpg Story ID From Discussion Story Points Exit Criteria
  • 12. How User Stories Help?
    • Let the customers explain the product in the way they understand
    • Can easily be changed, thrown away when no longer valid, and Prioritized
    • State why customer wants the feature to make an understanding between developer and customer
    • Leave room for discussion
    • Can easily make sure that we finish what we are asked to do
  • 13. Agile Techniques
    • User Stories
    • Estimating & Planning
    • Scrum
    • Test Driven Development
    • Continuous Integration
    • Iteration Close-down and Demo
    • Retrospective
  • 14. Why Traditional Planning Fails
    • Planning is by Activity rather than Feature
      • Activities don’t finish earlier than planned
      • Lateness is passed down the schedule
      • Activities are not dependent
    • Estimates become Commitments
      • This has to be done by this date and with all these features.
    • Features are not developed by Priority
    • Uncertainty is ignored
  • 15. Estimating & Planning
    • Story Point Estimation
    • Planning Poker
    • Prioritization
    • Planning a Release
    • Burndown Chart
  • 16. Story Point Estimation
  • 17. Story Point Estimation
    • Measure Relative Complexity of User Stories
    • Considers the Entire Efforts of Dev & Test
    • Use the Fibonacci Sequence in order to prevent arguments over a 10% estimate difference.
      • 1, 2, 3, 5, 8, 13, 21, etc…
    • Far less likely for management to successfully play “Time Math” with.
  • 18. Planning Poker
  • 19. Planning Poker
    • Every team member is given a deck of Planning Poker cards
    • The moderator gives an overview of a given feature
    • The team members ask question and discuss to clarify assumptions and risks. Discussion is recorded
    • When everyone is ready, they simultaneously vote for the estimate
    • If estimates differ, the high and low estimators explain their estimates
    • After another discussion, the team members revote
    • The vote continues until the estimates converge or everybody can agree on one estimate
  • 20. Prioritization
    • Face the Fact: You may not get everything you want in the time you want
    • BUT you can get what you really want first
    • Prioritization is the key to getting the features that will give the most value to the product
    • Prioritization can change as we learn more about the project
    • Increase Value and Decrease Risks earlier in project
  • 21. Prioritization in Agile Projects
    • Prioritization in Agile projects is just where you put your story card in the stack
    • Prioritization can be in many levels: Project, Release, Iteration
    • At the end of each Iteration or Release, Priorities can be revised
    • Prioritization is set by Customers with input from the team
  • 22. Planning a Release A Release (Customer decides what makes a Release)
    • User Stories
    • The one higher to the top has higher priority
    Iteration Length = Shovel size Velocity = The average amount of sand you can carry in the shovel Release Length = How long it takes to get the sand out with the shovel (DISCOVER)
  • 23. Burndown Chart 150 125 100 75 50 25 0 1 2 3 4 5 6 7 8 9 10 With estimated velocity, we can estimate how long the release may take. The Burndown chart needs to be updated every iteration to reflect the actual situation.
  • 24. Burndown Chart (later) http :// www . mountaingoatsoftware . com / system / asset / file / 65 / PredictiveBurndownChart . jpg
  • 25. Planning an Iteration
    • Start every iteration with an iteration planning meeting
    • Decide on what the team will focus on:
      • We should not move stories in and out during an iteration  Distraction: only 2 hours is never 2 hours
      • Usually, the highest priorities from the Release
    • Split stories to smaller stories if they cannot fit within an iteration
    • The team makes the commitment and sets the expectation for customer
  • 26. Why Agile Planning Works
    • Instead of creating the perfect plan, create a plan that is useful right now
      • BUT update plan when necessary
    • Effort Size and Duration are separated
      • Duration estimate is harder to match
    • Plans are made at different levels: Project, Release, Iteration
    • State Uncertainty in no Uncertain terms
    • Tracking is at the Team level, not Individual
    • Plans are by Features, not Tasks
    • Transparency Builds Trust and Credibility!
  • 27. Agile Techniques
    • User Stories
    • Estimating & Planning
    • Scrum
    • Test Driven Development
    • Continuous Integration
    • Iteration Close-down and Demo
    • Retrospective
  • 28. Scrum http://www.mountaingoatsoftware.com/system/hidden_asset/file/17/ScrumLargeLabelled.png
  • 29. Daily Scrum Meeting
    • Status update from team member
      • Development, QA, Project Manager participitate
      • Customers and users can attend, but cannot speak
    • Start at the same time everyday
    • Keep it short
      • Not more than 30 minutes
      • Stand-up helps to keep it short
    • Each team member:
      • What have you been doing since last SCRUM meeting?
      • What are you doing next?
      • Are there any issues?
  • 30. Daily Scrum Storyboard
  • 31. Special Thanks to K.Kulawat W. & K.Werachai P. from Thomson Reuters
  • 32. How Scrum Helps
    • Small Releases
      • Learn before your budget is used up
      • Give your customers a chance to change their mind  They will love you for this 
    • Transparency of Project Status
    • Everybody knows what everybody else is doing
    • Shippable Product at All Time
  • 33. Agile Techniques
    • User Stories
    • Estimating & Planning
    • Scrum
    • Test Driven Development
    • Continuous Integration
    • Iteration Close-down and Demo
    • Retrospective
  • 34. Test Driven Development
    • Developer is responsible for Unit Tests
    • Testers/QAs also write tests  Functional Tests
    • Encourage developers to make changes without fears
    • The changes that come into the project will require you to make design improvement (refactor) often
      • People like to pay technical debt by hacking things in
      • If you have unit tests, you will feel more at ease in moving things around
      • Refactoring should be every developer’s job and should be done ALL THE TIME
  • 35. Agile Techniques
    • User Stories
    • Estimating & Planning
    • Scrum
    • Test Driven Development
    • Continuous Integration
    • Iteration Close-down and Demo
    • Retrospective
  • 36. Continuous Integration
    • Continuous integration makes sure you find problems faster
    • In every change that developers make (into the source control system), Continuous Integration must be run
    • If the Continuous Integration fails, the developer MUST fix it immediately
      • Take out the code or Fix the code to pass the fail tests
    • Automation is the KEY
  • 37. Continuous Integration
    • Unit Tests
    • Functional Tests
    • Integration Tests
    • Deployment Tests
    • Coding Standard Check
    • Code Coverage
    • Notification on Failure and Success
  • 38. Agile Techniques
    • User Stories
    • Estimating & Planning
    • Scrum
    • Test Driven Development
    • Continuous Integration
    • Iteration Close-down and Demo
    • Retrospective
  • 39. Iteration Close-down meeting
    • Conclude the Iteration
      • Look at the stories that have been closed in this iteration (in the storyboard)
      • Everybody in the team and Customer see the same picture of the project
      • Team feels accomplished
    • Update the Progress in relation to the Release
      • Update Burndown Chart
    • Demo
      • Shippable Software
      • Customers are happy when they see progress
      • Early feedback from customers, which can be used for the next iteration planning
  • 40. Burndown Chart (later) http :// www . mountaingoatsoftware . com / system / asset / file / 65 / PredictiveBurndownChart . jpg
  • 41. Agile Techniques
    • User Stories
    • Estimating & Planning
    • Scrum
    • Test Driven Development
    • Continuous Integration
    • Iteration Close-down and Demo
    • Retrospective
  • 42. Retrospective Meeting
    • At the end of each Iteration and Release
    • The only way we know where we are is that we know where we’ve been
      • Learn from mistakes, Learn from success
    • Gives a chance for people to speak up
    • Do not let problems pile up
    • Time to Eliminate Wastes
    • Time for Improvement
    • Stop to Breathe
  • 43. Do s and Don’t s
    • Do s
      • Create Safe Environment
      • Identify Wastes
      • Define Improvement Goals (prioritize your goals also)
      • Define Tracking Method for Improvement Goals
      • Assign the person to track the improvement
    • Don’t s
      • Find people to blame for failure
      • Only a few people speak
      • Not including everybody in the team
      • Do not have any improvement goals at the end of the meeting
      • Decide that the problem is outside the team
  • 44. Agile Techniques
    • User Stories
    • Estimating & Planning
    • Scrum
    • Test Driven Development
    • Continuous Integration
    • Iteration Close-down and Demo
    • Retrospective
  • 45. Cost of Change Curve http :// www . ambysoft . com / essays / whyAgileWorksFeedback . html
  • 46. Adopting Agile
    • Start with adopting practices that are easier to bring into the project
      • Understand what your goal is in doing each practice before you start doing them
    • Start with a smaller team, and expand to more teams later
    • Each team may not need the same Agile practices
    • Keep improving and adjusting (through retrospective) to find what’s best for your project
  • 47. References
    • Agile Estimating and Planning
      • Mike Cohn
    • Principles of Software Engineering Management
      • Tom Gilb
    • Agile Retrospectives: Making Good Teams Great
      • Esther Derby, Diana Larsen, Ken Schwaber
    • Extreme Programming Explained: Embrace Change
      • Kent Beck
    • Many other websites, just search for it 
  • 48. Q&A
    • Thank you ka’ 
    • Does anybody have any question?