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)