Comparing-Comparing Rup, Xp And Scrum - Mixing The Process Cocktail.pdf

Net Objectives, 3/26/2003 NetObjectivesNetObjectives1

Comparing/Combining RUP, XP, and Scrum mixing the Process

Cocktail

www.netobjectives.comDan Rawsthorne

[email protected]

etNBJECTIVES

NetObjectivesNetObjectivesNet Objectives, 3/26/2003 2

My Goal

Enlighten Teach

Entertain Feed


Agenda

The Software ProblemWhat is Process?Why Agility WorksDescription of RUPDescription of XPDescription of ScrumBest of Breed CombinationsAdditional Success Factors


THE SOFTWARE PROBLEM


The Purpose of a Project is

To provide a solution for usersThat consists of quality code

And doesnt cost too much


This Leads To

Technical Problem building quality code that satisfies the Users needsBudget Problem managing the project so that it doesnt cost too much to do so


The Technical Problem has Three Parts

RequirementsDetermine What the Software has to doChallenge: Satisfy the Users

ProductionActually Build the Software Challenge: Deliver Quality Product

MaintenanceModify Software to satisfy new requirementsChallenge: Maintain Quality

Agility has changed the ways we do theseAgility has changed the ways we do these


The Budget Problem has Many Issues

How much do I want to spend to solve the Users problem?Do my developers know how to solve the problem?Are we making progress? Are we wasting money? Are we on schedule?Is the product good enough? CMM? Are other stakeholders going to be satisfied?

How do we answer these questions?How do we answer these questions?


Players

User CommunityHas problems to be solvedUsually disorganized, chaotic, group

Customer TeamProvides requirements and validationShould speak with one voice

DevelopersActually builds the stuffLots of different roles here

Business OwnerManages resources and moneyOften ignored in Development Process


Relationships Between the Players

Developers

Customer

User

Business Owner

Develop Product

Requirements

Reporting, Monitoring


The Processes we are Discussing

The three processes being discussed today are modern ones that enable agility

Rational Unified Process (RUP) RationaleXtreme Programming (XP) Kent BeckScrum Ken Schwaber, Mike Beedle

These are not the only ones, but are some of the most common. Others include:

Dynamic Systems Development Method (DSDM)Crystal Methodologies Alistair CockburnFeature Driven Development (FDD) Peter CoadAdaptive Software Development Jim Highsmith...


Agenda

The Software ProblemWhat is Process?

Why Agility WorksDescription of RUPDescription of XPDescription of ScrumBest of Breed CombinationsAdditional Success Factors


Every software project has a process: somewhere between hack it out and Space Shuttle softwareBasically, processes tell you what to do, and when to do it.

Plan-driven: you determine up-front what youre going to do, and follow itEvaluation-driven: at any given time figure out what the next thing to do is, and do itCombination: have an initial plan, continuously updating as needed

Process


A process is needed because stakeholders have various expectations for a software project, and want some guarantee that they will get them

Why do We Need a Process?

Quality code Provide business value Follow-on work Correct code Quality product offering

Training Help desk Etc

Management visibility Quality of life Accurate progress reports React to changing

requirements CMM/ISO Test Coverage


Formal Process vs Team Discipline

There is a natural tension between having a disciplined team and having formal processThe more disciplined the team is, the lessformal process you needMost people arent disciplined enough, so some process is usually necessaryProcess is useful, but we must look at why we want the processEvery Project is different


What Defines a Process?

Principles/Fears what guides you?Activities what do you do?Roles who does it?Practices how do you do it?Products what gets produced (and persisted)?


Three Levels of Development

Business Level

Product Level

Development Level

BusinessNeedUsersUsers

CustomersCustomers

DevelopersDevelopers


Evaluating a Process

Understand the Process: what are the Principles/Fears, Activities, Roles, Practices, and Products?Determine the Coverage: how well does the process span the three levels of development?Use Your Judgment: does this process meet your needs, for this team, for this project, at this time?

