Здравствуйте, Sharov, Вы писали:
S>Лиды -- тим-лид, глав программист для группы. Не каждый же программист будет докладывать скрам-мастеру, оне сначала доложаться лиду, тот -- уже скрам-мастеру. Как-то так. Наверное.
В моём представлении скраммастер это типа массовика-затейника, который проводит ретро и иногда дейли, следит за следованием процессу и разруливает конфликты. А вовсе не тот человек, который отвечает за выполнение проекта, его части или вникает в технические подробности.
Здравствуйте, Hobbes, Вы писали:
H>В моём представлении скраммастер это типа массовика-затейника, который проводит ретро и иногда дейли, следит за следованием процессу и разруливает конфликты. А вовсе не тот человек, который отвечает за выполнение проекта, его части или вникает в технические подробности.
Вроде так, но докладывают ему все енто по идее старшие разработчики\руководители группы, а не каждый по-отдельности.
Здравствуйте, Hobbes, Вы писали:
A>>Такое работает с маленькими командами, вроде как идеал — 5 челов H>Это круто если ты пишешь приложение для выгула собак, а если софт для боинга —
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Я тебе больше скажу, результат работы нужен больше заказчику, чем программистам, вне зависимости от наличия или отсутствия скрама. Вывод то из этого какой?
Очевидный. Программисту нужен интересный процесс и хорошая оплата.
Здравствуйте, sergey2b, Вы писали:
S>я несколько раз не толерантно одергивал индийскую коллегу что уже хочеться храть, а она 30 минут рассказывает как она добавила кнопку и две колонки на форме
Это неправильный скрам. По всем канонам, скрам не должен длиться более 10..15 минут.
S>сам же как пионер за минуту рапортую за неделю доваленны фичи A и B
Здравствуйте, Hobbes, Вы писали:
A>>Такое работает с маленькими командами, вроде как идеал — 5 челов H>Это круто если ты пишешь приложение для выгула собак, а если софт для боинга —
S>>я несколько раз не толерантно одергивал индийскую коллегу что уже хочеться храть, а она 30 минут рассказывает как она добавила кнопку и две колонки на форме
AK>Это неправильный скрам. По всем канонам, скрам не должен длиться более 10..15 минут.
Здравствуйте, sergey2b, Вы писали:
S>сам же как пионер за минуту рапортую за неделю доваленны фичи A и B
S>когда на скраме начальница из вышестоящего оффиса сказала что я мало работаю, я ей ответил а вы меня увольте, мне 15 минут надо что бы порнуху с диска скопировать и собрать свои книжки S>непосредственный начальник отвел в сторону и сказал не обращать внимание на дуру
Здравствуйте, Философ, Вы писали:
Ф>На кой этот цирк с конями нужен?
Как-то на одном проекте пояснили: чтоб все на работы приходили вовремя. Вроде как скрам — совещание и все такое.
Здравствуйте, sergey2b, Вы писали:
S>везет, нам говорят что это не изба читальня и документацию читать надо дома, а на работе работать
То есть тратить время на архитектуру запрещено?
S>я несколько раз не толерантно одергивал индийскую коллегу что уже хочеться храть, а она 30 минут рассказывает как она добавила кнопку и две колонки на форме
S>сам же как пионер за минуту рапортую за неделю доваленны фичи A и B
S>когда на скраме начальница из вышестоящего оффиса сказала что я мало работаю, я ей ответил а вы меня увольте, мне 15 минут надо что бы порнуху с диска скопировать и собрать свои книжки S>непосредственный начальник отвел в сторону и сказал не обращать внимание на дуру
Ну эта начальница судит о проделанной работе только по той минуте, за которую ты отрапортовал? Если так, и если принято растекаться по дереву — то учись у той индийской коллеги. Это тоже надо уметь — воду лить. Начальница врятли вообще поняла, о чем коллега растекалась, но впечатление о рабочей лошадке получила
И начальник твой тоже хорош, если он знает, что она неправа, и не стоит горой за свою команду, какой-же он начальник
Здравствуйте, Философ, Вы писали:
Ф>Вот, наступает час Ч, начинается митинг — разрабы рассказывают космосу о том чем они занимаются, что сделано, что сделать не получается. Ф>Разрабочик А не слушает разработчика Б — он продолжает в уме дебажить свой кусок, и вникать в дебри проблемы энжина чуваку, который гуём занимается совсем-совсем не интересно. Ф>Разработчик Б пытается не слушать разработчика А — чуваку, который неделю бьётся над битовыми картами в движке глубоко превать на очередную утечку оконные хэндлов, он вообще с трудом понимает что такое виндовые хэндлы и чем они отличаются от хэндлов GDI-объектов, и почему в 21 веке, в век WPF вообще об этом надо думать...
Ф>И т.д., т.е. ВСЕ пытаются не забивать друг другу голову задачами своих соседей — от своих голова пухнет.
”Жить стало лучше... но противнее. Люди которые ставят точку после слова лучше становятся сторонниками Путина, наши же сторонники делают акцент на слове противнее ( ложь, воровство, лицемерие, вражда )." (с) Борис Немцов
Здравствуйте, CreatorCray, Вы писали:
Ф>>Сам-то сейчас сможешь, навскидку, сказать разницу объектами пользователя и объектами GDI в винде? Иконка — объект пользвателя или GDI, а битмап? CC>HBITMAP — GDI CC>HICON — не GDI CC>
Зачем ты держишь в голове эту дурость? Ещё и работаешь в эппле.
Здравствуйте, Александр Кузнецов, Вы писали:
АК>В нормальной ситуации — не космосу, а коллегам.
Это намёк на то, что коллеги ближе к хаосу, чем к космосу, что ли?
АК>А что они тогда делают на общем митинге, если у них принципиально разные и заведомо не пересекающиеся никак задачи?
У них может быть общая задача. Например, у них команда, которая какой-то сервис пилит. Кто-то там технологию пиит, что-то её в микросервисы заворачивает, кто-то клиентов под это срагает на разные платформы кто-то клиентов, в смысле людей ли организации, курирует и т. д...
Общее дело, общие задачи, все понимают что для чего нужно. И т. д.
АК>Скрам-митинг (не по форме, а по сути) нужен тогда, когда у людей есть частично пересекающиеся задачи и: АК>1. изменения одного могут афектнуть работу другого. При этом узнать о таком без контакта с коллегами можно будет только по факту, и не гарантированно, что сразу. АК>2. один разработчик может что-то знать про работу другого и может что-то подсказать. При этом первый разработчик может тупо не знать, что можно подойти и спросить.
3. Люди просто делают общее дело.
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Философ, Вы писали: Ф>На кой этот цирк с конями нужен?
Очевидно, чтобы его продавать.
Молодому и темному поколению айтишников, матерые капиталисты быстро скормили в настоящем дешевый кокс, с обещанием будущей нирваны.
Финансовый бум взинтивший зряплаты, порадил кучу хомячья занимавшееся формоклёпом на дельфи, C#, а потом еще и копровеб. Выкрики и подбадривания: "это новое, модное, молодежное, IT — не для средник умов!!!" (такое только до первого ревью) разогнало рост хомячья в геометрической прогрессии. Естественно, огромный рост молодняка, как у вправлении так и подчиненнии породил проблемы управления. Неграмотный молодняк не кинлу взор в историческую перспективу управления, на базе которого было сделано все, что сейчас их огружает и тут подоспели матерые капиталисты на горячий рынок. И быстро предложили XP, Scrum, Kanban, Less, SAF и прочий шит, треннинги, с отговорками, что тренеру по плаванию не обязательно плавать, главное знать как тренировать)))
И Agile зашел, а дабы его гиперболизировать, с какого-то перепугу начали сравнивать его с Waterfall и говорить, что Waterfall это днище. Хотя сам автор в Waterfall сказал, что это лишь первая формализация процесса разработки и при даже Waterfall в то время уже подразумевал итеративность.
he first known presentation describing use of such phases in software engineering was held by Herbert D. Benington at the Symposium on Advanced Programming Methods for Digital Computers on 29 June 1956.
в 1956 году комп потреблял как завод и был неимоверно дорогим, но об итеративности уже тогда говорили, позже объясню почему.
Далее Rational Software, Айвар Якобсон, Гради Буч и другие формализуют процесс разработки и на свет в итоге появляется RUP, который очень объемно и детализированно описывает процесс разработки, вместе с итеративностью.
Примерно в тоже время микрософт создает MSF, в которой (методологии) учитывает социальный аспект.
Потом Появляется Кент Бек со своим XP, в котором уже папахивает невежеством производственных и управленческих процессов, но по прежнему есть рациональное зерно. Меняется подача материала. Если RUP и MSF это инструментарий, который подразумевает, что у пользователя достаточно мозгов, чтобы его применить во благо, то XP говорит, делайте так — и будет вам счастье.
А потом начинают подавать скрам, с идеями, которым уже 100500 лет и корни которых уходят в производство. И IT проект зачастую проще и легче, чем даже небольшое производство. Потому что на производстве в случае небольшой ошибки можно потерять полностью все изделие или партию, в IT revert, restore, restart и все живы и целы. По зависмостям IT команда напоминает бригаду интеллектуальных таджиков (если высоко квалифицированные, то это авторские таджики =) ), у которых есть фронт работ и им всего лишь надо скооперироваться, чтобы быстро найти решение проблеме или задаче.
Индустриальный век достаточно много решил разнообразных задач и итеративносить это было именно то, что двигает проект/продукт/изделие вперед. При разработке чего-то абсолютно нового всегда делается, модель, пробный обраце, опытный и так далее, та же самая итеративность. ОТК (отдел тех контроля) те же QA и тесты, при чем они присуствуют на многих этапах и та же гибкость. Вся строгость обеспечена разумностью ее примененияи и не более того, но прнцип гибкости — залог эволюции и адаптации. При этом реальное производство куда сложнее, чем средней IT проект, который пишут два-три стартапера.
Для простоты понимания скрама, всего его метрики свели в одну scrum velocity и story points, крайне нечеткую модель поведения и результатов работы обкладывают одним показателем (физ мат ау), который на практике выглядит как курс самой волательной валюты.
Если говорить в наши дни, то ни одна методология особо и не нужна, нужно управление. Собрать команду из людей которые хотят делать определенный продукт и делать его хорошо, а самое главное задача руководителя убирать всевозможные препядствия на пути к достижению цели.
Вместе должны сидеть и взаимодецствовать люди, которые целиком и полностью отвечают за конечный продукт, а не так, что вася пилит проект А, а петя проект Б, но стендап им необходим. Точно так же как и планнинг покер — булшит, минута которого мегадорогая, ровно как и ретроспектива.
Все сидят вместе и могут сразу сказать руководителю о том, что их не устраивает, да и менеджер сам должен видеть и устранять препядствия в работе, администраторы нужны в гардеробе.
Нормальному менеджеру методика не нужна, а г-но менеджеру не поможет ничего.