Search
Write a publication
Pull to refresh
-2
0
Евгений Затока @eugenvz

Пользователь

Send message

Может я слишком хорошо думаю о соответствующей ИТ инфраструктуре, но, тем не менее, допускаю, что пограничный контроль и ФНС могут неплохо взаимодействовать :-) То есть вся работа может превратиться в неоплачиваемый труд заграницей :-)
Может, конечно, я ошибаюсь.

Добрый день.
Интересно узнать с точки зрения налогообложения с учётом того, что работали за пределами РФ на компанию в РФ. Или же есть отдельные представительства компании?

Очень много букв :-), но, в общем, соглашусь.
Ещё добавлю фразу-вопрос одного топ-менеджера про то, зачем Agile'ом называть здравый смысл.
На мой взгляд, различные фреймворки (XP, Scrum, DSDM и т.п.) — это способы понять, о чём Agile, но беда в том, что некомпетентность всё развращает.

Олег, привет!
Интересная статья, правда я немного удивился, когда
в свете рассматриваемой темы не нашёл в списке литературы книгу «Чек-лист» (Атул Гаванде) :-)

На «подумать, проанализировать» и т.д. в Agile есть понятие «spikes», если что.

Я снова получу сейчас минусы, на которые, мне, в общем-то всё равно, но снова и снова вижу посты «знатоков» Agile и Scrum.
Ваша фраза «Спринт должен заканчиваться релизом...» уже говорит о том, что точно не на вашем текущем уровне понимания методологии рассуждать о её будущем. Ознакомьтесь сначала с матчастью, а, то, как опять же таки, если вернуться к вашей статье, ваши рассуждения выглядят не больше, чем рассуждения пролетариата о руководстве страной.

— Твоя судьба, Джон! – крикнул Боб. – В провале проекта виноват только ты! Команда здесь ни причем, они – просто разработчики, они делают то, что ты скажешь! Как ты стадо гонишь, так оно и идет, понимаешь, Джон?

— Понимаю… — сокрушенно сказал Джон и снова опустил голову.

— Ты был прекрасным разрабом, и я никогда не думал о том, чтобы сделать из тебя тимлида. – продолжал Боб на повышенных тонах. – Это азбука, аксиома: хороший разраб – это не хороший тимлид. Но ты меня… Нет, не обманул – просто запудрил мне мозги своим скрамом, и я решил – вот, вот он, тимлид нового поколения! Инициативный, вдумчивый, ищущий, не замкнутый в стереотипах! Тот, кто мне нужен! Как же я ошибся!