Always remember: there is no one size fits all, silver bullet, process out thereAlways remember: there is no one size fits all, silver bullet, process out there


Agenda

The Software ProblemWhat is Process?Why Agility Works

Description of RUPDescription of XPDescription of ScrumBest of Breed CombinationsAdditional Success Factors


Agility is

The ability to move faster than those things that can harm your projectThe ability to keep up with relevant changes

In requirementsIn knowledge of our systemIn environment

Agility is only relevant in a context


These Things Include

Changing RequirementsNew FunctionalityLearn more about system

Changing PrioritiesDifferent StakeholdersNew Situations

Changing EnvironmentNew OS, Languages, etc

Changing BudgetsFewer DevelopersDo More with Less

More

How Can We Make This Work?


In Order to Succeed You Need Something to Work With

All managers know that you need float in order to make a project workWhen developing software, where is the floatthat we have to work with?

Lets think about this for a minute


Scope, Functionality and Robustness

Scope measures how much is in the system the product of functionality and robustnessFunctionality is based on the problems being solved or goals being addressed

some is more important than othersThought of as the width of the systemDescribed mile wide inch deep

Robustness measures the depth at which functionality is handledSecondary versionsError recoveryBusiness RulesRefinementsThe actual depth

Example: say you had to handle names in your system


Say You Need to Handle Names in Your System

Names are how people identify themselvesJohn A. SmithProf. Frederick Martin Biedenweg III, PEChuck OReilly, Susan Walton-SmytheAlbert van der HoevenFrank O, Adolph WolfeschlegelsteinhausenbergerdorftCher, Madonna, StingNguyen Bich Frank Bich Nguyen Frank Bich

Tchang Kai Chek, Chang Kai Chek, Chiang Kai-shek, JiangJieshi,

(the artist formerly known as Prince) As you can imagine, there is a large cost difference

between handling the basic functionality and handling it all

This difference is the float you have to work with


Delivering Functionality in an Agile Project

What we know to start

What we budget

What we deliver

The Universe of Possibilities

MaxROI


Agenda

The Software ProblemWhat is Process? Why Agility WorksDescription of RUP

Description of XPDescription of ScrumBest of Breed CombinationsAdditional Success Factors


RUP (Rational Unified Process)

Process Framework

Well Engineered Development Management


Perceptions of RUP

Manageable, traceable, visible, the way things

should be done

Heavyweight, boring, waste of

time


RUP Principles

Use Case DrivenArchitecture CentricIterative and IncrementalUses UMLCan be Tailored to a Projects needs

Use Case DrivenArchitecture CentricIterative and IncrementalUses UMLCan be Tailored to a Projects needs

Develop Software Iteratively

Manage Requirements Use component-based

Architectures Visually Model

Software Verify Software Quality Control Changes to

Software

Develop Software Iteratively

Manage Requirements Use component-based

Architectures Visually Model

Software Verify Software Quality Control Changes to

Software


The Real Motivation of RUPMy View

Making mistakes is expensive, so make sure you know what you want to do before you do itA good solid system has a good solid architecturePlans and Budgets are hard to follow, so you need many interim deliverables to make sure youre on track (management touch points)Things change, so be iterative and incremental so that you can modify your plans as necessary


RUP Activities

Lifetime of a system is made up of CyclesDevelopment, improvement, maintenance

PhasesInception, Elaboration, Construction, Transition

IterationProject Management, Analysis, Requirements, Design, Code, Test

ActivityList later


Cycles/Phases/Iterations


Lifetime is made of Cycles

Deliver v1.0

Deliver v2.0


Business Level

Product Level

Development Level

Phases Concentrate on Different Levels of Development

kickoff

InceptionInception

ElaborationElaboration

ConstructionConstruction

TransitionTransition

delivery 1.0

ElaborationElaboration

ConstructionConstruction

TransitionTransition

delivery 2.0

InceptionInception


RUP Activities By Phase(Project Management)

Inception Elaboration Construction

Project Management

