Ch3. Agile SW Dev.pptx

3-bob - Dasturiy ta'minotni ishlab chiqish
Chapter 3 Agile Software Development 1
30/10/2014

Reja
 Agile usullar
 Agile ishlab chiqish texnikasi
 Agile loyihasini boshqarish
 Masshtabni tezkor usullari
30/10/2014

Dasturiy ta'minotni tezkor ishlab chiqish

Tez rivojlanish va etkazib berish, ko'pincha dasturiy
ta'minot tizimlari uchun eng muhim talabdir
 Korxonalar tez o'zgaradigan talablar sharoitida ishlaydi va dasturiy
ta'minotga barqaror talablar to'plamini ishlab chiqarish deyarli
mumkin emas
 Dastur o'zgaruvchan biznes ehtiyojlarini aks ettirish uchun tezda
rivojlanishi kerak.
 Rejaga asoslangan ishlab chiqish ba'zi turdagi tizimlar
uchun zarur, ammo bu biznes ehtiyojlariga javob
bermaydi.
 Chaqqon rivojlanish usullari 1990-yillarning oxirida paydo
bo'lgan, uning maqsadi dasturiy ta'minot tizimlarini etkazib
berish vaqtini tubdan qisqartirish edi
30/10/2014

Chaqqon rivojlanish
 Dastur spetsifikatsiyasi, dizayni va amalga oshirilishi
o'zaro bog'liq
 Tizim versiyalarni aniqlash yoki baholashda ishtirok
etadigan tomonlar bilan birgalikda bir qator versiyalar
yoki qo'shimchalar sifatida ishlab chiqilgan
 Baholash uchun yangi versiyalarni tez-tez etkazib berish
 Rivojlanishni qo'llab-quvvatlash uchun keng vositalarni
qo'llab-quvvatlash (masalan, avtomatlashtirilgan sinov
vositalari).
 Minimal hujjatlar - ish kodiga e'tibor qarating
30/10/2014

Rejaga asoslangan va chaqqon rivojlanish
30/10/2014

Rejaga asoslangan va chaqqon rivojlanish
 Reja asosida rivojlanish
 Dasturiy ta'minot muhandisligiga reja asosida yondashish har bir
bosqichda oldindan ishlab chiqilishi kerak bo'lgan natijalar bilan
alohida rivojlanish bosqichlariga asoslanadi.
 Sharshara shart emas - rejaga asoslangan, bosqichma-bosqich
rivojlanish mumkin
 Iteratsiya harakatlar davomida sodir bo'ladi.
 Chaqqon rivojlanish
 Texnik spetsifikatsiya, loyihalash, amalga oshirish va sinovdan
o'tkazish bir-biridan ajralib turadi va dasturiy ta'minotni ishlab
chiqish jarayonida muzokaralar jarayonida ishlab chiqish
jarayonining natijalari aniqlanadi.
30/10/2014

Tezkor usullar
30/10/2014

Agile methods
 Dissatisfaction with the overheads involved in software
design methods of the 1980s and 1990s led to the
creation of agile methods. These methods:
 Focus on the code rather than the design
 Are based on an iterative approach to software development
 Are intended to deliver working software quickly and evolve this
quickly to meet changing requirements.
 The aim of agile methods is to reduce overheads in the
software process (e.g. by limiting documentation) and to
be able to respond quickly to changing requirements
without excessive rework.
30/10/2014

Agile manifesti
 Biz dasturiy ta'minotni ishlab chiqish va boshqalarga bu
orqali yordam berish orqali yanada yaxshi usullarni kashf
etmoqdamiz. Ushbu ish orqali biz qadrlaymiz:
 Shaxslar va jarayonlar va vositalar bilan o'zaro aloqalar Keng
qamrovli hujjatlar ustida ishlaydigan dasturiy ta'minot Shartnoma
bo'yicha muzokaralar jarayonida mijozlar bilan hamkorlik qilish
Rejaga muvofiq o'zgarishga javob
 Ya'ni, o'ng tomonda qiymatlar mavjud bo'lsa, chap
tomonda biz ko'proq narsalarni qadrlaymiz
30/10/2014

Chaqqon usullarning asoslari
Principle Description
Mijozlarni jalb qilish Customers should be closely involved throughout the
development process. Their role is provide and prioritize new
system requirements and to evaluate the iterations of the
system.
Kuchli etkazib berish The software is developed in increments with the customer
specifying the requirements to be included in each increment.
Odamlar ishlamaydi The skills of the development team should be recognized and
exploited. Team members should be left to develop their own
ways of working without prescriptive processes.
O'zgarish Expect the system requirements to change and so design the
system to accommodate these changes.
Oddiylikni saqlang Focus on simplicity in both the software being developed and
in the development process. Wherever possible, actively work
to eliminate complexity from the system.
30/10/2014

Agile usulining qo'llanishi
 Dasturiy ta'minot kompaniyasi sotadigan kichik yoki o'rta
