Share
Onlangs had ik de mogelijkheid om een plug-in te bouwen met twee andere ontwikkelaars: Pippin Williamson en Andrew Norcross. We bedachten het idee via Twitter, scoopten het via e-mail en bouwden het met behulp van GitHub met behulp van zijn tools allemaal voordat het werd uitgebracht.
Ik weet het - de titel van dit bericht klinkt maar al te bekend, vooral gezien de wereldeconomie waarin we vandaag allemaal leven. Tenslotte werken velen van ons vanuit onze thuiskantoren, coffeeshops of waar dan ook terwijl de thuisbasis van ons bedrijf elders ligt.
Maar dit is een ander type gedistribueerd team.
Laten we allereerst erkennen dat we het enorm goed hebben als het gaat om het bouwen van software in de WordPress-ruimte, met een paar vrienden of in de context van een team in een bedrijfsomgeving..
Hoewel WordPress zelf door veel mensen over de hele wereld wordt gebouwd, zie je niet vaak dat dezelfde ervaring wordt doorgetrokken met thema's of plug-ins. Dit wil niet zeggen dat het zo is nooit gedaan (omdat het zo is), maar het lijkt erop dat het minder goed gedaan is.
Het doel van dit bericht is niet om de eerder genoemde plug-in te promoten, maar het is meer een oproep tot actie voor ons om creatievere manieren te vinden om publishing-producten samen met teams te bouwen - namelijk onze 'internetvrienden' of tweeps - met wie we misschien niet eerder gewerkt.
Maar er zijn een paar dingen die uit dit proces zijn voortgekomen en waarvan ik denk dat ze het waard zijn om te delen om anderen te helpen experimenteren met het ontwikkelen van projecten met mede tweeps..
Eenvoudig gezegd, het vergrendelen van de scope is onderdeel van het identificeren van de kernfuncties van uw plug-in. Als je voor het eerst begint, is het belangrijk om dat te kunnen kort en bondig vermeld wat uw product gaat doen.
In ons geval zeiden we:
We willen het gemakkelijk maken voor mensen om te identificeren welke opmerkingen een reactie van de auteur van het bericht nodig hebben.
Wat dit doet, kunt u een raster definiëren - of een bereik - waarmee alle potentiële functies kunnen worden gefilterd. Als het niet past in het kernidee van de plug-in, dan is het niet geschikt voor de eerste release.
Dat gezegd hebbende, dit voelt bijna alsof het een beetje cliché is, omdat het te verwachten is ieder softwareproject: de scope identificeren, vergrendelen en ernaar streven.
Maar wanneer u met een groep vrienden aan een gratis project werkt, kan dit steeds gemakkelijker worden genegeerd.
Voorbeeld: als een enkele ontwikkelaar, hoe vaak heb je bij jezelf gedacht: "Dat zou een coole functie zijn om te bouwen!" En toen, omdat je niemand had om je echt verantwoordelijk te houden om het te bouwen, was je in staat om het te bereiken.
Dat wil niet zeggen dat dat zo is fout - het kan zijn, misschien niet - ik ken de details van uw project niet; Als u echter met een team aan een project werkt, kost het tijdverspilling om aan iets te werken dat buiten het toepassingsgebied valt, wat tijdverspilling is en uiteindelijk de kern van de plug-in kan aantasten. Bovendien kan het de ontwikkeltijd van uw peers vertragen terwijl ze wachten tot uw functie compleet is, vooral als er een afhankelijkheid van uw werk is.
Eindelijk, als je een groep ontwikkelaars bij elkaar krijgt om iets voor de lol te bouwen, kan het project dat wel nooit Doe het omdat je het idee hebt opgevat van "zou dit niet cool zijn", en vermenigvuldigd met het feit dat er veel in jouw team zitten.
Het punt is dat, hoewel je het project samen met vrienden uitvoert, je het project lean moet scoren en het project vroegtijdig moet reiken; anders ben je nooit klaar.
En dit brengt ons bij het tweede punt: ondanks het feit dat u niemand "boven u" heeft die u verantwoordelijk houdt voor uw leveringsdatum, hebt u nog steeds een verplichting tegenover uzelf, uw bereik en degenen die kunnen wachten op het product om complete ontwikkeling.
Toegegeven, er is altijd een argument dat kan worden gemaakt dat, omdat mensen niet betalen, ze geen echte behoefte hebben aan iets dat moet worden afgemaakt; Als u echter een datum hebt ingesteld, is er een integriteitsniveau dat moet worden gekoppeld aan het streven om uw werk te leveren.
https://twitter.com/pippinsplugins/status/301792120266690561
Daarom is het belangrijk dat u een leverdatum instelt - hoe willekeurig dat ook is - en vervolgens mijlpalen instelt om ervoor te zorgen dat het ontwikkeltempo overeenkomt met die datum.
Pippin, Andrew en ik hebben bijvoorbeeld de plug-in in februari doorzocht en probeerden de plug-in in april te voltooien aan het einde van een van de WordCamp-evenementen. Natuurlijk was de deadline enigszins arbitrair, maar het hield ons niet alleen eerlijk in onze eigen ontwikkelingsinspanningen, maar het stelde ons ook in staat om elkaar verantwoordelijk te houden voor onze eigen specifieke taken.
Dit betekent dat als ik mijn voeten zou slepen, Pippin of Andrew me daarop zou kunnen roepen (het werkt natuurlijk overal).
Ten slotte is het werken met vrienden geweldig, vooral wanneer je verenigd bent rond dezelfde visie. Hiermee kunt u sneller meer gedaan krijgen omdat het werk over meer dan één persoon kan worden verspreid.
Maar het leuke aan software is dat het kan wees open source. Dit betekent dat als anderen niet alleen geïnteresseerd zijn in het project of worden gekocht in de visie, ze er zelfs aan kunnen bijdragen.
Maar hier is het ding, software gaat onvermijdelijk twee dingen fokken:
Met behulp van hulpmiddelen zoals GitHub kan de gebruiker van de plug-in - of het nu gebruikers, ontwikkelaars of ontwerpers zijn - hun problemen en / of functieverzoeken op een gecentraliseerde manier uitspreken.
Bovendien stelt het het kernteam niet alleen in staat om elke verzameling problemen toe te wijzen aan hun eigen mijlpalen, maar het zorgt ook voor andere bijdragers die ook in de visie gebracht weten precies hoe ze een bijdrage kunnen leveren. Er is geen giswerk. Er is geen "hey, misschien kunnen we doen deze!"
In plaats daarvan is er een lijst met problemen en verzoeken die nodig zijn (waardoor de lijst up-to-date wordt gehouden) zodat bijdragers weten dat ze uiteindelijk het product verbeteren - niet alleen blindelings iets toevoegen omdat ze denken dat het er goed uit zou zien.
Dit is natuurlijk niet beperkt tot GitHub: welk broncontrolesysteem en ticketsysteem je ook kiest om te gebruiken, zorg ervoor dat het voor anderen gemakkelijk is om te communiceren en anderen om openstaande kwesties te bekijken. Het laatste wat bijdragers nodig hebben is nog een andere hindernis om bij te dragen aan uw project.
Dus daar heb je het: Drie punten voor het werken aan producten met een gedistribueerd team buiten de typische georganiseerde omgeving.
Simpel gezegd, zorg ervoor dat u uw project in de gaten houdt, houd vast aan uw leverdatum en sta toe dat anderen bijdragen die geïnteresseerd zijn. Op deze manier maakt u het niet alleen gemakkelijk voor uw huidige team, maar ook voor uw toekomstige bijdragers om het product te verbeteren.
Ten slotte heb ik vermeden om de plug-in te bespreken die Pippin, Andrew en ik speciaal hebben gebouwd omdat ik wilde dat deze post over het proces gaat, niet over het product; echter, nu we de eerste hebben behandeld, kun je de laatste hier vinden op GitHub. Als je geïnteresseerd bent, voel je dan vrij om ons problemen, opmerkingen of zelfs trekverzoeken te laten!
Accentsconagua