Agile on the mainframe and other odd places
This presentation is the property of its rightful owner.
Sponsored Links
1 / 49

Agile on the Mainframe (and Other Odd Places) PowerPoint PPT Presentation


  • 84 Views
  • Uploaded on
  • Presentation posted in: General

Agile on the Mainframe (and Other Odd Places). How Mainframe Agile Teams Are (not so) Different November 8, 2007 Charlie Poole. Introductions. Charlie Poole. What I do… Languages… Cobol, PLI, Fortran, C, C++, C#, IBM & Intel assembler Platforms

Download Presentation

Agile on the Mainframe (and Other Odd Places)

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


Agile on the mainframe and other odd places

Agile on the Mainframe(and Other Odd Places)

How Mainframe Agile Teams

Are (not so) Different

November 8, 2007

Charlie Poole


Introductions

Introductions


Charlie poole

Charlie Poole

What I do…

Languages…

Cobol, PLI, Fortran, C, C++, C#, IBM & Intel assembler

Platforms

Mainframe, Windows, .Net, Linux, Mono, Cross-platform

Coaching and Training

XP, Agile, TDD, NUnit

Open Source

NUnit, NUnitLite, VSUnit, Fit


Charlie poole1

Charlie Poole

My dubious past…

Languages…

Cobol, PLI, Fortran, C, IBM assembly language

Hardware Platforms

Hardware: IBM, Dec, Honeywell, CDC, Univac

Software Environments

CICS, SQL, VM


About mainframe programmers

About Mainframe Programmers

  • Take a card...

    • Write a word or short phrase that comes to mind when you think of mainframe programmers, who are still doing it today.

    • Write several if you like.

    • It’s OK to be unfair – we’ll try to be more reasonable later on. 


Discussion part i

Discussion – Part I

  • What sorts of feelings are represented on your cards?

    • Admiration?

    • Respect?

    • Pity?

    • Disdain?

    • Puzzlement?


Discussion part ii

Discussion – Part II

  • Have similar words, phrases, feelings been applied to programmers in your own company?

    • By managers?

    • By co-workers?

    • By you?

  • What does this mean for introducing Agile?


A mainframe tale

A Mainframe Tale

Experiences at Key Bank


Warning label

Warning Label

  • This is a story about one of my clients and is included here with their permission, for which I am very grateful.

  • For obvious reasons, I will not be able to answer every question that pertains specifically to work being done for this client.

  • I request your understanding in limiting questions as much as possible to the general ideas this story illustrates.


A mainframe tale1

A Mainframe Tale

  • Key Bank is a very forward-looking company in its software development and has introduced agile approaches company-wide over the past few years.

  • They have their own internal coaches and bring in other folks from outside as needed.

  • They have been very successful at it.


A mainframe tale2

A Mainframe Tale

  • From the preceding, you can see that Key Bank are not amateurs at Agile...

    except on the mainframe...

    where we are all amateurs.


A mainframe tale details

A Mainframe Tale - Details

  • Key has LOTS of mainframe work, even as they increase their use of desktop and distributed apps.

  • Almost everything else depends on the mainframe apps.

  • The programmer population is getting older.

  • Conversion is not practical for much of this work.


A mainframe tale details1

A Mainframe Tale - Details

  • Key has introduced Agile development in all technical areas except for the mainframe.

  • Management likes what Agile does for them, but they aren’t getting it from the mainframe.

  • Programmers don’t know how to give management what they want.


Interlude how i got into this

Interlude: How I Got into This

  • Experience

    • Mainframe (years back) and Agile coaching

  • Attitude

    • Respect for Mainframe programmers

    • Like a challenge

  • Availability

    • Nobody else wanted to do it


A mainframe tale objectives

A Mainframe Tale - Objectives

  • To support agile in the mainframe environment. In particular, mainframe development should not appear to be an impediment in the overall flow of technical work.

  • To be able to prioritize features and deliver them incrementally, rather than waiting for the end of a project.

  • To shorten final testing times after introducing more reliable testing into the development process.


