[20160314][cuhk][csci4140]life of an agile team]
TRANSCRIPT
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
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)
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.)
● 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
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/
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!
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: [email protected]– Web: http://pantarei-design.com