mahsulotni ishlab chiqaradigan joyda mahsulotni ishlab
chiqish.
 Deyarli barcha dasturiy mahsulotlar va dasturlar endi tezkor
yondoshuv asosida ishlab chiqilgan
 Buyurtmachining ishlab chiqish jarayonida ishtirok etish
bo'yicha aniq majburiyati bo'lgan va dasturiy ta'minotga
ta'sir ko'rsatadigan tashqi qoidalar va qoidalar kam
bo'lgan tashkilot ichida maxsus tizimni ishlab chiqish.
30/10/2014

Agile development techniques
30/10/2014

Ekstremal dasturlash
 90-yillarning oxirlarida ishlab chiqilgan juda ta'sirchan
chaqqonlik usuli, chaqqon rivojlanish usullarini bir
qatorini kiritdi.
 Ekstremal dasturlash (XP) iterativ rivojlanish uchun
"ekstremal" yondashuvni talab qiladi.
 Yangi versiyalar kuniga bir necha marta qurilishi mumkin;
 O'sish har ikki haftada xaridorlarga etkaziladi;
 Barcha testlar har bir tuzilish uchun bajarilishi kerak va agar test
muvaffaqiyatli bajarilgan bo'lsa qabul qilinadi.
30/10/2014

Ekstremal dasturlashning aylanishi
30/10/2014

Ekstremal dasturlash amaliyotlari (a)
Principle or practice Description
Incremental planning Requirements are recorded on story cards and the stories to be
included in a release are determined by the time available and
their relative priority. The developers break these stories into
development ‘Tasks’. See Figures 3.5 and 3.6.
Small releases The minimal useful set of functionality that provides business
value is developed first. Releases of the system are frequent
and incrementally add functionality to the first release.
Simple design Enough design is carried out to meet the current requirements
and no more.
Test-first development An automated unit test framework is used to write tests for a
new piece of functionality before that functionality itself is
implemented.
Refactoring All developers are expected to refactor the code continuously as
soon as possible code improvements are found. This keeps the
code simple and maintainable.
30/10/2014

Ekstremal dasturlash amaliyoti (b)
)
Pair programming Developers work in pairs, checking each other’s work and
providing the support to always do a good job.
Collective ownership The pairs of developers work on all areas of the system, so that
no islands of expertise develop and all the developers take
responsibility for all of the code. Anyone can change anything.
Continuous integration As soon as the work on a task is complete, it is integrated into
the whole system. After any such integration, all the unit tests in
the system must pass.
Sustainable pace Large amounts of overtime are not considered acceptable as
the net effect is often to reduce code quality and medium term
productivity
On-site customer A representative of the end-user of the system (the customer)
should be available full time for the use of the XP team. In an
extreme programming process, the customer is a member of
the development team and is responsible for bringing system
requirements to the team for implementation.
30/10/2014

XP va chaqqon tamoyillar
 Incremental development is supported through small,
frequent system releases.
 Customer involvement means full-time customer
engagement with the team.
 People not process through pair programming, collective
ownership and a process that avoids long working hours.
 Change supported through regular system releases.
 Maintaining simplicity through constant refactoring of
code.
30/10/2014

Ta'sirli XP amaliyotlari
 Ekstremal dasturlash texnik yo'nalishga ega va ko'pgina
tashkilotlarda boshqaruv amaliyotiga qo'shilish oson
emas.
 Shunday qilib, tezkor XP amaliyotidan foydalangan
holda, dastlab aniqlangan usul keng qo'llanilmaydi.
 Asosiy amaliyotlar
 Spetsifikatsiya uchun foydalanuvchi hikoyalari
 Qayta ishlab chiqarish
 Sinov-birinchi ishlanma
 Pair dasturlash
30/10/2014

Talablar uchun foydalanuvchi hikoyalari
 XP-da, mijoz yoki foydalanuvchi XP jamoasining bir
qismi bo'lib, talablar bo'yicha qaror qabul qilish uchun
javobgardir.
 Foydalanuvchi talablari foydalanuvchi hikoyalari yoki
stsenariylari sifatida ifodalanadi.
 Bular kartochkalarga yozilgan va ishlab chiquvchi guruh
ularni amalga oshirish vazifalariga ajratadi. Ushbu
vazifalar jadval va xarajatlar smetasining asosidir.
 Xaridor o'zlarining ustuvorliklari va jadval jadvalidan kelib
chiqib, keyingi nashrlarga kiritish uchun hikoyalarni
tanlaydi.
30/10/2014

"Dori-darmonlarni buyurish" hikoyasi
30/10/2014

Dori-darmonlarni buyurish uchun topshiriq
kartalari namunalari
30/10/2014

Qayta ishlab chiqarish
 Dasturiy ta'minot muhandisligining odatiy donoligi
o'zgarishlarni loyihalashdir. O'zgarishlarni kutish uchun
vaqt va kuch sarflash kerak, chunki bu keyinchalik hayot
aylanishida xarajatlarni kamaytiradi.
 Ammo XP, bu ahamiyatsiz deb ta'kidlaydi, chunki
