Agile Development with PHP in Practice

Preview:

DESCRIPTION

After a short theoretical introduction into the Extreme Programming (XP) and Scrum, the two major flavours of agile development, we will work on an example web project using Extreme Programming. The workshop will cover the whole development cycle - from planning through setting up a continuous integration server with test framework, up to developing and shipping a web application with PHP. We will add new features incrementally in a test-driven way, covering the application with unit and acceptance tests, keeping it integrated and fully functional all the time. While working, we will exercise all main practices of XP, starting with Pair Programming, Simple Design, Test-Driven Development, Refactoring and finishing with Continuous Integration and Small Releases.

Citation preview

Practising Agile Development for Beginners

30.10.2009

Lars Jankowfsky

CTO swoodoo AG

Freitag, 30. Oktober 2009

About me:

PHP, C++, Developer, Software Architect since 1992

PHP since 1998

Many successful projects from 2 to 20 developers

Running right now three projects using eXtreme Programming

CTO and (Co-)Founder swoodoo AG

(Co-)Founder OXID eSales AG

Freitag, 30. Oktober 2009

lessons learned

COST QUALITY TIME SCOPECOST QUALITY TIME SCOPE

Freitag, 30. Oktober 2009

Get ReadyFIRE!Aim...Aim...Aim...

Freitag, 30. Oktober 2009

Agile methods are based on

Communication Feedback

Courage Simplicity

Freitag, 30. Oktober 2009

http://agilemanifesto.org/

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

Freitag, 30. Oktober 2009

Agile? THINK!

Agile?

Freitag, 30. Oktober 2009

popular Agile methods

Adaptive Software Development

Feature Driven Development

DSDM - Dynamic Systems Development Method

Scrum

crystal clear

XP

Freitag, 30. Oktober 2009

Scrum

Plan ( product backlog )

Sprint planning session

Sprint ( == Iteration )

Daily meetings

Sprint review

Closure

http://www.controlchaos.com/

Freitag, 30. Oktober 2009

eXtreme Programming

for smaller teams ( 2 - 12 )

focuses on automatic testing

a change in the way we program

includes continuous integration

http://www.extremeprogramming.org/

Freitag, 30. Oktober 2009

Lessons learned

Freitag, 30. Oktober 2009

eXtreme Programming

„Software development is too hard to spend time on things that don't matter. So, what really matters? Listening, Testing, Coding, and Designing.”

Kent Beck, “father” of Extreme Programming

Freitag, 30. Oktober 2009

eXtreme Programming

people vs. hardware

automated tests

continuous integration

Freitag, 30. Oktober 2009

eXtreme Programming

Coding Testing

Planning Designing

Freitag, 30. Oktober 2009

Planning XP

Planning

The Customer Stories

Estimation Release Plan

Freitag, 30. Oktober 2009

The Customer

Is always available Writes User Stories and specifies Functional TestsSets priorities, explains storiesMay or may not be an end-user Has authority to decide questions about the stories Create/Defines acceptance tests

Planning

Freitag, 30. Oktober 2009

Balancing Power

Freitag, 30. Oktober 2009

Customer bill of rights

As the customer, you have the right to:• An overall plan, to know what can be accomplished, when, and at what cost

• Get the most possible value out of every programming week

• See progress in a running system, proven to work by passing repeatable tests that you specify

• Change your mind, to substitute functionality, and to change priorities without paying exorbitant costs

• Be informed of schedule changes, in time to choose how to reduce scope to restore the original date, even cancel at any time and be left with a useful working system reflecting investment to date.

Planning

Freitag, 30. Oktober 2009

Programmer bill of rights

As the Developer, you have the right to:• Know what is needed, with clear declarations of priority;

• Produce quality work at all times;

• Ask for and receive help from peers, superiors, and customers;

• Make and update your own estimates;

• Accept your responsibilities instead of having them assigned to you.

Planning

Freitag, 30. Oktober 2009

The Stories Planning

A short story about the functionality from the point of view of the Customer

No technical jargon

One for each major feature in the system

Must be written by the customer

Are used to create time estimates for release planning

Replace a large Requirements Document

The stories are the base for acceptance tests

Only enough detail to make a low risk estimate of how long the story will take to implement.

Freitag, 30. Oktober 2009

Planning XP - the Stories Planning

Use simple technics ( postit )Find a place where all developer can see the stories

Freitag, 30. Oktober 2009

Estimation Planning

Yesterdays Weatheruse your experienceask other teams which may have done similar thingsEstimate using „Story Points“ == ideal Person Days

