Съвет за development process

след минутка ще си го прочел.
Да ти е сладко

Много често точно един скръм фен дошъл от корпорация при нас все се оправдава как дизйна му се осира, защото изискванията не били такива в началото.
Тъй като той по принцип трябва да е един от старшите в екипа, следва че трябва да може да прави анализ и да предвижда нещата. Едно от 1те неща които ме учеха като почвах работа е "Пиши си нещата флексибъл"

Та какво става когато старшия програмист която роля не е само да коди, но и да прави дизайн и да развива продукта от техническа гледна точка, не направи нещата като хората в даден спринг и в някой си следващ спринт е нужен голям рефакторинг и то на тестван код от предишен спринт? Закасняваме със срока или омазваме нещата? Ами следващите спринове, там става още по-омазано?
А какво става когато това са непредвидени от този програмист важни неща за продукта? Скалъпваме ли? В кой спринт?

Whenever I'm sad, I stop being sad and be awsome instead.

Решението е да се оправи блокера в следващия такт и неспасяемия код да се направи изцяло в следващия такт - и това е СТАНДАРТНО за капак.

Ей, пустиняк...абе ти нормален ли си бе?
Всъщност явно не си...

Аз пък бих ти бил по един циганси шамар на всеки един "такт" от твоя страна:-)

Какво да ти пиша по-нататък като караш на общи съчинения?

Напротив, много конкретен съм... И ти зададох конкретен пример...Т.е. как се спира Sprint-а, при положение, че "от месец се работи по същия тоя Sprint" и 20 програмиста вече са написали един тон код срещу/върху бъга "concurrency issue"???

Честно казано, намерил си кой да питаш. По-добре питай wiz или roxy. Ма то тази scrumсвиня може да е v2 на бота зад wiz, знам ли.

[линк]

спринт не се спира
Точно това имах предвид като ти подсказах че ще се опитваш да засереш нещата - процесите не са за да се заобикалят а за да се спазват.
Като сте видяли че сте се осрали, забършете се и следващия спринт го изкарайте без памперси. Ясно ли се изразих? Ако сте чак толкова негодни - идете по строежите

ПП: изглежда не ти е хрумвало защо тактовете са толкова къси. Целта на упражнението е да се приключват нещата на малки но добре работещи порцийки - голяма работа че от некадърност някой си ще пропусне един такт. Ако си ти - предлагам да ти резнем бонуса за начало

"Много често точно един скръм фен дошъл от корпорация при нас все се оправдава как дизйна му се осира, защото изискванията не били такива в началото.
Тъй като той по принцип трябва да е един от старшите в екипа, следва че трябва да може да прави анализ и да предвижда нещата. "

1. Няма как да се осере дизайна по тоя начин понеже ПО-то няма право да променя изискванията след като такта почне.
2. предвиждат бабите със стъклените кълба.

"Та какво става когато старшия програмист която роля не е само да коди, но и да прави дизайн и да развива продукта от техническа гледна точка,"

3. дизайна не се прави от програмист а от архитект. Ти утре може да поискаш и свирки да прави - ей-ти го сър цър 435 готоФ!

"не направи нещата като хората в даден спринг и в някой си следващ спринт е нужен голям рефакторинг и то на тестван код от предишен спринт?"

4. Закъснявате и преебавате (най-вероятно) срока. Алтернативата е да преебете качеството или да не изпълните изцяло продукта по спекс - ти кое би избрал? Аз лично бих резнал спекс. За следващите спринтове - нищо омазано не става, всеки спринт си има своя беклог и не зависи от това какво става преди него - сам за себе си е. Естествено - за проекта като цяло не е весело.

"А какво става когато това са непредвидени от този програмист важни неща за продукта? Скалъпваме ли? В кой спринт? "

5. виж т.4, няма принципна разлика.


Принципно в началото се определя колко спринта трябват за да изпълните проекта. Ако не стигнат - най-правилен според мен е варианта да предадете проекта без част от функционалността - но добре работещ и НАВРЕМЕ.
За оставащата функционалност ще се предоговорите дали да се прави и колко ще отнеме да се направи.

спринт не се спира

