Paremmat APIt nopeammin APIOps Cycles-menetelmän avulla

Tavoite Lean-johtamisessa on parantaa läpimenoaikaa ja laatua. Lean API -kehityksen avulla ja APIOps Cycles -menetelmällä voit tehdä hyviä rajapintoja lyhyessä ajassa.
‍

Älä ymmärrä minua väärin; tässä ei ole kyse vain hyvästä laadusta eli virheettömästä toteutuksesta. Kyse on siitä, mikä on parempaa yrityksellesi, asiakkaillesi, kumppaneillesi ja kehitystiimillesi.
‍

Kun aloitin APIOps Cyclesin luomisen, ihastuin Lean-johtamisen periaatteisiin. DevOpsin, teknisenä ja kulttuurisena toimintatapana, juuret ovat Leanissa. APIOps termiä, on käytetty pääasiassa viittaamaan automatisoituun API-kehitykseen käyttämällä DevOpsia ja API-hallintaa yhdessä.
‍

APIOpsista puhuvat pyrkivät usein luomaan parempia rajapintoja tai ainakin julkaisemaan ne nopeammin. Pelkkäään APIOps-tekniikkaan keskittyminen ei kuitenkaan auta saavuttamaan tuloksia. Tarvitset myös oikean kulttuurin, ihmiset, prosessit ja suunnittelumenetelmät.

‍

Lean on johtamisfilosofia ja käytäntö, joka pyrkii poistamaan ”jätteet” tuotantoprosessista.

‍

Joten miksi Lean-jätteiden poistaminen on välttämätöntä rajapinnoillesi?

Koska jätteet eivät tuo mitään arvoa asiakkaalle. Hukka vie organisaatiolta arvokasta aikaa ja resursseja. Voit tuottaa enemmän arvoa ja tuloja samoilla resursseilla, kun hukkaa on vähän.

LEANin kahdeksan jätettä ovat:

1. Viat

2. Ylituotanto

3. Odottaminen

4. Ei-lisäarvoa tuottamaton käsittely

5. Kuljetus (tai kosketukset)

6. Inventaario

7. Liike

8. Työntekijöiden ja osaamisen tuhlaaminen

‍

Miten kahdeksan jätettä vaikuttavat API-kehitykseen?

1. Viat

Tiedätkö miten API toimii? Puuttuuko sinulta jotain tietoa? Onko epästandardia käsittelyä?

2. Ylituotanto

API on tehty laajemmaksi, ja siinä on enemmän päätepisteitä tai attribuutteja kuin tarvitaan. Kehittäjät hukkuvat valtavan määrän tarpeettoman dokumentaation alle.

3. Odottaminen

Odottaminen on ajanhukkaa API-kehittäjille ja API-kuluttajille. APIin tai uuden ominaisuuden julkaisemisen odottaminen on tuhlausta. Hitaan, alisuorittavan rajapinnan vastauksen odottaminen on myös tuhlausta.

4. Ei-lisäarvoa tuottamaton käsittely

Esimerkkejä ovat monimutkaiset menettelyt ja prosessit tai raskas arkkitehtuuri. Projektinhallintaprosessien käyttäminen API-kehityksen ohjaamiseen tuotehallinnan sijasta. Liian tiukka hallinto eli hierarkkiset prosessit APIen julkaisemiseen.

5. Kuljetus (tai kosketukset)

Tämä jäte voi olla monessa muodossa: Tekniset ja liiketoiminta-asiatntuntija teivät puhu samaa kieltä. Liian monta kokkia sopassa. Tehtävän suorittamiseen tarvitaan liian monta erillistä API-pyyntöä.

6. Inventaario

APIen luominen varmuuden vuoksi, eikä välittömään käyttöön on varastohävikkiä.

7. Liike

Jätteet yksittäisen tehokkuuden näkökulmasta — kuinka monta asiakirjaa API-hyödyntäjän tai rajainnan kehittäjän on tutkittava käyttääkseen tai luodakseen erinomaisia rajapintoja? Tai kuinka usein he menevät edestakaisin, pyytävät apua, kokeilevat asioita?

8. Työntekijöiden ja osaamisen tuhlaaminen

Kouluttamaton ja motivoimaton API-tiimi ei ole kustannustehokas. Rajapinnat, jotka vaativat kehittäjiä opiskelemaan ahkerasti ennen niiden ymmärtämistä, tuhlaavat kehittäjiensä aikaa.

‍

APIOps Cycles -menetelmä auttaa organisaatioita ja yksilöitä ymmärtämään, mitä ja miten parantaa

- rajapintoja ja niiden laatua

- API-kehitystä ja hyödyntämistä

- APIen ja strategian välistä yhteyttä

‍

Sinun ei tarvitse olla Lean-harrastaja käyttääksesi APIOps Cycles -menetelmää. Halusin vain näyttää, kuinka tärkeää on pohtia, mitä menetelmiä käytät rajaipntojen kehittämiseen.

‍

‍APIOps ja APIOps Cycles ovat Osaangon tavaramerkkejä, ja niitä saa käyttää CC-BY-SA 4.0 -lisenssillä jaetun APIOPS Cycles -menetelmän käytön yhteydessä.

‍