Бағдарламалық жасақтаманы әзірлеу - Lean software development

Бағдарламалық жасақтама жасау
Негізгі қызмет
Парадигмалар мен модельдер
Әдістемелер және шеңберлер
Қолдау пәндері
Тәжірибелер
Құралдар
Стандарттар және білім органдары
Глоссарийлер
Контурлар

Бағдарламалық жасақтаманы әзірлеу аудармасы болып табылады арық өндіріс қағидалары мен тәжірибелері бағдарламалық жасақтама жасау домен. -Дан бейімделген Toyota өндіріс жүйесі,[1] ол ішіндегі субмәдениеттің қолдауымен пайда болады Шапшаң қоғамдастық. Lean икемді ұйымдарды қолдайтын мықты тұжырымдамалық негіздерді, құндылықтар мен принциптерді, сондай-ақ тәжірибеден алынған жақсы тәжірибені ұсынады.

Шығу тегі

Термин арық бағдарламалық жасақтама жасау Мэри Поппендик пен Том Поппендиктің 2003 жылы жазған аттас кітабында пайда болды.[2] Кітап дәстүрлі деп аталады арық принциптер, сондай-ақ 22 жиынтығы құралдар және құралдарды сәйкес ептілік тәжірибелерімен салыстырады. Поппендиктердің қатысуы жылдам бағдарламалық қамтамасыздандыру қоғамдастық, соның ішінде бірнеше Agile конференцияларындағы келіссөздер [3] нәтижесінде мұндай ұғымдар икемді қоғамдастықта кеңірек қабылданды.

Арық принциптер

Арық дамуды жеті қағида бойынша қорытындылауға болады, тұжырымдамасы бойынша өндіріс принциптеріне өте жақын:[4]

  1. Қалдықтарды жою
  2. Оқытуды күшейту
  3. Мүмкіндігінше кешірек шешіңіз
  4. Мүмкіндігінше жылдам жеткізіңіз
  5. Командаға күш беріңіз
  6. Тұтастықты қалыптастыру
  7. Барлығын оңтайландыру

Қалдықтарды жою

Арық философия тұтынушыға құндылық қоспайтынның бәрін қалдық ретінде қарастырады (муда ). Мұндай қалдықтарға мыналар кіруі мүмкін:[5]

  1. Ішінара жасалған жұмыс
  2. Қосымша мүмкіндіктер
  3. Қайта оқыту
  4. Тапсырманы ауыстыру
  5. Күтуде
  6. Қолдану
  7. Ақаулар
  8. Басқару қызметі

Салалық зерттеулер бағдарламалық жасақтаманың келесі қалдықтарын анықтады:[6]

  1. Қате функция немесе өнімді құрастыру
  2. Артта қалушылықты дұрыс басқармау
  3. Қайта өңдеу
  4. Қажетсіз күрделі шешімдер
  5. Бөтен танымдық жүктеме
  6. Психологиялық күйзеліс
  7. Күту / көп тапсырма
  8. Білімді жоғалту
  9. Тиімсіз байланыс.

Қалдықтарды жою үшін оны тани білу керек. Егер қандай-да бір белсенділікті айналып өтуге немесе онсыз нәтижеге қол жеткізуге болатын болса, бұл босқа кетеді. Ішінара жасалған кодтау ақыр соңында бас тартылды даму процесі бұл қалдықтар. Құжаттар сияқты қосымша функциялар және клиенттер жиі қолданбайтын мүмкіндіктер қалдықтар болып табылады. Адамдарды тапсырмалар арасында ауыстыру - ысырап. Басқа іс-шараларды, командаларды, процестерді күту босқа кетеді. Жұмысты аяқтау үшін қайта үйрену - бұл қалдықтар. Ақаулар мен төменгі сапа - бұл қалдықтар. Нақты құнды өндірмейтін басқарушылық үстеме шығындар - қалдықтар.

A ағындарды салыстыру қалдықтарды анықтау үшін техника қолданылады. Екінші қадам - ​​қалдықтардың пайда болу көздерін көрсету және оларды жою. Қалдықтарды жою процедуралар мен процедуралар жойылғанға дейін қайталанатын түрде жүзеге асырылуы керек.