А трябва мадъ факъ тестерче долно:-)

Точно това имах предвид като ти подсказах че ще се опитваш да засереш нещата - процесите не са за да се заобикалят а за да се спазват.

Добре бе пич...процесите трябва да се спазват стриктно и да не се заобикалят...Ок, това мога да го разбера. Не разбирам едно обаче, а именно:

При така поставения въпрос от мен как ТИ ЛИЧНО ще го спазиш?

изглежда не ти е хрумвало защо тактовете са толкова къси

Къси, къси...колко да са къси...Има ли значение колко са къси "тактовете" при положение, че при един малко по-сериозен "concurrency issue" проблем всичко отива на майната си?

Ако си ти - предлагам да ти резнем бонуса за начало

Баси омраза си ти...:-)))
Не е истина къф пустиняк си...:-))

Жив и здрав да си все пак де...повече с тебе няма какво да си кажем:-)

грешиш......сега ще ти вкара хомо-офертата, това е инфлексната точка на комуникацията ви в която става свалката

безхабернико

Аз лично в тая ситуация описах какво ще направя.

ПП: Типичния спринт е 1 месец, виждал съм и 2 седмици. Има значение колко са къси естествено - защото в най-лошия случай ще осереш работа за 1 спринт и поне няма да те уволнят преди да прецакаш и следващия
Ако си чак толкова зле че успееш да прецакаш целия проект заради архитектурно скудоумие - малко ще ти е да останеш без бонус, направо в карцера!

да го лапаш е при особени заслуги - ама ти си го знаеше преди още да му опиташ вкуса нали?

Аз лично в тая ситуация описах какво ще направя.

Ами аз нали през цялото време тва се опитвам да ти обясня бе клефук!!!

А именно, пустиняци като тебе съм ги гледал достатъчно.
Кво ми се обясняваш като млада девствена путка пред полов акт...

Как се спира Спринт при констатиране на "сериозен бъг"???
Как се слага същия тоя бъг (concurrency проблем) в back-log-a???
И в момента, в който го сложиш в в back-log-a - какво става със спринта мадъ факъ???

Аде бе scrum-master - а... или дай отговор на тоя елементарен/шибан/банален проблем - или си отпери два шамара и мирясай най-накрая?

я групата на шаро пак се пъне нещо и мен да замеси

не увъртай ами напиши дали вече се научи да четеш или още ти се привиждат неща дето ги няма?

пo paiп, no gaiп

съм одитирал проекти под скръм .....бих казал, че скръм = скръб

може ли да позная какъв е случая?

сигурно си бил най-печеното куче в кучкарник и понеже си гледал много умно някои гений е решил че много знаеш и те пратил да прецениш ферма с прасета

сигурно бирата и wqw и те са гледали умно и за това са дошли да помагат

видял си че прасетата нито лаят добре нито лижат добре и си решил че не могат нищо => значи не правят нищо (и нещата които правят са скръб)

познах ли?

До сега поне не съм видял успешена интграция на говеда

и аз не съм виждал интеграция на говеда в кучешка глутница ама ти си невероятен гений и може да продължиш да пробваш да интегрираш някое говедо, прасе или змей при вас

а интегрирани животни в подходящи ферми където са полезни съм виждал много

така можеш да си говориш с овцете на село където си отрасъл
Какво ще ми обясняваш бе смотан, не стига че само питаш - а в кухерицата ти не влиза и грам после.

Върни се и чети, няма да ти пиша по 100 пъти елементарни неща щото си тъп и не поемаш грам.

Чаткаш го агилето гледам... може скоро я скръм ментор да станеш, я директор на водопад. пропусна само да кажеш накрая 'celebrate your success' на края на всяка итерация :)
и да не забравя - абапа храни сапа

Не го храни АБАПА а съпорта, както и да е

4uh 4e v SAP minavat na kanban

Whenever I'm sad, I stop being sad and be awsome instead.

е популяризиран преди доста време във фирмата, но всеки тийм има свобода да избира. Аз лично не познавам хора по Канбан обаче, нищо че е обяснявано и в българския Лаб - може да има тимове, може и да няма.