Open agile is free and open source community agile-
1 like322 views
This document discusses similarities and differences between agile methodologies and open source software development. It analyzes how principles of agile development like early delivery, customer collaboration, responding to change, and valuing individuals align with practices in open source communities. While open source lacks formal business interactions and face-to-face teams, its distributed model relies on self-organizing developers and releasing code frequently in a way that achieves agile goals.
![Managing Open Source
Be agile to minimise lost effort
Adapt Scrum and Kanban rules to a
distributed large scale team of co-developer
(co-client)
Orchestrated by a team moderator /
integrator / leader [By doocracy]](https://image.slidesharecdn.com/openagile-isfreeandopensourcecommunityagile-141126034609-conversion-gate01/85/Open-agile-is-free-and-open-source-community-agile-21-320.jpg)
Open agile is free and open source community agile-
- 1. OpenAgile: Is Free And Open Source communities Agile? Produce something useful for someone
- 2. Open Source is subversive? world-class products by: ● part-time hacking ● several thousand developers ● scattered all over the planet, connected only by Internet?
- 4. Agile subversive too? ● Individuals and interactions* (communications) over processes and tools ● Working products over comprehensive documentation ● Customer collaboration over contract negotiation ● Responding to change over following a plan
- 5. Our highest priority is to satisfy the customer through early and continuous delivery of valuable products. Open source does not talk about the customer, but in general, x
- 6. ● Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. ● Open-source projects resist major changes as time goes on, but there is always the possibility of forking a project if such changes strike enough developers as worthwhile.
- 7. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter time scale. Open source delivers working code every night, usually, and an open-source motto is "release early, release often
- 8. Business people and developers must work together daily throughout the project. Open-source projects don't have a concept of a business person with whom they work, but users who participate in the project serve the same role.
- 9. "Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done." All open-source projects do this, almost by definition.
- 10. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. Open source differs most from agile methodologies here.
- 11. Working software is the primary measure of progress. This is in perfect agreement with open source.
- 12. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. Although this uses vocabulary that open-source developers would not use, the spirit of the principle is embraced by open source.
- 13. Continuous attention to technical excellence and good design enhances agility. Open source is predicated on technical excellence and good design.
- 14. Simplicity--the art of maximizing the amount of work not done--is essential. Open-source developers would agree that simplicity is essential, but open-source projects also don't have to worry quite as much about scarcity as agile projects do.
- 15. The best architectures, requirements, and designs emerge from self-organizing teams. Possibly open-source developers would not state things this way, but the nature of open-source projects depends on this being true.
- 16. At regular intervals, the team reflects on how to become more effective, and then tunes and adjusts its behavior accordingly. This is probably not done much in open-source projects, although as open-source projects mature, they tend to develop a richer set of governance mechanisms.
- 17. GNU, Linus values... release early and often, delegate everything you can, be open to the point of promiscuity
- 18. Treating your users as co-developers Release early. Release often. listen to your customers Having good ideas is recognizing good ideas from your users.
- 19. Perfection (in design) is achieved not when there is nothing more to add, but rather when there is nothing more to take away.
- 20. To solve an interesting problem, start by finding a problem that is interesting to you
- 21. Managing Open Source Be agile to minimise lost effort Adapt Scrum and Kanban rules to a distributed large scale team of co-developer (co-client) Orchestrated by a team moderator / integrator / leader [By doocracy]
- 22. Do Ocracy is an organizational structure . individuals choose roles and tasks for themselves and execute them. . Responsibilities attach to people who do the work, rather than elected or selected officials.
- 23. Work-in-progress limits Open Source likely driven by issues. Issue is a story? Issue must be solved
- 24. Planning meetings Issue tracker => Milestones (sprint like) iced issue (not planified) Tag the issues (todo in a milestone no tag, Assigned (working), done, finished (accepted))
- 25. Review meetings. Comments on issues
- 26. Standup meetings On regular basis publish in public forum a) what he/she do in previous quantum, b) what he/she is working on actual quantum, and c) what is blocking any of that work (assigned issues).
- 27. Retrospective reviews Open Source essence When something must be done will find someone to do it! not done? it probably not important!
- 28. Metrics.