Identify Risks ****** * *Develop Project Plan ****** * *Staff Project ****** *** ***Develop Iteration Plan * ***** *****Evaluate Iteration * *** *****Revisit Risk List * *** *****


RUP Activities By Phase(Business Modeling)

*******Find Business Workers/Entities

******Describe a Business Worker

******Describe a Business Entity

*******Review the Business UC Model

*******Review the Business Object Mdl

*******Describe Business UC

******Structure Business UC Model

******Find Business Actors and UCs

*******Capture a Common Vocabulary

Business ModelingConstructionElaborationInception


RUP Activities By Phase(Requirements)

*********Find Actors and Use Cases

******Prioritize Use Cases

******Structure the Use Case Model

*******Detail a Use Case

********User Interface Modeling

******User Interface Prototyping

*********Review Requirements

********Capture a Common Vocabulary

*******Elicit Stakeholder Requests

*******Manage Dependencies

******Develop Vision

RequirementsConstructionElaborationInception


RUP Activities By Phase(Analysis & Design)

*******Review Design

********Use Case Design

*******Database Design

*******Class Design

********Subsystem Design

********Review Architecture

*********Describe Distribution

*********Describe Concurrency

**********Use Case Analysis

********Architectural Design

**********Architectural Analysis

Analysis and DesignConstructionElaborationInception


RUP Activities By Phase(Implementation)

******Integrate Subsystem

******Review Code

******Perform Unit Test

******Fix A Defect

*******Implement Classes

******Plan Subsystem Integration

*******Integrate System

******Plan System Integration

*******Implementation Model

ImplementationConstructionElaborationInception


RUP Activities By Phase(Test)

******Evaluate Test

******Implement Test Componentsand Subsystems

******Design Test Classes and Pkgs

******Execute Performance Test

******Execute System Test

******Execute Integration Test

******Implement Test

*******Design Test

*********Plan Test

TestConstructionElaborationInception


RUP Roles

Project ManagerBusiness-Process AnalystBusiness DesignerBusiness ReviewerSystem AnalystUse Case SpecifierArchitectUser Interface DesignerRequirements Reviewer

DesignerDatabase DesignerArchitecture ReviewerDesign ReviewerSystem IntegratorImplementorCode ReviewerTest DesignerIntegration TesterPerformance Tester


RUP Practices

The actual practices are pretty much left up to the developerHowever, there are lots of diagrams like these that show how the activities fit together


Some RUP Products

Vision Document/ Business CaseGlossarySoftware Development Plan

Risk ListProject PlanMeasurement PlanCM PlanIntegration Build PlanTest Plan

Iteration PlansIteration AssessmentsUse Case ModelAnalysis ModelDesign ModelDeployment ModelImplementation ModelTest Model

Architecture Description (4+1) Use case view Analysis view Design view Deployment view Implementation view

User Interface Prototype Interfaces Analysis Packages Design Subsystems Implementation Subsystems Components Test Cases Test Procedures Test Components Test Evaluations Defect Lists


Discussion Questions

Whos going to like RUP, and why?Whos going to hate RUP, and why?


Agenda

The Software ProblemWhat is Process?Why Agility WorksDescription of RUPDescription of XP

Description of ScrumBest of Breed CombinationsAdditional Success Factors


XP (eXtreme Programming)

Development Practices

The Customer DrivesIts all about the Code


Perceptions of XP

Formalized hacking, waste of resources, no management control

Cool, trusts the developers, lets

me do my thing


XP Principles

Rapid FeedbackAssume SimplicityIncremental Change Quality Work

Rapid FeedbackAssume SimplicityIncremental Change Quality Work

Communication Simplicity Feedback Courage/Aggression

Communication Simplicity Feedback Courage/Aggression

Fine Scale Feedback Continuous Process Shared Understanding Programmer Welfare

Fine Scale Feedback Continuous Process Shared Understanding Programmer Welfare


The Real Motivation of XPMy View

Good clean code is easy to changeCustomers make all business decisionsDevelopers make all technical decisionsMake iterations as short as possible so that Customer can drive with rapid feedback


XP Activities