o'zgarishlarni oldindan aytib bo'lmaydi.
 Aksincha, ularni amalga oshirish kerak bo'lganda
o'zgartirishni osonlashtirish uchun kodni doimiy ravishda
takomillashtirish (refaktoring) taklif etiladi.
30/10/2014

Qayta ishlab chiqarishga misollar
 Kod nusxasini olib tashlash uchun sinf ierarxiyasini qayta
tashkil etish.
 Tushunishni osonlashtirish uchun atributlar va usullarni
tozalash va nomini o'zgartirish.
 Inline kodni qo'ng'iroqlar bilan dasturlar kutubxonasiga
kiritilgan usullarga almashtirish
30/10/2014

Sinov-birinchi ishlanma
 Sinov XP uchun asosiy hisoblanadi va XP har qanday
o'zgartirish kiritilgandan so'ng dastur sinovdan
o'tkaziladigan yondashuvni ishlab chiqdi.
 XP sinov xususiyatlari:
 Sinov-birinchi ishlanma.
 Stsenariylardan testlarni ko'paytirish.
 Foydalanuvchilarning testlarni ishlab chiqish va tekshirishda
ishtiroki.
 Avtomatik sinov bog'lamalari har bir yangi versiya paydo
bo'lganda har bir komponent sinovlarini o'tkazish uchun
ishlatiladi.
30/10/2014

Sinov asosida ishlab chiqish
 Kodni oldin testlarni yozish, amalga oshiriladigan
talablarni aniqlaydi.
 Testlar ma'lumot sifatida emas, balki dastur sifatida
yoziladi, shunda ular avtomatik ravishda bajarilishi
mumkin. Sinov uning to'g'ri bajarilganligini tekshirishni
o'z ichiga oladi.
 Odatda Junit kabi sinov tizimiga tayanadi.
 Oldingi va yangi testlarning barchasi yangi funksiya
qo'shilganda avtomatik ravishda ishga tushiriladi, shu
bilan yangi funktsionallikda xatolar yuzaga
kelmaganligini tekshirish
30/10/2014

Mijozlarni jalb qilish
 Mijozning sinov jarayonida roli - tizimning keyingi
chiqarilishida amalga oshirilishi kerak bo'lgan voqealarni
qabul qilish testlarini ishlab chiqishda yordam berish.
 Jamoaning bir qismi bo'lgan mijoz, rivojlanish davom
etar ekan, testlarni yozadi. Shuning uchun barcha yangi
kod mijozning ehtiyojlariga mos kelishini tekshirish uchun
tasdiqlangan.
 Biroq, mijozlar rolini qabul qiladigan odamlar cheklangan
vaqtga ega va shuning uchun ishlab chiqish guruhi bilan
to'liq ishlay olmaydi. Ular talablarni ta'minlash etarli
miqdordagi hissa qo'shgan deb hisoblashadi va shuning
uchun test jarayonida qatnashishni istamasliklari mumkin
30/10/2014

Dozani tekshirish uchun sinov holatining tavsifi
30/10/2014

Sinovlarni avtomatlashtirish
 Sinovlarni avtomatlashtirish testlar vazifa bajarilishidan
oldin bajariladigan komponentlar sifatida yozilishini
anglatadi
 Ushbu test komponentlari bir-biridan mustaqil bo'lishi kerak,
tekshirilayotgan ma'lumotlarning taqsimlanishini taqlid qilishi va
natijaning chiqish spetsifikatsiyasiga mos kelishini tekshirish
kerak. Avtomatlashtirilgan sinov doirasi (masalan, Junit) bu
bajariladigan testlarni yozishni va testlar to'plamini topshirishni
osonlashtiradigan tizim.
 Sinov avtomatlashtirilganligi sababli, har doim tez va
oson bajarilishi mumkin bo'lgan testlar to'plami mavjud
 Tizimga biron bir funktsionallik qo'shilganda, sinovlarni o'tkazish
mumkin va yangi kod kiritgan muammolar darhol hal qilinishi
mumkin Chapter 3 Agile Software Development 29
30/10/2014

Test-birinchi ishlab chiqish bilan bog'liq
muammolar
 Dasturchilar testlashdan ko'ra dasturlashni afzal
ko'rishadi va ba'zida testlarni yozishda qisqartirilgan
fikrlarni olishadi. Masalan, ular yuzaga kelishi mumkin
bo'lgan barcha istisnolarni tekshirmaydigan to'liq
bo'lmagan testlarni yozishlari mumkin.
 Ba'zi testlarni bosqichma-bosqich yozish juda qiyin
bo'lishi mumkin. Masalan, murakkab foydalanuvchi
interfeysida, ko'pincha "displey mantig'i" va ekranlar
o'rtasidagi ish oqimini amalga oshiruvchi kod uchun birlik
testlarini yozish qiyin.
 Sinovlar to'plamining to'liqligini baholash qiyin. Garchi
