Kā mēs īstenojam prasību analīzi?

Kā izskatās plānošanas process?

Prasību analīze tiek iekļauta plānošanas procesā, kam savukārt jābūt šādam:

1. A projekts vīzija, kas apraksta galīgo produkts jāveido.
2. Vispārējs rīcības plāns vai ideja, kurā izklāstīts, kas jādara, lai sasniegtu mūsu mērķus.
3. Pamatuzdevumu saraksts, kas nosaka projekta darba posmus.
4. Laika plānošana, kurā mēs nosakām, kas un kad ir jāizpilda.
5. Trešajā posmā izveidoto individuālo uzdevumu detalizēta plānošana.

Prasību analīze aptver plānošanas procesa pirmos trīs punktus.

Projekta vīzija

Šajā posmā mums vajadzētu uzdot sev dažus pamatjautājumus:

1. Ko mēs vēlamies darīt?

Protams, šajā brīdī mēs jau apzināmies, uz ko tiecamies, un projekta ideja jau sen ir iesniegta un pārdomāta, taču ir vērts par to padomāt dziļāk. Iespējams, mēs atklāsim jaunus jautājumus, kurus ir vērts izskaidrot. Šeit varētu noderēt šādi jautājumi:

• Kāda problēma būtu jārisina šim projektam?
• Kas būs tā galalietotājs?
• Vai mēs radām saskarni lietotājiem? Vai tās izveide ir plānota nākotnē? Vai ir noteikts, kāda veida saskarni mēs radīsim (datora vai mobilo ierīču)? Vai mums rūp RWD?
• Vai ir kādi līdzīgi lietojumi? Kādi ir to plusi un mīnusi?
• Vai par projektu jau ir izveidoti sākotnējie dizaini vai makets?
• Vai projekts būs atkarīgs no kādām ārējām lietojumprogrammām? Vai tām ir vai mēs zinām to ierobežojumus?
• Vai mēs zinām kaut ko par gaidāmo veiktspēju un drošības līmeni?

2. Kādas ir prasības?

Tagad ir pienācis laiks izveidot projektam noteikto prasību sarakstu. Papildus funkcionālajām prasībām mēs norādām arī tās, kas nav saistītas ar funkcionalitāti: lietojamību, atsaucību, ātrumu, veiktspēju un drošību.

Ļaujiet mums pārbaudiet, vai katra no prasībām atbilst šādiem kritērijiem:

• ir pabeigta - mums ir tās pilnīgs attēls,
• ir pareiza - patiesa un gaidīta,
• ir iespējama - iespējama un citas prasības to nenoliedz,
• ir nepieciešams - tas ir nepieciešams sistēmas darbībai vai to pieprasa klients,
• ir nepārprotama - salasāma un nav iespējams to nepareizi interpretēt,
• ir pārbaudāma - pēc ieviešanas, veicot novērošanu un testēšanu, ir iespējams noteikt, vai šī prasība ir vai nav izpildīta.

3. Kāds ir galīgais mērķis?

Šeit ir vērts izveidot vienkāršu projekta darbības vizualizāciju. Nekas nepalīdz pilnībā izprast projekta ideju tā, kā uzzīmēt pamata plūsmu vai vienkārši uz tāfeles punktos uzrakstīt, kas notiks pēc kārtas. Gadījumā, ja tiek izstrādāta lietojumprogramma ar lietotāja saskarni, ideālā situācijā ir pat visvienkāršākie maketējumi.

4. Kādas ir prioritātes?

Līdzīgi kā būvējot māju, arī IT projekti ir jāsāk no nulles un pēc tam jāpievēršas tam, kas jums visvairāk nepieciešams. Tāpēc sākumā, pamatojoties uz prasību sarakstu, ir jāprecizē visu iespējamo funkciju saraksts, ko konkrētais projekts veiks, un pēc tam jāvienojas par to, kurām no tām ir visaugstākā prioritāte un tās ir jāveic pēc iespējas ātrāk, un kuras ir “jaukās”.

Visa projekta vizualizācijas posma rezultātam jābūt vispārējam priekšstatam par to, kā projektam vajadzētu darboties, izmantojot maketus vai iezīmētu darbību plūsmu. Mums būtu jāsaņem arī saraksts ar visām iespējamajām funkcijām, kas konkrētajam projektam ir jāpilda, kā arī jāzina, kāda prioritāte ir katrai no tām.