A mainframe tale objectives1

A Mainframe Tale - Objectives

  • To identify the aspects of agile methodology, which are relevant to mainframe development – in most cases by actually trying them out.

  • To be able to estimate projects more aggressively in the future.

  • To be able to react quickly to problems and changes.


Defining agile

Defining Agile

What Do We Want?


Defining agile the wrong way

Defining Agile - the Wrong Way

  • Agile is sometimes taken to mean practices

    • Doing Test-Driven Development

    • Using Scrum

    • etc.

  • Not a satisfactory approach

    • It assumes Agile can be made into a recipe

    • Doesn’t help us move across technologies


Defining agile based on results

Defining Agile Based on Results

“Create real software in an iterative fashion, delivering small functional increments on a regular basis so that the team and the users can always see real progress”


Top down agile the wrong way

Top-down Agile – the Wrong Way

  • Tell the programmers to be “agile”

  • Tell them precisely how to be agile

  • Make sure they do it


Top down agile the right way

Top-down Agile – the Right Way

  • Tell the programmers why agile is important to the company.

  • Tell them what results you want to see.

  • Ask them to figure out how, providing them the time and support they need to do it.

  • Identify and remove obstacles.


One good thing about the mainframe

One Good Thing About the Mainframe

  • We don’t have pre-existing tools and practices in most cases.

  • We can’t tell them how to do it.

  • We are forced to enable the developers to “invent” their own flavor of agile.


Mainframe obstacles

Mainframe Obstacles


Mainframe obstacles1

Mainframe Obstacles

  • Very large file sizes are the norm, leading to long run times for any tests.

  • Test runs consist of a number of interdependent jobs and it is often not possible to run tests of a single job step.

  • For many applications, programs are not run directly but are under the control of a third-party application (Hogan) which is widely used in the banking industry.


Mainframe obstacles2

Mainframe Obstacles

  • The need to submit jobs and then wait for them to complete makes mainframe development proceed at a much slower pace than desktop work. Developers must either wait or turn their attention to some other task while a test proceeds.

  • For test runs, job steps must often be staged manually, because automated scheduling is not available. Because of processing demands during the day, this is reported as frequently done by developers working from home.


Mainframe obstacles3

Mainframe Obstacles

  • Existing utilities, such as dump analysis and tracing tools are not always used systematically due to unfamiliarity or inconvenience. Practice in this area can differ significantly from developer to developer.

  • For most applications, there is no standard test bed used to automatically run tests and determine if regressions have occurred. Where such tests exist, manual review is usually required.


Mainframe obstacles4

Mainframe Obstacles

  • The verification of test results is often manual, although it may sometimes be assisted through the use of file comparison utilities.

  • Testing tools, such as exist in the worlds of desktop and distributed development, are not generally available for the mainframe, and would need to be developed locally.

  • In many cases, separate tools are needed for Hogan and non-Hogan applications.


Cobtest

COBTEST

A Low-level Test Framework


Second warning

Second Warning

This is more interesting than important!


Cobtest a prototype test framework

COBTEST : a Prototype Test Framework

  • Works for both Hogan and non-Hogan Cobol programs.

  • Tests at a very low level – xUnit style.

  • Building block for higher level tools.


Cobtest structure

COBTEST Structure

Test Program

Program

Under Test

Test Framework

(COBTEST)


Using cobtest

Using COBTEST

CALL ‘COBTEST’ USING INIT-ACTION.

PERFORM ACCOUNT-TESTS.

PERFORM TEMPERATURE-TESTS.

PERFORM FRAMEWORK-SELF-TESTS.

CALL ‘COBTEST’ USING TERM-ACTION.


Using cobtest1

Using COBTEST

TEMPERATURE-TESTS.

