Selection of manifestos from the IT world
I have a hobby - I collect various manifestos and appeals from the IT world. At the moment I have already collected quite a lot, so I decided to publish them with my comments.
The article describes:
')
http://agilemanifesto.org
In addition to values, I recommend reading the list of princes: http://agilemanifesto.org/principles.html
The controversy over Agile is one of the hottest and has not abated so far. I suggest looking at one of the typical ones: http://habrahabr.ru/post/142412/#comment_4768622 . In addition to the comment thread itself, there is a discussion of the same dispute in the AgileRussia group .
Read this sample controversy for Agile fans and those who want to open their eyes. It is obvious from it that people argue about different types of projects and contracts, about different relations between a customer and a client. In such disputes, it is imperative to mention the limitations that inevitably come with each methodology and practice.
Large and small companies stumble upon errors when using the principles that the manifest of agile development declares. There is a lack of understanding of the limitations that lead to epic failures. One recent example is the development of the British system of social payments Universal Credit .
There are failures just out of misunderstanding. Typical wooden planes without an engine that do not want to take off . For example, from the most recent: "We do not write tests, we use Agile methods, we already have good code."
I suggest you look at the limitations by which you can evaluate whether Agile is right for you or not for:
About criticality, the size of the team and the number of changes everything is clear. The most ignored are the Qualification scale and the Culture scale. Agile leads to the fact that you should not spend too much time on a hard process. It may seem that this brings some relief. To some extent this is true, but this relaxation requires much greater responsibility and qualification from each participant in the software development process. This part is key and do not forget about it.
In more detail about the topic of restrictions, I recommend reading in the book Balancing Agility and Discipline: A Guide for the Perplexed .
Agility @ Scale: Strategies for Scaling Agile Software Development
This is a slightly modified version of Agile Manifesto, which is the personal opinion of an IBM employee. They tried to shift the manifesto to the rails of large corporations. The author replaced “software” with “solutions” and “customer” with “stakeholder”. Personally, I like these clarifications, although they could seem obvious. We do not just software, but deliver a solution for users. We have not just customers, but many stakeholders who want a working solution.
In addition, by reference to the article there is a modified list of principles. It added a few items about Lean.
http://blog.xebia.com/2010/12/23/moreagile-manifesto
This manifesto takes the left side of the original AgileManifesto and sets a new one as opposed to each statement. Conversion history is as follows:
For me personally, this manifesto did not make a consciousness revolution, but only made a few additions.
http://agilescout.com/agile-manifesto-2-1-moreagile-manifesto
This manifest is a small modification of the previous one. The difference is insignificant, the essence of the ideas is taken from the previous one.
http://www.halfarsedagilemanifesto.org
This manifesto began with the article “ Beyond Agile: New Principles? ” By Ron Jeffries. This manifesto is a copy of the original with additions that explain that in reality there is no 100% adherence to values. Take for example the fact that we are ready for changes in the plans, but first we need to make the plan itself, which we will change in the future.
I like this option, because it has a sobering effect on fanatics of flexible methodologies.
http://pmdoi.org
For me, this is one of the favorites for the depth of ideas. This declaration addresses issues that I consider to be key when developing software:
The DOI ideas are discussed in more detail in the article “For a de facto management or DOI” .
http://programming-motherfucker.com
PM, PO, ScrumMaster, etc. Roles in projects often with fanaticism impose various methodologies, management frameworks and practices on programmers. Most importantly, they lose respect for the developers. For a long time it could not continue, because it is obvious that in the end the value of software is how it solves the problems of users. If you use the most advanced process, but your software does not work, it will lead to failure.
I think the more managers there are on the project, the more programmers will support this manifesto. Not so long ago, I participated in a project where only 4 of 15 people were programming teams, it was still that zoo.
The column “They Really Value” is a showdown of the motives. I can partially agree with them, but I think that they show another too radical extreme, the exact opposite of the world of Effective Managers.
write-code-blyat.rf
Localized version of the previous manifest. And the picture is localized. In the English version, the character from the movie Pulp Fiction was used, we have a fist waving at the popular meme Be a peasant .
http://manifesto.softwarecraftsmanship.org
Software Craftsmanship is the developers' response to the emergence of an Agile methodology for its support from engineers. It can be considered an adequate version of the “Programming, Motherfucker” manifesto.
I have always said that without good developers, no process is possible. Suppose you have a scrum. You plan iterations, you write code and make releases. If the code is bad, how many iterations can you take at a good pace? I do not think so much. The basis of the IT industry are the developers and this manifesto reminds us that we need to constantly evolve.
https://sites.google.com/a/jezhumble.net/devops-manifesto
All interaction between developers and the IT infrastructure operational support service usually comes down to the fact that the first ones roll the finished releases to the second one through the “wall”. Developers create something new and make changes, while operational task specialists should ensure the stability of the entire infrastructure. This causes problems and the goal of the DevOps movement is to destroy the wall, to put everyone in one team.
On this topic, I recommend watching the video People, Process, Tools - The Essence of DevOps .
Surely you have a couple of favorite manifestos, maybe you wrote your own. I would be glad to see these manifestos in the comments.
A few more manifestos for reflection:
The article describes:
- Manifesto for Agile Software Development
- Agile Manifesto - IBM version
- MoreAgile Manifesto
- Agile Manifesto 2.1
- Manifesto for Half-Arsed Agile Software Development
- Declaration of Interdependence
- Programming, Motherfucker
- Software Craftsmanship Manifesto
- DevOps Manifesto
')
Manifesto for Agile Software Development
http://agilemanifesto.org
In addition to values, I recommend reading the list of princes: http://agilemanifesto.org/principles.html
Protests
The controversy over Agile is one of the hottest and has not abated so far. I suggest looking at one of the typical ones: http://habrahabr.ru/post/142412/#comment_4768622 . In addition to the comment thread itself, there is a discussion of the same dispute in the AgileRussia group .
Read this sample controversy for Agile fans and those who want to open their eyes. It is obvious from it that people argue about different types of projects and contracts, about different relations between a customer and a client. In such disputes, it is imperative to mention the limitations that inevitably come with each methodology and practice.
Restrictions
Large and small companies stumble upon errors when using the principles that the manifest of agile development declares. There is a lack of understanding of the limitations that lead to epic failures. One recent example is the development of the British system of social payments Universal Credit .
There are failures just out of misunderstanding. Typical wooden planes without an engine that do not want to take off . For example, from the most recent: "We do not write tests, we use Agile methods, we already have good code."
I suggest you look at the limitations by which you can evaluate whether Agile is right for you or not for:
About criticality, the size of the team and the number of changes everything is clear. The most ignored are the Qualification scale and the Culture scale. Agile leads to the fact that you should not spend too much time on a hard process. It may seem that this brings some relief. To some extent this is true, but this relaxation requires much greater responsibility and qualification from each participant in the software development process. This part is key and do not forget about it.
In more detail about the topic of restrictions, I recommend reading in the book Balancing Agility and Discipline: A Guide for the Perplexed .
Agile Manifesto - IBM version
Agility @ Scale: Strategies for Scaling Agile Software Development
- Individuals and interactions over processes and tools
- Working solutions over comprehensive documentation
- Stakeholder collaboration over contract negotiation
- Responding to change over following a plan
This is a slightly modified version of Agile Manifesto, which is the personal opinion of an IBM employee. They tried to shift the manifesto to the rails of large corporations. The author replaced “software” with “solutions” and “customer” with “stakeholder”. Personally, I like these clarifications, although they could seem obvious. We do not just software, but deliver a solution for users. We have not just customers, but many stakeholders who want a working solution.
In addition, by reference to the article there is a modified list of principles. It added a few items about Lean.
MoreAgile Manifesto
http://blog.xebia.com/2010/12/23/moreagile-manifesto
This manifesto takes the left side of the original AgileManifesto and sets a new one as opposed to each statement. Conversion history is as follows:
- Processes and tools -> Individuality and their interaction -> Teams and responsibility
- Exhaustive documentation -> Working product -> Value supply
- Agreeing the terms of the contract -> Cooperation with the customer -> Partnership
- Following the original plan -> Ready for change -> Acceptance of changes
For me personally, this manifesto did not make a consciousness revolution, but only made a few additions.
Agile Manifesto 2.1
http://agilescout.com/agile-manifesto-2-1-moreagile-manifesto
This manifest is a small modification of the previous one. The difference is insignificant, the essence of the ideas is taken from the previous one.
Manifesto for Half-Arsed Agile Software Development
http://www.halfarsedagilemanifesto.org
This manifesto began with the article “ Beyond Agile: New Principles? ” By Ron Jeffries. This manifesto is a copy of the original with additions that explain that in reality there is no 100% adherence to values. Take for example the fact that we are ready for changes in the plans, but first we need to make the plan itself, which we will change in the future.
I like this option, because it has a sobering effect on fanatics of flexible methodologies.
Declaration of Interdependence
http://pmdoi.org
For me, this is one of the favorites for the depth of ideas. This declaration addresses issues that I consider to be key when developing software:
- uncertainty - accepting that there is uncertainty in the project and the struggle to reduce it takes a lot of manpower and resources.
- the interdependence of all participants in software production — customers (surprisingly they are not always involved), developers, QA, etc. should be involved in the process
- Adaptation of practices to a specific situation on a project - this is not about a specific methodology or practice, it is assumed that you have tried them all and can adequately select the ones you need under the current tasks
The DOI ideas are discussed in more detail in the article “For a de facto management or DOI” .
Programming, Motherfucker
http://programming-motherfucker.com
PM, PO, ScrumMaster, etc. Roles in projects often with fanaticism impose various methodologies, management frameworks and practices on programmers. Most importantly, they lose respect for the developers. For a long time it could not continue, because it is obvious that in the end the value of software is how it solves the problems of users. If you use the most advanced process, but your software does not work, it will lead to failure.
I think the more managers there are on the project, the more programmers will support this manifesto. Not so long ago, I participated in a project where only 4 of 15 people were programming teams, it was still that zoo.
The column “They Really Value” is a showdown of the motives. I can partially agree with them, but I think that they show another too radical extreme, the exact opposite of the world of Effective Managers.
Manifest, bl @ th!
write-code-blyat.rf
Localized version of the previous manifest. And the picture is localized. In the English version, the character from the movie Pulp Fiction was used, we have a fist waving at the popular meme Be a peasant .
Software Craftsmanship Manifesto
http://manifesto.softwarecraftsmanship.org
Software Craftsmanship is the developers' response to the emergence of an Agile methodology for its support from engineers. It can be considered an adequate version of the “Programming, Motherfucker” manifesto.
I have always said that without good developers, no process is possible. Suppose you have a scrum. You plan iterations, you write code and make releases. If the code is bad, how many iterations can you take at a good pace? I do not think so much. The basis of the IT industry are the developers and this manifesto reminds us that we need to constantly evolve.
DevOps Manifesto
https://sites.google.com/a/jezhumble.net/devops-manifesto
All interaction between developers and the IT infrastructure operational support service usually comes down to the fact that the first ones roll the finished releases to the second one through the “wall”. Developers create something new and make changes, while operational task specialists should ensure the stability of the entire infrastructure. This causes problems and the goal of the DevOps movement is to destroy the wall, to put everyone in one team.
On this topic, I recommend watching the video People, Process, Tools - The Essence of DevOps .
Need more manifests
Surely you have a couple of favorite manifestos, maybe you wrote your own. I would be glad to see these manifestos in the comments.
A few more manifestos for reflection:
- The Software Team Leader Manifesto , Roy Osherove
- My Programming Manifesto , Jeremy Miller
- Code of honor
- Kill the programmer
Source: https://habr.com/ru/post/193232/
All Articles