Produce User StoriesRelease PlanningPlanning Game (iteration planning)DevelopmentSpike SolutionRun Acceptance Tests


XP Roles

Programmer CustomerTester Coach Tracker Manager


Business Level

Product Level

Development Level

XP Practices

CollectiveCodeOwnershipCollectiveCodeOwnership

UnitTestsUnitTests

PairProgrammingPairProgramming

ContinuousIntegrationContinuousIntegration

RefactorMercilesslyRefactorMercilessly

SimpleDesignSimpleDesign

CodingConventionsCodingConventions

SustainablePaceSustainablePace

AcceptanceTestsAcceptanceTests

PlanningGamePlanningGame

SystemMetaphorSystemMetaphor

OnsiteCustomerOnsiteCustomer

SmallReleasesSmallReleases

TestDrivenDevelopmentTestDrivenDevelopment


XP Products

Release PlanUser StoryCodeUnit TestsAcceptance Tests


Use Case versus User Story

Use Case: Describes how an Actor interacts with the system to achieve a Goal

Focus is on user and validationTells a complete story

User Story: A bite-size bit of functionality that has business value and can be developed in a few days

Focus is on developer and productionPart of a complete story


Use Case versus User StoryUse Case: Logon to System

Actor: ATM Customer Scope: ATM Machine Description: After swiping the ATM Card, the user is asked for a password. The system verifies that the card is legitimate and that the password corresponds to the card. The user is then given access to all the other ATM commands. The user is given three chances to enter a correct password; after the third time the ATM Card is kept by the machine.

Sample User StoriesDisplay welcome screen until user swipes ATM Card Display login screen until password is entered Verify that ATM card is legitimateVerify the password is legitimateImplement three strikes algorithm for password entrySwallow card if card is illegitimateSwallow card if password failsReturn Card if Network Goes Down


Another Version

Story: Ok on Password screen gives full capability to anybodyStory: fixed passwords for different capability suitesStory: "three Strikes" algorithmStory: Screen Capabilities by ID still fixed password for each capabilityStory: Different Password for each IDStory: Full Password capability (different password per ID per capability suite)


Ever Unfolding Story

Use Case

Goals/Constraints

Scenario

Data Element Business RuleUI Element

Extension Sub Use Case

Other Models

Requirements Model

Vision

(sub)System


Use Cases to User Stories 1

Use Cases Technical

Sooner

Later



1

Use Cases Technical

Sooner

Later



1 2

Use Cases Technical

Sooner

Later



Use Cases Technical

Sooner

Later



Whos going to like XP, and why?Whos going to hate XP, and why?


Agenda

The Software ProblemWhat is Process?Why Agility WorksDescription of RUPDescription of XPDescription of Scrum

Best of Breed CombinationsAdditional Success Factors


Scrum

Management Strategy

Communication and EmpowermentTeam/Management Interactions


Perceptions of Scrum

Huh?!


Scrum Principles

CommitmentFocusOpennessRespectCourage

CommitmentFocusOpennessRespectCourage

Built-in instability Change out of

Chaos Self-organizing

project teams Overlapping

development phases Multi-learning Subtle control Transfer of learning

Built-in instability Change out of

Chaos Self-organizing

project teams Overlapping

development phases Multi-learning Subtle control Transfer of learning

Visibility Communications Remove

Impediments No Interference

Visibility Communications Remove

Impediments No Interference


The Real Motivations of ScrumMy View

Changes may be hard to make, so identify them as soon as possibleDevelopers know how to develop, so just stay out of their way and let them do itMake 30-day iterations for two reasons:

Enough heft to allow Developers to believe theyre doing something realShort enough so that Management doesnt feel abandoned


Scrum Activities

Sprint PlanningSprintDaily ScrumSprint Review


Scrum Roles

Scrum MasterProduct OwnerScrum Team

Not much detail, because Scrum is a light-weight management process, not a development process


Scrum Practices

Identify and Remove ImpedimentsIdentify Product BacklogDefine Sprint BacklogNo Interference, no Intruders, no PeddlersFrequent, First-Hand Observations