MOVE ‘BOILING POINT’ TO TEST-NAME’

MOVE 212 to F-TEMP

CALL ‘TEMPF2C’ USING TEMPS

MOVE 100 TO EXPECTED-PACKED

MOVE C-TEMP TO ACTUAL-PACKED

CALL CHKPACK


Cobtest entry points

COBTEST Entry Points

  • COBTEST

    • Initialization and Termination

  • CHKEQUAL

    • Compare two alphanumeric fields

  • CHKPACK

    • Compare two packed fields

  • CHKBIN

    • Compare two binary fields


Testspec copy book

TESTSPEC Copy Book

77 INIT-ACTION PIC X(4) VALUE 'INIT'.

77 TERM-ACTION PIC X(4) VALUE 'TERM'.

01 TEST-SPECIFICATION.

05 TEST-NAME PIC X(50).

05 USER-MESSAGE PIC X(50).

05 EXPECTED-VALUE PIC X(100).

05 EXPECTED-REDEF-1 REDEFINES EXPECTED-VALUE.

10 EXPECTED-PACKED PIC S9(9).

10 FILLER PIC X(91).

05 EXPECTED-REDEF-2 REDEFINES EXPECTED-VALUE.

10 EXPECTED-BINARY PIC 9999 BINARY.

10 FILLER PIC X(98).

05 ACTUAL-VALUE PIC X(100).

05 ACTUAL-REDEF-1 REDEFINES ACTUAL-VALUE.

10 ACTUAL-PACKED PIC S9(9).

10 FILLER PIC X(91).

05 ACTUAL-REDEF-2 REDEFINES ACTUAL-VALUE.

10 ACTUAL-BINARY PIC 9999 BINARY.

10 FILLER PIC X(98).


Cobtest as a tool

COBTEST as a Tool

  • Aimed at tests written by programmers before or during coding.

    • Tests are of individual programs or routines.

    • Test program supplies data, one case at a time.

  • Can also be used to find out how a routine responds to various inputs.

  • Need other tools for other purposes.


Potential extensions of cobtest

Potential Extensions of COBTEST

  • Run tests dynamically, based on input

    • Possibly, separate Hogan and non-Hogan runners

  • Additional test predicates and data types

  • Data driven tests

    • Test reads inputs and expected values

  • Data interception

    • Test is inserted into processing flow


A major weakness

A Major Weakness

  • COBTEST enables running small, fast tests as you work.

  • Unfortunately, it can take 20 or 30 minutes to submit the test and get the result.

  • Two possible solutions…

    • Come up with way to eliminate the wait time.

    • Invent new patterns of working that take the time delays into account.


An agile workshop

An Agile Workshop

Engaging Mainframe Developers


An agile workshop1

An Agile Workshop

  • Open Space Format

  • Approximately 70 mainframe developers

  • Approximately 40 sessions offered around our two-part theme.


Workshop theme

Workshop Theme

What would it meanto be agileon the mainframe?

How can we

make it happen?


An agile workshop2

An Agile Workshop

  • Half day introduction to what agile means

  • Two Days of Open Space

  • Half day follow-through

    • Session reports and project organization

    • Creation of project backlogs

    • Top-level management acceptance


After the workshop

After the Workshop

  • Teams are organized as for any project, with a top-level manager as the Product Owner.

  • Mix of “low-hanging fruit” and projects requiring a long-term effort.

  • Quarterly two-day workshops will be held.


Conclusions and discussion

Conclusions and Discussion


Conclusions

Conclusions

  • Agile on the mainframe has unique problems.

  • We are forced to rely on the programmers to invent the practices they need.

  • We hope that doing so will give us a better set of practices.


Meta conclusion

Meta-Conclusion

This is what we should be doing anyway!


Odd places

Odd Places…

Are there other “Odd Places”

where this approach

might work?

What about your project?


Agile on the mainframe and other odd places

Thank You


  • Login