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

1. CUHK CSCI 4140 2016 Spring
Guest Lecture
Life of an Agile Team
PantaRei Design Limited
Wong Hoi Sing, Edison
2016 March 14th

2. 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

7. 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

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

14. What is Agile Development?
●
Agile
●
Scrum
●
Kanban
●
Scrum vs Kanban

15. Agile
●
A group of software development methods
●
Requirements and solutions evolve through
collaboration between self-organizing, cross-
functional teams
●
Promotes adaptive planning, evolutionary
development, early delivery, continuous
improvement, and encourages rapid and flexible
response to change

17. Scrum
●
Iterative and incremental
●
Fixed-length iterations (e.g. 2~4 weeks)
●
4 Ceremonies
– Sprint planning
– Daily stand-up
– Sprint demo
– Sprint retrospective

20. Scrum (cont.)
●
Roles
– Product Owner
– Development Team
– Scrum Master

21. Scrum (cont.)
●
User stories
– Express customer need as a story
– Set user role
– Small amount of work
– Should include notes for needed

24. Scrum (cont.)
●
Task
– For developer
– Get engineer talking with product owner
– Get mutual understanding of the story
– Satift customer needs

26. Scrum (cont.)
●
Burndown chart
– Public displayed chart showing remaing work in
the sprint backlog
– Simple view of the sprint progress
– Quick visualization for reference

29. 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

34. Scrum vs Kanban
Scrum Kanban
Cadence Regular fixed length sprints
(ie, 2 weeks)
Continuous flow
Release methodology At the end of each sprint if
approved by the product
owner
Continuous delivery or at the
team's discretion
Roles Product owner, scrum
master, development team
No existing roles. Some
teams enlist the help of an
agile coach.
Key metrics Velocity Cycle time
Change philosophy Teams should strive to not
make changes to the sprint
forecast during the sprint.
Doing so compromises
learnings around estimation.
Change can happen at any
time

35. Why Agile Development?
●
Waterfall
●
Agile vs Waterfall

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

38. Agile vs Waterfall
Agile Waterfall
Planning scale Short Long
Distance with customer Short Very long
Time to discover problem Short Very long
Ability to respond quickly
to change request
Short N/A

39. How Agile Team Works Daily?
●
Documentation Management
●
Agile Project Management
●
Code Repository Management
●
Continuos Integration

40. 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 HOW
DEVELOPMENT WORKS!

41. 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 IN
TASK TICKETS! YOU WILL LOSS IT!

42. 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

48. 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 Document
Management for details
– When need to write code, go to Code Repository Management, create a
branch for this duty, get the job done, create a pull request to Project
Manager
●
Once pull request comes, Project Manager check the quality of
deliverable, accept it, merge to master branch, then set ticket as
done

49. 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/

54. 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

55. 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

69. 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!

70. 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
/

75. Advanced Topic(s)
●
Branching Strategies
●
Code Reviews
●
Continuous Integration (CI)

76. Branching Strategies
●
Centralized Workflow
– Like CVS/SVN, uses a central repository to serve as
the single point-of-entry for all changes to the
project
– Everyone commit all changes and push to “master”
branch
– Need to resolve all conflict before each commit/push
●
https://www.atlassian.com/git/tutorials/compar
ing-workflows/centralized-workflow

78. 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/compar
ing-workflows/feature-branch-workflow

80. Branching Strategies (cont.)
●
Gitflow Workflow
– Gitflow Workflow defines a strict branching model designed
around 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

82. 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 Git
repositories
– 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

84. Code Reviews
●
So, what exactly is a code review?
– When a developer is finished working on an issue, another
developer 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!

87. Continuous Integration (CI)
●
Merging all develop working copies with a
share 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!

90. Q&A

91. References
●
http://en.wikipedia.org/wiki/Agile_software
_development
●
http://en.wikipedia.org/wiki/Scrum_%28sof
tware_development%29
●
http://en.wikipedia.org/wiki/Kanban_%28d
evelopment%29
●
https://www.atlassian.com/agile

92. Thank You
●
Please feel free to contact us:
– PantaRei Design Limited
– Unit 326, 3/F, Building 16W
No.16 Science Park West Avenue
Hong Kong Science Park, Shatin, N.T.
– Phone: +852 2576 3812
– Fax: +852 3753 3663
– Email: sales@pantarei-design.com
– Web: http://pantarei-design.com