Your SlideShare is downloading. ×
  • Like
A Case Of Artful Exploration
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Now you can save presentations on your phone or tablet

Available for both IPhone and Android

Text the download link to your phone

Standard text messaging rates apply

A Case Of Artful Exploration

  • 292 views
Published

Agiles 2009 presentation

Agiles 2009 presentation

Published in Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
292
On SlideShare
0
From Embeds
0
Number of Embeds
1

Actions

Shares
Downloads
3
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide
  • 2 min (J)‏ Hi, I'm juan, I work in Agilar, ||I'm Diago and I work in GE||, we will talk about a project that we found interesting, we think that it has characteristics that define an interesting project type . Those characteristics are shared with other projects were we worked. We are presenting a Portal (multi-site) development porject using a free open source platform with Scrum and XP. We are not new to open source nor to agile, but in this particular setting, some questions arise. ¿Can we apply agile techniques when the development activities are only a small part of the work we do? ¿Which practices are useful when dealing with exploration of existing functionality that primes over construction? We found the Artful Making approach helpful in our situation. We will share our experiences and hopefully it will help you when you come across a similar project. 2 min (J)‏ Hi, I'm juan, I work in Agilar, ||I'm Diago and I work in GE||, we will talk about a project that we found interesting, we think that it has characteristics that define an interesting project type . Those characteristics are shared with other projects were we worked. We are presenting a Portal (multi-site) development porject using a free open source platform with Scrum and XP. We are not new to open source nor to agile, but in this particular setting, some questions arise. ¿Can we apply agile techniques when the development activities are only a small part of the work we do? ¿Which practices are useful when dealing with exploration of existing functionality that primes over construction? We found the Artful Making approach helpful in our situation. We will share our experiences and hopefully it will help you when you come across a similar project. 2 min (J)‏ Hi, I'm juan, I work in Agilar, ||I'm Diago and I work in GE||, we will talk about a project that we found interesting, we think that it has characteristics that define an interesting project type . Those characteristics are shared with other projects were we worked. We are presenting a Portal (multi-site) development porject using a free open source platform with Scrum and XP. We are not new to open source nor to agile, but in this particular setting, some questions arise. ¿Can we apply agile techniques when the development activities are only a small part of the work we do? ¿Which practices are useful when dealing with exploration of existing functionality that primes over construction? We found the Artful Making approach helpful in our situation. We will share our experiences and hopefully it will help you when you come across a similar project.
  • 5 min (J)‏ We will now see a video of the IT manager of Turner, the customer, describing the project Liferay was selected because of it scalability and maturity. Staffing: IT Mkt / SUN / Grupo Esfera (Liferay committer, Graphic Designer, Developers) The project matches one of the requirements for Artful Making: Innovation
  • 3 min (D)‏ Cost of Exploration: Cost of throwaways. Cost of Reconfiguration: Cost of modifications to the product.  A new way of learning Exploration learning is used to find several alternatives, and choose the most valuable to achieve excellence. Exploration requires a redefinition of efficiency.
  • 5 min (J)‏ Inception to bid on The requirements came mainly from two significant stakeholders: Marketing & IT. Workshop for Requirements Elicitation with Marketing, Nobody was end user advocate. Absence of the site itself, or its features, in the result. Prototypes Workshops to envision the Product (Site). Used paper prototyping, focused on features. Rapid prototyping with Portal (Flying Portlets?) Trying to explore with lower reconfiguration cost. Why reconfiguration was so costly?
  • 5 min (J)‏ Learning to use the tool and learning a new type of job at the same time proved too much. The Marketing users were not used to building a site from scratch, not even the graphic design. There was a huge existing content base to be replaced (graphic design, etc.)‏ Focus in functionality rather than Site pages made producing feedback more difficult. Content development was a responsibility of the customer which was not well understood Platform development was responsibility of a mixed team (vendor and customer IT)‏
  • 3 min (D) It converged as expected (around sprint 4). Project has fixed price Customer has great disposition to balance cost, effort and functionality From the customer's point of view complexity is still unknown. Customer planning participation improved with the impending soft launch (beta release).‏
  • 3 min (D)‏ Do one: dev team show that the current site could be implemented in the new tool Flying: prototyping one “killing UI “ idea Low fidelity: co-designing a couple of sites with papers Two reviews: at the review, dev showed platform, designers showed content. On site: one dev team member sat with designers to build a new site from scratch
  • 5 min (J)‏ OSS is good, right, lot of code, in our case, well done. Highly configurable, and if you don't like it, change it. What can go wrong? Project inception did not include a clear idea of the role of the platform, how we will negociate use vs extend vs modify Package implementation vs. development from scratch has some characteristics: Lot of existing and configurable functionality. Much easier to keep on the tracks that to go off road. Is lot of existing functionality... good or bad? It is good in the sense that many times we just have to use or configure, but it add a lot of complexity. We could not design in YAGNI fasion Legacy System? Good design, has tests It evolves on its own, out of our control Legacy/OSS -> influence in commiters and community / risk of branching -> less freedom in solutions When to get improvements from the community? Application level platform: Reuse ideas. Those trade offs were not clearly exposed at first, so consensus evolved during the project, with some friction.
  • 3 min (D)‏ Unit tests did exist for the platform Where should we add our test? When should we run it? Hard to get off the road Why? You have to understand the functionality that you are trying to replace (Invisible Cost of Reconfiguration) What should we test? Hard to find the inflexion point,
  • 3 min (D)‏ Extension support allowed us to add modules that could be deployed independently, create an installer hook, and patch the code base with our modifications without modifying the platform installation. CI Problems: Problems with server resources. Problems with the default build lifecycle (doc generation), Problems controlling the running platform instance from CI. Tests were effective, broke several times and developers were informed within a few minutes (Artful Making: Collaboration).
  • 3 min (J)‏ Liferay has functional testing. But what we need to test is not the product but that customer needs are satisfied by a mix of std features plus configuration plus modified features plus additional features. It was not clear at all how to do that in a efficient and sustainable way. We made some experiments. We tried with Selenium, and we had partial success. It worked for integration tests, but they were too expensive to develop, mantain and run for every feature. Keep in mind that most of the customers needs were covered with std features and configuration. So we tried to made a different appoach for the 80% of std features. We also wanted to minimize maintainance Product regression is hard: when modified the product to be regression tested is the whole Free open source Common language (Artful Making: Reconceive). Example: Section vs Page
  • To do Explicación de Artful making, más relación con el proyecto: comentarios en notas. En whole team, explicar el área gris de maquetado, y mas detalle de la estructura de equipo (ie no colocado)