Scrum Products

Sprint BacklogRelease BacklogProduct Backlog

Burndown Graph

020406080

100120140160180

1 3 5 7 9 11 13 15 17 19 21 23 25 27 29

days

wor

k re

mai

ning



Whos going to like Scrum, and why?Whos going to hate Scrum, and why?


Agenda

The Software ProblemWhat is Process?Why Agility WorksDescription of RUPDescription of XPDescription of Scrum Best of Breed Combinations

Additional Success Factors


Best of Breed Combinations

My View of the Best


Best of Breed Practices/Concepts

These are the practices/concepts that I look for in a Projects process

999Risk Management99Quality Code99Management Touch Points99Large Teams99Small Teams99Complex Projects

99Use Cases

999Developer/Support Interaction99Developer/Management Interaction99Developer/Customer Interaction99Validation-Centric

?9Architecture-Centric999Iterative and Incremental

ScrumXPRUPPractice or Concept

999Business Owner Buy-In


Two Sample Cocktails

Top-Down ProcessLarge, complex projectManagement centered, ceremony needed

Bottom-Up ProcessSmall e-commerce projectDeveloper centered, keep as simple as possible

Each project must mix its own cocktail


Cocktail 1 Large, Complex Projectwhat Im thinking

Start with RUPUse 1-month iterations, a la ScrumUse XP Practices as much as possible

System Analyst or Architect acts as XP Customer for Construction PhaseAdapt XP Practices as I can for other Phases

Handle Team/Management interaction in Scrum fashionTailor out as much else as I can, without running foul of any major Stakeholders fears

Call the process Tailored RUP because thats what it is


InceptionDevelop use cases in pairs (analyst/architect + user)Do just enough to develop a backlog to start with

ElaborationDevelop architecture in pairs (analyst/architect + lead developer)Continue to work on Use Cases

ConstructionMultiple XP teams developing different parts of the architectureScrum Master for each team with Project Manager over allCross-team pairing for interface and infrastructure issues

TransitionIntegration of different parts of the architecturePairing to fix bugs and integrate

Cocktail 1 what it looks like

Iteration 1 Iteration 2 Iteration 3 Iteration 4 Iteration 5 Iteration 6

Inception Elaboration Construction Transition


Cocktail 2 Small e-commerce project

Start with XPUse 1-month iterations, a la Scrum (shorter if your tools can handle it and the team wants to)Add other Scrum practices to manage the teams relations to management

Scrum MasterProtect/Insulate the team

Add Use Cases from RUPArchitect pairs with Marketing Staff to develop themMarketing sells use cases to the worldArchitect converts use cases to user stories for the developers

Call the process XP++ or Scrum with an XP Center


Cocktail 2 what it looks like

Business Level

Product Level

Development Level

CollectiveCodeOwnershipCollectiveCodeOwnership

UnitTestsUnitTests

PairProgrammingPairProgramming

ContinuousIntegrationContinuousIntegration

RefactorMercilesslyRefactorMercilessly

SimpleDesignSimpleDesign

CodingConventionsCodingConventions

SustainablePaceSustainablePace

AcceptanceTestsAcceptanceTests

PlanningGamePlanningGame

SystemMetaphorSystemMetaphor

OnsiteCustomerOnsiteCustomer

Small ReleasesSmall Releases

TestDrivenDevelopmentTestDrivenDevelopment

Use CasesUse Cases

Identify and Remove ImpedimentsIdentify and Remove Impediments No Interference, no Intruders, no PeddlersNo Interference, no Intruders, no Peddlers


Needs to Tasks Problem

No matter what process you use, the fundamental technical problem is to analyze the users needs in order to determine development tasks

Business Level

Product Level

Development LevelTaskTaskTask

TaskTaskTaskTaskTaskTask

TaskTaskTask

Need


Needs to Tasks - RUP

Here are the major steps in moving from a Users need to a collection of Developer Tasks in RUP

Business Level

Product Level



