Om maar met de deur in huis te vallen: iedere softwareontwikkelaar zou agile moeten werken. Wij leveren de appcloud, wat inhoudt dat je werkt met een stabiele omgeving. Daarnaast is er een low-code platform - veel kennis doe je op door gewoon de stappen te zetten. Sterker nog, in mijn ogen is de beste manier om bepaalde projectonderdelen aan te pakken - wat ik noem - doe-het-zelf-agile. Laat me het uitleggen*.

 

Stel je voor dat je een e-mail-template wilt aanpassen en tegelijkertijd de omstandigheden waaronder de mails worden verstuurd wat wilt bijstellen. Wellicht denk je nu aan een bijbehorende lijst die op de standaardinterface van de eindgebruikers. Heb je daarvoor een design nodig? Nee. Maar wel een user story, een sprint en een demo? Natuurlijk niet! Het enige wat je op dat moment nodig hebt is een Salesforce Administrator die jou uitlegt hoe je dit voor elkaar krijgt, een sandbox om te testen, en wat tijd en lef. Op die manier weet je direct wat het platform aan kant-en-klare oplossingen biedt. En de volgende keer doe je het helemaal zelf.

 

*Dit is deel 3 van mijn blogreeks, lees deel 1; de developers driver's seat, en deel 2; code altijd hergebruiken, hier.

 

Met wie werk je waaraan?

 

Ik zie geen enkele reden om anderen volledig buiten het proces te laten; een compleet project waarin jij iemand uitlegt wat je wenst en die persoon de mogelijkheden laat onderzoeken. DIY; coördineer met je expert; wees voorzichtig wanneer je gaat implementeren; en zorg ervoor dat de verandering door developers- en testomgevingen gaat; dat is alles en zo is het goed. Geef je team enkele georganiseerde en/of zelftrainingen en laat ze ‘prototypen’ en implementeren wat ze zelf denken nodig te hebben. Dat zou wel eens een betere investering kunnen zijn dan ze user stories te laten schrijven.

 

 

Wanneer sprints en demo’s of ‘ouderwets’?

 

Voor de zaken die je businessanalisten en systeembeheerders niet zelf kunnen uitvinden geldt per definitie: wees flexibel (agile) met korte sprints en regelmatige demo's, om er zeker van te zijn dat iedere ontwikkelaar precies datgene bouwt wat de organisatie nodig heeft.

 

Denk aan de belangrijke pas op de plaats!
De fijne kneepjes van agile en scrum sla ik hier over. Ik wil je meteen meenemen naar het gebied waarvan ik denk dat je eerste een pas op de plaats moet maken voor je te agile wordt. Er zijn namelijk momenten waarop je volgens mij beter de 'ouderwetse' route van research, discussie en design kunt volgen. Bijvoorbeeld wanneer:

 

  • er integraties met andere systemen zijn; design en plan ze tot in detail, tot en met de keuze van je tools (wellicht heb je ESB nodig, of niet - Salesforce biedt event driven architecturen en is zodoende API-driven);

  • je een superieure gebruikerservaring nodig hebt; richt je dan niet louter op je BAS, developers of UAT-testers; start een UX-project waarin experts de gebruikerservaring onderzoeken;

  • je weet dat je veel codedesign nodig hebt, inclusief een goed werkend mechanisme voor continuous integration en geautomatiseerd testen (kijk hiervoor eens naar DX).

 

Op dat laatste punt wil ik dieper ingaan. Ben jij er zeker van je eenvoudige implementatie met maar één functionaliteit, zoals een e-mail die is gebaseerd op wat voor de hand liggende zaken? Is het dan puur een kwestie van eventueel design en een ontwikkelstraat links laten liggen en er meteen op los coderen? Het is prima iets te ontwikkelen dat 'gewoon werkt'. Dan denk ik zelf aan een middelgroot projecten waarin je mogelijk veel code produceert, maar waarin hergebruik van code voor komende projecten geen rol speelt. Maar zelfs dan kun je developers vragen hoe ze de code willen structureren, vaste benamingen voorstellen, en een doorlopende-integratiestraat realiseren. Compleet met automatische codechecks en -testen.

 

Geautomatiseerd checken, testen en documenteren

 

