Sedan början har programvara utvecklats enligt en sekvens av steg. Det börjar vanligtvis med en bra idé eller önskad lösning för ett specifikt problem. Sedan går det hela vägen till den faktiska leveransen eller till och med underhållet av slutprodukten.
Oavsett om ditt företag eller team använder ett mer traditionellt eller agilt tillvägagångssätt, skulle flödet av att få en utgång genererad som en input till nästa steg vara en del av varje mjukvaruutvecklingsprocess.
I den här artikeln kommer vi att prata om några av de metoder som används för olika ändamål under programvarans livscykel, som används av mjukvaruutvecklingsföretag runt om i världen, som vår - Imaginärt moln. Följ med oss på den här agila resan som är på väg att börja!
SDLC står för Livscykel för mjukvaruutveckling. I motsats till vad många tror, SDLC är inte ett ramverk eller till och med en beskriven process. Även om det kan definieras som en konceptuell modell Används för att representera hur programvara görs i en serie steg. Dessa steg täcker faser från idéfasen till leverans, beskrivna enligt följande:
1. Planering;
2. Analys/Krav;
3. Design och prototyper;
4. Mjukvaruutveckling;
5. Testning;
6. Distribution;
7. Drift och underhåll
Oavsett metodik eller utvecklingsram som ditt team använder, bör det täcka med mer eller mindre detalj alla steg som finns i SDLC. Till exempel, en vattenfallsinriktning skulle följa varje steg som en specifik fas i projektet, som är slutet på vart och ett av dem, en fasport/milstolpe när det gäller projektets framsteg. En Agil metodik skulle normalt ”kondensera” alla dessa steg till repetitiva, cykliska och iterativa bitar, som täcker alla dessa steg för varje iteration.
Begreppet Agile inom mjukvaruutveckling har funnits i årtionden. Bristen på formbarhet, vanliga tungviktprocesser och motståndskraft mot förändringar, ofta i branschen fram till slutet av 90-talet med vattenfallsorienterade projekt, konfronterades med en ny riktning. Det var då Agile-metoder (hade inte ens det här namnet då), som Scrum, XP, Kristall, Funktionsdriven utveckling (FDD), och Dynamisk systemutvecklingsmetod (DSDM), bland andra, började dyka upp.
Med idéer som täcker olika aspekter från: välkommen förändrade krav; Leverera programvara ofta; nära synergi mellan affärsmän och utvecklingsteam; liksom reflektionen över hur man kan förbättra, ger ljus till en Nytt sätt att skapa mjukvara. Förutom alla surr eller trender som kommer och går, är den verkliga fördelen som Agile föreslår att ta itu med kända problem som vanligtvis står inför i mjukvaruutvecklingsvärlden i ett annat perspektiv.
Istället för att följa den överanvända vägen för att bara täcka de fyra värdena som finns i Agilt manifestVår strategi kommer att vara att prata om Agiles principer och bästa praxis. De är ofta sidosatta, även om de representerar ännu mer detaljer om tankesättet som Agile bör ge.
En ”övning” kan definieras som ”den faktiska tillämpningen eller användningen av en idé, tro eller metod, i motsats till teorier som rör den”. Denna definition representerar tydligt Vad är agila metoder: ett sätt att tillämpa teorin bakom själva begreppet vad det innebär att vara Agile.
Agila metoder kan till och med användas utan att följa en given Agile-metodik - dvs. använda TDD (testdriven utveckling) ensam kommer inte att göra din leverans eller process helt smidig i sig. Det är relevant att förklara att de flesta agila metoder kallas det eftersom de antingen framkom från en agil metodik eller skapades av agila utövare.
Olika agila metoder uppmuntrar olika agila metoder för att göra dem mer objektiva och produktiva.
Var och en av dessa metoder kommer i allmänhet att fokusera på en specifik aspekt, såsom ledning, utveckling, testning etc.
Utan vidare presenterar vi nedan en lista över agila metoder som kan tillämpas i olika steg i din SDLC (livscykel för mjukvaruutveckling).
Tänk på att vissa av de metoder som presenteras här kan vara möjliga att tillämpa en eller flera gånger, beroende på deras mål. Vissa metoder råkar täcka djupare ett steg av SDLC än andra. Det kan dock vara så att en viss praxis helt täcker en aspekt och delvis en annan etapp. Tumregeln har alltid varit: mindre fokus på att vara strikt, och mer fokus på att uppnå önskat resultat :).
En av de första etapperna som projektet bör ha är dess produktvision. Med den första visionen för projektet behövs verkligen några korta definitioner: vem är kunderna, teamet, en omfattning på hög nivå (och motomfattning!) , ritningar av det tekniska tillvägagångssättet, potentiella risker, samt beräknad tid och kostnad. Ett trevligt ämne som ska behandlas är Visionsförklaring - även känd som ”elevator pitch”, som borde se mer eller mindre ut som nedan.
Affärsmodellduk bör användas för att forma den produkt som ska byggas och ta en praktisk riktning för att definiera affärsmodeller. Används i samband med Lean Startup, detta är ett verktyg som effektivt kan fungera som ett visuellt diagram över idéer och uppfattningar om ett befintligt eller nytt företag.
Formulera därför en fullständig förståelse som arbete i hypotes och värdeförslag. Täckning nio kvarter: aktiviteter, partners, resurser, värdeförslag, kunder, kundkanaler, kundrelationer, kostnader och intäkter på ett strukturerat sätt. Business Model Canvas kan spela en viktig allierad roll för att planera ett projekt.
Produktbackloggen är en lista över affärs- och projektmål och innehåller vad som förväntas utvecklas av utvecklingsteam, upprätthålls av Produktägare. Det är ett levande dokument, uppdateras kontinuerligt, prioriteras och ordnas av affärsvärde. Det kan också ha produktförbättringar, buggar, tekniska frågor etc. Dess syfte är främst att ha allt som behövs för att nå projektets produktvision.
Paolo Caroli skapade lean Inception som hans anpassning och utveckling av Inception-fasen som användes på ThoughtWorks. Tanken bakom det är att kombinera Design Thinking och Lean Startup via en upptäcktsverkstad för att definiera produktens MVP. Med en veckas intervall syftar workshopen vanligtvis till att hitta den riktning teamet ska ta för att bygga den perfekta produkten. Detta tillvägagångssätt kan ses som en förlängning av ämnet ”Produktvision” som nämnts tidigare. Det täcker också steg som definitionen av personas, resor, funktioner, tekniska, UX- och affärsrecensioner, etc under den en veckas tidsram.
Produktdesignprocess är hur vi på Imaginary Cloud definierar hur vi skapar digitala produkter - och ja, vi har en bok om det. Detta tillvägagångssätt, som vi använder internt i de projekt vi arbetar i, används också externt av olika branschaktörer. Den fokuserar på att täcka de nödvändiga stegen för att skapa en anmärkningsvärd lösning, vilket inte bara ger kunder och produktägare till centrum för denna diskussion men också användare.
Denna process kan ta en till några veckor beroende på produktens komplexitet och hur djupt vi behöver gräva för att definiera lösningen). Det inkluderar 12 steg, går hela vägen från forskning, idé, utförande och teknisk bedömning för att undersöka och identifiera produktens bana på bästa möjliga sätt.
Vi nämnde Product Backlog tidigare i det här inlägget som ett sätt att gå för planering och strukturera dina produktmål. Det är också giltigt att visa en metod för att arbeta med den (förutsatt att användarberättelser används för att skapa och underhålla din produktbacklog).
Kartläggning av användarberättelser är rent en teknik som möjliggör en visuell uppdelning - eller ”skivning” - av användarberättelser på ett sådant sätt att de kan hanteras och adresseras på ett sekventiellt sätt som är vettigt som en produkt, från ryggraden till mindre detaljer. Detta tillvägagångssätt är värdefullt när det ger sammanhanget på det sätt som funktionerna delas upp som ett helt projekt, inte bara en representation av en grupperad lista. Viktigt att säga att definitionen av hur tunna eller tjocka skivorna är definierade, inriktad på en berättelse från början till slut, kommer från direkt interaktion med kunder/användare.
Domändriven design - eller DDD - är ett begrepp som används i mjukvarudesign att strukturera programvaruarkitekturmodellerna med hjälp av en abstraktion av applikationens affärsdomän. Det kräver integration och samarbete från både teknisk och affärsmässig sida (använder därför en av DDD:s huvudegenskaper: allestädes närvarande språk, inriktat på en gemensam förståelse av termer från alla håll).
Eftersom DDD fokuserar starkt på definitionen av domänlagret, förutom att dra nytta av Objektorienterad programmering koncept, det blev ganska populärt bland OOP-samhället. Men dess allmänna idé kan användas oavsett vilket programmeringsparadigm som används, speciellt för att det kan användas som en grund för praxis som TDD, BDD, CI, refactoring, etc.
Tekniker som att använda entiteter, värdeobjekt eller underdomäner som avgränsade sammanhang, byggstenar som tjänster, förvar, fabriker och händelser ger en strategisk design till applikationen. Det gör det möjligt att kombinera Domänens struktur, livscykel och beteende på ett kortfattat och relaterat sätt.
Spike - en vanlig term i Agile som kommer från XP - hänvisar till en typ av användarberättelse används för att utforska och söka tillräckligt med förståelse för ett tillvägagångssätt och därför minska risken om det tas. Arkitektonisk spik går ett steg längre mot mjukvarudesign och arkitektur. Syftet är att definiera ryggraden i modelleringsarkitekturen och hur det kommer att Alla arbetar tillsammans, men med tillräcklig pragmatism föreslås denna lösning med den ännu begränsade befintliga informationen om problemdomänen. Under denna praxis involverar definitionerna ofta mjukvarulager, delsystemgränser, mycket troligt vissa arbetskod och källkontrollverktyg som ett minimalt/optimalt skelett av applikationen. Det bidrar till att definiera och vara en del av systemmetaforen, en ”enkel delad berättelse om hur systemet fungerar”.
Inte tillräckligt för att säga att när projektet och applikationen utvecklas bör dess arkitektur också anpassas och förfinas, eftersom Architectural Spike bara är den första uppgiften i den riktningen. Denna idé diskuteras i praktiken som omfattas av avsnittet nedan.
Den elfte principen för Agilt manifest som nämnts tidigare säger att”De bästa arkitekturerna, kraven och designen kommer från självorganiserande team.” När man talar strikt om designen kanske du fortfarande undrar vad det betyder. Emergent Design talar om att bygga lösningen evolutionärtsom tillåter dess utformning och arkitektur definieras under hela utvecklingsresan. Att använda lite jargong istället för att göra BDUF (Stor design på framsidan), JEDI används ofta (Just Enough Design Initially). Att följa detta sätt att tänka, stegvis, ger utvecklare utrymme att fokusera på direkta projektbehov och undvika en tidig och suboptimal definierad arkitektur - även om det är värt att nämna att fokus bör ligga på att ta itu med andra krav än att bara försöka förutsäga framtiden.
Trots viss kritik beträffande fördelarna med att skapa definitionen av arkitektur (i motsats till att definiera starka och fullständiga ryggrad av en så viktig del av applikationen) bör man dra stor nytta av vad Agile kan ge in en adaptiv och inlärningsmiljö.
Övningen att göra Kontinuerlig integration (CI) motsvarar att ha den huvudsakliga strömlinjeformen av kod som tar emot ändringar eller tillägg som gjorts av utvecklare separat i ett enda programvaruprojektförvar/filial. Den här åtgärden bör utlösa några steg som automatiserade tester och syntaxstilgranskningsverktyg, vanligtvis orkestrerade av ett CI-verktyg i samband med en Versionskontroll hanteringssystem. XP föreslår att denna process bör göras flera gånger om dagen för att garantera att en integrerad version av koden finns.
CI är den första fasen i en kedjeprocess som omfattar Continuous Deployment (en applikation släpps i produktion om den lyckas med alla steg i den automatiska distributionsprocessen) och Continuous Delivery (med kodbasen distribuerbar till olika miljöer vid varje given tidpunkt).
Standardstrategin för kontinuerlig integration som föreslås av Martin Fowler följer nedanstående:
De viktigaste fördelarna som observerats med CI går från upptäcka buggar mer effektivt, undvika omkostnaderna för manuell integrationsprocess, alltid tillgänglig uppbyggnad av miljöerProcessen blir mer transparent (därigenom förbättra meddelandet) och uppmuntra en mer robust testtäckning. CI skapar också utrymme för implementering av metoder som pull-förfrågningar och kodgranskning.
Testdriven utveckling, eller TDD, är känd som praktiken av test-first programmering, som följer, genom att skapa automatiserade enhetstester, repeterbart flöde av:
Huvudmålen med detta tillvägagångssätt är att Gör koden tydligare, enkel och felfri, samtidigt som man tänker bättre på strukturen och beaktar systemets interna gränssnitt och ansvarsområden.
Det finns specifika verktyg som stöder enhetstestning och TDD, allmänt kända som XUnit-verktyg (JUnit, NUnit, XPYUnit, PHPUnit, etc), men inte begränsat till dem.
TDD är utan tvekan ett paradigmskifte för en utvecklare som inte är van vid att följa dessa steg. Ett vanligt tabu om TDD är att det kräver för mycket ansträngning och tid att spendera, därför inte värt det. Tumregeln i sådana fall är att hitta en mellanväg och förstå det TDD bör ge både mer testad och därför renare kod till ansökan.
Det är viktigt att nämna att TDD inte kan vara den enda delen av applikationens kvalitetssäkringsstrategi, och detta kommer att täckas nedan när vi pratar om QA. Dessutom bör den automatiserade testskapad när man använder en TDD-metod säkert vara en del av applikationens strategi för kontinuerlig integration, vilket är ett av de steg som krävs för att få den processen klar.
Förmodligen den bästa definitionen av Refaktorering Kommer från Martin Fowler.
”En disciplinerad teknik för att omstrukturera en befintlig kod, ändra dess interna struktur utan att ändra dess yttre beteende”
Eller...
”En förändring som gjorts i programvarans interna struktur, för att göra det lättare att förstå och billigare att ändra utan att ändra dess observerbara beteende”.
Behovet av kodrefactoring kommer ofta från”kod lukt”: en indikation på eventuell omorganisation på grund av svaghet eller potentiella problem som finns i koden. En vanlig användning av Refactoring är att betala den tekniska skulden, en av de största projektets mardrömmar. I TDD kallas också steget som nämner handlingen att (åter) skriva kod som klarar testet ofta också Refactoring.
För vissa människor kan det vara utmanande att förstå fördelarna med att koncentrera ansträngningarna på att arbeta med kod som redan skrivits. Det kan dock säkert höja kodens underhållbarhet, sammanhållning, läsbarhet, prestanda och återanvändbarhet, bland annat som borde motivera den tid som spenderas. Det är giltigt att betona det Refactoring handlar inte om att skapa nya funktioner, eftersom detta går utöver dess syfte. Målet bör alltid vara att behålla sitt nuvarande beteende (befintliga och/eller nya tester bör införas för att garantera detta).
Några exempel på det vanliga utnyttjandet av Refactoring är: användning av designmönster, polymorfism, inkapsling av fält, ändra användningen av parametrar, undantag etc.
Förmodligen den bästa definitionen av Refaktorering Kommer från Martin Fowler.
BDD står för Beteendedriven utvecklingoch kan definieras som”ett tillvägagångssätt för utveckling som förbättrar kommunikationen mellan affärs- och tekniska team för att skapa programvara med affärsvärde”. BDD syftar till att vara bingingpunkten bland affärsmän, utvecklare och QA-testare (för att inte säga alla personer som är involverade i projektet), för att garantera en gemensam förståelse och enhetlig kommunikation av applikationens egenskaper. Detta uppnås genom att skapa sina specifikationer baserade på scenarier och exempel, med hjälp av ett gemensamt mönster ”Given-When-Then” för att representera lösningens faktiska beteenden.
ATDD (Acceptance Test-Driven Development) går ett steg längre och använder grunden för BDD för att implementera kodade acceptanstester med hänsyn till förväntat beteende definieras tidigare i scenarierna. ATDD liknar TDD i den meningen att det i allmänhet automatiserar en serie misslyckade acceptanstester innan du skapar kod för att få dem att passera, och delar en liknande cykel med det tillvägagångssättet.
Testverktyg som Behat, Cucumber eller SpecFlow är exempel på alternativ som stöder användningen av körbara specifikationer, vilket möjliggör användning av ATDD i projektet och utnyttjar det som definierades med BDD.
Även om det inte formellt definieras som en agil praxis, är det sunt förnuft i samhället att automatisering i tester är huvudstruktur för att hantera kvalitetssäkring När det gäller Agile. Det gör att andra metoder som ATDD, TDD, CI, bland andra kan vara så effektiva som möjligt.
Som ni kanske gissar, automatiserad testning är formen av att använda en separat mjukvara för att implementera tester i din programvara. Antingen genom att kontrollera de externa gränssnitten, till exempel mobil eller webbläsarbaserad GUI-testning, intern kommunikation mellan lager, som API:er eller till och med inriktning på prestationsanalys. Den tydligare och främsta fördelen med att använda ett sådant tillvägagångssätt är att undvika upprepningen i manuella processer, för att inte tala om sannolikheten för att mänskliga fel införs.
Dessa fördelar kan ses i vissa teststrategier som regressionstester, eller en Kontinuerlig integrationspipeline. Det är viktigt att överväga när och vad man ska automatisera, med tanke på den ansträngning som krävs för att genomföra dessa typer av tester. Nivån på automatiserad testtäckning, oavsett om det är enhetstestning, integrationstestning eller mer allmänt end-to-end-testning, kommer att kräva olika ansträngningar och ge olika värde, beroende på önskat fokus. Liknande logik gäller när man bestämmer vilken verktygsuppsättning som ska användas, för vilken en samvetsgrann utvärdering föreslås. Selen, Jasmine och RSpec är exempel på olika testverktyg tillgängliga för olika teständamål.
Sessionsbaserad testning är ett annat exempel på en testpraxis som, trots att den inte officiellt definieras som Agile, det har stor adoption inom den agila världen. Denna teststrategi kan anges som ett mer strukturerat sätt att göra manuell undersökande testning, vilket i princip innebär att testa en mjukvara utan föregående design eller definition av testfall, fritt söka defekter. På så sätt följer sessionsbaserad testning a”Dela för att erövra” utforskande idé, dela upp aktuella tester i - gissa vad? -, sessioner. Den följer en uppsättning steg (självförklarade) nämligen: uppdrag, stadga, session, sessionsrapport, debriefing och analys, som hjälper till att täcka med tillräckligt med detaljer vad som behövs för att uppnå en sådan process.
Inom det agila sammanhanget, flera sessioner kan definieras för varje användarberättelse, till exempel täcka mer eller mindre av var och en beroende på deras associerade risker. Sådan flexibilitet gör det möjligt för denna praxis att hantera den snabba takt som finns i Agile. Förutom det höga fokus som är kopplat till automatisering av tester och tester på utvecklingssidan, är det också ytterst viktigt att förstå värde intill manuell testning när det görs effektivt. Det kan nå vissa aspekter av programvaran som bara dessa tillvägagångssätt inte kan. Både manuella och automatiserade teststrategier kombinerade bör göra det nödvändiga jobbet för att garantera den kvalitetssäkring som behövs för ett projekt.
DevOps står för kombination och samarbete mellan utvecklings- och IT-verksamhetsteam för att uppnå kontinuerlig och snabb leverans. Detta tillvägagångssätt får båda sidor att arbeta tillsammans och försäkra vikten av deras kommunikation och integration genom att använda begreppet Infrastruktur som kod (IaaC). De viktigaste stegen för att nå detta är: Infrastrukturautomation (att ha system, konfigurationer och appdistributioner som kod i projektets övergripande struktur); Kontinuerlig leverans (bygga, testa, distribuera appar på ett automatiserat och snabbt sätt) och Site Reliability Engineering: (driva system, vilket innebär övervakning och orkestrering, vilket garanterar att de stöder sådana funktioner från början).
På det här sättet”DevOps stege” nedan är inställd och närvarande i projektet.
Att använda DevOps visar några fördelar som lugnande skalbarhet, tillförlitlighet, säkerhet, snabb leverans (och därmed snabbare tid till marknaden, om det behövs), kortare Mean Time To Recovery (MTTR), förebyggande av risk för mänskliga fel, lägre felfrekvens på nya utgåvor, bland andra. DevOps utan tvekan ses som en kompletterande praxis när du använder Agile. Det ger aspekter som frekvent leverans, tidig upptäckt av fel, högre transparens när det gäller övervakning av en applikation etc. övervägs del av Agile metodik SAFe.
Denna praxis täcker ämnen som redan beskrivits som en del av Kontinuerlig integration och DevOps, för att inte tala om korrelationen med automatiserad testning. Genom att binda samman alla koncept kan vi därför definiera Continuous Deployment som nästa steg i kontinuerlig integration. Det använder sig av automatiserad testning för att säkerställa att en korrekt kod automatiskt släpps ut i produktionsmiljön, vanligtvis genom att dra nytta av DevOps infrastrukturverktyg. Den automatiska utgåvan är faktiskt en skillnad och en vanlig missuppfattning när det gäller kontinuerlig leverans, eftersom även om de delar samma förkortning, i den senare är åtgärden ”gå till produktion” vanligtvis manuell. Kontinuerlig driftsättning är det kompletta, automatiserade programvarudistributionsflödet från början till slut. Det kan implementeras för att ske så många gånger som behövs för en given applikation, beroende på affärsbehov.
De typiska stegen som finns i Continuous Deployment är:
Dessa steg bör ge tillräcklig garanti för att den kod som skapats är tillräckligt väl täckt och kontrollerad. Därför är det moget att nå produktion utan större hot, vilket möjliggör möjligheten att enkelt återställa den chansen från rörledningen om det behövs. Det finns verkligen oro för att automatisera ett så viktigt steg, och de tillhörande riskerna är verkligen närvarande. Det är också nödvändigt att nämna att att ha en sådan struktur byggd kring din applikation medför sina kostnader. Fortfarande, de utbetalningar som ett sådant tillvägagångssätt ger kan vara en kärnegenskap för en framgångsrikt projekt och mjukvarulösning.
Om du har nått den här delen av artikeln bör det vara rättvist att anta att du vet Vad är Kanban. I ett nötskal kan det beskrivas som en arbetsflödeshanteringsmetod för att visualisera det arbete som den kontrollerar. Det skapades inom det japanska lean tillverkningsområdet, mer exakt Toyota Production System.
På senare tid blev huvudidéerna från detta arbetssätt implementeras i mjukvaruindustrin och skapade det som nu kallas Kanban Method, som använder som sin primära artefakt: Kanban-kortet. Denna styrelse är det ledande visuella förvaret i realtid för information och framsteg i en given process, vilket ger ljus på möjliga blockerare och flaskhalsar på ett enkelt sätt. Kolumnerna som finns i tavlan representerar steg i flödet och begreppet Work In Progress (och dess gräns, per kolumn), vilket är en värdefull resurs. Hela tanken är att dina uppgifter (biljetter, ärenden, du namnger det) flyter genom varje kolumn i tavlan.
Kanban är en evolutionär metod som kan implementeras mycket enkelt (och gradvis utveckla sin process och användning) för att få saker gjorda. Också, eftersom det är inget annat än ett icke-störande förändringshanteringssystem, Kanban har använts i hög grad i drifts- och underhållsprojekt. Det utnyttjar de punkter som nämns för att implementera i en on-demand, just in time-miljö, där initiativ som Scrum bara medför omkostnader och slöseri.
Kanban definieras inte strikt som en agil praxis. Emellertid det används för att implementera Agile och Lean-principer samtidigt som man ökar både medarbetarnas och kundnöjdheten.
Målet med denna artikel var att presentera verkliga alternativ som kan användas i alla SDLC (Livscykel för mjukvaruutveckling) med starkt fokus på agila metoder.
Detta tillvägagångssätt är här för att stanna och sådana förslag har använts, diskuterats och förbättrats genom åren. De löser vanliga problem som finns i de dagliga uppgifterna i mjukvaruutvecklingsprojekt.
Trots att det är några av metoderna mer eller mindre vanliga och kända utvärderar vi på Imaginary Cloud först varje scenario i våra projekt. Sedan tillämpar vi metoder och tekniker som gör att lösningarna vi bygger kan nå nästa nivå och nå framgångsrika leveranser.
Baserat på vårt teams expertis kan vi definiera och rekommendera hur man använder agila metoder på bästa sätt och när man ska tillämpa dem i livscykeln för din verksamhet. webbapplikation eller UI/UX Designprojekt.
Tror du att du kan behöva en hand? Hör av dig!
Hittade den här artikeln användbar? Du kanske gillar dessa också!
Passionerad om mjukvara och smidig. Kan lätt hittas matlagning, spela volleyboll eller spendera lite tid med videospel.
Människor som läste det här inlägget tyckte också att dessa var intressanta:
.webp)
.webp)
.webp)
.webp)
.webp)
.webp)
.webp)
%20(1).webp)
.webp)
.webp)
.webp)
.webp)
.webp)
.webp)