TaskTaskTask

Need

Use CaseDetail a Use Case

Analyze a Use CaseUse CaseRealization Analysis ClassesAnalyze a Class


Needs to Tasks - XP

Here are the major steps in moving from a Users need to a collection of Developer Tasks in XP

Business Level

Product Level



TaskTaskTask

Need

User StoryUser StoryUser StoryUser Story

Magic Performed by Customer

Iteration Planning Game


Needs to Tasks Combined

Heres what I recommend for the major steps in moving from a Users need to a collection of Developer Tasks

Business Level

Product Level



TaskTaskTask

Need

User StoryUser StoryUser StoryUser Story

Iteration Planning Game

Use CaseDetail a Use Case

Ever-Unfolding Story


Agenda

The Software ProblemWhat is Process?Why Agility WorksDescription of RUPDescription of XPDescription of ScrumBest of Breed CombinationAdditional Success Factors


Team Values

Cooperation Communication Trust Honesty Respect Courage/Aggression Quality work Play to win


Environment

Available Customer Source Code Management Coding Standards Continuous Integration Facilitate Communications Information Radiators Team Room


Please Fill Out Evaluations


Net Objectives Who We Are

Mission: Guiding and empowering our customers in their software development efforts via courses and coaching.Vision: Effective and efficient software development without suffering.We provide training, mentoring and consulting for all phases of object-oriented software development.We assist companies transitioning to object-oriented development by providing mentoring throughout the entire development process.


Use Cases and Analysis

Writing Effective Use Cases. Capturing functional requirements with Use Cases is a software development best practice. This two-day course provides theory and practice in writing use cases, an understanding of how use cases fit into software development, and a variety of optional topics. The course is largely based on Alistair Cockburn's book "Writing Effective Use Cases" - winner of the Jolt Productivity Award for 2001. As a certified member of Cockburn and Associates, we are one of the few companies authorized to teach it.

Use Case Based Requirements Analysis. Use Cases are the best tool known for capturing and documenting the functional requirements for a system. Unfortunately, trying to capture a system's use cases all at once often leads to a severe case of "analysis paralysis". The Ever-Unfolding Story is an incremental technique for developing use cases and refining them into more detailed requirements. Because it's incremental, the Ever-Unfolding Story allows for frequent validation of the requirements, and supports both artifact-driven and agile development processes. The course consists of lecture and hands-on exercises, and the use case portion is largely based on Alistair Cockburn's book "Writing Effective Use Cases" - winner of the Jolt Productivity Award for 2001.


Agile Development and OOA/UML

Agile Development Best Practices. In simple terms, an Agile Project is one that is predicated on making sure it is always doing the right thing, not merely following a plan that has since gone out of date. Thecornerstone of this approach is getting and adapting to feedback as the project progresses. Most projects can't do this, so they fall further behind and either fail or provide inferior products. Changes are of many types, but the most common (and important) changes are to the system's requirements. This course analyzes what it means to be an agile project, and provides a number of best practices that provide and/or enhance agility. Different agile practices (including RUP, XP and Scrum) are discussed.

Object-Oriented Analysis With the UML. The word "analysis" means many things when discussing software development. In this two-day course you will learn about three different kinds of analysis: Domain Analysis, Requirements Analysis, and Architectural Analysis. The course consists of lecture and many hands-on exercises; you will learn a number of different modeling techniques, and use many common Unified Modeling Language (UML) diagrams. Throughout the course the focus is on the Analyst's job - providing information that will give other developers a "fighting chance" to develop the correct software.


Design Patterns Explained: A New Perspective on Object-Oriented Design. This course goes beyond merely teaching several design patterns. It also teaches the principles and strategies that make design patterns good designs. This enables students to use these advanced design techniques in their problems whether design patterns are even present. After teaching several patterns and the principles underneath them, the course goes further by showing how patterns can work together to create robust, flexible, maintainable designs.