Оқытуды күшейту

Бағдарламалық жасақтама - бұл код жазу кезінде қайталануларға негізделген үздіксіз оқыту процесі. Бағдарламалық жасақтама дегеніміз - бұл кодты жазушылар мен олар білген нәрселерді жазумен байланысты проблемаларды шешу процесі. Бағдарламалық жасақтама мәні талаптарға сай емес, қолдануға жарамдылығымен өлшенеді.

Қосымша құжаттама немесе егжей-тегжейлі жоспарлаудың орнына әр түрлі идеяларды код жазу арқылы құрастыруға болады. Пайдаланушылар талаптарын жинау процесін соңғы пайдаланушыларға экран ұсыну және олардың пікірін алу арқылы жеңілдетуге болады. Ақаулардың жиналуын код жазылған бойда тестілеуден өткізу керек.

Оқыту процесі қысқа қайталану циклдарын қолдана отырып жеделдетіледі - олардың әрқайсысы қайта өңдеумен және интеграциялық тестілеу. Клиенттермен қысқа кері байланыс сессиялары арқылы кері байланысты арттыру қазіргі даму кезеңін анықтауға және болашақта жақсартуға күш салуға көмектеседі. Сол қысқа сессияларда, екеуі де тапсырыс берушілердің өкілдері және дамытушылар тобы домен мәселесі туралы көбірек біледі және одан әрі дамытудың мүмкін шешімдерін анықтайды. Осылайша, клиенттер дамудың күш-жігерінің бар нәтижесіне сүйене отырып, олардың қажеттіліктерін жақсы түсінеді, ал әзірлеушілер осы қажеттіліктерді қалай жақсы қанағаттандыру керектігін біледі. Тапсырыс берушімен қарым-қатынас пен оқу үдерісіндегі тағы бір идея - бұл дамудың негізі - бұл болашақ шешімдердің мүмкін болатын шешімдері емес, шектеулері туралы хабарлауға шоғырландырылады, осылайша клиентпен диалог арқылы шешімнің тууына ықпал етеді.[жаргон ]

Мүмкіндігінше кешірек шешіңіз

Қалай бағдарламалық жасақтама жасау әрқашан кейбір белгісіздіктермен байланысты, жақсы нәтижелерге а орнатылған немесе опцияларға негізделген шешімдерді нақты емес болжамдар мен болжамдарға емес, фактілерге негізделгенге дейін мүмкіндігінше кешіктіру. Жүйе неғұрлым күрделі болса, соғұрлым оған маңызды өзгерістер енгізілуі керек, осылайша маңызды және шешуші міндеттемелерді кешіктіруге мүмкіндік береді. Итеративті тәсіл осы қағидатқа ықпал етеді - өзгерістерге бейімделу және қателіктерді түзету, жүйені шығарғаннан кейін ашылған жағдайда өте қымбатқа түсуі мүмкін.

Белгіленген даму кезінде: мысалы, автомобильге жаңа тежегіш жүйесі қажет болса, үш команда бірдей проблеманың шешімдерін ойластыруы мүмкін. Әр команда проблемалық кеңістік туралы біледі және мүмкін шешімді жобалайды. Шешім ақылға қонымсыз деп саналатындықтан, ол кесіледі. Кезеңнің соңында тірі қалыптар салыстырылады және басқалары үйренуге негізделген кейбір өзгертулермен таңдалады - бұл мүмкін болатын соңғы сәтке дейін міндеттемені кейінге қалдырудың керемет мысалы. Бағдарламалық жасақтаманың шешімдері сонымен қатар үлкен дизайнмен туындаған тәуекелді азайту үшін осы тәжірибеден пайда көруі мүмкін. Сонымен қатар, дұрыс жұмыс істейтін, бірақ әр түрлі болатын бірнеше іске асырулар болады (іске асыруға байланысты, ішкі). Бұларды ақауларға төзімді жүйелерді енгізу үшін қолдануға болады, олар барлық кірістер мен шығыстардың дұрыстығын бірнеше іске асыруда бір уақытта тексереді.