sizda juda ko'p tizim sinovlari mavjud bo'lsa ham, sizning
test to'plamingiz to'liq qamrovni bermasligi mumkin.
30/10/2014

Pair dasturlash
 Pair dasturlash, kodni birgalikda ishlab chiqishda juft
bo'lib ishlaydigan dasturchilarni o'z ichiga oladi.
 Bu kodga umumiy egalikni rivojlantirishga yordam beradi
va bilimlarni butun jamoaga tarqatadi.
 Bu norasmiy ko'rib chiqish jarayoni bo'lib xizmat qiladi,
chunki kodlarning har bir qatoriga birdan ortiq kishi
qaraydi.
 Bu tizimni qayta ishlab chiqishni rag'batlantiradi, chunki
butun jamoa tizim kodini takomillashtirishdan foyda
ko'rishi mumkin
30/10/2014

Pair dasturlash
 Ikkala dasturlashda, dasturchilar dasturni ishlab chiqish
uchun bitta kompyuterda birga o'tirishadi.
 Juftliklar dinamik ravishda yaratilgan bo'lib, barcha guruh
a'zolari rivojlanish jarayonida bir-biri bilan ishlashadi.
 Juft dasturlash paytida sodir bo'ladigan bilimlarni
almashish juda muhimdir, chunki u jamoa a'zolari chiqib
ketganda loyiha uchun umumiy xavflarni kamaytiradi.
 Juftlikni dasturlash har doim ham samarasiz emas va
birgalikda ishlaydigan juftlik alohida ishlaydigan 2 ta
dasturchidan ko'ra samaraliroq ekanligi to'g'risida dalillar
mavjud
 . Chapter 3 Agile Software Development 32
30/10/2014

Agile project management
30/10/2014

Agile loyihasini boshqarish
 Dasturiy ta'minot loyihalari menejerlarining asosiy
majburiyati dasturni o'z vaqtida va loyiha uchun
rejalashtirilgan byudjet doirasida etkazib berish uchun
boshqarishdir.
 Loyihani boshqarishda standart yondashuv rejaga
asoslangan. Menejerlar loyihaning nima uchun etkazib
berilishi, qachon etkazib berilishi va kim loyiha natijalarini
ishlab chiqish ustida ish olib borishini ko'rsatadigan reja
tuzadilar.
 Agile loyihasini boshqarish bosqichma-bosqich
rivojlanish va moslashuvchan usullarda qo'llaniladigan
boshqa yondashuvni talab qiladi
 .
30/10/2014

Skrum
 Skrum bu chaqqon usul bo'lib, u o'ziga xos epchil
amaliyotga emas, balki iterativ rivojlanishni boshqarishga
qaratilgan.
 Skrumda uchta bosqich mavjud.
 Dastlabki bosqich - bu rejaning umumiy bosqichi bo'lib, unda siz
loyihaning umumiy maqsadlarini belgilab, dasturiy ta'minot
arxitekturasini yaratasiz.
 Undan keyin bir qator sprint sikllari davom etadi, bunda har bir
tsikl tizimning o'sishini rivojlantiradi.
 Loyihani yakunlash bosqichi loyihani yakunlaydi, tizim yordami
va foydalanuvchi qo'llanmalari kabi kerakli hujjatlarni to'ldiradi va
loyihadan olingan saboqlarni baholaydi
 .

30/10/2014

Shikastlanish terminologiyasi (a)
Scrum term Definition
Development team A self-organizing group of software developers, which should be no more than
7 people. They are responsible for developing the software and other
essential project documents.
Potentially shippable
product increment
The software increment that is delivered from a sprint. The idea is that this
should be ‘potentially shippable’ which means that it is in a finished state and
no further work, such as testing, is needed to incorporate it into the final
product. In practice, this is not always achievable.
Product backlog This is a list of ‘to do’ items which the Scrum team must tackle. They may be
feature definitions for the software, software requirements, user stories or
descriptions of supplementary tasks that are needed, such as architecture
definition or user documentation.
Product owner An individual (or possibly a small group) whose job is to identify product
features or requirements, prioritize these for development and continuously
review the product backlog to ensure that the project continues to meet critical
business needs. The Product Owner can be a customer but might also be a
product manager in a software company or other stakeholder representative.
30/10/2014

Shikastlanish terminologiyasi (b)
Scrum term Definition
Scrum A daily meeting of the Scrum team that reviews progress and prioritizes
work to be done that day. Ideally, this should be a short face-to-face
meeting that includes the whole team.
ScrumMaster The ScrumMaster is responsible for ensuring that the Scrum process is
followed and guides the team in the effective use of Scrum. He or she is
responsible for interfacing with the rest of the company and for ensuring
that the Scrum team is not diverted by outside interference. The Scrum
developers are adamant that the ScrumMaster should not be thought of
as a project manager. Others, however, may not always find it easy to
see the difference.
Sprint A development iteration. Sprints are usually 2-4 weeks long.
Velocity An estimate of how much product backlog effort that a team can cover in
a single sprint. Understanding a team’s velocity helps them estimate
what can be covered in a sprint and provides a basis for measuring
improving performance.
30/10/2014

