CUHK CSCI 4140 2016 SpringGuest Lecture

Life of an Agile Team

PantaRei Design LimitedWong Hoi Sing, Edison

2016 March 14th

Wong Hoi Sing, Edison● CEO, Founder, PantaRei Design

– 2009, PantaRei Design founded

– 2010, HKFYG YBHK applicant

– 2011, ITF SERAP applicant

– 2011, HKSTP Incu-Tech applicant

● FOSS and Drupal Developer, Contributor and HKDUG Co-founder

– 2000, Debian GNU/Linux 2.2 ('potato')

– 2005, Drupal Developer

– 2008, BarCamp HK Speaker

– 2008, HKDUG Co-founder

– 2011, Drupal 7.x Core Contributor

● http://hswong3i.net

● hswong3i@pantarei-design.com

PantaRei Design● Everything Changes and Nothing Remains Still● Reinvent Enterprise with Open Source Software and Cloud Computing● Hong Kong based FOSS Service Provider

– Content Management System (CMS) with Drupal– Cloud Hosting Solution with Amazon Web Services (AWS)– Team Collaborate Solution with Atlassian

● Business Partner with industry leaders– 2012, AWS Consulting Partner– 2013, Acquia Partner– 2013, Atlassian Experts– 2014, Rackspace Hosting Partner

● http://pantarei-design.com

Outline

● What is Agile Development?● Why Agile Development?● How Agile Team Works Daily?● Advanced Topic(s)

What is Agile Development?

● Agile● Scrum● Kanban● Scrum vs Kanban

Agile

● A group of software development methods● Requirements and solutions evolve through

collaboration between self-organizing, cross-functional teams

● Promotes adaptive planning, evolutionarydevelopment, early delivery, continuousimprovement, and encourages rapid and flexibleresponse to change

Scrum

● Iterative and incremental● Fixed-length iterations (e.g. 2~4 weeks)● 4 Ceremonies

– Sprint planning– Daily stand-up– Sprint demo– Sprint retrospective

Scrum (cont.)

● Roles– Product Owner– Development Team– Scrum Master

Scrum (cont.)

● User stories– Express customer need as a story– Set user role– Small amount of work– Should include notes for needed

Scrum (cont.)

● Task– For developer– Get engineer talking with product owner– Get mutual understanding of the story– Satift customer needs

Scrum (cont.)

● Burndown chart– Public displayed chart showing remaing work in

the sprint backlog– Simple view of the sprint progress– Quick visualization for reference

Kanban

● Just-in-time delivery● Only focused on work that's actively in

progress● Keep pluck the next work item off the top of

the backlog● Keep the most important work items on the

top of the backlog

Scrum vs KanbanScrum Kanban

Cadence Regular fixed length sprints(ie, 2 weeks)

Continuous flow

Release methodology At the end of each sprint ifapproved by the productowner

Continuous delivery or at theteam's discretion

Roles Product owner, scrummaster, development team

No existing roles. Someteams enlist the help of anagile coach.

Key metrics Velocity Cycle time

Change philosophy Teams should strive to notmake changes to the sprintforecast during the sprint.Doing so compromiseslearnings around estimation.

Change can happen at anytime

Why Agile Development?

● Waterfall● Agile vs Waterfall

Waterfall

● Usually sucks● Planning far in advance● Lack of visibility into rate of progress● Project fall behind schedule (easily)

Agile vs WaterfallAgile Waterfall

Planning scale Short Long

Distance with customer Short Very long

Time to discover problem Short Very long

Ability to respond quicklyto change request

Short N/A

How Agile Team Works Daily?

● Documentation Management● Agile Project Management● Code Repository Management● Continuos Integration

Documentation Management● Product Owner provide the story and requirement

specification, in simple English● Project Manager need to covert such simple English

into manageable documentation for Developers● Tips: Manage your client! Don’t let them manage you!● REMEMBER: YOUR CLIENT IS COMING FROM THE

HELL! THEY DON’T UNDERSTAND HOWDEVELOPMENT WORKS!

Documentation Management(cont.)

● Split the requirement specification into “point form”● Each point should be simple English that client can

understand, and able to describe the “Deliverable”, e.g.– Front Page Layout Design in HTML for Mobile Device– Contact Form with Exportable Result in CSV/XLS– Support Multilingual Content in ZH/GB/EN

● DON’T MANAGE REQUIREMENT SPECIFICATION INTASK TICKETS! YOU WILL LOSS IT!

Documentation Management(cont.)

● Atlassian Confluence– Create a page with “Product Requirements”

template– Manage “Requirement Specification” in point form,

with some detail information– Link the point to JIRA, so create it as “Story” ticket

for Scrum

● https://www.atlassian.com/software/confluence