Ан жылдам бағдарламалық қамтамасыздандыру тәсіл клиенттер үшін опцияларды құруды ертерек жылжытуы мүмкін, осылайша клиенттер өз қажеттіліктерін жақсырақ түсінгенге дейін кейбір шешуші шешімдерді кешіктіреді. Бұл сонымен қатар кейінірек өзгерістерге бейімделуге және қымбат технологиямен байланысты шешімдердің алдын алуға мүмкіндік береді. Бұл ешқандай жоспарлауға қатыспау керек дегенді білдірмейді - керісінше, жоспарлау іс-әрекеті әр түрлі нұсқаларға және қазіргі жағдайға бейімделуге, сондай-ақ жедел әрекет етудің заңдылықтарын белгілеу арқылы түсініксіз жағдайларды анықтауға шоғырлануы керек. Әр түрлі нұсқаларды бағалау олардың тегін еместігін, бірақ шешімдерді кеш қабылдау үшін қажетті икемділікті қамтамасыз ететіндігін түсінген бойда тиімді болады.

Мүмкіндігінше жылдам жеткізіңіз

Технологияның жедел эволюциясы дәуірінде ол ең үлкені емес, ең жылдамы тірі қалады. Соңғы өнім үлкен ақауларсыз неғұрлым тезірек жеткізілсе, соғұрлым тезірек кері байланыс алынып, келесіге қосылады қайталану. Қайталау неғұрлым қысқа болса, соғұрлым ұжымдағы оқыту мен қарым-қатынас жақсарады. Жылдамдықпен шешімдерді кешіктіруге болады. Жылдамдық клиенттің кеше талап еткен нәрсесін емес, қазіргі қажеттіліктерін қанағаттандыруға кепілдік береді. Бұл оларға неғұрлым жақсы білім алғанға дейін шын мәнінде не қажет екендігі туралы шешім қабылдауды кейінге қалдыруға мүмкіндік береді. Клиенттер а-ның тез жеткізілуін бағалайды сапа өнім.

The дәл уақытында өндірістік идеологияны қолдануға болар еді бағдарламалық жасақтама жасау, оның нақты талаптары мен ортасын тану. Бұған қажетті нәтижені ұсыну және топтың өзін-өзі ұйымдастырып, белгілі бір нәтижеге жету үшін міндеттерді бөлу арқылы қол жеткізіледі қайталану. Бастапқыда тұтынушы қажетті ақпаратты ұсынады. Бұл жай ғана шағын карточкаларда немесе ұсынылуы мүмкін әңгімелер - әзірлеушілер бұл үшін қажет уақытты бағалайды іске асыру әр картаның Осылайша жұмыс ұйымы өзгереді өздігінен тартылатын жүйе - әр таңертең а кездесу, команданың әрбір мүшесі кеше не істелгенін, бүгін және ертең не жасалуы керек екенін қарастырады және әріптестерінен немесе тапсырыс берушіден қажет кез-келген ақпаратты ұсынады. Бұл процестің ашықтығын талап етеді, бұл сонымен қатар командалық қарым-қатынас үшін пайдалы.

Осы қағида негізінде жатқан миф мынада асығыстық ысырап етеді. Алайда, арық іске асыру нәтижені ерте көру және талдау үшін тез жеткізу жақсы тәжірибе болғанын қамтамасыз етті.

Командаға күш беріңіз

Туралы көптеген кәсіптерде дәстүрлі сенім қалыптасқан шешім қабылдау ұйымда - менеджерлер жұмысшыларға өз жұмысын қалай жасау керектігін айтады. Ішінде жаттығу техникасы, рөлдер ауысады - менеджерлерге қалай тыңдау керектігін үйретеді әзірлеушілер, сондықтан олар қандай шаралар қолданылуы мүмкін екенін жақсы түсіндіре алады, сондай-ақ жақсарту бойынша ұсыныстар бере алады. Арық тәсіл ептілік қағидасына сәйкес келеді[7] «мотивацияланған тұлғалардың айналасында жобалар құрыңыз [...] және оларға жұмысты аяқтауға сеніңіз»,[8] алға жылжуды ынталандыру, қателіктерді іздеу және кедергілерді жою, бірақ микроменеджмент емес.