Refactoring and Unit Testing Key Skills for Agile Development. The practice of Agile Software Development requires, among otherthings, a high degree of flexibility in the coding process. As we get feedback from clients, stakeholders, and end users, we want to be able to evolve our design and functionality to meet their needs and expectations. This implies an incremental process, with frequent (almost constant) change to the code we're working on. Refactoring, the discipline of changing code without harming it, is an essential technique to enable this process. Unit testing, which ensures that a given change has not caused an unforeseen ripple effect in the system, is another.

Design Patterns and Refactoring


Java: On-site and Instructor Led Web-Based Training

Object-Oriented Programming: Java Edition. Java is a powerful programming language, but its true value emerges only when a solid understanding of Object Oriented Programming techniques are applied. This two-day course focuses on the essential concepts of OO: Encapsulation, Inheritance, and Polymorphism, and includes practical examples and exercises using Java code. Emphasis is placed on implementation issues such as strong cohesion, loose coupling, and eliminating redundancy. Best practices, as illustrated by common design patterns are also discussed.

On-line/instructor led Java Training. This is our on-line equivalent of our 5-day Java training. This is not a self-study program where you get e-mail answers to your question. This is a high-touch training program where you work in frequent (albeit remote) contact with both the instructor and your student community. The core of the Java language is taught as well as some SWING and many of the core Java classes. It requires about 4 hours a week from each participant and takes place over 12 weeks.


C#: On-site and Instructor Led Web-Based Training

C# for C++ and Java Developers. C# is the flagship language for .NET, and despite what many have suggested, it is neither Java with enhanced syntax. nor is it C++ with better manners. C# is a new language, with many new syntactic elements. Also, programming in .NET requires an understanding of the framework and the development process it isdesigned to support. This 1-day course is intended to elucidate the C# language in terms of syntax, process, and some early-adopter best practices, making the transition for Java and C++ developers as smooth as possible.

On-line/Instructor Led C# Training. This course teaches the basics of the C# language as well as many of the standard C# classes that support the language. It is equivalent to a 5-day C# training class. It requires about 4 hours a week from each participant and takes place over 12 weeks.


Object-Oriented Programming in .NET

Object-Oriented Programming: C# Edition. The emergence of .Net for distributed computing has brought along with it a new flagship language: C# (C-Sharp). Those who are familiar with C, C++, and Java will find the syntax of C# relatively easy to absorb, but using the language properly will require a firm grounding in OO concepts and practices. This two-day course focuses on the essential concepts of OO: Encapsulation, Inheritance, and Polymorphism, and includes practical examples and exercises using C# code. Emphasis is placed on implementation issues such as strong cohesion, loose coupling, and eliminating redundancy. Best practices, as illustrated by common design patterns are also discussed.

Object-Oriented Programming: VB.NET Edition. Visual Basic (VB) has undergone a major transformation with the new version for .Net. What was once an object-based, procedural language has now become an Object Oriented language akin to C++, Java, and C#. While the primary aspects of its syntax has not changed, this shift to a true Object Orientation will require those with an investment in VB knowledge to learn new concepts such as inheritance, polymorphism, designing to interfaces, and object composition. This 2-day course will take the experienced VB 5.0 or VB 6.0 developer and teach them the OO concepts they need to move to VB.Net.


C++ and XML

Object-Oriented Programming: C++ Edition. C++ is a powerful programming language, but its true value emerges only when a solid understanding of Object Oriented Programming techniques are applied. This two-day course focuses on the essential concepts of OO: Encapsulation, Inheritance, and Polymorphism, and includes practical examples and exercises using C++ code. Emphasis is placed on implementation issues such as strong cohesion, loose coupling, and eliminating redundancy. Best practices, as illustrated by common design patterns are also discussed.

XML and Its Family of Technologies. XML is a powerful new standard for data modeling and communication, controlling presentation, and inter/intra-process communication. As XML is a cross-platform tool, it is a natural fit for the Java programming language, which is also operating system independent. This course introduces the student to XML and its primary supportive technologies such as SAX/DOM, DTD/Schema, JDOM, and XSLT, with an emphasis on the motivations behind these tools and the way they interrelate. The instructor will then provide detailed, practical examples of how these tools can be used in a Java-based project.