Agile Project Management● Project Manager should create Epic / Story / Task ticket for

Developers, and manage it with Scrum / Kanban● Developers being assigned for different duty

– When requirement specification is needed, go back to DocumentManagement for details

– When need to write code, go to Code Repository Management, create abranch for this duty, get the job done, create a pull request to ProjectManager

● Once pull request comes, Project Manager check the quality ofdeliverable, accept it, merge to master branch, then set ticket asdone

Agile Project Management (cont.)

● Atlassian JIRA– Ticket created by Confluence as “Story”– Story goes to Backlog– Project Manager groups different Story from

Backlog to on going working Sprint– Sprint start and Developer get the job done

● https://www.atlassian.com/software/jira/

Code Repository Management● GIT! GIT! GIT!● Write test case for all new code!

– PM should NEVER accept new code without test case

● Ticket > Branch > Commit > Push– Push will trigger CI to run your test case– PM should NEVER accept new code if test case failed

● Pull Request > Peer Review > Merge● Once code merged, duty get done, back to Project

Management and set ticket as done, too

Code Repository Management(cont.)

● Atlassian BitBucket– Create branch for ticket– Clone source code, checkout your branch– Write new code + test case– Commit and push– Create “Pull Request”– PM merge code once peer review committed

● https://www.atlassian.com/software/bitbucket

Continuos Integration

● Developer write code with test case● Once code commit and push to Code

Repository, CI server will be triggered● CI clone the code, run the test, and report

test case run successful / fail● REMEMBER: IF YOUR TEST CASE LOGIC FAIL,

YOU WILL RESULT AS FALSE POSITIVE!

Continuos Integration (cont.)

● Atlassian Bamboo– Code commit to BitBucket, so Bamboo being

triggered– Bamboo clone the code from BitBucket– Run the defined test procedures– Return the test result to JIRA/BitBucket

● https://www.atlassian.com/software/bamboo/

Advanced Topic(s)

● Branching Strategies● Code Reviews● Continuous Integration (CI)

Branching Strategies

● Centralized Workflow– Like CVS/SVN, uses a central repository to serve as

the single point-of-entry for all changes to theproject

– Everyone commit all changes and push to “master”branch

– Need to resolve all conflict before each commit/push

● https://www.atlassian.com/git/tutorials/comparing-workflows/centralized-workflow

Branching Strategies (cont.)

● Feature Branch Workflow– All feature development should take place in a

dedicated branch instead of the “master” branch– Feature branches should have descriptive names,

like animated-menu-items or issue-#1061– Can do peer review with pull request before merge

into “master” branch

● https://www.atlassian.com/git/tutorials/comparing-workflows/feature-branch-workflow

Branching Strategies (cont.)● Gitflow Workflow

– Gitflow Workflow defines a strict branching model designedaround the project release

● “master” branch stores the official release history● “develop” branch serves as an integration branch for features● feature branches use “develop” as their parent branch● release branch off of “develop”, prepare for merge into “master” branch● “hotfix” branches are used to quickly patch production releases

● http://danielkummer.github.io/git-flow-cheatsheet/● https://www.atlassian.com/git/tutorials/comparing-workflow

s/gitflow-workflow

Branching Strategies (cont.)● Forking Workflow

– Instead of using a single server-side repository to act as the “central”codebase, it gives every developer a server-side repository

– Each contributor has a private local and a public server-side Gitrepositories

– Developers push to their own server-side repositories– Only the project maintainer can push to the official repository– This allows the maintainer to accept commits from any developer

without giving them write access to the official codebase

● https://www.atlassian.com/git/tutorials/comparing-workflows/forking-workflow

Code Reviews● So, what exactly is a code review?

– When a developer is finished working on an issue, anotherdeveloper looks over the code and considers questions

● Code reviews share knowledge● Code reviews make for better estimates● Code reviews enable time off● Code reviews mentor newer engineers● But code reviews take time!

Continuous Integration (CI)

● Merging all develop working copies with ashare mainline several times a day

● Protect quality in the code base– Continuous builds– Test automation (e.g. phpunit)

● Branching and CI: a match made in Heaven!

https://travis-ci.org/

Q&A

References

● http://en.wikipedia.org/wiki/Agile_software_development

● http://en.wikipedia.org/wiki/Scrum_%28software_development%29

● http://en.wikipedia.org/wiki/Kanban_%28development%29

● https://www.atlassian.com/agile

Thank You● Please feel free to contact us:

– PantaRei Design Limited– Unit 326, 3/F, Building 16W

No.16 Science Park West AvenueHong Kong Science Park, Shatin, N.T.

– Phone: +852 2576 3812– Fax: +852 3753 3663– Email: sales@pantarei-design.com– Web: http://pantarei-design.com