После вышеприведённого блока я окончательно убедился, что автор заметки не знает/понимает, что такое Scrum. Дальше читать не стал.
На Хабре тема «обсёра чего-то отдалённо напоминающего Scrum» довольно хайповая, поэтому не удивлён в количестве плюсов у данного опуса.
Как я (и не только я) уже здесь писал, Скрам и вообще гибкий подход — это про ВЫСОКОпрофессиональных программистов и сотрудников в принципе.
Уровень организации труда (дисциплина, саморганизация и т.д.) должен быть на порядок выше, чем при более традиционных подходах. Иначе это хаос, негодование, потеря времени и денег.
Скрам — это, скажем так, одна из реализаций Agile.
Agile использует итеративную модель.
Полагаю, что отличий здесь не стоит искать.
Верно в отношении того, что на Daily проблемы не обсуждаем, а обозначаем.
Насчёт их решения не понял, почему теряется день. Если проблема важная, то никто не мешает её обсудить сразу после Daily. В общем вопрос организации своей работы, в частности, вопрос приоритизации.
Я как раз от крупных компаний и отталкивался ;-) и прекрасно знаю, что в первую очередь СМ это почему-то психолог/психиатр/психоаналитик :-)
Согласен с вами, что карго-культ, который в итоге получается, ничего кроме негатива не вызывает.
Об этом в том числе я и писал.
Я смотрю на комментарии и понимаю, что многие восприняли мою статью, как оду Скраму, как к призыв к тотальному переходу на него. На самом деле это не так, но каждому я не собираюсь это доказывать.
Эта статья на «задуматься», а не «мы все в Скрам!».
1. Были вполне себе профессиональные работники.
2. В другой сфере деятельности, скорее всего могли бы. В той, где я это наблюдал, со Скрамом было эффективнее.
3. В процессе сбора статистики и пока она в плюсе.
4. См. п. 3.
5. Планирование по Скрам в наших реалиях позволяет сэкономить очень много времени, а значит и денег.
Я считаю, что даже специалистам высокого класса можно было бы извлечь пользу из гибких методологий.
В ваших сообщениях чувствуется «боль потери времени на совещания». Это может быть вызвано тем, что:
1. Может Скрам в принципе не подходит для вас (Скрам — не серебряная пуля).
2. Может нет реального понимания, как правильно проводить эти совещания. Нет «того СМ», который должен был объяснить, что к чему.
Одна из интересных вещей, которую я в своё время открыл в Скрам — это то, что оказывается в нём тоже есть планирование :-) Причём даже посерьёзнее в некоторых моментах, чем в старом добром Waterfall.
Ещё раз: я не склоняю всех к сожительству Скраму. Просто то, что часто называют Скрамом, как правило, таковым не является.
Не знаю, что там с новообращёнными, но настоящие СМ свои ошибки признавать могут (да, я и такое видел). В каждом случае, почему Скрам не работает разбираться надо. Может его вообще не стоит в конкретном случае использовать (повторюсь, что я не за то чтобы Скрамом затыкать все дыры)?
Более того, знают текущее состояние команды, и у них обязательно есть план по тому, как команде двигаться дальше.
Я вас уверяю, что у большинства скептиков округлятся глаза при вопросах про метрики.
Начнут рассуждать, что сейчас всё хорошо, и будет обязательно лучше.
Беда вот только цифр обычно от них не допросишься…
Вы выдали ключевую фразу, которую я «подрежу» слегка:
Была бы заинтересованность
.
Смена методологии очень часто заставляет выйти наружу реальную заинтересованность (читай производительность, эффективность и т.п.) человека в работе. И скорее именно это уже не нравится человеку, а не «гибкость» той или иной методологии.
Это про частые реалии и здесь я спорить не буду. Те, про кого вы написали — это не PO и, соответственно, это не команда. Есть ещё одна схожая ветвь, когда без стейкхолдеров «типа PO» начинает в конце спринта неприятно удивляться результату, выданному DevTeam. И это тоже не PO и не команда.
Но не только в книжках, но и в жизни я встречал и работал с командами, которые были единым целым — Scrum Team. Там, в общем-то было без сюрпризов и без «размываний» и прочих «размазываний» ответственности.
В одном из своих комментов я уже ссылался на одно интервью, где речь шла о совсем других компетенциях (более высокого уровня), когда идёшь в гибкие методологии.
Да, последний абзац довольно ходовой и в наше время :-)
Но, пожалуй, всё это больше про «Скрам, как карго-культ», что лично я абсолютно неприемлю и считаю, что подобный подход в основном и бросает тень на фреймворк.
Вы ошибаетесь, мне никто ничего не продавал.
Что касается ответственности, то в итоге она на PO, например. Он отвечает перед стейкхолдерами. Так что, как минимум, одного ответственного отыскали.
Если вы делите PO и DevTeam, то это уже не команда (то есть не та самая Scrum Team).
Да, так и есть.
В одном интервью очень правильно заметили, что гибкие методологии требуют более высокого уровня компетенции, проектной и профессиональной дисциплины. В ином случае получаем хаос, потерю контроля, а, значит, и денег.
tangro, Ermit, maxzh83, geher,
Да, отчасти про это и статья.
Я, ровно как и создатели Скрам, не считаю Скрам серебряной пулей. Всему есть своё применение. Я также абсолютно не призываю «натягивать сову на глобус» (то есть использовать всем только Скрам).
Речь о том, что не вникнув в суть чего-либо (в данном случае был выбран Скрам, а вообще можно к чему угодно применять) начинается череда незаслуженных оценок, негатива и пр.
1

Information

Rating
Does not participate
Location
Россия
Date of birth
Registered
Activity