Upload
samuel90
View
1.170
Download
2
Embed Size (px)
DESCRIPTION
Citation preview
© Vincent Massol 2004
AOSD: Agile Offshore
Vincent Massol17/12/04
© Pivolis 2004
Agenda
Agile Offshore Software Development (AOSD)
Team organization
Infrastructure
Communication tools
Delivery Management
Active Quality
Return of experience
© Pivolis 2004
Agenda
Agile Offshore Software Development (AOSD)
Team organization
Infrastructure
Communication tools
Delivery Management
Active Quality
Return of experience
© Pivolis 2004
Types of offshore projects
There are 2 main types of offshore projects
Fixed-price projects− Black box for the customer− Well-defined specifications− Not at heart of Customer’s Information System
- Or highly risky if they are!
Collaborative/Agile projects− Moving specifications− IT teams on both sides
- Possibly developers on both sides- Possibly Architects/Framework on one side and development team on the
other side
− Minimal project duration required- For processes/tools/communications to settle- For people interactions to reach a satisfactory level
− Can tackle complex projects (and with higher satisfaction levels)
This presentation is about Collaborative/Agile projects
© Pivolis 2004
AOSD is flexible
Best practices from XP, RUP and Open Source:XP
− Continuous Integration− Strong Quality− Short iterations
RUP− UML notation to formalize specifications
Open Source− Collaborative tools and associated practices
Different versionsAOSD Java, AOSD .Net, AOSD SAP, etc
− We will focus on AOSD Java in this presentation
AOSD is a modular methodologyIntegrates well into an existing contextAllow progressive and continuous adoption of its practices to improve communication/quality/productivity.
© Pivolis 2004
AOSD core values
Continuous improvements
Establish a team spirit with virtual teams
Automation as much as possible
Continuously improved during project lifecycle
Continuous communications
Shared expectations
© Pivolis 2004
Agenda
Agile Offshore Software Development (AOSD)
Team organization
Infrastructure
Communication tools
Delivery Management
Active Quality
Return of experience
© Pivolis 2004
Team Organization (Logical model)
Development Manager
OnsiteProject Lead
Functional teamOffshore
Delivery Manager
Onsite developers Offshore coordinator Offshore coordinator Offshore coordinator
OffshoreProject Lead
OffshoreProject Lead
OffshoreProject Lead
Offshore developers Offshore developers Offshore developers
Depending on the size
there can be one or
several coordinators
Offshore
Project Manager
offshore
onsite
© Pivolis 2004
Coordinator role
Neutral stance as much as possible
Administrative tasks: Arrival/Departure administration (e.g. Secure id card, Star Team account, Test Director account, Wiki account, JIRA account, mailing lists accounts, etc) Organization of visits (identification of requirement, dates, agendas, people) in both directionsVisa handling
Infrastructure for offshore: Infrastructure coordination + improvements (monitor performances, tune tools) - with help from customer’s infrastructure team
Organisational: Weekly technical and management conf calls with all the teams (dev team + integration team + tech team) + follow up from these calls Management meetings Communication facilitators + related communication improvements Offshore team selection (senior members mostly) Offshore training programme improvements Crisis escalation investigation + handling Accompany Onsite members during offshore visits, ensuring success of agenda/visit.
[Good to have] Methodology/Expertise: Definition of Project Development Process with “offshore in mind” and continuous improvements (e.g. short iterations introduction, usage of JIRA for detailed plannings, acceptance criteria for code delivery, wiki setup, etc). Work inside the teams to implement the collaborative development process. Quality suggestions + improvements (testing strategy / build improvements for quality + measurements) Expertise on build (e.g. Maven) + continuous build + testing + collaborative development processes Architecture + implementation of regression platform
© Pivolis 2004
Team organization lessons: No Micromanagement
LocalProject Lead
DeveloperProjectLead
Developer
Developer
onsite offshore
ProjectManager
Developer
Developer
Developer
onsite offshore
© Pivolis 2004
Role diversity in offshore
Same roles on both sides as much as possible
To prevent feeling of “superiority” from one side / Help teams jellTo spread overall knowledge which helps improve productivityBecause of distribution cost
− A technical Guru only on one side will have difficulties helping across distance
Examples of possible offshore roles− Integration team – Tests− Business conception− Detailed design− Architecture relay / Build guru
© Pivolis 2004
Agenda
Agile Offshore Software Development (AOSD)
Team organization
Infrastructure
Communication tools
Delivery Management
Active Quality
Return of experience
© Pivolis 2004
Infrastructure
VPN over
internet
Offshore
firewallfirewall
Onsite
Source
Repository
Continuous
build
Intranet (Wiki,
Build results,
Issue tracker)
DMZ reachable from offshore
firewall
© Pivolis 2004
Agenda
Agile Offshore Software Development (AOSD)
Team organization
Infrastructure
Communication tools
Delivery Management
Active Quality
Return of experience
© Pivolis 2004
Communication tools
Value in team knowledge
sharing
Usage frequency
“Word”doc
Travels
Video Conf.
Wiki
Phone
Mailinglist/forum
chat
Travels: Every 1.5 months (3p per trip)
“Word” docs: 1 every month
Phone: 3 calls per week (for 10p)
Wiki: 1 topic modified per day (for 10p)
Email: several times per day
Through builds: every 2 hours
Chat: continuously
© Pivolis 2004
How to share functional knowledge?
Travels in both directionsFunctional training for Project LeadsEspecially before new subjects
Have Project Leads do the business conceptionAs much as possible
Have Project Leads do the detailed design
Open chat channels with functional personsWe have dedicated functional persons. 1 per team => 1 person per 10 developers roughly. Can decrease with time.
Helpful to have onsite coordinators in teams
Send functional tests along with use casesHave a separate team script and automate them
© Pivolis 2004
Agenda
Agile Offshore Software Development (AOSD)
Team organization
Infrastructure
Communication tools
Delivery Management
Active Quality
Return of experience
© Pivolis 2004
Iteration planning (Time-boxed)
time
Phase start Phase end
Production delivery
Work Packet 1 Work Packet N(6-7 weeks)
Iteration(2 weeks)
Continuous build(2 hours)
Functional delivery
Delivery
Fixed iteration delivery dates (Time-Boxing)Must not be changed, content can change
Iterations must list *all* tasks taking ½ day or moreTo prevent misunderstandingTo allow easy progress follow upTo generate release notes automaticallyDone using Issue Driven Development
Meetings every week
© Pivolis 2004
Issue Driven Development
Every task is visible as an issue in the issue tracker
If a task is not there, add it before checking in and add task id in check-in comment
It is critical that the iteration issues are up to date continuously
Otherwise, leads to expectation gaps which itself leads to frustrations on both sides
If a task cannot be performed in time for the iteration or if it is changed or a new task added, trigger a CCB conf call
CCB = Change Control BoardMade of representative of the different streams (business, architecture, developers, management, etc)
© Pivolis 2004
Agenda
Agile Offshore Software Development (AOSD)
Team organization
Infrastructure
Communication tools
Delivery Management
Active Quality
Return of experience
© Pivolis 2004
Active Quality
Goal: share quality concepts through build automation
Contrasts with Documentation-driven qualityAutomatedPreventive instead of curative
Automation through builds/continuous builds and make the build fail as much as possible
Tests− Unit tests, Integration tests, Functional tests− Clover/Emma/JCoverage
Code quality− Checkstyle/PMD/Findbugs, Pattern Testing
Others− Metrics (NCSS, JDepend, etc)
Each tool requires an associated strategyOtherwise useless!
Requires trained coachs and evangelizationNeed to develop culture of excellence
Continuous integration requires a Build manager/engineer (full time job)
© Pivolis 2004
Continuous build & platforms
© Pivolis 2004
Testing
Developerworkstation
Assemblymachine
ISTplatform
Pre-UATplatform
UATplatform
Developer platform
Accessed from offshore
- Unit tests (mocks)
- Some integration tests
(DbUnit)
- Integration testing
(manual)
- Functional tests by
developers (manual)
- Technical / Functional tests
(manual)
- Performance testing
(manual)
- Functional tests by IT
users (manual)
- Functional tests by
end users (manual)
Automated f.e. with Abbot for Swing apps
© Pivolis 2004
Agenda
Agile Offshore Software Development (AOSD)
Team organization
Infrastructure
Communication tools
Delivery Management
Active Quality
Return of experience
© Pivolis 2004
Lessons learnt (1/2)
Require good mediators/coordinatorsTo solve communication issues due to language and cultural differencesTo suggest improvements continuouslyTo act as “harmonizers”
− Ex: prevent productivity measurements and associated disastrous communications
To shield teams from the wearing effect of working from a distanceLots of travels/exchanges
Hard to work with someone you haven’t seen− Leads to misunderstandings
Help share knowledge at all levelsAt all levels
− Managers, Project Leads, Lead Developers/Gurus, Developers
Lots of disciplineTo follow development methodology
− JIRA issues and update− The Build Must Pass! (requires developing a build culture)− Weekly meetings
© Pivolis 2004
Lessons learnt (2/2)
Share activities between onsite/offshore
Not just development, but also− Business Conception, Detailed Design, Testing, etc
Improve team spirit/job satisfactionAllow offshore people to progressShare the global knowledge and thus improve efficiency
Write functional test cases before development starts
Helps transfer business knowledgeEasy way to know requirements have been understoodCan then be scripted/automated by testing team
Dedicated offshore support persons in each team
To minimize question round trips
© Pivolis 2004
The Right Attitude
Always give the benefit of the doubt to the distant partyIs it possible that it is me who has not understood?Cross-check what you have understoodLook for reasons instead of only consequencesDig into the reasons to find root causes
Think of the distant party as « we » instead of « them » and « us »
Always try to improve processes/tools so that the global solution works better
Why do this?Because if you have accepted the situation there’s no point in dragging your feet. Either don’t accept it or do it well!Interesting human experience…International exposure and competencies (valuable on the market)
© Pivolis 2004
Benefits of distributed teams
Today the main driver is cost…
Exchange of knowledge in both directions
On how to develop softwareOn cultures / languages
Broadening of vision for all participants
Key skill for participants: working in an international team
Organization are more and more distributed
Will require practices for working from a distance− Ex: Mars/Earth
Ability to find talents/skills
Ex: Open Source (pushed to the extreme)
© Pivolis 2004
Q&A
?