Тағы бір қате сенім адамдарға деген көзқарас болды ресурстар. Адамдар болуы мүмкін ресурстар статистикалық мәліметтер парағы тұрғысынан, бірақ бағдарламалық жасақтама жасау, кез-келген ұйымдық бизнес сияқты, адамдарға тек міндеттер тізімі мен тапсырмаларды орындау кезінде мазаламайтындығына сенімділік қажет. Адамдарға мотивация және мақсатқа жету үшін қол жетімді шындық шеңберінде жоғары мақсат қажет, бұл командаға өз міндеттемелерін өзі таңдай алады. Әзірлеушілерге тапсырыс берушіге рұқсат беру керек; The топ басшысы қиын жағдайларда қолдау мен көмек көрсетуге, сондай-ақ скептицизмнің команданың рухын бұзбауын қамтамасыз етуі керек. Адамдарды құрметтеу және олардың жұмысын мойындау - бұл командаға мүмкіндік берудің бір әдісі.

Тұтастықты қалыптастыру

Тұтынушыға жүйенің жалпы тәжірибесі қажет. Бұл қабылданған тұтастық деп аталады: оны қалай жарнамалайды, жеткізеді, орналастырады, қол жеткізеді, оны қолдану қаншалықты интуитивті, бағасы және проблемаларды қаншалықты жақсы шешеді.

Тұжырымдамалық тұтастық дегеніміз - жүйенің жекелеген компоненттері икемділік, қолдау, тиімділік және жауаптылық тепе-теңдігімен тұтастай алғанда жақсы жұмыс істейді. Бұған проблема доменін түсіну және оны бірізділікпен емес, бір уақытта шешу арқылы қол жеткізуге болады. Қажетті ақпарат шағын партия түрінде алынады - бір үлкен бөлікке емес - жақсырақ бетпе-бет сөйлесу арқылы және ешқандай жазбаша құжаттамада емес. Ақпарат ағыны екі бағытта - тұтынушыдан әзірлеушіге дейін және кері бағытта тұрақты болуы керек, осылайша ұзақ оқшауланғаннан кейін үлкен стресстік ақпараттан аулақ болыңыз.

Интегралды архитектураның дұрыс жолдарының бірі қайта өңдеу. Бастапқы код базасына көптеген мүмкіндіктер қосылатындықтан, одан әрі жақсартуларды қосу қиынға соғады. Рефакторинг - бұл қарапайымдылықты, анықтықты, кодтағы мүмкіндіктердің минималды санын сақтау. Кодтағы қайталанулар дұрыс жасалынбағандықтың белгілері болып табылады және оларды болдырмау керек. Толық және автоматтандырылған құрылыс процесі жүйенің қазіргі күйімен бірдей нұсқасы, синхрондалуы және семантикасы бар әзірлеушілер мен тапсырыс берушілердің толық және автоматтандырылған жиынтығымен бірге жүруі керек. Соңында тұтастығын мұқият тестілеуден өткізу керек, осылайша жүйенің тұтынушы күткен нәрсені орындауын қамтамасыз етеді. Автоматтандырылған сынақтар сонымен қатар өндіріс процесінің бір бөлігі болып саналады, сондықтан егер олар қосымша құн қоспаса, оларды қалдық деп санау керек. Автоматтандырылған тестілеу мақсат болмауы керек, керісінше ақауларды азайту үшін құрал болуы керек.

Барлығын оңтайландыру

Қазіргі заманғы бағдарламалық қамтамасыз ету жүйелері олардың бөліктерінің жиынтығы ғана емес, сонымен қатар олардың өзара әрекеттесуінің өнімі болып табылады. Бағдарламалық жасақтамадағы ақаулар даму процесінде жинақталады - үлкен міндеттерді кішігірім тапсырмаларға бөлу арқылы және дамудың әр түрлі сатыларын стандарттау арқылы ақаулардың негізгі себептерін табу және жою қажет. Жүйе неғұрлым үлкен болса, соғұрлым оның дамуына қатысатын ұйымдар көп болады және олардың бөліктерін әр түрлі командалар дамытады, әр түрлі жеткізушілер арасында өзара байланыс орнатудың маңыздылығы соғұрлым өзара әрекеттесетін компоненттері бар жүйені шығару үшін қажет болады. Дамудың ұзақ кезеңінде қысқа мерзімді пайданы оңтайландырудан гөрі күшті субмердігерлік желі әлдеқайда тиімді, бұл екі жаққа да ұтымды қарым-қатынас орнатуға мүмкіндік бермейді.