Projekta vizualizācija ir būtisks brīdis prasību analīzes laikā. Tā palīdz pilnībā izprast problēmas būtību, un, jo labāk problēmu ilustrējošie materiāli, jo efektīvāki ir nākamie plānošanas posmi.

Rīcības plāns

Šajā posmā mēs jau nosakām, kā mēs iedomājamies projekta darbību kopumā. Ir labi, ja ir dažas idejas, kā tās īstenot, pārdomāt un apspriest katru no tām, kā arī izcelt to vājās un stiprās puses. Šeit ir vērts arī detalizēti ieskicēt kādu izvēlēto ideju, ja ne visas.

Šajā posmā ir laiks apsvērt arī tīri tehnoloģiskus jautājumus, ne tikai to, kādā valodā vai ietvarstruktūrā tiks rakstīts projekts, bet arī to, kādi papildu rīki mums būs nepieciešami, piemēram, vai mēs nolemjam izmantot AWS kaudze vai varbūt kaut kas cits. Ja svārstāmies starp dažām tehnoloģijām vai nezinām, ko izmantot, tad ir vērts šādu lēmumu laikus pārcelt un deleģēt pētniecības uzdevumam. Protams, to varam darīt tikai tad, ja turpmākā plānošana netiek bloķēta ar šādu izpēti. Pretējā gadījumā mēs tos droši varam piesaistīt uzdevumiem, kas ir sprint.

Galvenie uzdevumi

Kad esam izstrādājuši projekta plānu, mēs turpinām definēt galvenos uzdevumus, kurus pēc tam detalizēti apspriedīsim un sadalīsim sīkākos uzdevumos. izstrādes komanda plānojot jaunu sprintu. Ir svarīgi pēc iespējas precīzāk aprakstīt katru uzdevumu.

Kopsavilkums

Kā minēts iepriekš, prasību analīzes process var atšķirties atkarībā no projekta sarežģītības. Ir vieglākas un sarežģītākas problēmas, ir arī tādas, kuras jau kāds ir atrisinājis, un ir pilnīgi jaunas, pie kurām ir nepieciešams ilgāk apstāties. Neatkarīgi no tā ir daži svarīgi padomi, kas jāpatur prātā:

• Saziņa. Tas ir vissvarīgākais katra projekta dzīves cikla komponents; viss ir skaidri jādefinē un jāizskaidro.
• Ātri izprotiet problēmu. Ir lieliski, ka ir uzrakstīta projekta dokumentācija, bet atcerēsimies, ka tā ir pēc iespējas kodolīgāka un neaizņem tūkstoš lappušu. Katrs izstrādes dalībnieks komanda jābūt piekļuvei un jāspēj ātri izprast projekta vīziju.
• Vienkāršība ir svarīgāka par visu. Centīsimies, lai tas, ko plānojam, būtu pēc iespējas vienkāršāks, izvēlēsimies vienkāršākus risinājumus, kurus nākotnē var viegli attīstīt, vai arī atteikties no tiem, kad radīsies nepieciešamība.
• Jums tas nebūs nepieciešams. Ņemot vērā, ka programmēšanā mēs vadāmies pēc YAGNI principa, šeit mums tas ir aizmugurē, un mēs pārāk daudz neakcelerējam.
• Izmaiņas. Nebaidīsimies no tām; agri vai vēlu tās ir nepieciešamas katrā projektā. Turklāt nemānīsim sevi, ka tas, ko plānojam šodien, darbosies mūžīgi. Tajā pašā laikā neuzskatīsim pārmaiņas par kaut ko sliktu un nevēlamu. Izmaiņām jābūt sinonīmam ar uzlabojumiem, un tieši to mēs arī vēlamies - lai projekts būtu vislabākais.
• Laiks. Neļausim, lai plānošana ieilgtu un ievilktos mūžīgi. Ja mums ir problēma, kas mūs bloķē, tad meklēsim risinājumus ārpusē vai izvēlēsimies vieglāko variantu.

Iepriekš minētos aspektus vienmēr ir vērts atcerēties, analizējot prasības, un tad tas noritēs raiti un būs labi plānota projekta pamatā.

Lasīt vairāk:

• Kāda ir labākā projektu vadības pieeja programmatūras izstrādē?
• Codest labā prakse programmatūras veidošanā. Mūsu pieeja klientu ceļojumam
• Īss ceļvedis, kā izveidot un attīstīt savu tirdzniecības vietu. Ko ir vērts zināt?