Freitag, 30. Oktober 2009

Release Plan

Customer defines the business value of desired stories ( priority ) Stories which are too large need to be split into smaller chunksHigher risks stories should come firstDefine release dates - these are fixed, scope not

Planning

Freitag, 30. Oktober 2009

The Release plan Planning

Freitag, 30. Oktober 2009

Never slip a date!

falling behind ? Change the plan!

Planning

Freitag, 30. Oktober 2009

Iterations Planning

From release backlog the stories with highest priorities are taken and assigned to the next iteration.

An iteration can be 1-3 weeks usually

Stories for Iteration are broken down into Tasks by Developers

Tasks are estimated by all Developers as a group

Developers “sign up” for Tasks, and estimate the time to complete

Freitag, 30. Oktober 2009

Iterations... Planning

If a task has more than 2-3 Story points, then break it into smaller parts.

If there are any questions ask the customer, he should attend Iteration planning meeting

Can only sign up for as many points as were completed in the last Iteration

Once development begins, Project Velocity measures progress

Freitag, 30. Oktober 2009

Iterations... Planning

Freitag, 30. Oktober 2009

Stand Up Meeting Planning

Track status in daily Stand-Up Meeting

Ask for Story Points left - not for SP done

Every morning for 5 minutes

STAND UP!

What did you do yesterday ?

What do you plan todo today ?

Any „Showstoppers“ or important issues ? ( e.g. taking half day off... )

Tell Team what you did, not some „Task number“

Freitag, 30. Oktober 2009

During Iteration: Tracking speed Planning

Freitag, 30. Oktober 2009

Designing XP

Designing XP

Simplicity Standards

Spike Solutions Never Add Functionality Early

Freitag, 30. Oktober 2009

(c) aboutpixel.de(c) spackletoe http://www.flickr.com/photos/spackletoe/90811910/)Freitag, 30. Oktober 2009

Simplicity Designing XP

Keep things as simple as possible as long as possible by never adding functionality before it is scheduled.

Always do the simplest thing that could possibly work

Beware, keeping a design simple is hard work!

Freitag, 30. Oktober 2009

(c) istockphoto

Freitag, 30. Oktober 2009

Standards Designing XP

Name classes and methods consistently. (Metaphor)

Choose a system of names for your objects that everyone can understand easily (Zend?)

Being able to guess at what something might be named if it already existed and being right is a real time saver

PHP Code Sniffer http://pear.php.net/package/PHP_CodeSniffer

pre commit hook

Freitag, 30. Oktober 2009

Spike Solutions

Don‘t guess on difficult questions, try it!

Create simple programs to get answers.

It reduces the risk of a technical problem or increase the reliability of a user story's estimate.

API? Performance? Database?

Designing XP

Freitag, 30. Oktober 2009

Never Add Functionality Early Designing XP

Don‘t implement what you don‘t need now

Only 10% of your guesses will be really used later

Turn a blind eye towards future requirements and extra flexibility.

Concentrate on what is scheduled for today only.

Freitag, 30. Oktober 2009

Coding XP

Coding XP

Code the unit test first. Check in daily.

Collective code ownership. Optimization last.

No overtime. Refactor Mercilessly

Freitag, 30. Oktober 2009

Code the unit test first. Coding XP

Upon creation of a function write unit tests

Write many tests for each function

Success case

Error case

Stupid input case

Freitag, 30. Oktober 2009

PHPUnit - http://www.phpunit.de/

Freitag, 30. Oktober 2009

Proxy for testing protected methods

