AGILE METHODOLOGY Amri HidayatSenior Technology Analystamri.hidayat@gmail.com

SCRUM ROLES

Scrum Team

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

SCRUM CEREMONIES

Sprint PlanningDaily Standup

Showcase (Review)Retrospective

SCRUM VALUES

FocusCourage

OpennessCommitment

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, don’t show (describe what the user story is about)• Describe the impact of the functionality being presented• Show the tests (if running it doesn’t 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”)