This experience is based on the practice summary of two small and medium-sized projects (one 2000 Manday, one 1500 Manday) in the past two years, and I hope to discuss and make progress with you.
About Agile
- Agile is a Systems Engineering
- Agile is More of an Attitude - Jim Highsmith
- Be a Practitioner Not a Scientist How to Deliver the Right Software by Example
- Agile is a Practice to Theory
- Agile Learning Is a process from theory to practice and back from practice to theory
- Skip the agile terminology and focus on the essence
- Imposing agile practices on a team is not agile practice Scrum Elements
- Large projects can take multiple levels of agile Team (unpracticed)
misunderstandings about agile "Agile Development Knowledge System"
- only good development teams can do agile
- small projects can do agile
These two misunderstandings are caused by one of the agile practices for small and medium projects (about project owners and Responsible person) has been described in http://www.iteye.com/topic/1134228 . It is due to the flexible characteristics of agile management, giving people a feeling of being uncontrollable or chaotic.
Agile, the most fearful thing is to be agile for the sake of agility. A big coffee has said that imposing agile on a team is not an agile thing.
If you know how the term "agile" came into being, you'll know that agile is nothing magical, it's just a summary of a set of good practices. Therefore, there is absolutely no to take "agile" too seriously , but to have a deep understanding of the practices recommended by those big names.
quote
Birth of the Agile Manifesto: From February 11 to 13, 2001, 17 leaders in software development gathered at Snowbird, a ski resort in Utah, USA. After two days of discussion, the term "Agile" was accepted by all the attendees to encapsulate a new set of software development values. This set of values, delivered to the world through a concise Agile Manifesto, heralded the beginning of the agile development movement.
Agile learning should be a process from practice to theory. Some deficiencies found in the process of project practice can always be found in agile corresponding practical activities. So, from this point of view, agile is just a tool set , use it if you need it, and *collect* it first if you don't need it (is it a sensitive word first *collection*?). Just like in life, if I want to unscrew a screw, I don't have to use a hammer, but also a saw.
Agile is also a systems engineering. Only when many practices cooperate with each other can the project be completed well. If the control of requirement changes is not done well, the Spirit plan will be affected. If unit testing is not done well, continuous integration is not done well. If the review is not done well, the quality may go wrong, resulting in overtime work. Overtime can lead to low morale. When morale is low, quality is even more affected. Such a vicious circle formed.
So, agile is not a sunflower book, it's just a set of excellent problem-solving tools.