Auditing in an Agile Environment Andres Camacho August 2012

Agenda Intro to Agile Software Development Highlight practices Things to look for in an audit Questions Debunk some myths along the way

access to all of their expenses and online accounts Manilla Security is top of mind at Manilla Secure software development Secure, one-stop “Digital Life Management Dashboard” that gives consumers simple, instant, direct access to all of their expenses and online accounts

What happens when things change? Waterfall Standard waterfall software development Along the way documents are created: MRD (Marketing Requirements Document) PRD (Product Requirement Document) Design documents QA Test plans “Wicked Problem” – a term coined in the 1970s, a problem whose requirements and limitations cannot be entirely known before completion What happens when things change?

Agile Software Development Iterative Working software over comprehensive documentation Collaboration over contract negotiation Responding to change Early visibility How does Agile reconcile with IT audits and secure software development?

Agile Software Development User stories Whole team Backlog Early visibility Automated tests Fast iterations Continuous integration Pair programming User stories Whole team Backlog Early visibility Automated tests Fast iterations Continuous integration Pair programming User stories Velocity Whole team Test driven development Estimation session Sustainable pace Backlog Daily standups Early visibility Automated tests Simple designs Fast iterations Planning game Continuous integration Refactoring Pair programming Collaboration over contract negotiation Many companies don’t implement all practices We’ll cover a few and highlight things to look for in audits

User Story Unit of work Small, stands on its own two feet Estimable Placeholder for a conversation One of the hardest exercises for those new to Agile is breaking down big features into small stories No front end vs backend As a … I can … so that …

User Story Requestor of the story accepts Owner of the story is the one who implements Acceptor is not necessarily QA. At Manilla blackbox,QA may come in after the fact

Story Workflow Started Finished Delivered – Ready for Requestor to take a look in a staging environment Rejected Accepted

Backlog User stories that are ready to be implemented Developers work next story in queue No P’s We use Pivotal Tracker

Pivotal Tracker Pivotal Tracker – Built from the ground up for Agile Pivotal Tracker – 380,000 users

Git Standard source code control software for Ruby community Github, social coding Rigorous commit workflow At Manilla we use enterprise GitHub 2 million projects, 1 million users Is GitHub secure?

Commit Workflow All work done using feature branches Format: feature-3274744-Add_custom_reminders feature branch Commit hook ensures story id

Iteration Stories and bugs that are released to production Stories labeled (tagged) by release date We can always go back to Pivotal and see what was released on a particular date When something goes wrong, always ask what changed? Tagging iterations helps us trace back changes.

Release W TH F M T W TH F Production Staging bug fixes tag and release to production bug fixes Staging release branch feature branch Stole from another presentation, won’t get into details 3 branches of code, called branches because they resemble branches on a tree Blackbox QA, still a need at Manilla Walk through release to production Remember what I said about fast iterations? Some companies do continuous deployment ----- Meeting Notes (7/13/12 14:43) ----- Can recall what happened on stories Master Staging branch merged End of Iteration

Whole Team Hire generalists Everyone gets to work on everything Automatic cross training Small teams Product/QA are part of the team Team size: Enough to share a pizza – 4-8

Pair Programming 2 developers 1 story Built in code review Built in cross training Collaboration Workspace is important: desks for easy pairing, large monitors, spare mice and keyboards

Collaboration

Pull Request Request by a contributor to pull code changes into a codebase Used extensively by open source projects Adopted as a code review tool We can’t always pair program

Pull Request

Automated Tests “pay me now or pay me more later” Critical, especially with dynamic languages (Ruby, Python) Unit tests, acceptance tests Test Driven Development At Manilla 3 lines of test code for every 1 line of code

Continuous Integration Check in early and often Automated builds and deployments Keep the build fast Everyone can see the results

Continuous Integration Not only are tests automated but deployments are too Java – compiling is a test Dynamic language like Ruby/Rails no compile step, tests are critical As a manager it is much easier to get Ruby/Rails dev to write tests. The community is a big proponent

Early Visibility Early visibility also means iterate fast, get your product out there Minimum Viable Product – the minimum core set of features/functionality. Get it in front of users and have then give feedback.

Where is the documentation?

Documentation Tests serve as documentation When tests fail they are described using plain English. Example.

Documentation New project, makes an HTML site by inspecting tests Allows for test descriptions Not documenting code here, instead documenting tests

Resources Manilla – http://www.manilla.com Pivotal Tracker – http://www.pivotaltracker.com Github – http://www.github.com Relish - https://www.relishapp.com/

My Background Degree in Finance, many courses in Accounting Auditor for Price Waterhouse in San Jose, CA Computer Science courses at San Francisco State Positions at Price Waterhouse, NextCard, QRS, Yaga, Vinfolio, and Manilla