Skrum sprint aylanishi
30/10/2014

Scrum sprint aylanishi
 Sprintlar belgilangan uzunlikda, odatda 2-4 hafta.
 Rejalashtirish uchun boshlang'ich nuqta - bu loyihada
bajariladigan ishlarning ro'yxati bo'lgan mahsulotning
orqada qolishi.
 Tanlov bosqichida mijozlar bilan ish olib boradigan
barcha loyiha jamoasi qatnashadi, ular sprint paytida
ishlab chiqilishi kerak bo'lgan mahsulotning
xususiyatlaridan va funktsional imkoniyatlarini tanlash
uchun.

30/10/2014

Sprint aylanishi
 Bular kelishib olingandan so'ng, guruh dasturiy ta'minotni
ishlab chiqish uchun o'zlarini tashkil qiladi.
 Ushbu bosqichda jamoa mijoz va tashkilotdan ajratilgan,
barcha aloqa "Scrum master" deb nomlangan kanal
orqali amalga oshiriladi.
 Scrum masterining vazifasi rivojlanish guruhini tashqi
chalg'itishdan himoya qilishdir.
 Sprint oxirida bajarilgan ishlar ko'rib chiqilib, manfaatdor
tomonlarga taqdim etiladi. Keyingi sprint aylanishi
boshlanadi.
 .
30/10/2014

Skrumda jamoaviy ish
 'Scrum master' har kuni yig'ilishlarni tashkillashtiradigan,
bajarilayotgan ishlarning orqada qolishini kuzatib
boradigan, qarorlarni yozib qo'ygan, orqada qolib
ketayotganlarga qarshi choralarni ko'radigan va
jamoadan tashqarida mijozlar va rahbariyat bilan aloqa
o'rnatadigan vositachi.
 Jamoa qisqa kunlik yig'ilishlarda (Scrums) qatnashadi,
unda barcha guruh a'zolari ma'lumot almashadilar, oxirgi
uchrashuvdan beri erishilgan yutuqlar, yuzaga kelgan
muammolar va keyingi kunga nima rejalashtirilayotgani
tasvirlanadi.
30/10/2014

Skrumning foydalari
 Mahsulot boshqariladigan va tushunarli bo'laklarga
bo'linadi.
 Barqaror talablar taraqqiyotni ushlab turmaydi.
 Butun jamoada hamma narsa ko'rinib turadi, natijada
jamoaviy aloqa yaxshilanadi.
 Mijozlar buyurtmalarni o'z vaqtida etkazib berishlarini
ko'rishadi va mahsulot qanday ishlashi to'g'risida fikr
olishadi.
 Mijozlar va ishlab chiquvchilar o'rtasida ishonch
o'rnatiladi va har bir kishi loyihaning muvaffaqiyatli
bo'lishini kutadigan ijobiy madaniyat yaratiladi.
30/10/2014

Tarqalgan Skrum
30/10/2014

Shkalali usul
30/10/2014

Scaling agile methods
 Agile usullari kichik va o'rta loyihalar uchun
muvaffaqiyatli bo'lib chiqdi, ular kichik qo'shma jamoa
tomonidan ishlab chiqilishi mumkin.
 Ba'zida ushbu usullarning muvaffaqiyati hamma
birgalikda ishlayotganida mumkin bo'lgan aloqa
yaxshilanishi tufayli bo'ladi, deb ta'kidlashadi.
 Chaqqon usullarni qo'llash ko'lamini kattalashtirishni o'z
ichiga oladi, chunki ular turli xil joylarda ishlaydigan bir
nechta rivojlanish guruhlari mavjud bo'lgan loyihalarni
amalga oshirish uchun kerak bo'ladi.
30/10/2014

Kattalashtirish va kattalashtirish
 "Masshtabni kengaytirish" kichik guruh tomonidan ishlab
chiqilishi mumkin bo'lmagan yirik dasturiy ta'minot
tizimlarini ishlab chiqishda tezkor usullardan foydalanish
bilan bog'liq.
 "Masshtabni kengaytirish" ko'p yillik dasturiy ta'minotni
ishlab chiqish tajribasiga ega bo'lgan yirik tashkilotda
tezkor usullarni qanday joriy etish bilan bog'liq.
 Chaqqon usullarni qo'llanganda chaqqon asoslarni
saqlash juda muhimdir:
 Moslashuvchan rejalashtirish, tizimning tez-tez nashr etilishi,
uzluksiz integratsiya, sinov asosida ishlab chiqish va yaxshi
jamoaviy aloqa.
30/10/2014

Chaqqon usullar bilan amaliy muammolar
 Chaqqon rivojlanishning norasmiyligi yirik
kompaniyalarda keng qo'llaniladigan shartnomalarni
belgilashning huquqiy yondashuviga mos kelmaydi.
 Agile usullari dasturiy ta'minotga emas, balki yangi