Арық ойлауды нақты, нақты жағдайда іске асырмас бұрын, жобаның барлық мүшелері жақсы түсінуі керек. «Үлкен ойла, кішігірім әрекет ет, тез істен шық; тез үйрен»[9] - бұл ұрандар өрісті түсінудің маңыздылығын және бағдарламалық жасақтаманы әзірлеудің барлық кезеңінде арық принциптерді қолдануға жарамдылығын жинақтайды. Барлық арық қағидалар бірге жұмыс істегенде ғана, жұмыс ортасына қатысты мықты «ақыл-оймен» ұштасқанда, жетістікке жетуге негіз болады бағдарламалық жасақтама жасау.

Бағдарламалық жасақтаманың тәжірибесі

Бағдарламалық жасақтаманы дамытудағы немесе Poppendiecks-тің «құралдар» деп атайтын нұсқасы бастапқы эквиваленттерден сәл ғана өзгертілген жылдам бағдарламалық қамтамасыздандыру. Мұндай тәжірибелердің мысалдары:

Бағдарламалық жасақтаманың икемді дамуы - бұл Agile Manifesto-да көрсетілген құндылықтар мен қағидаларға негізделген әдістер мен тәжірибелер жиынтығының қолшатыр термині болғандықтан, бағдарламалық жасақтаманы ептеп әзірлеу бағдарламалық жасақтама жасаудың икемді әдісі болып табылады.[10]

Сондай-ақ қараңыз

Әдебиеттер тізімі

  1. ^ Ясухиро Монден (1998), Toyota өндіріс жүйесі, дәл қазірге деген интеграцияланған тәсіл, Үшінші басылым, Норкросс, GA: Engineering & Management Press, ISBN  0-412-83930-X.
  2. ^ Мэри Поппендиек; Том Поппендиек (2003). Lean Software Development: икемді инструмент. Аддисон-Уэсли кәсіби. ISBN  978-0-321-15078-3.
  3. ^ Мэри Поппендиек: «Бағдарламалық жасақтаманы дамытудағы көшбасшылық рөлі» https://www.youtube.com/watch?v=ypEMdjslEOI
  4. ^ Мэри Поппендиек; Том Поппендиек (2003). Lean Software Development: икемді инструмент. Аддисон-Уэсли кәсіби. 13-15 бет. ISBN  978-0-321-15078-3.
  5. ^ Мэри Поппендиек; Том Поппендиек (2003). Lean Software Development: икемді инструмент. Аддисон-Уэсли кәсіби. 19-22 бет. ISBN  978-0-321-15078-3.
  6. ^ Седано, Тодд; Ральф, Пол; Перейра, Сесиль. «Бағдарламалық жасақтаманы әзірлеу қалдықтары». IEEE.
  7. ^ «Шапшаң Манифестің артындағы 12 қағида - ептілік альянсы». agilealliance.org. 4 қараша 2015.
  8. ^ Марк сызықтары; Скотт В.Амблер (2012). Тәртіптік жедел жеткізу: Тәжірибеші маманға кәсіпорында бағдарламалық жасақтаманы жедел жеткізу бойынша нұсқаулық. IBM Press. 54–5 бет. ISBN  978-0-13-281013-5.
  9. ^ Мэри Поппендиек; Том Поппендиек (2003). Lean Software Development: икемді инструмент. Аддисон-Уэсли кәсіби. 182–18 бет. ISBN  978-0-321-15078-3.
  10. ^ «Agile Software Development дегеніміз не?». agilealliance.org. 29 маусым 2015.

Әрі қарай оқу