class unittools{ public static function getProxy($superClassName, array $params = null) { $proxyClassName = "{$superClassName}Proxy"; if (!class_exists($proxyClassName, false)) { $class = <<<CLASS class $proxyClassName extends $superClassName { public function __call(\$function, \$args) { \$function = str_replace('UNIT', '_', \$function); if(method_exists(\$this,\$function)) { return call_user_func_array(array(&\$this, \$function), \$args); } else { throw new Exception("Method ".\$function." in class ".get_class(\$this)." does not exist"); } } public function setNonPublicVar(\$name, \$value) { \$this->\$name = \$value; } public function getNonPublicVar(\$name) { return \$this->\$name; } }CLASS; eval($class); } if (!empty($params)) { // Create an instance using Reflection, because constructor has parameters $class = new ReflectionClass($proxyClassName); $instance = $class->newInstanceArgs($params); } else { $instance = new $proxyClassName(); } return $instance; }}

Coding XP

Freitag, 30. Oktober 2009

STOP

Freitag, 30. Oktober 2009

Freitag, 30. Oktober 2009

Enforces layered Architecture

Freitag, 30. Oktober 2009

class someOtherClass { var $setting;

function calculateSomething($a, $b) { return $a+$b; }}

class myOldNastyClass {

function needToTestThisFunction() {

$class = new someOtherClass();

$z = $_GET['input'];

// ....

return $class->calculateSomething( $class->setting, $z); }}

Layer Example Coding XP

Freitag, 30. Oktober 2009

Layer Example

class someOtherClass { private $setting;

public function calculateSomething($a, $b) { return $a+$b; }

public function setSetting($set) { $this->setting = $set; }

public function getSetting() { return $this->setting; }}

class myInput { public function getParameter($name) { return $_GET[$name]; }}

class myOldNastyClass {

private $input; // set e.g. in constructor

public function needToTestThisFunction(someOtherClass &$class, $z) {

$z = $input->getParameter('input'); // ....

return $class->calculateSomething( $class->getSetting(), $z); }}

Coding XP

Freitag, 30. Oktober 2009

(c) istockphoto

Freitag, 30. Oktober 2009

Code the unit test first. Coding XP

OOP, public, private

Globals

Superglobals

Sessions

Cookies

Freitag, 30. Oktober 2009

Dependencies ... Coding XP

Separate logic from view

create accessors, add all parameters in calls

Freitag, 30. Oktober 2009

Dependency Example

class displayUserDetails(){ /** * Processes input and sends user first name, last name to display; */ function show() { global $dbLink; global $templateEngine; $itemId = (int) $_REQUEST['user_id']; $firstName = $dbLink->getOne("select first_name from users where id = $itemId"); $lastName = $dbLink->getOne("select last_name from users where id = $itemId"); $templateEngine->addTemplateVar('firstName', $firstName); $templateEngine->addTemplateVar('lastName', $lastName); $templateEngine->display(); }}

Coding XP

Freitag, 30. Oktober 2009

Dependency Example Coding XP

/** * A view class responsible for displaying user details. */class userView(){ /** * Loads user object and sends first name, last name to display */ public function show() { $userId = $this->_inputProcessor->getParameter("user_id"); $this->templateEngine->addTemplateVar('user', $this->model->loadUser(userId)); $this->templateEngine->display(); }} /** * And the corresponding model */class userModel(){ public function loadUser($userId) { $user = new User( $userId ); return array('firstName' => $user->getFirstName(), 'lastName' => $user->getLastName()); }}

Freitag, 30. Oktober 2009

Fixtures Coding XP

Make sure that tests don‘t alter fixture

Fixture is FIXture

if you feel creating fixtures is too much work - refactor more!

Do never let tests leave altered tests

Freitag, 30. Oktober 2009

YAML loading

public static function create($fileName) { $fileName = 'Fixtures'.DIRECTORY_SEPARATOR.$fileName; ob_start(); include $fileName; $fileContents = ob_get_contents(); ob_clean(); $yamlData = syck_load($fileContents); return $yamlData; }

Coding XP

Freitag, 30. Oktober 2009

YAML storing

public static function load($fixtures, $tableName) { if (is_array($fixtures) && count($fixtures)) { foreach ($fixtures as $fixture) { if (is_array($fixture) && is_array(current($fixture))) { Fixtures::load($fixture, $tableName); } $fields = array_keys($fixture); $statement = "INSERT INTO $tableName (" . implode(', ', $fields) . ") VALUES (:" . implode(", :", $fields) . ")"; $stmt = self::$_db->prepare($statement); if (count($fixture)) { foreach ($fixture as $key => $value ) { $stmt->bindValue(':'.$key, $value); } } $stmt->execute(); self::$_usedTables[$tableName] = $tableName; } } }

Coding XP

Freitag, 30. Oktober 2009

YAML - cleanup

if (!empty(self::$_usedTables)) { foreach (array_reverse(self::$_usedTables) as $tableName) { self::$_db->execute("TRUNCATE TABLE $tableName"); } }

Coding XP

Freitag, 30. Oktober 2009

Fixtures the other side ...

manual fixtures are too much work

use a test database

think about automatic creation of YAML files

Coding XP

Freitag, 30. Oktober 2009

Mocking stubs?

„...may simulate the behavior of existing code (such as a procedure on a remote machine) or be a temporary substitute for yet-to-be-developed code...“

Coding XP

Freitag, 30. Oktober 2009

Mocking stubs? Coding XP

Unittesting is about testing a unit of work, not a complete workflow

isolates your code from external dependencies

can be done with PHPUnit, but you don‘t need to

Freitag, 30. Oktober 2009

Mocking stubs The PHPUnit way Coding XP

/** * A simple stub providing a simple result directly instead of using the database */class UserModelStub extends UserModel { public getUserCount() { return 10; }}

UserModelStub extends PHPUnit_Framework_Testcase { public function testGetUserCount() { $stub = $this->getMock(‘UserModel‘); $stub->expects($this->any())->method(‘getUserCount‘)->will($this->returnValue(10)); }}

Freitag, 30. Oktober 2009

Check in daily

Forces developer to write small functions

Makes it impossible to create huge frameworks/functions

This is the fundament for having good tests later

Remember: You are not allowed to check in without Tests!

Coding XP

Freitag, 30. Oktober 2009

Collective code ownership Coding XP

Collective Code Ownership encourages everyone to contribute new ideas to all segments of the project. (Don Wells)

Have a look what your collegaues are doing

Any developer can change any line of code to add functionality, fix bugs, or refactor.

Freitag, 30. Oktober 2009

Pair Programming? Coding XP

All code to be included in a production release is created by two people working together at a single computer... ????

Our experience is different!

Use pair programming on difficult tasks e.g. refactoring, framework etc.

In small teams it makes no sense to use it always.

Freitag, 30. Oktober 2009

Freitag, 30. Oktober 2009

Optimize last Coding XP

Make it work, make it right, then make it fast.

Never guess what performance will be - measure it!

Create clear rules for performance and test it. ( „ab“ or „siege“ can be used in unit tests )

Freitag, 30. Oktober 2009

No overtime Coding XP

Projects that require overtime to be finished on time will be late no matter what you do.

Overtime sucks the spirit and motivation out of a team.

Better play a game instead and build castles instead of creating bugs in the software

Freitag, 30. Oktober 2009

Refactor Mercilessly Coding XP

“Refactoring is the process of changing a software system in such a way that it does not alter the external behavior of the code yet improves its internal structure.”

Martin Fowler

Freitag, 30. Oktober 2009

(c) istockphoto

Principle of „Bad smell“

Freitag, 30. Oktober 2009

comments „what not why“

long methods

dead code

data classes

Freitag, 30. Oktober 2009

Refactor Mercilessly Coding XP

No fear! Your tests will show if you break something.

Keep your code clean!

Freitag, 30. Oktober 2009

Freitag, 30. Oktober 2009

Testing XP

Testing XP

Create acceptance tests.

Use continuous integration!

Run tests automatically Publish the results

Freitag, 30. Oktober 2009

Hope vs. Knowledge

Freitag, 30. Oktober 2009

UNIT TESTS

INTEGRATION TESTS

ACCEPTANCE TESTS

Freitag, 30. Oktober 2009

Acceptance Tests Testing XP

use Selenium

Java solution which enables automatic „click“ tests.

Download Selenium RC

http://www.openqa.org/selenium-rc/download.action

Create Acceptance Tests with Selenium IDE

Use PHPUnit and create Unit Tests

Base Tests on Customer Stories

Freitag, 30. Oktober 2009

Integration Tests Testing XP

can be Unit Tests or Selenium

Testing API‘s, whole Modules

Overall picture instead of single functions

Freitag, 30. Oktober 2009

continuous integration

„Continuous Integration is a software development practice where members of a team integrate their work frequently, usually each person integrates at least daily - leading to multiple integrations per day. Each integration is verified by an automated build (including test) to detect integration errors as quickly as possible. „

Testing XP

http://www.martinfowler.com/articles/continuousIntegration.html

Freitag, 30. Oktober 2009

continuous integration Testing XP

cruisecontrol - http://cruisecontrol.sourceforge.net/

phpundercontrol - http://phpundercontrol.org

check out http://buildix.thoughtworks.com/

Freitag, 30. Oktober 2009

continuous integration Testing XP

Freitag, 30. Oktober 2009

„Questions?“

Freitag, 30. Oktober 2009

Resources used:

Extreme Programming: A gentle introduction.

http://www.extremeprogramming.org/

Extreme Programming - Introduction

Mayford Technologies Inc.

Wikipedia

Extreme Programming Explained: Embrace Change - Kent Beck

Refactoring Improving the Design of Existing Code - Martin Fowler

Freitag, 30. Oktober 2009

Recommended