dasturiy ta'minotni ishlab chiqishda ko'proq mos
keladi. Shunga qaramay, yirik kompaniyalarda dasturiy
ta'minot xarajatlarining asosiy qismi mavjud dasturiy
ta'minot tizimlarini saqlab turish bilan bog'liq.
 Chaqqon usullar kichik qo'shma jamoalar uchun
mo'ljallangan, ammo hozirda dasturiy ta'minotni ishlab
chiqish ko'p jihatdan dunyo bo'ylab tarqalgan jamoalarni
qamrab oladi.
30/10/2014

Shartnoma masalalari
 Maxsus tizimlar uchun dasturiy ta'minot
shartnomalarining aksariyati tizim ishlab chiqaruvchisi
tomonidan tizim mijozi uchun bajarilishi kerak bo'lgan
narsalarni belgilaydigan spetsifikatsiya asosida amalga
oshiriladi.
 Ammo, bu tezkor rivojlanish normasi bo'lganidek,
interleave spetsifikatsiya va rivojlanishni taqiqlaydi.
 Funktsionallikka emas, balki ishlab chiquvchiga vaqtni
to'laydigan shartnoma talab qilinadi.
 Ammo, bu mening ko'pgina yuridik idoralarim uchun katta xavf
hisoblanadi, chunki etkazib beriladigan narsalar kafolatlanmaydi.
30/10/2014

Chaqqon usullar va dasturiy ta'minot
 Aksariyat tashkilotlar yangi dasturiy ta'minotni ishlab
chiqishda emas, balki mavjud dasturiy ta'minotni
saqlashga ko'proq pul sarflashadi. Shunday qilib, agar
tezkor usullar muvaffaqiyatli bo'lsa, ular asl rivojlanish
bilan bir qatorda texnik xizmat ko'rsatishi kerak.
 Ikkita asosiy masala:
 Rasmiy hujjatlarni minimallashtirishga urg'u berilgan holda,
tezkor yondashuv yordamida ishlab chiqilgan tizimlar barqaror
bo'ladimi?
 Mijozlarni o'zgartirish haqidagi so'rovlarga javoban tezkor
usullardan tizimni rivojlantirish uchun samarali foydalanish
mumkinmi?
 Dastlabki ishlab chiqish guruhini qo'llab-quvvatlashning
iloji bo'lmasa, muammolar paydo bo'lishi mumkin.
30/10/2014

Chaqqon texnik xizmat
 Asosiy muammolar:
 Mahsulot hujjatlarining yo'qligi
 Mijozlarni rivojlantirish jarayonida ishtirok etish
 Rivojlanish guruhining uzluksizligini ta'minlash
 Chaqqon rivojlanish rivojlanish guruhiga nima qilish
kerakligini bilishga va tushunishga tayanadi.
 Uzoq umr ko'radigan tizimlar uchun bu haqiqiy muammo,
chunki original ishlab chiquvchilar har doim tizimda
ishlamaydi.
30/10/2014

Chaqqon va rejali usullar
 Ko'pgina loyihalar rejali va chaqqon jarayonlarning
elementlarini o'z ichiga oladi. Balans to'g'risida qaror
qabul qilish quyidagilarga bog'liq.
 Amalga oshirishdan oldin juda batafsil spetsifikatsiya va dizaynga
ega bo'lish muhimmi? Agar shunday bo'lsa, ehtimol siz rejaga
asoslangan yondashuvdan foydalanishingiz kerak.
 Siz dasturiy ta'minotni xaridorlarga etkazib beradigan va ulardan
tezkor aloqa olib boradigan qo'shimcha etkazib berish strategiyasi
haqiqatmi? Agar shunday bo'lsa, tezkor usullarni qo'llashga e'tibor
bering.
 Ishlab chiqilayotgan tizim qanchalik katta? Agile usullari
eng samarali hisoblanadi, agar tizim norasmiy ravishda
aloqa qila oladigan kichik guruh bilan tuzilgan bo'lsa. Katta
ishlab chiqish guruhlarini talab qiladigan katta tizimlar
30/10/2014

Chaqqon tamoyillar va tashkiliy amaliyot
Printsip Amaliyot
Mijozlarni jalb qilish
Bu ishlab chiquvchilar guruhi bilan vaqt o'tkazishga tayyor va qodir bo'lgan
va tizimning barcha tomonlarini ifoda etadigan mijozga ega bo'lishiga
bog'liq. Ko'pincha, mijozlar vakillari o'z vaqtlariga nisbatan boshqa
talablarga ega va dasturiy ta'minotni ishlab chiqishda to'liq ishtirok eta
olmaydilar.
Tartibga solish kabi tashqi manfaatdor tomonlar mavjud bo'lgan joylarda, o'z
fikrlarini chaqqon jamoaga etkazish qiyin.
O'zgarish
O'zgarishlarni ustuvorlik bilan belgilash juda qiyin bo'lishi mumkin, ayniqsa
tizimlar uchun manfaatdor tomonlar ko'p. Odatda, har bir manfaatdor tomon
turli xil o'zgarishlarga turli xil ustuvorliklar beradi.
Kuchli etkazib berish
Tez rivojlanish va qisqa muddatli rejalashtirish har doim ham biznesni
rejalashtirish va marketingni uzoq muddatli rejalashtirish davrlariga mos
kelavermaydi. Marketing menejerlari samarali marketing kampaniyasini
tayyorlash uchun bir necha oy oldin mahsulot qanday xususiyatlarga ega
ekanligini bilishlari kerak bo'lishi mumkin.
30/10/2014

