Ағылшыншамен салыстырыңыз: абзацты басыңыз — түпнұсқа терезеде ашылады. Абзац астындағы EN түймесі оны мәтін ішінде көрсетеді.
Мазмұны
Кіріспе
Бағдарламалық жасақтаманы әзірлеуде жұмсақ өндіріс принциптерін қолдану
Use of lean manufacturing principles in software development
Жұмсақ бағдарламалық жасақтаманы әзірлеу – бұл жұмсақ өндіріс принциптері мен тәжірибелерін бағдарламалық жасақтаманы әзірлеу саласына бейімдеу. Toyota Production System жүйесінен алынған, ол agile қауымдастығының жұмсақ өндіріс бағытын қолдайтын субмәдениетінің арқасында дамып келеді. Жұмсақ өндіріс тұтас тұжырымдамалық ая, құндылықтар мен принциптер, сондай-ақ agile ұйымдарды қолдайтын тәжірибеден алынған жақсы тәжірибелер ұсынады.
Lean software development is a translation of lean manufacturing principles and practices to the software development domain. Adapted from the Toyota Production System, it is emerging with the support of a pro lean subculture within the agile community. Lean offers a solid conceptual framework, values and principles, as well as good practices, derived from experience, that support agile organizations.
Шығу тегі
"Жүйкелі бағдарламалық жасақтаманы әзірлеу" термині 2003 жылы Мэри Поппендиек пен Том Поппендиектің осы атпен жазған кітабында пайда болды. Кітапта дәстүрлі "арық" принциптері мен 22 құрал жиынтығы қайта қарастырылады, сондай-ақ құралдар тиісті икемді практикалармен салыстырылады. Поппендиектердің икемді бағдарламалық жасақтаманы әзірлеу қауымдастығына қатысуы, оның ішінде бірнеше икемді конференциялардағы баяндамалары, осы ұғымдардың икемді қауымдастықта кеңінен қабылдануына ықпал етті.
The expression "lean software development" originated in a book by the same name, written by Mary Poppendieck and Tom Poppendieck in 2003. The book restates traditional lean principles, as well as a set of 22 tools and compares the tools to corresponding agile practices. The Poppendiecks' involvement in the agile software development community, including talks at several Agile conferences has resulted in such concepts being more widely accepted within the agile community.
Оқуды кеңейту
Бағдарламалық жасақтаманы әзірлеу – код жазу кезінде итерацияларға негізделген, үздіксіз оқу процесі. Бағдарламалық жасақтаманы жобалау – бұл бағдарламашылардың код жазу және алған тәжірибесін қолданатын мәселені шешу процесі. Бағдарламалық жасақтаманың құндылығы талаптарға сәйкестігімен емес, пайдалануға ыңғайлылығымен өлшенеді. Қосымша құжаттама немесе егжей-тегжейлі жоспарлаудың орнына, код жазып, құру арқылы түрлі идеяларды сынап көруге болады. Пайдаланушылардың талаптарын жинау процесін соңғы пайдаланушыларға интерфейстерді көрсету және олардың пікірлерін алу арқылы жеңілдетуге болады. Ақаулардың жинақталуын болдырмау үшін код жазылғаннан кейін дереу тесттер жүргізу қажет. Оқу процесін қысқа итерациялық циклдарды қолдану арқылы жылдамдатуға болады – әр цикл рефакторинг және интеграциялық тестілеумен байланысты. Клиенттермен қысқа пікір алмасу арқылы кері байланыс беруді арттыру, дамудың ағымдағы кезеңін анықтауға және болашақ жақсартуларға күш-жігерді бағыттауға көмектеседі. Осы қысқа сессиялар барысында клиенттердің өкілдері де, даму тобы да домендік мәселе туралы көбірек біліп, одан әрі даму үшін мүмкін болатын шешімдерді іздейді. Осылайша клиенттер өздерінің қажеттіліктерін жақсырақ түсінеді, бұл даму жұмысының қолданыстағы нәтижелеріне негізделген, ал дамушылар осы қажеттіліктерді қалай толықтыруға болатынын жақсырақ біледі. Клиентпен байланыс және оқу процесіндегі тағы бір идея – болашақ шешімнің шектеулерін баяндауға баса назар аудару, мүмкін болатын шешімдерге емес, осылайша клиентпен диалог арқылы шешімнің тууына жағдай жасау.
Software development is a continuous learning process based on iterations when writing code. Software design is a problem solving process involving the developers writing the code and what they have learned. Software value is measured in fitness for use and not in conformance to requirements. Instead of adding more documentation or detailed planning, different ideas could be tried by writing code and building. The process of user requirements gathering could be simplified by presenting screens to the end users and getting their input. The accumulation of defects should be prevented by running tests as soon as the code is written. The learning process is sped up by usage of short iteration cycles – each one coupled with refactoring and integration testing. Increasing feedback via short feedback sessions with customers helps when determining the current phase of development and adjusting efforts for future improvements. During those short sessions, both customer representatives and the development team learn more about the domain problem and figure out possible solutions for further development. Thus the customers better understand their needs, based on the existing result of development efforts, and the developers learn how to better satisfy those needs. Another idea in the communication and learning process with a customer is set based development – this concentrates on communicating the constraints of the future solution and not the possible solutions, thus promoting the birth of the solution via dialogue with the customer.
Шешімді мүмкіндігінше кеш қабылдаңыз
Бағдарламалық жасақтаманы әзірлеу әрқашан белгілі бір белгісіздікпен байланысты болғандықтан, жинақтарға негізделген немесе нұсқаларға негізделген тәсілмен жақсы нәтижелерге қол жеткізуге болады. Шешімдер нақты деректерге негізделгенге дейін, ал нақты емес болжамдар мен күтулерге емес, мүмкіндігінше кейінге жылжыту керек. Жүйе қаншалықты күрделі болса, соғұрлым өзгерістерге бейімделу мүмкіндігі артық болуы керек, осылайша маңызды және шешуші міндеттемелерді кейінге қалдыруға болады. Итеративтік тәсіл осы принципті қолдайды – өзгерістерге бейімделу және қателерді түзету қабілеті, егер жүйе шығарылғаннан кейін анықталса, өте қымбатқа түсуі мүмкін. Жинақтарға негізделген әзірлеуде: мысалы, егер автомобильге жаңа тежегіш жүйесі қажет болса, үш команда бір мәселені шешу үшін әртүрлі шешімдерді әзірлей алады. Әр команда мәселені зерттейді және мүмкін болатын шешімді ұсынады. Егер шешім ұнамсыз деп танылса, ол жойылды. Белгілі бір кезеңнің соңында, қалған шешімдер салыстырылады және біреуі таңдалады, мүмкін басқалардан алынған білім негізінде кейбір түзетулермен. Бұл – міндеттемелерді соңғы мүмкін сәттерге дейін кейінге қалдырудың тамаша мысалы. Бағдарламалық шешімдер де осы тәжірибеден пайда көріп, алдын ала жобалаудың салдарынан туындайтын тәуекелді азайта алады. Сонымен қатар, бірнеше дұрыс жұмыс істейтін, бірақ ішкі құрылымы жағынан әртүрлі іске асырулар пайда болады. Оларды бірнеше іске асыру арқылы барлық кіріс және шығыстардың дұрыстығын бір уақытта тексеретін, қателерге төзімді жүйелерді құру үшін пайдалануға болады. Шапшаң бағдарламалық жасақтаманы әзірлеу тәсілі клиенттерге нұсқаларды ертерек ұсынуға мүмкіндік береді, осылайша клиенттер өз қажеттіліктерін толық түсінгенге дейін маңызды шешімдерді кейінге жылжытуға болады. Бұл сондай-ақ өзгерістерге бейімделуге және ерте қабылданған технологиялық шешімдердің салдарынан туындайтын қымбат қателерді болдырмауға мүмкіндік береді. Бұл жоспарлаудың қажет еместігін білдірмейді – керісінше, жоспарлау қызметі әртүрлі нұсқаларға және ағымдағы жағдайға бейімделуге, сондай-ақ жағдайды түсіндіру үшін жылдам әрекет етуге арналған үлгілерді құруға бағытталған болуы керек. Әртүрлі нұсқаларды бағалау тиімді, егер олардың тегін емес екені, бірақ кейінірек шешім қабылдау үшін қажетті икемділікті қамтамасыз ететіні анықталғанда.
As software development is always associated with some uncertainty, better results should be achieved with a set based or options based approach, delaying decisions as much as possible until they can be made based on facts and not on uncertain assumptions and predictions. The more complex a system is, the more capacity for change should be built into it, thus enabling the delay of important and crucial commitments. The iterative approach promotes this principle – the ability to adapt to changes and correct mistakes, which might be very costly if discovered after the release of the system. With set based development: If a new brake system is needed for a car, for example, three teams may design solutions to the same problem. Each team learns about the problem space and designs a potential solution. As a solution is deemed unreasonable, it is cut. At the end of a period, the surviving designs are compared and one is chosen, perhaps with some modifications based on learning from the others a great example of deferring commitment until the last possible moment. Software decisions could also benefit from this practice to minimize the risk brought on by big up front design. Additionally, there would then be multiple implementations that work correctly, yet are different (implementation wise, internally). These could be used to implement fault tolerant systems which check all inputs and outputs for correctness, across the multiple implementations, simultaneously. An agile software development approach can move the building of options earlier for customers, thus delaying certain crucial decisions until customers have realized their needs better. This also allows later adaptation to changes and the prevention of costly earlier technology bounded decisions. This does not mean that no planning should be involved – on the contrary, planning activities should be concentrated on the different options and adapting to the current situation, as well as clarifying confusing situations by establishing patterns for rapid action. Evaluating different options is effective as soon as it is realized that they are not free, but provide the needed flexibility for late decision making.
Мүмкіндігінше тез жеткізу
Технологияның қарқынды дамып келе жатқан дәуірінде ең үлкені емес, ең жылдамдары сақталатын болады. Түпкілікті өнім ірі кемшіліктерсіз қаншалықты тез жеткізілсе, кері байланыс та соншалықты жылдам алынып, келесі итерацияға енгізіледі. Итерациялар қысқа болған сайын, команда ішіндегі оқу мен байланыс та жақсырақ болады. Жылдамдық шешімдерді кешіктіруге мүмкіндік береді. Жылдамдық клиенттің қазіргі қажеттіліктерін қанағаттандырады, кешегі талаптарын емес. Бұл оларға нақты не қажет екені туралы шешімді, жақсы білім алғанша кейінге жылжытуға мүмкіндік береді. Клиенттер сапалы өнімді жылдам жеткізуді бағалайды. Дәл уақытында өндіріс идеологиясы бағдарламалық жасақтаманы әзірлеуге де қолданылуы мүмкін, оның ерекше талаптары мен ортасы ескеріле отырып. Бұл қажетті нәтижені ұсыну арқылы және команданың өзін-өзі ұйымдастыруына, сондай-ақ белгілі бір итерация үшін қажетті нәтижені орындау үшін міндеттерді бөлуіне рұқсат беру арқылы жүзеге асырылады. Бастапқыда клиент қажетті ақпаратты ұсынады. Бұл шағын карточкалар немесе оқиғалар түрінде болуы мүмкін – дамытушылар әр карточканы іске асыру үшін қажетті уақытты бағалайды. Осылайша жұмыс ұйымдастыру өзіне-өзі тарту жүйесіне айналады. Әр таңертең өткізілетін жиналыста команданың әрбір мүшесі кеше не істегенін, бүгін және ертең не істеу керектігін қарастырады, сондай-ақ әріптестерінен немесе клиенттен қажетті ұсыныстарды сұрайды. Бұл процестің ашықтығын қажет етеді, бұл командалық байланысқа да пайдалы. Осы принциптің негізінде жатқан миф – асығу ысырапқа алып келеді. Дегенмен, Lean-ді енгізу тәжірибесі көрсеткендей, нәтижелерді мүмкіндігінше ертерек көру және талдау үшін жылдам жеткізу – жақсы тәжірибе.
In the era of rapid technology evolution, it is not the biggest that survives, but the fastest. The sooner the end product is delivered without major defects, the sooner feedback can be received, and incorporated into the next iteration. The shorter the iterations, the better the learning and communication within the team. With speed, decisions can be delayed. Speed assures the fulfilling of the customer's present needs and not what they required yesterday. This gives them the opportunity to delay making up their minds about what they really require until they gain better knowledge. Customers value rapid delivery of a quality product. The just in time production ideology could be applied to software development, recognizing its specific requirements and environment. This is achieved by presenting the needed result and letting the team organize itself and divide the tasks for accomplishing the needed result for a specific iteration. At the beginning, the customer provides the needed input. This could be simply presented in small cards or stories – the developers estimate the time needed for the implementation of each card. Thus the work organization changes into self pulling system – each morning during a stand up meeting, each member of the team reviews what has been done yesterday, what is to be done today and tomorrow, and prompts for any inputs needed from colleagues or the customer. This requires transparency of the process, which is also beneficial for team communication. The myth underlying this principle is haste makes waste. However, lean implementation has shown that it is a good practice to deliver fast in order to see and analyze the output as early as possible.
Топқа күш беру
Көптеген кәсіпорындарда ұйымда шешім қабылдау туралы дәстүрлі түсінік қалыптасқан: басшылар қызметкерлерге өз жұмысын қалай істеу керектігін айтады. "Жұмыс жасау" әдісінде рөлдер ауыстырылады – менеджерлер бағдарламашыларды қалай тыңдауға үйренеді, осылайша олар қандай шаралар қолдануға болатынын жақсы түсіндіріп, жақсартулар бойынша ұсыныстар бере алады. Lean тәсілі "мотивацияланған адамдардың айналасында жобаларды құру және жұмысты аяқтау үшін оларға сену" принципін ұстанады, прогреске ынталандыру, қателерді анықтау және кедергілерді жоюға көмектеседі, бірақ микробасқаруға жол бермейді. Тағы бір жалған пікір – адамдарды қарапайым ресурстар деп санау. Адамдар статистикалық мәліметтер бойынша ресурс ретінде қарастырылуы мүмкін, бірақ бағдарламалық жасақтаманы әзірлеуде және кез келген ұйымдық бизнесте адамдарға міндеттер тізімі мен жұмыстың орындалуына кедергі келтірмейтініне кепілдік беру жеткіліксіз. Адамдарға жұмыс істеу үшін мотивация және қол жетімді болатын нақты мақсат қажет – команда өз міндеттемелерін таңдай алатынына сенімділікпен. Бағдарламашылар клиенттерге тікелей қол жеткізуге мүмкіндік алса, команда жетекшісі қиын жағдайларда қолдау көрсетуі және көмектесуі керек, сондай-ақ күмән команданың рухын құлатпауына көз жеткізуі керек. Адамдарды құрметтеу және олардың еңбегін бағалау – команданы күшейтудің бір жолы.
There has been a traditional belief in most businesses about the decision making in the organization – the managers tell the workers how to do their own job. In a work out technique, the roles are turned – the managers are taught how to listen to the developers, so they can explain better what actions might be taken, as well as provide suggestions for improvements. The lean approach follows the agile principle "build projects around motivated individuals [ ] and trust them to get the job done", encouraging progress, catching errors, and removing impediments, but not micro managing. Another mistaken belief has been the consideration of people as resources. People might be resources from the point of view of a statistical data sheet, but in software development, as well as any organizational business, people do need something more than just the list of tasks and the assurance that they will not be disturbed during the completion of the tasks. People need motivation and a higher purpose to work for – purpose within the reachable reality, with the assurance that the team might choose its own commitments. The developers should be given access to the customer; the team leader should provide support and help in difficult situations, as well as ensure that skepticism does not ruin the team's spirit. Respecting people and acknowledging their work is one way to empower the team.
Адалдықты қалыптастыру
Клиент жүйе туралы толыққанды түсінікке ие болуы керек. Бұл – қабылданатын тұтастық, яғни жүйені қалай жарнамалау, жеткізу, енгізу, пайдалану, оның қолданудың қаншалықты интуитивті болуы, бағасы және мәселелерді қаншалықты тиімді шешетіні. Тұжырымдық тұтастық – жүйенің жеке компоненттерінің икемділік, техникалық қолдау, тиімділік және жауап беру қабілеті арасындағы үйлесімділікпен жұмыс істеуі. Мұны мәселені бірден шешу арқылы, бірінен соң бірін емес, жүзеге асыруға болады. Қажетті ақпарат үлкен бір бөлік түрінде емес, кішігірім бөліктермен берілуі керек – мүмкіндігінше бетпе-бет әңгімелесу арқылы, жазбаша құжаттама емес. Ақпарат ағыны екі бағытта да үздіксіз болуы керек – клиенттен дамытушыларға және керісінше, осылайша ұзақ дамытудан кейін туындайтын үлкен стресстік ақпараттан аулақ болуға болады. Тұтас архитектураға жетудің бірден-бір дұрыс жолы – рефакторинг. Бастапқы код базасына жаңа мүмкіндіктер қосылған сайын, одан әрі жақсартулар енгізу қиындай түседі. Рефакторинг – кодтың қарапайымдылығын, түсініктілігін, мүмкіндіктердің ең аз санын сақтау туралы. Кодтағы қайталаулар – нашар код дизайнының белгісі және олардан аулақ болу керек (мысалы, DRY ережесін қолдану арқылы). Толық және автоматтандырылған құрастыру процесі дамытушылар мен клиенттердің толық және автоматтандырылған сынақтарымен бірге жүруі керек, олар жүйенің ағымдағы күйімен бірдей нұсқалауға, синхрондауға және семантикаға ие болуы керек. Соңында тұтастық мұқият сынау арқылы тексерілуі керек, осылайша жүйенің клиент күткенін орындайтынына көз жеткізіледі. Автоматтандырылған сынақтар өндіріс процесінің бір бөлігі болып есептеледі, сондықтан олар құндылық қоспаса, оларды пайдасыз деп санау керек. Автоматтандырылған тестілеу мақсат емес, мақсатқа жету құралы болуы керек, атап айтқанда, қателерді азайту.
The customer needs to have an overall experience of the system. This is the so called perceived integrity: how it is being advertised, delivered, deployed, accessed, how intuitive its use is, its price and how well it solves problems. Conceptual integrity means that the system's separate components work well together as a whole with balance between flexibility, maintainability, efficiency, and responsiveness. This could be achieved by understanding the problem domain and solving it at the same time, not sequentially. The needed information is received in small batch pieces – not in one vast chunk preferably by face to face communication and not any written documentation. The information flow should be constant in both directions – from customer to developers and back, thus avoiding the large stressful amount of information after long development in isolation. One of the healthy ways towards integral architecture is refactoring. As more features are added to the original code base, the harder it becomes to add further improvements. Refactoring is about keeping simplicity, clarity, minimum number of features in the code. Repetitions in the code are signs of bad code designs and should be avoided (i. e. by applying the DRY rule). The complete and automated building process should be accompanied by a complete and automated suite of developer and customer tests, having the same versioning, synchronization and semantics as the current state of the system. At the end the integrity should be verified with thorough testing, thus ensuring the System does what the customer expects it to. Automated tests are also considered part of the production process, and therefore if they do not add value they should be considered waste. Automated testing should not be a goal, but rather a means to an end, specifically the reduction of defects.
Бүкілін оңтайландыру
Қазіргі заманғы бағдарламалық жүйелер тек олардың құраушы бөліктерінің жиынтығы ғана емес, сонымен қатар олардың өзара әрекеттесуінің нәтижесі болып табылады. Бағдарламалық жасақтамадағы кемшіліктер даму процесінде жинақталады – ірі тапсырмаларды кішірек тапсырмаларға бөлу және дамудың әртүрлі кезеңдерін стандарттау арқылы кемшіліктердің түпкі себептерін анықтап, жою қажет. Жүйе неғұрлым ірі болса, оның дамуына қатысқан ұйымдардың саны көп болса және әртүрлі командалармен жасалған бөліктердің саны арта түссе, әртүрлі жеткізушілер арасындағы анық қарым-қатынастардың маңызы осымен пропорционалды түрде артады. Ұзақ мерзімді даму кезеңінде, берік қосалқы мердігерлер желісі, өзара тиімді қарым-қатынасқа мүмкіндік бермейтін қысқа мерзімді пайданы бағалаудан әлдеқайда пайдалы. Lean (жайлау) ойлауды жобаның барлық қатысушылары нақты жағдайда қолдану алдында жақсы түсінуі керек. "Ірі ойла, кішкентай қадамдар жаса, тез қателіктерге жол бер, жылдам үйрен" – бұл ұрандар саланың түсінігінің және бағдарламалық жасақтаманы дамыту процесінде lean принциптерін енгізудің тиімділігінің маңыздылығын көрсетеді. Бағдарламалық жасақтаманы дамытуда табысқа жету үшін барлық lean принциптері жұмыс ортасына қатысты "ақылға қонымды" тәсілмен бірге кешенді түрде іске асырылуы керек.
Modern software systems are not simply the sum of their parts, but also the product of their interactions. Defects in software tend to accumulate during the development process – by decomposing the big tasks into smaller tasks, and by standardizing different stages of development, the root causes of defects should be found and eliminated. The larger the system, the more organizations that are involved in its development and the more parts are developed by different teams, the greater the importance of having well defined relationships between different vendors, in order to produce a system with smoothly interacting components. During a longer period of development, a stronger subcontractor network is far more beneficial than short term profit optimizing, which does not enable win win relationships. Lean thinking has to be understood well by all members of a project, before implementing in a concrete, real life situation. "Think big, act small, fail fast; learn rapidly" – these slogans summarize the importance of understanding the field and the suitability of implementing lean principles along the whole software development process. Only when all of the lean principles are implemented together, combined with strong "common sense" with respect to the working environment, is there a basis for success in software development.