Salesforce vraagt om geautomatiseerde Apex-testen. Onlangs hebben we een verbeterd implementatiemechanisme gelanceerd onder de naam Salesforce DX. Daarnaast zijn er plannen voor het automatiseren van het testen van Lightning UI voor ons Lightning Component Framework. Wanneer je een CI-straat opzet (wat ik je voor complexere implementaties aanraadt), overweeg dan het gebruik van automatische codecontroles en manieren om je codes automatisch te documenteren. Hetzelfde geldt voor je databasemodel. Met die mate van automatisering rondom je code beheer je meteen het kwaliteitsverschil tussen leveranciers. Veel ontwikkelaars die ik ken werken graag met zulke tools, ook al zijn ze het zo nu en dan oneens met de feedback op hun code. Zoals ik in mijn vorig blog zei, worden developers al te vaak beoordeeld op demo's en functionaliteit. Ze weten als geen ander dat schone code telt, maar de gelegenheid om daar de credits voor te pakken ontbreekt. Zodra je de code checkt, is die kans er wel. In een notendop:

 

  • de herbruikbaarheid en beheersbaarheid van code moet je implementatieplannen dienen (inpakken en opnieuw gebruiken?), alsook de hoeveelheid coderegels die je verwacht;

  • let op dat je niet teveel wilt regelen voor een simpel probleem; de hoogste kwaliteitseisen leiden tot aanzienlijke kosten;

  • bovendien kan het lastig zijn voor torenhoge ambities het juiste team samen te stellen.

 

 

Het complete verhaal: de klantgerichte omgeving

 

In deel 1 van deze blogreeks suggereerde ik dat iedereen in jouw team Salesforce zou moeten leren en zelf UI's moet 'customizen'. Ik vertelde echter niet het complete verhaal. Als je op zoek bent naar een superieure gebruikerservaring moet je dat niet doen. Bijvoorbeeld in een klantgerichte omgeving. Dus ook interne klanten als de agents van je klantcontactcenter, die vanwege het grote aantal oproepen efficiënt op hun beeldschermen moeten (door)werken. Dat is een klus die jij en/of (andere) ontwikkelaars niet zelf kunnen doen. Je moet dan echt Lightning Components coderen voor een kant-en-klaar ontwerp. Daarnaast heb je UX-experts nodig om wireframes te genereren, gebruikersonderzoek uit te voeren, en de resultaten te delen met het totale ontwikkelteam. Dan heb je en feedbackcirkel van wat wenselijk en wat haalbaar is. Precies wat je nodig hebt. Kijk hiervoor ook eens naar deze Trailhead, om meer te weten te komen over UX. Heel wat anders dan de welbekende gebruikersacceptatietest - een andere discipline.

 

Kijk goed welke architectuur je kiest

 

En dan de uitsmijter op het gebied van design: het integreren van systemen via API-calls. Of het nu gaat om standaard Salesforce REST API's, maatwerk-SOAP, JSON of een bestandsinterface. Vergeet agile en voorkom allerlei ongemak. Om te beginnen moet je de architectuur goed overwegen. Welke tools ga je inzetten? Heb je een Enterprise Architecture nodig of een designpatroon als Microservices? Hoe ga je om met de unieke identifiers en hoe gaan je berichten eruitzien? Als je niets ontwerpt en plant kun je straks met de verkeerde architectuur zitten. Zelfs wanneer je de juiste weg bent ingeslagen kun je continu ruis op de lijn hebben, in de vorm van verschillende teams die verschillende velden in waarden verwachten in de uitgewisselde berichten. Een goede manier om dit tegen te gaan is de event based architectuur, omdat je zaken kunt ontkoppelen. Maar ook deze keuze hangt volledig af van je user cases. Kortom, neem er de tijd voor en neem geen overhaaste beslissingen op dit punt.

 

Conclusie

 

Design waar nodig. De ene keer werk de oude manier prima. zoals de patronen voor enterprise-integratie, en de andere keer ben je gebaat bij 'hippere' methodes als UX-design. Dat gezegd hebbende, vind ik dit een belangrijke voorwaarde voor dergelijke uitdagingen: zorg er altijd voor dat een bedreven Salesforce-architect meekijkt naar het beantwoorden van alle designvragen, of het nu een collega is of en partner van een systeemintegrator, een freelancer of Salesforce CSG. Niet eens op permanente basis, maar wel wanneer een kritische blik noodzakelijk is. Grote slagkracht gaat immers altijd gepaard met grote verantwoordelijkheid. Op die manier is ons platform ingericht, zodat onze klanten er optimaal profijt hebben.