Chaqqon tamoyillar va tashkiliy amaliyot
Printsip Amaliyot
Oddiylikni saqlang
Etkazib berish jadvalining bosimi ostida jamoa a'zolari kerakli tizimni
soddalashtirishni amalga oshirishga vaqtlari bo'lmasligi mumkin.
Odamlar ishlamaydi
Guruhning individual a'zolari jadal ishtirok etish uchun mos xususiyatlarga ega
bo'lmasliklari mumkin, shuning uchun boshqa guruh a'zolari bilan yaxshi
munosabatda bo'lmasliklari mumkin.
30/10/2014

Chaqqon va rejaga asoslangan omillar
30/10/2014

Tizim muammolari
 Tizim qay darajada ishlab chiqilmoqda?
 Agile usullari nisbatan samarasiz bo'lib, ular norasmiy ravishda
muloqot qila oladigan kichik guruhdir.
 Tizimning qaysi turi ishlab chiqilmoqda?
 Amalga oshirishdan oldin ko'p tahlilni talab qiladigan tizimlar ushbu
tahlilni o'tkazish uchun etarli darajada batafsil dizaynga muhtoj.
 Kutilayotgan tizimning ishlash muddati qanday?
 Uzoq umrga mo'ljallangan tizimlar tizimni ishlab chiquvchilarning
maqsadlarini qo'llab-quvvatlash guruhiga etkazish uchun hujjatlarni
talab qiladi.
 Tizim tashqi tartibga solinadimi?
 Agar tizim sozlangan bo'lsa, ehtimol sizga tizim xavfsizligi
holati bo'yicha batafsil hujjatlarni taqdim etish talab
30/10/2014

Odamlar va jamoalar
 Rivojlanish guruhida dizaynerlar va dasturchilar
qanchalik yaxshi?
 Ba'zan, dasturchilar batafsil dizaynni kodga tarjima qiladigan
rejali yondoshuvlarga qaraganda, chaqqon usullar yuqori
mahorat talab qiladi, deb ta'kidlashadi.
 Rivojlanish bo'yicha guruh qanday tashkil etilgan?
 Agar jamoaning obro'si tushib qolsa, dizayn hujjatlari talab
qilinishi mumkin.
 Qanday qo'llab-quvvatlash texnologiyalari mavjud?
 Vizualizatsiya va dasturni tahlil qilish uchun IDE-ni
qo'llab-quvvatlash, agar dizayn hujjatlari mavjud
bo'lmasa, zarurdir
30/10/2014

Tashkiliy masalalar
 An'anaviy muhandislik tashkilotlarida reja asosida
rivojlanish madaniyati mavjud, chunki bu muhandislikda
norma hisoblanadi.
 Tizimning batafsil spetsifikatsiyasini ishlab chiqish odatiy
tashkiliy amaliyotmi?
 Mijozlar vakillari tizimning o'sishi haqida fikr bildirishlari
mumkinmi?
 Norasmiy chaqqon rivojlanish batafsil hujjatlarning
tashkiliy madaniyatiga mos kelishi mumkinmi?
30/10/2014

Katta tizimlar uchun agile usullari
 Katta tizimlar odatda alohida, har bir tizimni ishlab
chiqadigan alohida aloqa tizimlarining
to'plamidir. Ko'pincha, bu jamoalar turli joylarda, ba'zan
turli vaqt zonalarida ishlaydi.
 Yirik tizimlar - "jigarrangfild tizimlari", ya'ni ular mavjud
tizimlarning bir qatorini o'z ichiga oladi va o'zaro
ishlaydi. Tizimning ko'plab talablari ushbu o'zaro ta'sirga
tegishli va shuning uchun moslashuvchanlik va
bosqichma-bosqich rivojlanish uchun qarz bermaydilar.
 Tizimni yaratish uchun bir nechta tizim birlashtirilgan
joyda, ishlab chiqilishning muhim qismi original kodni
ishlab chiqish bilan emas, balki tizim konfiguratsiyasi
bilan bog'liq. Chapter 3 Agile Software Development 58
30/10/2014

Katta tizim rivojlanishi
 Katta tizimlar va ularning rivojlanish jarayonlari ko'pincha
