How Agile Offsharing is ready for technology transfer
•Télécharger en tant que PPT, PDF•
0 j'aime•1,363 vues
Agile Offsharing is an idea for improving knowledge transfer between sites in distributed software development.
Recommandé
Recommandé
Contenu connexe
Similaire à How Agile Offsharing is ready for technology transfer
Similaire à How Agile Offsharing is ready for technology transfer (20)
Dernier
Dernier (20)
How Agile Offsharing is ready for technology transfer
- 1. 1 / 12Lutz Prechelt, prechelt@inf.fu-berlin.de Agile Offsharing: A software process idea Lutz Prechelt Freie Universität Berlin based on joint work with: Stephan Salinger, Julia Schenk, Franz Zieris, Holger Schmeisky, Christopher Oezbek, Laura Plonka, Danou Nauck, Karl Beecher, Edna Rosen, Björn Kahlert and ~50 Saros contributors ICSE 2014 "Ready – Set – Transfer" Contest Panel
- 2. 2 / 12 Our topics 1 Pair Programming (PP) 2 Saros, a distributed IDE Ingredients 3 Distributed Pair Programming (DPP) 4 Agile Offsharing idea to be transferred Lutz Prechelt, prechelt@inf.fu-berlin.de Round 1 Round 2
- 3. 3 / 12 Domain, Users & Requirements "Local" SW developers Subsystem BSubsystem A can understand write w rite communication by documents, visits, email, chat, phone, daily video standup, etc. 4 The Agile Offsharing idea Lutz Prechelt, Freie Universität Berlin Geographic & cultural distribution "Remote" SW developers Distributed Pair Programming Joint system *Works for other types of knowledge asymmetry as well *
- 4. 4 / 12 Agile Offsharing makes a radical step Conventional approach: Minimize the need for communication ("Reduce coupling!") Agile Offsharing approach: Actively increase the need for communication ("If it hurts, do it more often!") Lutz Prechelt, prechelt@inf.fu-berlin.de
- 5. 5 / 12 Details Agile Offsharing is not for everybody Preconditions: • Modest time zone difference • Limited cultural difference • both national and SW development culture • Low-enough language barrier • for enough team members • Volunteer team members • Reliable, low-latency network connectivity Steps for use: • Setup & try out DPP tooling • Find volunteers • Select tasks & form pairs • Do DPP • Reflect on DPP sessions Can only be worked out by technology transfer Lutz Prechelt, prechelt@inf.fu-berlin.de
- 6. 6 / 12 Why is Agile Offsharing needed? Lutz Prechelt, Freie Universität Berlin We tend to under-estimate what needs explanation:
- 7. 7 / 12 How is Agile Offsharing transfer-ready? 1 Pair Programming (PP) 2 Saros, a distributed IDE Ingredients 3 Distributed Pair Programming (DPP) 4 Agile Offsharing trials Lutz Prechelt, prechelt@inf.fu-berlin.de
- 8. 8 / 12 1 Knowledge about Pair Programming (PP) • Research on conceptualizing the PP process since 2004 • on real industrial sessions • Goal: Find helpful behavioral patterns and antipatterns • Results so far: • Base concepts • Roles • e.g. Spokesperson, Watchman, Guide/Robot, Task expert/Mentee • Knowledge transfer mechanisms • e.g. Clarification Cascade Lutz Prechelt, prechelt@inf.fu-berlin.de time
- 9. 9 / 12 2 The Saros DPP tool • Distributed IDE • Plugin for Eclipse, soon also for IntelliJ IDEA • In development since 2006, Open Source • Industrial strength • >1000 downloads per month Lutz Prechelt, prechelt@inf.fu-berlin.de
- 10. 10 / 12 2 The Saros DPP tool
- 11. 11 / 12 Knowledge about Distributed-Pair Programming (DPP) • Research on conceptualizing the DPP process since 2010 • builds on the PP research • Goal 1: Find helpful behavioral patterns and antipatterns • Coping with limited awareness • Making sensible use of concurrent editing • Goal 2: Validate usefulness • Results so far: • Effortless awareness bridging (Eclipse dialogs) • Prudent, limited use of concurrent editing • DPP can be as efficient as PP – or even slightly more Lutz Prechelt, prechelt@inf.fu-berlin.de 3
- 12. 12 / 12 4 Agile Offsharing trials • Just starting, with Lithuanian outsourcing provider NFQ • builds web applications with long-term customers • NFQ funds our full-time group member Holger Schmeisky • since 2014-04 • Also: In discussion with 2 large multinationals • we expect to start trials at one of them later this year Lutz Prechelt, prechelt@inf.fu-berlin.de Corporation D Corporation S
- 13. 13 / 12Lutz Prechelt, prechelt@inf.fu-berlin.de Thank you!
Notes de l'éditeur
- I will present Agile Offsharing, an idea for distributed software development processes.
- I will present the ingredients of the Agile Offsharing idea in the second presentation round. They are: Knowledge about PP, a tool Saros, and knowledge about DPP. Together, they form the justification of the AGOG idea.I will now only present the idea itself and the need for it.
- Assume you have a distributed situation for the development of an information system, with some "local" developers and some "remote" developers. ## Only the local developers have access to the domain, the users, and the requirements. ## The remote developers do not. ## Conventionally, we will do two things: First, we will attempt to create enough communication, planned and unplanned, written and verbal. ## Second, we will attempt to minimize the need for communication, in particular by splitting the development into subsystems, assigned to only one site. ## A common result is that the subsystems will not quite fit together. In contrast, Agile Offsharing suggests to voluntarily communicate more than is strictly necessary, specifically to increase domain knowledge at the remote site. It does that by ## not assigning subsystems to sites and by ## adding synchronous code-level collaboration in form of distributed pair programming, DPP. Participants, tasks, and priorities for DPP are selected so that they maximize knowledge transfer. We know that pair programming is very effective for knowledge transfer, as I will explain in round 2. ## The approach also applies if the knowledge disbalance regards some other area, say, technology knowledge or knowledge of an existing code base.
- To summarize, Agile Offsharing requires a fairly radical mental step: ##In the conventional approach, we attempt to reduce coupling between the sites, which sounds like a perfectly sensible thing to do. ## In the Agile Offsharing approach, we voluntarily increase coupling. That sounds crazy, but it creates opportunities for knowledge transfer and we expect those to be more valuable than the lower coupling.
- Agile Offshoaring will not work in every case. It requires several conditions to be met, as listed here, in particular a low-enough language barrier. ## The specific steps, in particular how to select work tasks and how to optimize the knowledge transfer, will have to be worked out in specific project contexts. Therefore, the technology transfer will be tailor-made.
- The main reason why AGOG is needed is that we tend to grossly under-estimate whether something requires explanation. Consider this example: The following photograph shows the donut counter in a Safeway supermarket. It has reduced prices if you buy a dozen of donuts. The counter exhibited an unexpected requirements ambiguity. ## "At Safeway, a dozen is 12." What do we learn from this? Well, if your software is more complicated than a donut counter, you better expect plenty such surprising needs for explanation. And those needs hide in details, which is why you can get a lot of benefit from using DPP for knowledge transfer. Thank you!
- To explain how Agile Offsharing is transfer-ready, I will first talk about the maturity of its ingredients. The first one is knowledge about pair programming.
- We do research on PP since 10 years. It builds on recordings of real, everyday, industrial PP sessions and intends to identify learnable patterns of helpful PP behavior. As a foundation, we formed a conceptualization of elementary behaviors in PP and published it as a book. We investigated roles in PP and found that participants take on many roles, some of them focussed on knowledge transfer. We investigated how pair programmers transfer knowledge during a session and found learnable patterns of behavior such as the Clarification Cascade. On the right, you see an ordinary session; shown in red, there is a lot of knowledge transfer and PP is a strong knowledge transfer vehicle.
- Ingredient 2: Developers will not be willing to do a lot of DPP with screen sharing, so we build a proper DPP tool since 8 years. Saros is a plugin for Eclipse, soon also for IntelliJ. We now consider Saros industrial strength and have 1000 downloads a month.
- Here is a schematic view of Saros: Each partner works in their own local IDE as usual. All files and all operations are local, but files are kept in sync with the partner's for each individual change in real time. Both partners can navigate and edit independently. Awareness of the partner's workspace is provided by highlighting in the partner's color: a pseudo scrollbar, a pseudo cursor, the partner's current selection. For strict PP work style, there is a Follow-the-partner Mode.
- Ingredient 3: We are investigating DPP since 4 years, building on top of the PP research. There are two goals: First, finding how the participants cope with the limited awareness and how they make use of concurrent editing without damaging the PP advantages. Second, validating that efficient DPP is possible at all. ## What we found: At least capable pairs bridge awareness limitations easily, often by additional verbalization, for instance when an Eclipse dialog window appears only on one side. Second, concurrent editing can be used in limited manner so that it reaps many small benefits without breaking the PP work mode. Overall, we feel that DPP can sometimes be the better form of PP. Quick advertisement: ## If you want to understand this dash, come to SE in Practice this afternoon.
- OK, the effectiveness of PP, of Saros, and of DPP are all quite tangible, but what about AGOG itself? We work with outsourcing provider NFQ. They find the idea of AGOG so convincing that they fund one of our group members to work with them and several of their customers full-time to introduce AGOG. This started two months ago, first working through the company and customer complexity. We expect actual DPP use to start in July. A second trial site is in preparation. Thank you!
- Thank you!