The Amdocs SD&I journey to engineering practices - Agile Israel 2014
-
Upload
agileisrael -
Category
Documents
-
view
675 -
download
0
Transcript of The Amdocs SD&I journey to engineering practices - Agile Israel 2014
WiseCode
The Amdocs SD&I Journey to Agile Engineering
Practices
Implementing Agile in a large
organization with a large code base
and set ways of operation is a whole
new ballgame…
Workforce over 3,500
3 development centers in Israel, 2 in India and several others world-wide
Responsible for
◦ Customization
◦ Adaptation
◦ Integration
Short & Long lived Projects
Typical projects span 20-200 man years
Amdocs SD&I
The Commission
SD&I (then DCC) started Agile
implementation mentored by AgileSparks
Approached Trainologic in order to
analyze “Software Engineering Practices”
The questions:
◦ Are we following “Best Practices”
◦ Can we do more in this field:
Higher quality
Faster delivery
A Challenge
Amdocs is extremely successful
SD&I are known for their full
commitment and 100% delivery
At any given time there are multiple
efforts of improvement
Analysis
Talked with over 200 people in Amdocs
Delivery – Israel, India and UK
◦ 1x1 meetings, Round Tables, OTJ observation
Reviewed all aspects of SW engineering
◦ Architecture, Design, Coding, Debugging and
Reviewing
◦ Build & Integration
◦ Unit testing and Test Automation
◦ Configuration Control and Version Management
◦ Planning
Reviewed QE and Metrics
Analysis Findings
A well established set for “rules of
operation” at all levels
Challenges of large project management
Technical obstacles in order to fully
realize the improvements promised
by Agile
The 4 Pillars of Agile Implementation
Agile Managerial Practices
Agile Engineering Practices
Agile Development Environment
Engineering Professionalism
Agile Engineering Practices
Avoiding Waterfall
◦ Design in every stage
◦ Developer ownership
◦ Striving for release
Automated Testing
◦ TDD & Unit Testing
Agile Development Environment
Acceptable Hardware
Acceptable Software (VCS!)
Avoiding NIH and opening to the world
Continuous Integration
Legacy Build System
A typical build cycle using the legacy build
system took 7+ days and 1-2 dedicated
people
During time of build development was
constrained
Following build a torrent of “hot fixes”
would ensue
Engineering Professionalism
Setting a base line
◦ Clean Code
◦ SOLID
◦ TDD
OJT – mentoring teams
Creating internal leadership
◦ Coachers
Where do we Begin?
Local vs. Wide Spread
Serial vs. Parallel
Preach vs. Set foundations
Trying to do it all
During the first year:
◦ New Build System
◦ Unit Testing frameworks
◦ Development Courses
◦ OJ Mentoring
◦ Pep talk sessions
Uphill Battle
Shift in responsibilities
A new trust model
“Are we expected to do more?”
Changes in the schedule structure
Initial Wins
Light weight design processes
Shift from governance to mentoring
CI in the common project infrastructure -
BSS
Many Challenges Fright of change: “Yes, but…”
◦ Not Here
◦ Not Now
Misinterpretations
An Unexpected Win
Local leadership in the Negev:
◦ Long standing strategic customer
◦ 12 Year old project
◦ Large legacy code base
◦ Customer commissioned 2 substantial
improvement cycles
◦ First cycle followed the “old way”
◦ Second cycle “Jumped into the water”
And the results…
Within 3 cycles (2 month):
◦ Stable, always shippable
◦ Fully tested
A total shift in developer culture
A slow shift in management culture
Where we are today
3 Projects doing CI
3 Projects scheduled for CI by September
Developer responsibilities changed
Modern tooling becoming the norm
Unit testing slowly entering main stream
Looking Forward
It’s a complex implementation, but we
hope we are HereImplementation
Time
Some Closing Thoughts
The importance of local leadership
Continuous engagement
Prepare for a long battle
Never under-estimate the legacy build
Sequential or Parallel implementation?
Trumpeting success stories