ularni ishlab chiqish imkoniyatini cheklaydigan tashqi
qoidalar va qoidalar bilan cheklanadi.
 Katta tizimlar uzoq vaqt sotib olish va ishlab chiqish
vaqtiga ega. Ushbu davr mobaynida tizim haqida
biladigan uyg'un guruhlarni ushlab turish qiyin, chunki
odamlar muqarrar ravishda boshqa ish va loyihalarga
o'tishadi.
 Katta tizimlar odatda turli xil manfaatdor tomonlarga
ega. Ushbu barcha manfaatdor tomonlarning barchasini
rivojlanish jarayoniga jalb qilish deyarli mumkin emas..
30/10/2014

Katta tizimlardagi omillar
30/10/2014

Masshtab modelidagi IBM-ning qobiliyati
30/10/2014

Katta tizimlargacha kengayish
 Muhandislik talablariga mutlaqo bosqichma-bosqich
yondoshib bo'lmaydi.
 Bitta mahsulot egasi yoki mijozlarning vakili bo'lishi
mumkin emas.
 Katta tizimlarni ishlab chiqish uchun faqatgina tizim
kodiga e'tibor qaratish mumkin emas.
 Jamoa ichidagi o'zaro aloqa mexanizmlari ishlab
chiqilishi va ishlatilishi kerak.
 Doimiy integratsiya deyarli mumkin emas. Shunga
qaramay, tizimni tez-tez qurib turish va tizimning
muntazam ravishda chiqarilishini ta'minlash juda
muhimdir. Chapter 3 Agile Software Development 62
30/10/2014

Ko'p jamoali Scrum
 Rollarni ko'paytirish
 Har bir jamoada o'zlarining ish qismlari va ScrumMaster uchun
mahsulot egasi mavjud.
 Mahsulot me'morlari
 Har bir jamoa mahsulot me'morini tanlaydi va ushbu arxitektorlar
umumiy tizim arxitekturasini loyihalashtirish va rivojlantirish
uchun hamkorlik qilishadi.
 Tarkibni bo'shating
 Har bir jamoadan mahsulotni chiqarish kunlari aniq va to'liq tizim
ishlab chiqarilishi uchun hizalanadi.
 Skrumlarning buzilishi
 Har kuni Scrum of Scrum bor, unda har bir jamoaning
vakillari progress va rejani muhokama qilish uchun
30/10/2014

Tashkilotlar orasida tezkor usullar
 Qattiqqo'l uslublarni qo'llash tajribasiga ega bo'lmagan
loyiha menejerlari yangi yondashuv xavfini qabul
qilmasliklari mumkin.
 Katta tashkilotlar odatda barcha loyihalarni bajarishi kerak
bo'lgan sifatli protseduralar va standartlarga ega va
ularning byurokratik xususiyati tufayli, ular tezkor
uslublarga mos kelmasligi mumkin.
 Jamoa a'zolari nisbatan yuqori mahoratga ega bo'lsa,
chaqqon usullar yaxshi ishlaydi. Biroq, yirik tashkilotlarda,
ko'nikma va qobiliyatlarning keng doirasi bo'lishi mumkin.
 Achchiq usullarga madaniy qarshilik bo'lishi mumkin,
ayniqsa an'anaviy tizimlar muhandislik jarayonlaridan
foydalanishning uzoq tarixi bo'lgan tashkilotlarda.
30/10/2014

Asosiy fikrlar
 Agile usullari - bu dasturiy ta'minotni tezkor ishlab
chiqishga, dasturiy ta'minotni tez-tez nashr etishga,
hujjatlarni minimallashtirish va yuqori sifatli kodni ishlab
chiqarish orqali sarf-xarajatlarni qisqartirishga
yo'naltirilgan rivojlanishning izchil usullari.
 Chaqqon rivojlanish amaliyotiga quyidagilar kiradi
 Tizimni spetsifikatsiyasi uchun foydalanuvchi hikoyalari
 Dasturiy ta'minotning tez-tez nashr etilishi,
 Dasturiy ta'minotni doimiy ravishda takomillashtirish
 Sinov-birinchi ishlanma
 Mijozlarning rivojlanish guruhidagi ishtiroki.
30/10/2014

Asosiy fikrlar
 Scrum - bu loyihani boshqarish doirasini ta'minlaydigan
chaqqon usul.
 U tizim aylanishini ishlab chiqishda qat'iy belgilangan vaqt
oralig'iga ega bo'lgan sprintlar to'plamining o'rtasida joylashgan.
 Rivojlanishning ko'plab amaliy usullari rejaga asoslangan
va chaqqon rivojlanish aralashmasidir.
 Katta tizimlar uchun tezkor usullarni o'lchash qiyin.
 Katta tizimlar oldindan loyihalashga muhtoj va ba'zi hujjatlar va
tashkiliy amaliyot chaqqon yondashuvlarning norasmiyligiga zid
bo'lishi mumkin.
30/10/2014

Ch3. Agile SW Dev.pptx

More Related Content

Featured

Ch3. Agile SW Dev.pptx