Transcript

  • 1. A Case of Artful Exploration An agile experience of extending free open  source software Diego Fontdevila Juan Gabardini
  • 2. Index
  • 6. Project Case
    • IT Manager Alejandro Borra
    • 7. Tool Selection
    • 8. Team Casting
    • 9. Existing vs. New or modified functionality
    Business case video
  • 10. Artful Making
    • Qualities of Artful Making
    • Iteration Cost Structure
      • Cost of Exploration
      • 14. Cost of Reconfiguration
    • New way of learning
  • 15. Project Vision Issues
    • Inception
    • 16. Platform vs. Product (Site) Development
    • 17. Prototyping
      • Workshops
      • 18. Killer features
  • 19. Whole team
    • Whole team mindset was hard to reach
    • 20. Content development -> Marketing team
    • 21. Platform development -> Development team (vendor and customer IT)‏
  • 22. Iteration estimation and rythmn
    • It converged as expected (around sprint 4).
    • 23. Project has fixed price
    • 24. Customer has great disposition to balance cost, effort and functionality
    • 25. From the customer's point of view complexity is still unknown.
    • 26. Customer planning participation improved with the impending soft launch (beta release).
  • 27. Cost of iteration
    • Exploration (Rehearsals & experiments)‏
      • Experiments and prototypes
    • Reconfiguration
      • Patches vs. Platform versions
      • 28. Extensible platform
      • 29. On site support for site developing
    Workshop video
  • 30. Free Open Source & Complexity
    • Is this a package implementation?
      • Modifications to the code base
    • Role of the platform
    • 31. Is it a Legacy System?
    • 32. Application level platform
  • 33. Design and Unit Test
    • Contract Design vs Exploratory Design
    • 34. Not useful to make test-first while exploring
    • 35. Hard to get off the road
    • 36. Where should we add our test?
    • 37. Understanding test architecture
    • 38. Hard to find the inflexion point (Michael Feathers)‏
  • 39. SCM & Continuous Integration
    • Platform with superb extension support
      • Hooks, independent deployment of modules, etc.
    • But... implementing a CI process was hard
    • 40. Identifying dependencies
    • 41. What test should we run? (original, ours?)‏
    • 42. All the same, the few tests that were implemented actually broke many times, thus helping maintain consistency.
  • 43. Functional Testing
    • How to validate coverage of requirements served by existing functionality?
      • How to
    • Product regression is hard
      • And automating it harder
    • Modifications to existing functionality require evidence of business value.
      • Problem reaching a common language
  • 44.
    •   Release October 15
    Conclusion
  • 45. Thanks!