Съвет за development process

"С естимейшъните е същото - има хора, които ще ти кажат колко дни ще отнеме горе-долу, има такива дето като ги питаш колко сложна им се струва задачата от 1 до 5, те гледат умно и мълчат. "

Разликата между опитния и неопитния - единия знае какво може, другия нищо не знае...

не работя ве, нали в САП не се работело било и т.н.
Беги да правиш интервюта на новобранките и студентите без знания но с потенциал

но пропускаш 2 неща:
1. след началото на такта не се допускат промени в дефинициите от страна на продъкт оунъра
2. след като програмиста не разбира задачата - не я приема, вместо да я вземе и после да обяснява какво и как било

Хората които нарушават такива елементарни правилца да си патят от главите! Къде точно е проблема в скръм тук? Проблем има от заобикалянето му в изброените от теб случаи.

ПП: Може да се случи програмист да се разболее - и така да пропусне такта, това обаче е съвсем друга бира.

По скръм програмиста сам си взима задачите, никой не му ги налага насила нито му определя насила срокове (реално срока идва по естествен път = 1 такт, колкото е избран да бъде такта). Скръм мастъра няма правомощия да налага насила задачи. На скръм мийтинга пък не присъстват хора като продъкт оунъра - така че как може някой да насилва друг?

Мисля че в повечето случаи хората не смеят/могат да отказват просто.

точно така спекулативно си заминаваш - то туй е и спекулата, риск печели-риск губи.
Етапите обикновено са няколко (писмена забележка за несправяне със задължения, лишаване от бонус, местене в съппорта, уволнение), но и уволнението за несправяне с работа си го има хехехе!
Според фирмите, и без това гаражейките така или иначе не ги броя за фирми с 1-2 изключения.

ПП: Абе гаргамел, ЕйсМен-а досега опяваше как скръма давал колективна безотговорност

си одитирал като не го разбираш скръма?
Да те .. в одитора, сигурно и одитите ги разбираш колкото да интервюираш студенти

Скръма дава перфектна прозрачност и никой няма нужда да загрява по 20 минути, все пак това е ежедневен мийтинг и ако човек не може да помни както е правил вчера и какво го чака днес - къде изобщо е тръгнал програмист да става

Много се кефя баце на такива лешпери като тебе, дето Scrum-а са го чели само на книга и/или са им "разправяли" за него:-)

Скръма дава перфектна прозрачност

Кво да ти кажа...то да се чуди човек откъде да започне...:-)
Ти да не си решил да ставаш скръм мастер, а?

Я разкажи как върви Scrum-a в Sap Labs-а...Нали си там вече от 10 г...:-)
Или познанията по Агилето не само от QA-а?:-)

Колкото до това:
Хората не "работят" като тебе - да симулират дейност

Ми то в SAP-a са най-големите скътавки и симуланти...Сигурно заради "добрата имплементация на SCRUM-а" е така...де да знам...:-)

Зависи от проекта. Ако има система в продакшън и има критичен дефект, как точно скръммастерът ще обясни, че екипът е по средана та спринт и не може да се работи по дефекта . Просто издиша работата. Също така ако никой не си хареса даден таск, какво правим ?
За проектче, което е във фаза на начална разработка със сработен екип съм съгласен, че повечето итеративни процеси ще са подходящи.

ти може да си гледал по книжки мой човек - аз го гледам наживо кажи речи 3 години (щото от толкова е в употреба при нас). Погледах го и другаде, не в България - та не ме кръщавай за неща дето са ти тотална мъгла.

Ела да ме разсмееш и ми обясниш сега за него, както хубаво ми обясняваш и за САП (фирмата дето я познаваш пак само от четене на книжки)

Вярно е че в тази фирма може да се скатава, но това вреди най-вече на скатаващия. Не че някои хорица изобщо могат да го проумеят.

е вече предаден на съпорта, оргиналния тим изобщо не се занимава с него (не че е от значение тима - но това вече не е проект в дивеломпънт изобщо).
Я иди на Уикито на СКРЪМ-а и огледай какво прави човечето наречено Продъкт оунър - после ела и си отговори на въпроса ако можеш. Сам ще видиш колко е нелеп.

Случва се никой да не иска даден таск, отнема известно време и уговорки - но таскове не остават. И не, не се натриса насила - а човека който го вземе получава друга компенсация.

Не бе отовреняк...обясни ми следното:

как е възможно да се съчетаят тези две неща:
Вярно е че в тази фирма може да се скатава, но това вреди най-вече на скатаващия.
И следното:
Скръма дава перфектна прозрачност и никой няма нужда да загрява по 20 минути

Искаш да ми кажеш, че в САП-а се уволняват хора заради "SCRUM прозрачността" ли?:-)))

Аз пък съм сигурен в едно...ти никога, ама никога не си участвал в истински Scrum проект...може да си ходил в командировка, ама това не променя нещата...

Виж сега, има проекти, които се пускат в продъкшън след година-две разработки и системите работят поне 5 години. Да твърдиш, че оригиналният тим не се занимава с такъв проект е доста елементарно. Просто на този етап Сръм-ът е неподходящ поради изброената от мен по-горе причина.
Не ме разбирай погрешно, когато проектът е "предаден на съпорта", съпортът си върши работата като казва "Ало" и решава тривиалните проблеми. Но само с него не се изчерпват нещата.
За препоръката за Уикито - мерси, но не е необходимо - член съм на ScrumAlliance от няколко години.

нещата са елементарни:
ако искаш да се развиваш професионално, не скатаваш (1). Пишеш много код, учиш много и пробваш много. Така можеш както да растеш в сегашната си компания, така и да скочиш на по-високо стъпало в друга.
Скръма наистина дава прозрачност (2) и както вече писах (а ти не си имал капацитета да дочетеш целия ми постинг) човек няма какво да загрява за да обясни какво е правил вчера и какво ще прави днес (3) - а това е което прави на ежедневните скръм мийтинги.
Как се съчетават тези нещица ли? Не е задължително да се съчетават понеже (1) не е последица от (2) и (3).

Относно САП не виждам къде съм писал че уволняват заради скръм-визибилити.

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

ПП: Не ходя в командировки, нямам и намерение Но не се и затварям само в САП.

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

е те отидоха в сап, давали им били кебапчета и не работели .....отделно им обяснявали колко яко е скръм-а

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

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

не само ти е необходимо а и ти е наложително - за Уикито става дума
Изглежда "членството" ти може да ти върши работа само ако е нанегланциран хартиен носител...

Провери ли за П. Оунъра като ти казах - или продължаваш да се чудиш? Може би след като провериш - ще ти се изясни що за скръм изобщо може да има един проект във фазата на поддръжка.

Май ти звучи доста сложно след като имплементацията на проекта стигне зрелостта си - да се направи хендоувър на съпорта (който се занимава и с бъгфикс вместо елементарната ти представа да вдига телефоните - има няколко нива)? В цитираните от теб срокове екипа ще разработва 2 години след което съпорта ще се занимава още 3 години с оплакванията от клиенти. Доста кратък срок ама сигурно и великите проекти които си виждал са ... доста жалки Типичното време за поддръжка на сериозен софтуер е 10 години. По твоята логика един тим трябва да работи по проекта 12 години (2 + 10) вместо да го предаде след 2 години и да работи по още 5 проекта (10/2=5)? "Умен" си няма що - и имаш адски "продуктивна" логика хахахаха

ме научи как да работя с потенциал и без умения хех, нали това ти беше специалността, Смехурко!

ще пусна един мейл ей сега, че не процесваш ЦСН-чета и германското правителство ще спре да дотира сап заради тебе