Share
Agile of Agile Development - we horen deze woorden tegenwoordig vaker. Maar weten we echt waar het allemaal over gaat? Hoe kan dit ons helpen effectiever te worden, terwijl we veel plezier hebben met het ontwikkelen van software? Hoe kunnen we het gebruiken om met zakenmensen te communiceren en deze communicatie gemakkelijk en constructief voor beide partijen te maken?
Er waren een stel zeer getalenteerde en ervaren jongens die serieuze software ontwikkelden. Deze ontwikkelaars observeerden andere bedrijven en ontwikkelteams en hoe hun processen hun werk eenvoudiger maakten. Ze hebben hun observaties samengesteld om het Agile Manifest te creëren. En zij zeiden:
We onthullen betere manieren om software te ontwikkelen door het te doen en anderen te helpen. Door dit werk zijn we gaan waarderen:
Dat wil zeggen, hoewel er waarde is in de items aan de rechterkant, we waarderen de items aan de linkerkant meer.
In dit artikel zal ik twaalf theorieën en technieken van Agile Development presenteren. Dit is slechts de eerste stap naar de nieuwe wereld van softwareontwikkeling.
Onze hoogste prioriteit is om de klant tevreden te stellen door vroege en continue levering van waardevolle, maar niet volledig uitgeruste, software. Dit betekent dat we software ontwikkelen en ten minste één functie toevoegen, per iteratie.
Laten we ons voorstellen dat we een blog-engine willen maken; we kunnen dit doen met behulp van het volgende proces:
Het is een eenvoudige benadering, maar de klant ziet de echte vooruitgang van zijn software en geeft u onmiddellijk feedback over elke nieuwe functie. Het kan perfect zijn of moet worden aangepast, maar u kunt snel reageren op wijzigingen: een win-win-situatie.
Zelfs laat in de ontwikkelingscyclus, laten Agile-processen u toe om wijzigingen aan te nemen voor het concurrentievoordeel van de klant.
De klant wil dat het project snel wordt afgewerkt en zo dicht mogelijk bij het ontwerp wordt getrokken. Dit kan eenvoudig worden bereikt door gewoon naar hun input te luisteren en klaar te zijn voor veranderingen. Als we snel kunnen reageren op veranderende eisen, zijn we waarschijnlijk de beste keuze die onze klant ooit heeft gemaakt. Bij Agile draait alles om communicatie en veranderingen. We doen de dingen zoals ons wordt gevraagd om ze te doen, waardoor het software ontwikkelingsproces sneller verloopt. Dit wordt bereikt omdat we kleine stukjes software ontwikkelen, en een verandering in de vereisten heeft geen echt effect op ons.
We moeten updates van een paar weken tot een paar maanden leveren; hoe korter de tijd, hoe beter.
klanten voelen zich meer zelfverzekerd in ons en ons product als het wordt bijgewerkt
Uit mijn ervaringen hebben klanten meer vertrouwen in ons en ons product als het wordt bijgewerkt - wat essentieel is voor onze relatie met hen. Een ander voordeel is de feedback van onze klant; waardoor we kunnen reageren door klassen, functies, modules of zelfs de architectuur te veranderen. We zullen niet meer wakker worden na dagen of maanden werk, alleen om te zien dat alles in de prullenbak terechtkomt. Laten we een hypothetische situatie beschouwen:
Er is u gevraagd om een module te maken die enkele eenvoudige tekst in een inhoudbeheer zal weergeven. Plots veranderen de vereisten en moet u een formulier toevoegen dat een e-mail moet sturen naar een geconfigureerd adres. Bovendien moet het formulier aanpasbaar zijn, zodat de gebruiker nieuwe velden kan toevoegen en validators kan definiëren. U moet dus eigenlijk de oorspronkelijke eenvoudige tekstvereisten vergeten. Hoe snel zou u willen weten over deze verandering?
Als u met uw klant aan een project werkt en regelmatig levert, weet u deze wijzigingen sneller en worden dergelijke wijzigingen gemakkelijker voor u beiden.
Dit kan het moeilijkste principe zijn om aan te wennen, als je software hebt ontwikkeld in de oude watervalstijl. U, als ontwikkelaar, spreekt meestal niet dezelfde taal als uw klant, maar u kunt manieren vinden om zinvolle communicatie met hen te onderhouden. Een van de beste manieren is naar mijn mening om alles te beschrijven met een eenvoudig verhaal dat ons vertelt, de ontwikkelaar, voor wie de functie is, wat zijn verantwoordelijkheid is en waarom we het überhaupt nodig hebben. Natuurlijk wordt dit eenvoudiger naarmate we meer met onze klant werken. Een andere nuttige benadering is Gedragsgerichte ontwikkeling (BDD), maar dat is een onderwerp voor een ander artikel.
Geef de mensen met wie u werkt de omgeving en ondersteuning die ze nodig hebben en vertrouw hen vooral om de klus te klaren.
Het is belangrijk om een boeiende sfeer te bieden en alle tools die nodig zijn om goede software te maken. Bedrijven verliezen hun beste werknemers meestal omdat ze niet echt om hen geven. De overtuiging dat ontwikkelaars software kunnen schrijven, testen en implementeren op een server met behulp van een FTP-client en live productiebestanden kunnen bewerken, is ergens verloren gegaan. Als je die oude schoolgewoonten niet hebt veroordeeld, kun je het beter nu doen.
Het behoud van werknemers is slechts een voordeel; je kunt ook sneller en betere software ontwikkelen. Denk er maar eens over: het schrijven van herbruikbare code, geautomatiseerde tests en geautomatiseerde inzet op elke server (kan onder andere) de ontwikkelingstijd positief beïnvloeden. We denken meestal dat we een project vertragen omdat we moeten leren hoe we nuttige hulpmiddelen kunnen gebruiken, zoals Jenkins, GIT, SVN, Gerrit, Behat, enz. Eerlijk gezegd doen we dat, maar we kunnen die tools en concepten dan opnieuw gebruiken in toekomstige projecten.
Het is de meest efficiënte en effectieve methode voor het overbrengen van informatie naar onze klanten en ons ontwikkelteam.
Wie is niet overweldigd en / of boos geworden door 6.255.384 e-mails te zien in je inbox, omdat je bedrijf eist dat alle gesprekken "op papier" zijn? Ik heb dat een paar keer in mijn leven persoonlijk gezien en ik raad het af om in een bedrijf met dergelijke gewoonten te werken. Face-to-face gesprekken maken communicatie eenvoudiger en soepeler, en stellen ons in staat om meer informatie te geven. We kunnen verbale en non-verbale manieren van communicatie gebruiken om onze teamgenoten te laten zien wat we denken. Het is duidelijk sneller dan elkaar e-mailen.
Maar bovenal moeten we elkaar vertrouwen; Vertrouwen is gemakkelijk te verkrijgen in een omgeving die persoonlijke communicatie stimuleert.
Dit is een van mijn favoriete regels; het laat ons vrij werken volgens onze eigen processen. Softwareontwikkelaars zijn anders dan andere werknemers; dus natuurlijk moeten ze als zodanig worden behandeld. Uit mijn persoonlijke ervaring heb ik geleerd om niemand te beoordelen van het ontwikkelingsteam zolang de klus geklaard is. Ontwikkelaars willen geen slechte software maken en dat doen ze minder snel als we ze laten werken volgens hun eigen voorkeuren. De klant is immers blij zolang het werk dat hij heeft gedaan correct is uitgevoerd; het maakt ze niet uit hoe het was gedaan.
Agile processen bevorderen duurzame ontwikkeling, waardoor een constant tempo onbeperkt kan worden gehandhaafd.
De bekendste voordelen van Agile (zoals het accepteren van veranderende eisen, snelle reactie op feedback, enz.) Worden algemeen gewaardeerd, maar het beste voordeel is naar mijn mening het vermogen om precies te bepalen hoe lang een project of functie zal duren. consumeren. Na enkele leveringen zal het dev-team het meest waardevolle bedrijfsnummer produceren: capaciteit. Capaciteit is de hoeveelheid werk die het team in één iteratie kan doen. Het capaciteitsnummer is stabiel na enkele iteraties en we kunnen de belachelijke deadlines en tijdschattingen vermijden die "uit een hoofd worden getrokken" terwijl we het aanbod van ons bedrijf aan de klant presenteren.
Veel mensen zeggen dat het onmogelijk is en het plannen blijkt accurater te zijn. Ben ik het niet mee eens; het schema gaat ervan uit dat er geen fouten of onvermijdelijke vertragingen zullen zijn.
Het is een perfect plan voor een perfect team, en dat bestaat niet.
Continue aandacht voor onze branche verhoogt de wendbaarheid.
Er wordt van ons verwacht dat we evolueren en vooruitgang boeken. We moeten elke dag blijven leren, omdat de industrie zo snel evolueert. Naarmate hardware en software beter worden, moeten we up-to-date blijven; anders zullen we verloren raken in de "zee van nieuw" en zal het moeilijk zijn om weer op het goede spoor te komen.
Refactoring is de oplossing voor de meeste problemen. Door constant te refactoren (indien nodig), kunnen we gemakkelijk nieuwe technieken toepassen en onze software-architectuur verbeteren.
Bill Gates zei ooit:
Als ik wat gecompliceerd werk moet doen, zal ik het aan de meest luie persoon die ik heb geven, omdat ze de eenvoudigste manier vinden om het te doen.
Eenvoud is de gouden regel. Dit betekent niet dat je lui moet zijn, maar het betekent wel dat ontwikkelaars het grootste deel van hun tijd hun eigen werk compliceren. Als u alleen de klus doet die de klant wil, zonder extra functionaliteiten en verbeteringen, wordt uw werklast lichter en bereikt u uw doelen. Uiteindelijk is dat alles waar de klant om geeft.
De beste architecturen, vereisten en ontwerpen komen voort uit zelforganiserende teams.
Wij zijn slechts mensen; we kunnen niet alles voorspellen.
Ben je ooit in een situatie geweest waarin je een grote en tijdrovende applicatie ontwikkelde, en nadat je talloze uren voor het scherm doorliep met het schrijven van duizenden regels code en het lezen van artikelen, tutorials en boeken, ging je zitten kijken naar een aantal slechte (maar werk) code dacht: "Nu weet ik hoe ik het beter moet schrijven"? Ik denk dat we allemaal deze momenten hadden.
Hier komt de elfde regel om de hoek kijken. We hebben een team van ontwikkelaars die de principes van Test Driven Development (TDD) kunnen volgen, waar refactoring deel uitmaakt van het proces. Op een of andere magische manier is onze software nuttig, mooi, goed geschreven, getest en snel gemaakt. Wij zijn slechts mensen; we kunnen niet alles voorspellen.
Dit komt allemaal voort uit het idee van een zelforganiserend team, waarbij elk lid een rol heeft - niet gegeven of geforceerd - maar een die is ontstaan na een bepaalde hoeveelheid tijd om samen te werken. Dat is de schoonheid van teamwerk.
Met regelmatige tussenpozen moet uw ontwikkelaarsteam nadenken over hoe u effectiever kunt worden en het gedrag dienovereenkomstig aanpassen.
Dit kan enkele ontwikkelingscycli vereisen, maar het team zal in perfecte harmonie werken. Zelfs het toevoegen van nieuwe mensen aan dit team zou niet schadelijk zijn. Bij een Agile ontwikkelingsteam draait alles om het klusje klaren. Als ze in een vriendelijke omgeving werken, vinden ze de "melodie van het werk" en zie je hoe snel softwareontwikkeling kan zijn.
Er zijn een paar methodologieën afgeleid van en gebouwd op Agile-principes. Ik zal ze niet allemaal beschrijven omdat elke methodologie in zijn eigen artikel kan worden behandeld. Ik zal echter enkele van de meer bekende Agile benaderingen beschrijven. Een ding om te onthouden is dat er geen enkele methode is om ze allemaal te regeren. Kies er een die het beste bij u past en configureer hem zelfs volgens uw specifieke vereisten.
SCRUM is gemaakt door Ken Schwaber en Jeff Sutherland en is een bedrijfsgericht framework voor het beheer van softwareontwikkelingsprocessen. Er zijn veel verschillende soorten SCRUM; onthoud gewoon dat het belangrijkste doel is om effectief en efficiënt te werken en niet te houden aan regels.
XP, gemaakt door Kent Back, is een lijst met best practices die ontwikkelaars moeten volgen bij het maken van software. Het wordt vaak "de extensie van SCRUM" genoemd. Deze methodologie van ontwikkelingsgerichte regels was geboren, omdat SCRUM eerder bedrijfsgericht was.
Twee van de belangrijkste principes van Lean zijn: DALAP (beslis zo laat mogelijk) en DAFAP (zo snel mogelijk leveren). Ik raad persoonlijk aan om meer te lezen over deze methodologie, omdat het zeer nuttig kan zijn.
Er zijn meer methodologieën in de Agile-familie; Ik heb simpelweg naar de populairste opties verwezen. Als u Agile wilt gebruiken in uw ontwikkelingsproces, moet u weten wat deze methodieken zijn, om de juiste keuze voor u te maken.
Werken Agile-technieken echt??
Werken Agile-technieken echt en zijn de methodes echt zo magisch als iedereen zegt? Niet altijd.
Het probleem dat ik tegenkwam in bedrijven, waar Agile-methoden geen resultaten opleverden (of zelfs de zaak nog erger maakten), was een slecht gekozen methodologie en het gebrek aan overtuiging onder de gebruikers (zakenlieden, het ontwikkelingsteam, enz.). Daarom moet je er volgens de schrijver zeker van zijn dat iedereen die bij het proces betrokken is de regels begrijpt en ze weten 'waar het allemaal om gaat'.
Bedankt voor het lezen!
Accentsconagua