Voitot:
- Kyky muuntaa epämääräiset liiketoimintapyynnöt selkeiksi, testattaviksi ohjelmistovaatimuksiksi ja käyttäjätarinoiksi tekoälytuen avulla
- Kyky verrata järjestelmäsuunnittelun, tietomallin ja arkkitehtonisten päätösten hyviä ja huonoja puolia jäsennellysti tekoälyn kanssa
- Kyky arvioida kriittisesti tekoälyn ehdotettu suunnittelu vaatimuksia, skaalautuvuutta ja rajoituksia vastaan
Suurin osa ohjelmistoprojekteista epäonnistuu huonon koodin, vaan väärinymmärrettyjen vaatimusten vuoksi. Yhden lauseen pyyntö, kuten "Anna käyttäjien ladata raportteja", jättää jälkeensä kymmeniä vastaamattomia kysymyksiä: Missä muodossa? Kuka on vastuussa? Kuinka monta levyä? Entä jos se on hidasta? Vaatimusanalyysi (liiketoiminnan pyynnön kääntäminen selkeiksi, testattavissa oleviksi teknisiksi tarpeiksi) ja ohjelmistosuunnittelu (rakenteen rakentaminen paperille vastaamaan näitä tarpeita) on vaihe, jossa kalleimmat virheet estetään ennen koodin kirjoittamista. Tässä osiossa opimme käyttämään tekoälyä "ajattelukumppanina" tässä vaiheessa: kumppanina, joka selvittää epävarmuutta, selvittää vaihtoehdot, mutta jättää lopullisen päätöksen sinulle.
AI tuottaa kaksi suurta arvoa täällä. Ensinnäkin se kysyy kysymyksiä, jotka ohitat; Se tuo pintaan piilotetut oletukset ja reunatapaukset pyynnössä. Toiseksi se taulukoi nopeasti suunnittelupäätöksen edut ja haitat. Mutta se on vaara: tekoäly antaa yleisiä suosituksia "parhaana käytäntönä" tietämättä täysin kontekstiasi (budjetti, tiimi, olemassa oleva järjestelmä, oikeudellinen rajoitus). Sinun tehtäväsi on suodattaa tämä neuvo omaa totuuttasi vastaan.
Käsitteet: Käyttäjätarina: Lyhyt lause, joka ilmaisee tarpeen muodossa "... kuten, haluan pystyä... koska...". Hyväksymiskriteerit: Testattavissa olevat ehdot, jotka on täytettävä, jotta työtä voidaan pitää "tehtynä". Ei-toiminnallinen vaatimus: Vaatimukset, jotka liittyvät "miten se käyttäytyy" eikä "mitä se tekee", kuten nopeus, turvallisuus, skaalautuvuus.
Epämääräisestä pyynnöstä testattavaan vaatimukseen
Hyvä vaatimus on mitattavissa ja todennettavissa. Ei "anna järjestelmän olla nopea", vaan "anna hakutulosten palata 500 ms:n sisällä". Tässä on vaiheittainen tapa käyttää tekoälyä epävarmuuden kaventamiseksi:
- Anna pyyntö sellaisenaan ja luo kysymys. Älä pyydä tekoälyltä ratkaisua, vaan ensin "lisää kaikki epäselvät tähän pyyntöön kysymykseksi".
- Annat vastaukset. Vain sinä tiedät kontekstin; Vastaa tekoälyn kysymyksiin todellisilla liiketoimintarajoitteillasi.
- Pyydä se kääntämään käyttäjien tarinoiksi ja hyväksymiskriteereiksi. Käännä selvitetty tarve testattaviksi kohteiksi.
- Lisää reunatapauksia ja negatiivisia skenaarioita. "Tyhjä tulos", "luvaton käyttäjä", "liian suuri tiedosto" jne.
Epäselvyyden purkamiskehote: "Muunnamme seuraavan liiketoimintapyynnön ohjelmistovaatimukseksi. Älä ehdota vielä ratkaisua. Poimi ensin KAIKKI epäselvyydet ja piilotetut oletukset, joihin ei vastata tässä pyynnössä kysymysluettelona. Ryhmittele kysymykset seuraavien otsikoiden alle: laajuus, käyttäjä/valtuutettu, datamäärä, suorituskyky, virheolosuhteet, turvallisuus. Raportoi käyttäjien tilaus:"
Käyttäjätarina + hyväksymiskriteerit kehote: "Jaa seuraava selvitetty tarve käyttäjätarinoihin, jotka noudattavat INVEST-periaatteita. Kirjoita kullekin tarinalle 3-5 testattavaa hyväksymiskriteeriä (Tietetty-Milloin-muodossa). Lisää vähintään 2 negatiivista skenaariota (luvaton käyttö, tyhjät tiedot). Tarve: [kirjoita selvitetty tarve tähän]"
Suunnittelupäätösten vertailu tekoälyyn
Muotoilu on jatkuva kompromissi: nopeus vs. joustavuus, yksinkertaisuus vs. skaalautuvuus? Tekoäly laittaa nämä kompromissit nopeaan laskentataulukkoon. Esimerkiksi "lähetä ilmoitus" -ominaisuuden osalta voit keskustella siitä, haluatko käyttää synkronista (lähetä pyynnöstä) vai asynkronista (jono, lähetys taustalla) lähestymistapaa.
Suunnittelun vertailukehote: "Suunnittelen "lähetä sähköposti-ilmoitus käyttäjälle" -ominaisuutta. Vertaa kahta lähestymistapaa: (A) synkroninen toimitus HTTP-pyynnön aikana, (B) asynkroninen toimitus taustalla asettamalla se viestijonoon. Tee taulukko seuraavista akseleista: käyttäjän odotusaika, vikasietoisuus, monimutkaisuus, yhden lauseen vähentäminen, mikä olisi vaikeutta2. loppujen lopuksi älä tee päätöstä puolestani."
akseli
synkroninen lähetys
Asynkroninen (jono)
Käyttäjän odotusaika
Pitkä (odottaa lähetystä)
Lyhyt (palaa heti)
Vikasietokyky
Matala (pyyntö räjähtää, jos lähetys räjähtää)
Korkea (yritä uudelleen)
monimutkaisuus
alhainen
Keskikorkea (jonoinfrastruktuuri)
Infrastruktuurikustannukset
alhainen
Tarvitaan lisäkomponentteja
Mihin se sopii
Pieni äänenvoimakkuus, yksinkertainen sovellus
Suuri määrä, kriittinen toimitus
Vinkki: Tekoälylle kertominen "älä tee päätöstä puolestani, vaan näytä minulle vaihtoehdot ja ehdot" pakottaa sinut ajattelemaan ja vähentää riskiä hyväksyä ehdotus sokeasti. Paras suunnittelupäätös on asia, jonka tekee kontekstisi tunteva henkilö (sinä).
Heikko kehote / Vahva kehote
HEIKKO: "Suunnittele tietokanta tilausjärjestelmää varten." (Tulos: mikä mittakaava, mitkä suhteet, mitkä rajoitukset eivät ole selkeitä; yleinen, epärealistinen kaava.) VAHVA: "Ehdota tietomallin luonnosta pienelle verkkokaupalle. Entiteetit: Asiakas, tilaus, tuote, tilausnimike. Rajoitukset: tilauksessa voi olla useita tuotteita; tuotteen hinta voi muuttua ajan myötä, mutta nykyinen tilaushinta tulee säilyttää. ja miksi "Selitä, että teit päätöksen. Määritä, kuinka ratkaisit hintahistorian ongelman. Anna se entiteettien ja kenttien luettelona, ei koodina."
Ero voimakkaan kehotteen; mittakaava (500 tilausta päivässä), liiketoimintasääntö (aikaisempi hinta on säilytettävä) ja haluttu tulostusmuoto. Yksi lause, kuten "Aiempi hinta on säilytettävä", muuttaa suunnittelun kokonaan; Jos et määritä tätä, tekoäly tuottaa epätarkan mutta uskottavalta näyttävän kaavion.
Mini Kotelot
Tapaus 1 – Piilotettu oletus. Tiimi koodaa suoraan "käyttäjä voi ladata profiilikuvan" -pyynnön. Toinen tiimi kysyi tekoälyltä epävarmuudesta: "enimmäiskoko? sallitut muodot? sopimaton sisällönhallinta? poistaa vanha valokuva?" Se tuottaa 8 kysymystä kuten. Ensimmäinen tiimi saa tiedon ongelmasta tuotannossa, kun palvelin täyttää 20 Mt:n tiedostot; Toinen tiimi ratkaisee sen suunnittelussa.
Tapaus 2 – Väärä asteikko-oletus. AI ehdottaa monimutkaista välimuistikerrosta raportointiominaisuutta varten. Kun insinööri huomauttaa, että todellinen data on vain 30 raporttia päivässä, tekoäly yksinkertaistaa ehdotusta. Asteikon määrittämättä jättäminen aiheuttaa tarpeettoman monimutkaisuuden kustannuksia; määrittäminen säästää 2 viikkoa turhasta työstä.
Tapaus 3 – Hyväksymiskriteerien puute. "Mitä tapahtuu, jos maksu epäonnistuu?" Koska kysymystä ei koskaan kysytty, tilausjärjestelmä merkitsee silti tilauksen "vahvistetuksi", jos maksu epäonnistuu. Tekoälyn luoma negatiivisten skenaarioiden luettelo kaappaa tämän aukon; 1 rivin hyväksymiskriteeri estää oikean rahan menetyksen.
Yleisiä virheitä
- Pyynnön välittäminen suoraan koodiin. Ennen kuin epäselvyys on ratkaistu, kirjoitettu koodi ratkaisee nopeasti väärän ongelman.
- Sokeasti omaksumalla tekoälyn yleiset "parhaat käytännöt". Jos et määritä kontekstiasi (mittakaava, budjetti, tiimi), suositus ei toimi sinulle.
- Ei-toiminnallisten vaatimusten ohittaminen. Jos nopeutta, turvallisuutta ja mittakaavaa ei ole määritelty, suunnittelu on epätäydellinen.
- Ajattele vain onnellista skenaariota. Negatiiviset skenaariot, kuten tyhjät tiedot, luvaton käyttäjä, virhetila, tulisi sisällyttää suunnitteluun.
- Päätöksen delegointi tekoälylle. AI luo vaihtoehtoja; Sinä päätät, mikä kompromissi sopii yrityksellesi.
Yhteenvetona
Vaatimusanalyysi ja suunnittelu on vaihe, jossa halvimmat virheet havaitaan. Täällä tekoäly luo kysymyksiä, jotka paljastavat epävarmuuden, laatii käyttäjien tarinoita ja hyväksymiskriteerejä sekä kartoittaa suunnittelun kompromisseja. Mutta vain sinä tiedät kontekstin; Sinun tehtäväsi on suodattaa tekoälyn suositukset mittakaavan, budjettisi, tiimisi ja oikeudellisten rajoitusten perusteella ja tehdä lopullinen päätös. Kuri "älä tee päätöstä puolestani, näytä minulle vaihtoehdot" johtaa sekä parempaan suunnitteluun että syvempään oppimiseen.
Sovellustehtävä
Valitse kontekstistasi yhden lauseen työpyyntö. Käytä ensin monitulkintakehotetta tekoälyyn ja vastaa kysymyksiin todellisilla rajoitteillasi. Käännä sitten selvitetty tarve vähintään kahdeksi käyttäjäkertomukseksi ja kullekin kolmeksi hyväksymiskriteeriksi; Sisällytä vähintään yksi negatiivinen skenaario. Luo lopuksi vertailutaulukko suunnittelupäätökselle (synkroninen/asynkroninen, taulukkorakenne jne.) ja kirjoita oma päätöksesi kahdella lauseella.
tarkistuslista
- [ ] Poistin epäselvyydet kysymyksinä ennen pyynnön välittämistä koodiin.
- [ ] Annoin tekoälylle kontekstin (mittakaava, auktoriteetti, suorituskyky, oikeudellinen rajoitus).
- [ ] Jakoin käyttäjätarinat testattaviksi hyväksymiskriteereiksi.
- [ ] Lisäsin ainakin yhden haittapuolen/edun skenaarion.
- [ ] Arvioin suunnittelupäätöksen kompromissitaulukon avulla.
- [ ] Tein lopullisen päätöksen kontekstini perusteella, en jättänyt sitä tekoälylle.