3. Typical Agile Cycle
Capacity planning, Scoring, Story point
Pair programming, mob programming,
Continues integration
Review the upcoming work
Demo with PO and stakeholders
Definition of done?
What went well, dint went well,Idea’s?
3
Sprint planning
Backlog grooming
Sprint Demo
Story acceptance
Retrospective
End
Development
and testing
4. Sprint planning
• Capacity planning: before starting new sprint teams
estimate the productive hours they are available for sprints.
• This hours are basically when you just sit and code. Any
meetings are excluded from this estimate. On a average 5
hour per day is productive hours when you just sit and
code. Rest of the time is meetings and discussions/helping
team mates.
• Story are usually divided into small, medium, large and
extra large (3, 5,8, 13 points respectively).
• It is recommended that the story greater than 13 points
should be further break down into smaller stories.
4
5. Pair programing
• Pair programming is an agile software development
technique in which two programmers work together at one
workstation. One, the driver, writes code while the other,
the observer or navigator, reviews each line of code as it is
typed in.
5
6. Mob Programming
• Mob programming is a software development approach
where the whole team works on the same thing, at the
same time, in the same space, and at the same computer.
This is similar to pair programming where two people sit
at the same computer and collaborate on the same code at
the same time.
6
7. Backlog Grooming
• As sprint progresses it is very important to figure out and
plan upcoming work.
• This meeting can be done twice every sprint. Time boxed
to 30 min each.
• Agile god’s always recommend you should always have
next 6 sprints (3 months) work planned and groomed.
• This also gives visibility to PO and company as a whole
that if team can take new work or reprioritize some of the
work.
7
8. Definition of done ?
• All used cases covered as per acceptance criteria.
• 85% code coverage.
• At least few functional e2e passing (automated).
• Code review completed and review comments addressed.
• Code is merged to GIT repo.
8
9. Retrospective
• Is a practice used by teams to reflect on their way of working, and to
continuously become better in what they do. This consist of four
key area’s:
What went well ? What didn't’t went well?
Area’s of improvement Appreciations for team
• Often items from retro gets converted to a new story and assigned to it
owner in the coming sprint.
• In the next retrospective actions item are reviewed again with team
9
10. GIT FLOW
• GIT flow model:
Reflects production Upcoming release Current work
• Idea here is when you are ready to push the code to prod you cut a release from develop. In
continues integration release is usually planned at the end of every sprint.
• If any bug found after release. You commit that change directly to release push it prod and then
merge it to master.
10
Master Release Develop
Current Sprint
HotFix
11. GIT Flow (continued)
• Long running branches are strongly discouraged. Its gets difficult to maintain
long running branches. You should always merge your branch at the end of
every sprint.
• If you need to push something to production before the live data. It is
recommended that you develop the feature with a WOWO (wire on wire off)flag
and push the changes to production with feature turned off.
• It is recommended to push code to production at the end of every sprint.
Instead doing it every month or 3 months. In this approach you will find bugs
sooner and your development branch is close to production code.
11
12. SDLC
Pipeline
commit
Usual sprint activates Create a unique manifest Code deployment
Code coverage Stage env
Run unit tests QA env
Linting
Some light testing final code deploy to prod Run e2e func test on
staging
12
Developer Git Static analysis Deployment to QA
Functional testDeploy to ProdSanity testing
Post prod merge Monitoring/Alerts
13. Node.js @ Paypal
• Expert/Mentors : In 2012, Paypal hired Douglous Crawkford a trailblazing JavaScript guru.
• Early adoption: In 2012, the build there first app with node.js. In 2013 PayPal open sourced
kraken.js : node.js framework.
• Kraken Framework(open sourced):
It’s not a framework in itself, but a convention layer on top of express that allows it to scale to larger
development organizations. They wanted engineers to focus on building their applications and not
just focus on setting up their environments.
• Development:
Built almost twice as fast with fewer people
Written in 33% fewer lines of code
Constructed with 40% fewer files
• Performance:
Double the requests per second vs. the Java application
35% decrease in the average response time for the same page. This resulted in the pages being served 200ms
faster— something users will definitely notice.
13
14. Node.js @ PayPal (continued)
• Automation team: 3-4 member team focused on building automation tools so
development team can focus more on development and less on how to
automate it. Nemo.js is an open sourced node.js UI testing framework
developed by PayPal.
• Node infrastructure team: 8-10 member team of highly experienced node.js
engineer. There goal is develop frameworks (Kraken) and libraries/utilities so
that development team can focus on the development tasks.
• Training team: 8-10 member team dedicated to provide node.js/Javascript
training to PayPal employees.
• Community: Internal node.js community with 700 node.js developer ready to
help out if you need any help with development or just need some opinion.
Slack channels are used where people can ask any questions related to
node.js
14
