Először is érdemes elolvasni a magyarra ferdített változat helyett az angol verziót, aminek több értelme van:
1, Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
2, Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
3, Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
4, Business people and developers must work together daily throughout the project.
5, Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
6, The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
7, Working software is the primary measure of progress.
8, Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
9, Continuous attention to technical excellence and good design enhances agility.
10, Simplicity--the art of maximizing the amount of work not done--is essential.
11, The best architectures, requirements, and designs emerge from self-organizing teams.
12, At regular intervals, the team reflects on how to become more effective, then tunes and adjusts ts behavior accordingly.
Illetve ezt javaslom olvasásra:
https://www.linkedin.com/pulse/12-agile-manifesto-principles-simply-exp…
1-es pont: ezt szokták nagy sokan szigorúan venni, és akkor be is bukik minden. Amikor elindul egy projekt, akkor a hagyományos modellben van egy speckó, lefejleszted,
fél év múlva a megrendelő kap egy sw-t, tehát a kezdeti specifikáció és a végső termék közötti olló baromi nagy. Egy alternatíva erre, hogy gyorsan kap release-eket valami
pl. egy teszt szerverre, ahol szépen meg tudjátok mutogatni, hogy ez így meg úgy fog működni. Ennek az előnye az, hogy a felhasználó vissza tud jelezni, hogy bocsi, bár
ebben egyeztünk meg, de rájöttem, hogy ez így ebben a formában nem lesz jó, nem-e lehetne másképp? A szoftver tehát időben konvergál ahhoz, amit a felhasználó valóban szeretne,
nem pedig egy "specifikációhoz" ami teljesen biztosan hiányos, hibás, és nem végiggondolt.
2-es pont: ez nem azt jelenti, hogy kávédarálónak indult, és űrhajó lesz belőle. Ez azt jelenti, hogy lehetőséget adunk a felhasználónak a fent említett változtatásokra ésszerű keretek között.
5-ös pont, az emberek azért lesznek motiváltak (mert ha nem fizeted meg őket, akkor nem fognak nálad dolgozni) mert hagyják őket békén dolgozni, nem pedig végtelen mennyiségű szükségtelen adminisztrációs baromsággal kell foglalkozniuk, illetve nem fentről valaki kiosztja a melót hogy ki mit csináljon, hanem a csoport önszerveződik. Igy önállóan egymás között el tudják dönteni, hogy ki mit szeretne csinálni a következő sprintben.
7-es pont: az eredetiben egyébként az van, hogy "emphasis on working software over comprehensive documentation". Tehát fontosabb a működő program, mint hogy le legyen dokumentálva, amit egyébként a kutya sem fog elolvasni.
9-es pont: Continuous attention to technical excellence and good design enhances agility. Igy máris van értelme...
10-es pont: 80-20 szabály. Az eredményeid 80%-a a melód 20%-ából fog jönni. Ezt kell jól megcsinálni. Csinálj jó, ügyes könyvtárakat, toolokat, stb. amik segítik a munkád.
11-es pont: annyi, hogy bízzuk a fejlesztőkre, hogy ők hogyan szervezik meg magukat, mert ők tudják. A PM ne ugasson bele, a felsővezetés meg végképp. Én már találkoztam olyannal, hogy a felsőbb vezetésből valaki, aki korábban fejlesztő volt, osztotta az észt olyanokról, amikhez nem értett. Finoman helyre kellett rakni, hogy ad.1. ez nem az ő dolga, ad 2. hülyeséget beszél.
12-es pont: angolul megint értelmes.
---
magamról: 2001 óta java fejlesztő vagyok...