Event Storming арқылы талаптарды жинау: воркшоп сценарийі
Event Storming арқылы талаптарды жинау: 1-2 сессияда оқиғалар, командалар, агрегаттар мен бастапқы backlog жинауға арналған қадамдық сценарий.

Талаптарды жинау үшін Event Storming неге қажет
Event Storming — процесс туралы білім адамдар арасында бөлінген жағдайда, "қалай жұмыс істейді" деген ақпарат чаттарда, хаттарда және негізгі қызметкерлердің басында сақталған жерде талаптарды жинауға көмектеседі. Ұзақ құжат орнына сіз тезірек жалпы көріністі аласыз: не болып жатыр, қайда кідірістер туындайды және неге әртүрлі командалар бірдей сөздерді әртүрлі түсінеді.
Көбінесе әдіс үш ауыртпалықты жояды. Біріншісі — талаптардың шашылып қалуы: әркім өз бөлігін еске алады, бірақ ешкім процесті толық көрмейді. Екіншісі — терминология: «өтініш», «тапсырыс», «шот» сатылым, есеп және IT үшін әртүрлі нәрсе болуы мүмкін. Үшіншісі — жасырын ерекшеліктер: "егер клиент мекенжайын өзгертсе?", "егер жеткізу бөлшектелсе?", "егер келісім болмаса?" сияқты сұрақтар әдетте сіз оқиғалар тізбегін қадам-қадаммен өткенде ғана шығады.
Әдіс бірнеше рөлді синхрондастыру және автоматтандыру қай жерде нақты пайда әкелетінін жылдам түсіну қажет болғанда әсіресе пайдалы. Мысалы, ішкі сұрауларды өңдеуге арналған сервис іске қосқанда: қолдау «қалай қабылданады» деген қадамдарды сипаттайды, әзірлеу статустар тұрғысынан ойлайды, ал басшыға метрикалар қажет болады. Оқиғалар картасы барлығына бірдей айтуды, формулировкалар туралы дауласуды азайтады.
Алайда бұл барлық жағдайға жарамды құрал емес. Егер тапсырма шағын әрі анық болса, қысқа сұхбат өткізіп, бірден макет сызған оңайырақ. Егер команда өнім мақсаттары бойынша әлі келіспеген болса немесе пайдаланушы сценарийін "тірі" адамдарда тексеру қажет болса, прототиптеу мен тесттер көбірек пайда береді.
Сессияның сәттілігін саны стикерлермен емес, нәтижелермен өлшеңіз:
- бастапқыдан соңына дейінгі жалпы процесс желісі бар, соның ішінде жиі болатын ерекшеліктер;
- негізгі терминдер бойынша сөздік келісілген (әр сөздің нақты мағынасы);
- тар жерлер мен кейінірек нақтылау қажет сұрақтар көрініп тұр;
- команда оқиғалар картасынан тапсырмалар тізіміне мағынаны жоғалтпай ауыса алады.
Егер осы тармақтар орындалса, кейін командалар мен агрегаттарды бөліп, талқылауды нақты backlog-қа айналдыру оңайырақ болады.
Сессиядан қандай артефактілер қалуы тиіс
Сессияның мәні — "сөйледік" емес, командада әлі де қайта айтып берудің қажеті жоқ жұмысқа арналған артефактілер қалуы. Олар бизнес пен әзірлеуге бірдей түсінікті болуы керек.
Домендік оқиғалар — бұл болған фактілер, сондықтан олар өткен шақта жазылады: «Тапсырыс рәсімделді», «Шот шығарылды», «Жеткізу расталды». Бұл форма бақылауды жеңілдетеді: сіз өзгерістің нәтижесін белгілейсіз, ниет пен интерфейс экрандарын талқыламайсыз.
Командалар (commands) оқиғалардан өзгеше: олар өзгерісті жүзеге асыратын бастамашы. Бұл адам, сыртқы сервис немесе регламентті процесс болуы мүмкін. Команда көбінесе бұйрық райында болады: «Тапсырыс рәсімдеу», «Бюджет лимитін тексеру», «Жеткізуді растау». Оқиға "не шындыққа айналды" деген сұраққа жауап берсе, команда — "олай болуы үшін не істеу керек" сұрағына жауап береді.
Агрегат (DDD) қарапайым тілмен — ережелер біркелкі сақталуы тиіс шекара. Агрегат ішінде деректер бірге және бірдей ережелер бойынша өзгереді, ал сырттан жүйенің басқа бөліктері сол ережелерді айналып өтпеуі керек. Мысалы, сатып алу процесінде агрегат «Тапсырыс» болуы мүмкін: оның статусы, позициялары және рұқсат етілген ауысулар бар (мысалы, тапсырыс «Төленбесе» «Жеткізуді растау» мүмкін емес).
Воркшоптан кейін сізде жұмыс құжаттарына оңай тасымалданатын және дамыту жоспарына айналатын заттар жиыны қалуы керек:
- негізгі бұтақтар мен нұсқалар көрсетілген оқиғалар картасы (хронология);
- оқиғаларға байланған командалар тізімі, нақты бастамашылары көрсетілген (роль немесе жүйе);
- алғашқы агрегаттар және олардың шекарасы (қай жерде ережелер, қай жерде статустар, қай жерде тікелей өзгертуге болмайтыны);
- дау туғызатын орындар тізімі: терминология, ережелер, жауапкершілік бойынша айырмашылықтар;
- гипотезалар мен ашық сұрақтар: юристерден, қауіпсіздіктен, есептен, пайдаланушылардан не сұрау керек.
Қарапайым сапа белгісі: егер сессиядан бір күннен кейін сіз картаны ашып, «қай 5-10 нәрсені бірінші орнатамыз және неге» деп жауап бере алсаңыз — артефактілер жұмыс істеп тұр. Егер тек таулы сызықтар мен жалпы сөздер қалса, оқиғалар, командалар және ережелер жоқ болса, сессияны қайталау қажет.
Дайындық: адамдар, шекаралар, материалдар
Тиімді сессия стикерлерден басталмайды, дұрыс процесті таңдауынан басталады. Талаптарды жинау үшін бір жолақты құн ағынын алу жақсы — оны кездесу барысында басынан аяғына дейін өтуге болады. Егер бірден сатулар, қойма, есеп және қолдауды қамтуға тырыссаңыз, ұзын қабырға және аз келісім шығады.
Алдын ала шекараны анықтаңыз: процесс қайдан басталады (триггер, кіріс сұрауы, оқиға), қай жерде аяқталады (қайсысын «сәттілік» деп есептейміз) және не әдейілеп шетте қалатынын. "Алдын ала ерекшеліктерді жазып қою" әдісі көмектеседі: 3-5 типтік "егер...". Мысалы, егер сіз «серверлерді сатып алу және пайдалана енгізу» процесін талқыласаңыз, кепілдік жөндеу немесе құрал-жабдықты списыға шығару бөлек сессияға шығарыңыз.
Қатысушылар құрамы процесстің нақты жұмысын көрсетуі керек, ұйымдық құрылым емес. Әдетте 6-10 адам жеткілікті: процесс иесі/product owner, операциялар өкілі, аналитик, әзірлеуші, QA. Маңыздысы — шешім қабылдаушылар да, күнделікті жұмысты орындайтындар да қатысуы.
Рөлдерді бастамадан тағайындау керек, сонда кездесу шашылып кетпейді: фасилитатор ережелер мен темпті ұстайды, уақыт сақтаушы таймбокстарды бақылайды, хатшы нәтижені тіркейді, ал процесс иесі дау тудырған түсіндірулер бойынша шешім қабылдайды.
Материалдарды қарапайым ұстаңыз. Офлайн үшін қабырға, стикерлер және маркерлер қажет. Онлайн – қатысушылар курсорлары көрінетін және карточкаларды ыңғайлы жылжытатын кез келген тақта жарайды. Әдетте 3-4 түс жеткілікті (оқиғалар, командалар, сұрақтар, ескертпелер) және үш жазу ережесі:
- оқиғалар — өткен шақта («Тапсырыс расталды»);
- командалар — бұйрық райында («Тапсырысты растау»);
- агрегаттар — зат есімдер («Тапсырыс», «Шот»).
Егер шекаралар, адамдар және материалдар дайын болса, сессия жылдамырақ өтіп, нәтижесінде анық оқиғалар, командалар, агрегаттар және командаға арналған жұмыс тізімі шығады.
Қадамдық формат (1 күн немесе 2х2 сағат)
Бұл формат сізге тек «қабырғадағы карта» емес, әрі қарайғы нақты қадамдар алуды қаласаңыз сәйкес келеді.
1 күндік вариант (шамамен 3.5–5 сағат таза уақыт)
Қысқа ашылудан бастаңыз: не үшін жиналғаныңыз және бүгінгі жетістік не екенін айтыңыз (мысалы: оқиғалар картасы келісілген, бизнеске сұрақтар тізімі, алғашқы backlog жобасы). Әдеттегідей ережелер туралы келісіңіз: оқиғалар өткен шақта жазылады, формулировкалар туралы дау екі минуттан артық созылмайды, дау тудырған барлық орындар белгіленіп, ары қарай қозғалу.
Одан әрі қадамдарды темпті сақтай отырып орындаңыз:
- Лента оқиғалар: қатысушылар домендік оқиғаларды уақыт бойынша қояды, қайталанатындарды біріктіреді, тәртіпті түзетеді.
- Ауыртпалықтар және белгісіздер: қасындағы сұрақтар, қолмен жасалатын қадамдар, "қай жерде жиі бұзылады" деген орындар белгіленеді.
- Командалар және акторлар: негізгі оқиғалар үшін кім бастайды және қандай команда оған апаратынын анықтайды.
- Жүйелер мен интеграциялар: қай жерде автоматтандыру бар, қай жерде қолмен беру бар, қандай сыртқы жүйелер қатысады көрсетіледі.
Детальдарға батып қалмау үшін «алдымен кеңістік, кейін тереңдік» принципін ұстаңыз. Алдымен бастапқыдан аяғына дейінгі тізбекті жауып шығыңыз, кейін ең маңызды 3-5 түйінге тереңірек түсіңіз.
B2B жеткізу процесінің қысқа мысалы: «Жабдыққа сұрау алынды» → «Коммерциялық ұсыныс жіберілді» → «Келісімшарт қол қойылды» → «Жеткізу жөнелтілді» → «Құрал-жабдық қабылданды» → «Қолдау тіркелді». Әр қадамда көбінесе қолмен келісулер, қол қою құқықтары және интеграциялар (CRM, есеп, сервис-деск) тез көрініс береді.
Вариант: 2 сессия по 2 сағат
Егер адамдар бос емесе немесе домен күрделі болса, жұмысты екі кешке бөліңіз. Бірінші кездесу — негізінен оқиғалар мен проблемаларға арналған. Екінші — командаларға, интеграцияларға және нәтижені бекітуге.
Сессиялар арасында бір адам (әдетте аналитик немесе фасилитатор) картаны тәртіпке келтіруге жауапты: оқиғаларды бір стильге келтіреді, айқын қайталануларды алып тастайды, сұрақтарды 5-10 тақырыпқа топтастырады және 3-5 тар орынды белгілейді, қайда міндетті түрде қайта оралу керек екенін көрсетеді.
Қорытындыны кез келген форматта қатаң уақытқа сыйдырыңыз. Соңғы 15-20 минут ішінде: не келісілген, қандай сұрақтар ашық қалды (және кімде шар), команда бірінші толқынға не алады — тіркеңіз. Бұл воркшоптан кейін апта-аптаға созылған хат алмасуды үнемдейді.
Оқиғалардан командалар мен агрегаттарға қалай өту керек
Карта дайын болғанда оны тарихтан командалар мен агрегаттармен жұмыс істейтін модельге айналдыру қажет: commands және агрегаттар. Барлығын бірден жобалау қажет емес. Дау-жансыз бұл картадан көрінген мән және ережелерден бастаңыз.
Оқиғалардан мағыналы блоктар мен агрегат шекараларын анықтау
Оқиғаларды «бұл бөлік не туралы және кім жауапты?» деген сұраққа жауап беретін шағын фрагменттерге топтастырыңыз. Әдетте блоктар бір мақсат төңірегінде пайда болады: тапсырыс рәсімдеу, келісу, жөнелту, қабылдау, жабу.
Әр блокта агрегат шекараларын іздеңіз. Практикалық тәсіл: қай оқиғалар жиі бірге ұсталып, бірбіріне ұқсас ережелерді талап етеді және бірдей күй бөлігін өзгертеді — солар агрегат кандидаты болуы мүмкін.
Жақсы агрегат белгілері:
- бір жауапкершілік (мысалы, «тапсырыс», «жеткізу», «қабылдау акті»),
- ережелер бір жерде шоғырланған, жүйе бойынша шашылмаған,
- минималды көлем: ішіне тек ережелерді сақтау және өзгерістерді тіркеу үшін қажетті нәрсе ғана кіреді,
- өзгерістердің анық «иесі» бар: кім күйді өзгерте алады және қандай шарттарда.
Оқиғалардан командалар мен әрекеттер алу
Команда — бұл оқиғаны (немесе бас тартуды) тудыратын ниет. Әр оқиға үшін сұраңыз: «Осы болу үшін не істеу керек еді?» және «кім бастайды: пайдаланушы, жүйе, сыртқы контрагент?» Осылайша сіз пайдаланушы әрекеттері мен API деңгейіндегі командаларды аласыз.
Командаларды «етістік + объект + нақтылау» форматында ұстаңыз: «Тапсырыс жасау», «Тапсырысты растау», «Тапсырысты болдырмау себебі көрсетілген», «Жеткізуді тіркеу». Егер команда оқиға тудырмаса, ол тым техникалық немесе оқу ғана шығар.
Команданың сапасын тез тексеру:
- анық бастамашы бар (роль немесе жүйе);
- қай агрегатты өзгертетіні түсінікті;
- қандай деректер қажет екені айқын;
- шығуда нақты оқиғаларды күтуге болады.
Агрегат жанында инварианттарды бекіту
Инварианттарды агрегат қасында қысқа формулировкада жазыңыз: «жоқ», «әрқашан», «тек егер». Бұл картаны кейін тесттерге айналатын ережелер жинағына айналдырады.
Жеткізу процесінің мысалында: «Тапсырыс жасалды», «Тапсырыс келісілді», «Жеткізу жөнелтілді», «Қабылдау расталды» сияқты оқиғалар екі агрегатты көрсетеді — «Тапсырыс» және «Жеткізу». «Тапсырыс» қасында: "жеткізуді келісім болмаса жөнелтуге болмайды", "бюджет лимиті бар кезде ғана", "болдырмау себебі әрқашан сақталсын". "Жеткізу" қасында: "сериялық нөмірлерсіз қабылдауды растауға болмайды", "жөнелту тіркелмегенде растамаймыз".
Осылайша сіз оқиға → команда → агрегат + инварианттар байланысын аласыз. Бұл картадан тапсырмаларға өтудің көпірі.
Event Storming нәтижесінен backlog қалай жинау керек
Карта backlog-қа айналатын кезде оқиғаларды эпиктерге, тарихтарға және команданың бағалап, спринтке алатын тапсырмаларға айналдыратын бірліктерге бөлісесіз.
Алдымен картаны логикалық кесектерге бөліңіз. Эпиктерді процесс бөліктері бойынша («тапсырыс», «төлем», «жеткізу») немесе негізгі агрегаттар бойынша («Тапсырыс», «Шот», «Жөнелту») құрастыру ыңғайлы. Бір негізгі тәсілді таңдап, екіншісін тексеру үшін қолданыңыз, сонда маңызды шекаралар жоғалмайды.
Содан кейін оқиғалар тізбегін тарихтарға айналдырыңыз. Жақсы тәсіл: пайдаланушы мақсатын алып, ол мақсатқа жету үшін қандай оқиғалар болуы керек екенін тексеру. Картада үзілістер немесе даулы жерлер көрінсе, олар зерттеу тапсырмасы ретінде backlog-қа түседі.
Жұмыс шаблоны:
- бір сценарийді басынан аяғына дейін таңдаңыз (happy path);
- осы сценарийді іске қосатын және аяқтайтын 1-3 тарихты нақтылаңыз;
- келесі қадамды ашатын интеграциялар бойынша тапсырмалар қосыңыз;
- тәуекелдер мен белгісіздіктерді spike/зерттеу ретінде жазыңыз;
- ерекшеліктер (қателер, болдырмау, қайтарулар, бөлшек жеткізулер) үшін қайталаңыз.
Acceptance criteria-ді оқиғалар арқылы жазу ыңғайлы, себебі олар тексерілетін болады. Қарапайым формат: "X болғанда, Y пайда болуы тиіс". Мысалы: ""Өтініш мақұлданған" оқиғасы болғанда, "Өтініш жабдық сатып алуға жіберілді" қалып, жүйе статусын "Істе" деп өзгертеді".
Приоритизацияны үш өлшем бойынша ұстап отырыңыз: мәні, тәуекел және ашықтық. Мән — пайдаланушыға нәтиже беретін нәрсе. Тәуекел — қымбат сынуы мүмкін нәрсе (қауіпсіздік, заңдылық, қаржы). Ашықтық — интеграциялар мен инфрақұрылым, болмаған жағдайда басқа тапсырмалар жүрмейді.
Мысал сценарий: оқиғалар картасынан алғашқы тапсырмаларға дейін
Мысалы, воркшоп — мекеме үшін IT-ережелер мен жабдықтарды сатып алу және жеткізу процесі: қажеттілік пайда болудан бастап қабылдау мен аяқтау құжаттарына дейін. Бұл ұйым дербес ПК немесе сервер сатып алып, стандартты келісулерден өтіп, жеткізіп, құжаттарды рәсімдейтін типтік сценарий.
Қабырғада домендік оқиғалар тізбегі пайда болады: «Өтініш жасалды» → «Бюджет расталды» → «Жеткізуші таңдалды» → «Келісімшарт қол қойылды» → «Жабдық жеткізілді» → «Акт қабылданды». Бірден тармақтар көрсетіңіз: егер бюджет расталмаса не болады, жеткізу бөлшектелсе не болады, акт ақаулыққа байланысты қол қойылмаса не болады.
Сосын негізгі оқиғаларды командаларға айналдырыңыз: "Өтініш жасау" → "Өтініш жасалды", "Бюджетті келісу" → "Бюджет расталды", "Жеткізушіні таңдау" → "Жеткізуші таңдалды", "Жеткізуді тіркеу" → "Жабдық жеткізілді". Мұнда бастамашыны және ережелерді тексеру орнын (лимиттер, өкілеттіктер, мерзімдер) нақтылаңыз.
Кейін агрегат кандидаттарын белгілеңіз: қайда күй тіркеледі және қандай ережелер бірдей сақталуы керек. Бұл сценарийде әдетте пайда болады: «Өтініш» (позициялар, сомалар, статустар), «Келісімшарт» (реквизиттер, шарттар, нұсқалар), «Жеткізу» (накладнойлар, партиялар, сериялық нөмірлер), «Қабылдау» (тексеру нәтижелері, кемшіліктер, акт).
Содан соң алғашқы backlog жинауға болады. Барлығын бірден жазбаңыз: алғашқы релиздің мақсаты — ең жиі кездесетін жағдай бойынша сквозной жолды өткізу.
- Өтініш: жасау, позициялар тізімі, статустар «Черновик/Жіберілді»
- Бюджет: лимит ережелері, келісім қатынастары, растауды тіркеу
- Жеткізушіні таңдау: критерийлер, таңдау протоколы, шешімді тіркеу
- Келісімшарт: карточка, қол қою (күні/нөмірі), статус ауысулары
- Жеткізу және қабылдау: жеткізуді тіркеу, бөлшек жеткізу, акт қабылданды/қабылданбады
10-15 тапсырмаға жету үшін әр тармақты 2-3 нақты тарихқа бөліңіз: рөлдер мен құқықтар, өрістер мен валидациялар, статустар мен ауысулар, хабарламалар, қарапайым есептер, плюс 1-2 интеграция (мысалы, номенклатура және контрагенттер анықтамалығы). Осылай командаға алғашқы релизке нақты міндеттер шығады, ал карта келесі итерациялар үшін опора болып қалады.
Фасилитация: темпті қалай ұстап, терминдер туралы қалай келісу керек
Фасилитацияның басты қағидасы: алдымен домендік оқиғаларды белгілейміз, кейін детальдарды талқылаймыз. Егер топ ерте жобалауға, статустарға, өрістерге және интеграцияларға көшсе, карта өсуді тоқтатады, ал қатысушылар тез шаршай бастайды.
Бастапқыда «бөлменің ережелерін» айту және оларды үнемі еске салу пайдалы. Бұл әсіресе сатулар, өндіріс, логистика және қолдау арасында көп қиылыстар бар компанияларда маңызды: әр бөлімнің өз термині мен бір процесс туралы өз көзқарасы болады.
Әдетте жұмыс істейтін ережелер жинағы:
- оқиғалар өткен шақта жазылады: «Тапсырыс расталды», «Сервер жөнелтілді», «Қолдау сұрауы тіркелді»;
- дау тек оқиғаға немесе оның реттілігіне әсер ететін нәрсеге қатысты жүргізіледі; қалғанын «сұрақтар» бөліміне жіберіңіз;
- бір карточка — бір ой; сыймаса, екі карточка болсын;
- егер ілініп қалсаңыз, таймер қосып, шешім қабылдаңыз немесе "паркинг"қа жылжытыңыз.
Терминдік қақтығыстар міндетті. Фасилитатордың мақсаты — бәрінің орнына шешім қабылдау емес, қауіпсіз әрі жылдам келісімге келетін жол табу. Жұмыс техникасы: балама нұсқаларды қасқа жазып қойыңыз («клиент» vs «тапсырыс беруші», «жеткізу» vs «тапсырыс жеткізілімге беру») және сұраңыз: "Бүгін осы картада қай сөзді қолданамыз, әрі қарай қозғалу үшін?" Уақытша анықтама темпті сақтауға көмектеседі, ал ресми нұсқа сұрақтар тізіміне кетеді.
Ұяң қатысушыларды тарту үшін үзілістер жасап, бағытталған сұрақтар қойыңыз: "Сіздің бөлікте бұл іске не болады дереу?" немесе "Бұл оқиға болғанын қалай байқайсыз?" 30 секундтық "шеңбер бойынша" техникасы да жақсы жұмыс істейді: әркім бір оқиға немесе нақтылау қосады. Басым қатысушыларды шектеу үшін ойды карточкаға жазып, сөзді топқа қайтарыңыз.
Таймбокстар шексіз пікірталастардан құтқарады. Даулы сәттер үшін практикалық үлгі:
- 5 минут: екі нұсқаны немесе оқиғалар реттілігін қалыптастыру;
- 3 минут: әр нұсқаның салдарын айту;
- 2 минут: бүгінгі жұмыс нұсқасын таңдау және сұрақтың иесін тағайындау.
Темп төмендесе, қысқа резюме көмектеседі: "Бізде отгрузкаға дейінгі тізбек бар, енді қабылдау мен кепілдік сұраулары бөлігін толықтыру жетіспейді". Бұл фокус пен прогресс сезімін қайтарады.
Жиі кездесетін қателер мен тұзақтар
Ең жиі кездесетін проблема — мақсатты жоғалту. Сіз талаптарды жинап жатырмыз деп ойлайсыз, ал бір сағаттан кейін барлық нәрсе талқыланып жатыр: ерекшеліктер, интеграциялар, есептер, болашақ релиздер. Шекараны ұстап тұрыңыз: қай процесс, қандай өнім бөлімі және қандай уақыт горизонты талқыланып жатыр.
Типтік қателер және оларды тез түзету жолдары:
- Өте кең қамту. Егер бірден сатулар, есеп, логистика және қолдау болса, тоқтап, бір құн ағынын таңдаңыз. Қалғанын бөлек воркшопқа шығарңыз.
- Оқиғалар мен әрекеттерді араластыру. «Клиент төледі және біз жөнелттік» — бұл екі факті. Оқиға — болған нәрсе, команда — оқиғаны жасау үшін істелген әрекет.
- Дерекқор мен экрандарды жобалауға кету. «Кестеде status өрісі болады» немесе «форма сызайық» — ерте. Алдымен оқиғалар, ережелер және жауапкершілік шекаралары келісілсін.
- Процесс иесі мен шешім қабылдау құқығы жоқ. Егер екі бөлім дауласса және шешетін адам болмаса, топ ілініп қалады. Шешім қабылдай алатын немесе уақытша нұсқаны тіркей алатын адам болуы керек.
- Ашық сұрақтар мен келесі қадам тіркелмей қалуы. Стикерлер әдемі, бірақ әрекет жоқ болса, нәтиже нөл.
Формулировкалар шатасуына қарсы тәсіл: "бұл өткен шақта жазыла ма?" тексерісі. Егер жазуға келмесе — оқиға емес. "Клиентті тексеру" — команда, "Клиент тексерілді" — оқиға.
Тағы бір тұзақ — мінсіз процесті сызу және қайтарулар, қателер мен қолмен жасалатын айналымдарды ұмыту. Негізгі ағымды жасағаннан кейін қысқа түрде ерекшеліктерді қарап шығыңыз: қайсысы жиі бұзылады, қайда кідірістер пайда болады, қай шешімдер қолмен қабылданады.
Дауларға батпау үшін арнайы аймақ жасаңыз: кез келген дау 3-5 минуттан артық созылса, оны сұрақ карточкасына айналдырып, иесін және мерзімін тағайындаңыз.
Қысқа чеклист және келесі қадамдар
Сессиядан кейін нәтижені тез тексеріп шығу пайдалы, бәрінің есінде тұрған кезде:
- Оқиғалар картасы: оқиғалар өткен шақта, тізбекте үзіліс жоқ, акторлар анық (кім бастайды, кім нәтижені алады).
- Командалар: әр командаға бастамашы мен тексерілетін нәтиже жазылған (не өзгеруі керек).
- Агрегаттар: әрқайсының жауапкершілігі мен ережелері (инварианттар) бар, бір логика жүйенің әртүрлі жерінде қайталанбайды.
- Backlog: тапсырмалар құндылық бойынша топтастырылған, приоритеттер мен тәуелділіктер бар, әрі қарайғы нақтылауға келесі кездесу белгіленген.
- Тәуекелдер мен белгісіздіктер: дау тудырған жерлер белгіленген, оларды қалай жауып алуға болатыны анық (мәлімет, шешім, прототип).
Картада "саңылаулар" табылса, оларды чатта жабуға тырыспаңыз. Қажетті адамдармен 45-60 минуттық қысқа кездесу жинап, сол нақты бөлікті аяқтау жылдам болады.
Осы аптаға арналған келесі қадамдар
- Сөздік бекітіңіз: 10-20 негізгі термин және қысқа анықтамалар.
- Бірінші жиынтықты келісіңіз: қай 1-2 сценарий бірінші алынады және неге (мәні, тәуекел, тәуелділіктер).
- Жылдам прототип жасаңыз: экран ағыны немесе қарапайым интерфейс, жалпы нәтижені тексеру үшін.
- Интеграциялар мен инфрақұрылым жоспарын әзірлеңіз: қай жүйелерге тиелеміз, қандай деректер қажет, кім қолжетімділікті қамтамасыз етеді.
- Бақылау нүктесін тағайындаңыз: картаны қайта қарау күні, backlog жаңартулары және дау тудырған сұрақтарға шешім қабылдау мерзімі.
Егер жоба инфрақұрылымға (серверлер, жұмыс орындары, дата-орталық), интеграциялар мен 24/7 эксплуатация талаптарына тіреліп қалса, системдік интеграторды алдын ала тарту пайдалы. Қазақстанда бұл бөлікті жиі GSE.kz жабады: жабдықты таңдау және жеткізіп беру, интеграция және әрі қарайғы қолдау — воркшоп нәтижелерінің жұмыс істейтін шешімге тез жетуіне көмектеседі.