A Case Of Artful Exploration
•Transferir como ODP, PDF•
0 gostou•335 visualizações
Agiles 2009 presentation
![Index ,[object Object]](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)
Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (20)
Destaque
Semelhante a A Case Of Artful Exploration
Semelhante a A Case Of Artful Exploration (20)
Último
Último (20)
A Case Of Artful Exploration
- 1. A Case of Artful Exploration An agile experience of extending free open source software Diego Fontdevila Juan Gabardini
- 4. Challenges
- 5. Conclusion
- 8. Team Casting
- 9. Existing vs. New or modified functionality Business case video
- 11. Ensemble
- 12. Collaboration
- 16. Platform vs. Product (Site) Development
- 18. Killer features
- 20. Content development -> Marketing team
- 21. Platform development -> Development team (vendor and customer IT)
- 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).
- 29. On site support for site developing Workshop video
- 31. Is it a Legacy System?
- 34. Not useful to make test-first while exploring
- 35. Hard to get off the road
- 36. Where should we add our test?
- 38. Hard to find the inflexion point (Michael Feathers)
- 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.
- 45. Thanks!
Notas do Editor
- 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)