Scribd Logo
Upload

Welcome to Scribd!

  • 402 views

    Scrum Refresher

    Uploaded by

    Amri Hidayat
    This slide is shared among CCH Cyberjaya Software Development Team with a background of Scrum (Agile Methodology). The presentation is intended to share best practices on both Scrum methodology and software engineering best practices.

    Copyright:

    © All Rights Reserved
    Download as PPTX, PDF, TXT or read online from Scribd

    Scrum Refresher

    Uploaded by

    Amri Hidayat
    402 views26 pages
    This slide is shared among CCH Cyberjaya Software Development Team with a background of Scrum (Agile Methodology). The presentation is intended to share best practices on both Scrum methodology and software engineering best practices.

    Copyright

    © © All Rights Reserved

    Available Formats

    PPTX, PDF, TXT or read online from Scribd

    Did you find this document useful?

    Is this content inappropriate?

    This slide is shared among CCH Cyberjaya Software Development Team with a background of Scrum (Agile Methodology). The presentation is intended to share best practices on both Scrum methodology and software engineering best practices.

    Copyright:

    © All Rights Reserved
    Download as PPTX, PDF, TXT or read online from Scribd
    Download as pptx, pdf, or txt
    402 views26 pages

    Scrum Refresher

    Uploaded by

    Amri Hidayat
    This slide is shared among CCH Cyberjaya Software Development Team with a background of Scrum (Agile Methodology). The presentation is intended to share best practices on both Scrum methodology and software engineering best practices.

    Copyright:

    © All Rights Reserved
    Download as PPTX, PDF, TXT or read online from Scribd
    Download as pptx, pdf, or txt
    You are on page 1of 26

    AGILE METHODOLOGY

    Amri Hidayat
    Senior Technology Analyst amri.hidayat@gmail.com

    SCRUM ROLES

    Scrum Team

    Taken from:http://en.wikipedia.org/wiki/Dragon_boat

    SCRUM CEREMONIES

    Sprint Planning Daily Standup


    Showcase (Review) Retrospective

    SCRUM VALUES

    Focus
    Courage Openness Commitment

    Respect

    Commitment

    ENGINEERING BEST PRACTICES

    Scrum
    Topless meetings No distractions (Scrum Values: Focus, Commitment, Respect)
    No phones / tablet / chatting while other team member is contributing in

    a conversation Generate more discussions

    Ad-hoc & frequent communications


    Scrum values: Courage, Openness Face2Face > Skype > Phone > Chat > Nothing

    Scrum (cont.)
    Smaller handoffs Scrum value: Focus

    Scrum (cont.)
    Smaller handoffs (cont.)

    Scrum (cont.)
    Estimates & Commitments Trade-off between commitment & estimation Scrum Values: Courage, Openness, Commitment

    Scrum (cont.)
    Sprint Showcase Tell, dont show (describe what the user story is about) Describe the impact of the functionality being presented Show the tests (if running it doesnt work) [ Hint: Recorded Coded UI ]

    Swarming
    Pair Programming Helps on knowledge sharing between team member
    Also helps reducing communication between team member <> product

    owner.
    Boost confident of the team on taking/conquering more complex

    problem (mission critical applications) Collective Ownership of the whole application


    Anyone can: Change any line of code, Fix bugs, Improve architecture No one: Becomes a bottle neck for changes (i.e. leaves, holiday, etc)

    Scrum Values: Focus, Openness, Respect, Courage, Commitment Real world example of swarming ?

    Taken from: http://www.navy.mil/view_image.asp?id=20537

    http://www.navy.mil/view_image.asp?id=3239

    Design Patterns
    Data Layer: Nhibernate, Entity Framework, Active Record
    Methods: Repository, Data Transfer Object, Object Relational Mapping Support for Agile Database Design: Migrating (brining UP & bringing DOWN) Reverting Seeding

    Dependency Injection: StructureMap, Unity, Ninject


    Methods: Constructor Injection Method Injection Property (Setter Injection)

    Test Driven Development


    Unit Testing
    Methods: Red, Green, Refactor Arrange, Act, Assert

    Mocking: Moq, NMock, Mox, Rspec


    Hand-in-hand with Dependency Injection

    Helps tester with complex (unrelevant) dependency Example: Assert method which requires a user to be authenticated first (e.g. Oauth) Assert method which retrieved data from a backend database (time consuming and prone for error)

    Test Driven Development


    Demo (MoqExample.zip)
    TDD Mocking Dependency Injection

    Test Driven Development (cont.)


    Automated Regression Test (CodedUI, Selenium, Robotium)
    Note: Use the same programming language (or technology stack) as the

    main application being tested. The developer will have the knowledge on both developing the main application and creating the test scripts for test it.
    Example: Test .NET desktop/ASP.NET application with CodedUI Test Android app with Robotium

    Framework for Integrated Testing (FIT)


    Customer provide examples of how their software should work Test data (expected values) provided by product owners/customers.

    They now best what to expect for the outcome

    Branching & Merging Strategy


    Traditional (One development branch)
    Pros: Easy to maintain Fast & easy commits Cons: High risk on a big team working on different features (user stories) Messy Forward Integration

    Branching & Merging Strategy (cont.)


    Feature-based (One branch per feature/user story) Pros:
    Scrum Values: Focus, Commitment Work on 1 (or 2) user story at one time. It encourage team to swarm on a feature Reduces/Eliminates unrelated (other user stories) bugs introduced in QA release
    Traditional:
    Iteration almost ended, showcase about to start (3 user stories in 1 sprint) Only 2 user stories completed (DONE DONE), What happens to the last user story which has already being checked in but not yet tested ? Revert back ? Delete files ?

    Feature-based:
    Iteration almost ended, showcase about to start (3 user stories in 1 sprint) Only 2 user stories completed (DONE DONE), What happens to the last user story which has already being checked in but not yet tested (remember: in different branch) ? Do Nothing!. Let work on it next sprint.

    Cons: High maintenance


    Could end up with a lot of branches being created.

    Feature-based Branching

    Branching & Merging Strategy (cont.)


    Feature-based Day 1 - Iteration Starts (Tuesday) Team decides to take US 510 a very complicated feature with ItemID: 21422
    Create a branch (called 21422 or US510)

    Day 2 to 3 Team work on US 510 (perform add, change, delete,

    commit)
    Add/Change/Delete/Commit on branch US510

    Day 4 Team completed with the development of US 510

    (Development DoD)
    Merge back to QA branch. At this point, developer starts manual testing (or

    trigger automated ui testing). Product owner starts user acceptance test.


    Day 5 Product owner accepts US 510 (User Story DoD)
    Merge back to Main branch. Close US510 branch.

    Day 6 Team decides to take US 511 also a very complicated

    feature

    Create a branch (called US511)

    Day 10 SHOWCASE, bug found!


    Create a branch (called Bug button is not big enough)

    You might also like