Bibliography

Best place to buy books: www.bestbookbuys.com

Full bibliography at http://www.netobjectives.com/resources/rs_bks.htm


Net ObjectivesCommunity of Practice

We provide a public forum for discussion of topics including:

Design patternsAgile methods (including XP, Scrum, RUP)Use casesEmergent design

We also have several books under development on-line for review by the community.Go to http://www.netobjectivesgroups.com for more information.To subscribe to our e-zine, send an e-mail to [email protected] with subscribe in the subject line


Bibliography Patterns - Core

Design Patterns: Elements of Reusable Object-Oriented Software, Gamma, Helms, Johnson, Vlissides (still the best reference book on patterns)

Design Patterns Explained: A New Perspective on Object-Oriented Design, Shalloway, Trott Design Pattern Java Workbook, Metsker (good for Java implementation)

Pattern Oriented Software Architecture: A System of Patterns, Bushmann, (a little dated, but still useful)Timeless Way of Building, Christopher Alexander (a classic. The only book in my top ten personal and top ten business)


Bibliography Patterns - Specialized

Patterns Of Enterprise Application Architecture, Fowler, et. al.

Pattern Oriented Software Architecture Vol 2: Patterns for Concurrent and Networked Objects, Schmidt, Stal, Rohnert, Buschmann, (great book for multithreaded, distributed patterns)


Bibliography - Agile Methodologies

Agile Software Development, CockburnAgile Software Development With Scrum, Schwaber, BeedleExtreme Programming Explained: Embrace Change, BeckExtreme Programming Installed, JeffriesExtreme Programming Applied: Playing to Win, Auer, Miller

Bibliography - The UML and Use CasesWriting Effective Use-Cases, CockburnPatterns for Effective Use Cases, Adolph&Bramble, et. al. with contributions from our own Dr. Dan RawsthorneUML Distilled, Martin Fowler (easiest and best way to learn what the UML is)


Bibliography - Java

Effective Java, BlochJava Design, Coad (best book on how to do OO in Java by far)Thinking in Java (3rd Ed), Eckel. Great book to learn Java and object-oriented programming from.

Bibliography - Miscellaneous(The) CRC Card Book , Bellin, Simone (CRC cards are a great way to verify initial designs)Multi-Paradigm Design for C++, Coplien (excellent description of commonality/variability analysis -- I even recommend the first part for Java programmers. See http://www.netobjectives.com/download/CoplienThesis.pdf for the books equivalent on the web)


Bibliography Refactoring/XP Related

Emergent Design: Refactoring and Design Patterns for Agile Development, by Scott L. Bain, Alan Shalloway, Dr. Dan Rawsthorne. Late 2003. For previews:http://www.netobjectives.com/emergentdesign/ed_toc.htmJava Tools for Extreme Programming: Mastering Open Source Tools Including Ant, JUnit, and Cactus, Richard Hightower, Nicholas LesieckiRefactoring, Martin Fowler (most in depth book on this old practice)Test Driven Development: By Example, Kent Beck. Not as great as we were hoping, but very useful.


On-Line Books

Many books are available on-line at:www.netobjectivesbooks.com/N_O_BookFeedback_Wiki/owbase/ow.asp?OnLineBooks

Specific Articles of Great Interest

Test Infected: Programmers Love Writing TestsA great article on doing test driven development with Junit byGamma and Beck - the authors of JUnit.

http://members.pingnet.ch/gamma/junit.htm


Famous Sayings

The check is in the mail.Ill respect you in the morning.Weve got all the requirements.Thatll never happen.That always happens.I'll write the tests later.I can write bad code because I know refactoring.Yes, Im sure.Well integrate it in later.Ill fix it later.

Comparing-Comparing Rup, Xp And Scrum - Mixing The Process Cocktail.pdf

Documents

Transcript of Comparing-Comparing Rup, Xp And Scrum - Mixing The Process Cocktail.pdf