Здравствуйте, Vladek, Вы писали:
V>2. Бюрократия. Ежедневные отчёты заказчику, ежедневные отчёты посредникам, митинги, трекеры времени, графики. Отношение как к фрилансеру на почасовой оплате, который часто врёт.
Написал бы одним словом — Agile.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Vladek, Вы писали:
V>Похожая тема про другое, а мне гораздо интереснее, почему вы сами решаете уйти или сменить место работы.
V>Я убежден, что работник всегда внутренне мотивирован на работу и всегда работает на пределе своих возможностей. Работодатель работника может только демотивировать.
ИМХО не всегда так. Бывает работаешь себе спокойно в одной конторке:
и начальство вроде более менее адекватное, лишнюю бирократию конечно разводит но совсем чуть-чуть,
и коллектив вполне неплохой, не то чтобы вы прям дружите, но вполне нормально общаетесь,
и проект, не то чтобы такой уж интересный, но вполне неплох,
и код, конечно не идеален, но тоже не ужас-ужас, вполне можно разобраться, что к чему, даже на рефакторинг иногда время выделяют,
переработки хоть и бывают но редко, обычно только перед релизами, ну или сразу после (если вдруг что-то накосячили),
система работает относительно стабильно, критические баги случаются редко, настроен Continious Integration, код более менее покрыт тестами (далеко не весь конечно, но все-таки покрыт),
и зарплата, не то чтобы большая, но вполне рыночная.
И вот сидишь ты такой уже не первый год, уже неплохо разбираешься в системе, фиксишь себе баги, добавляешь новые фичи, вроде бы все хорошо, все номально, вроде и движуха какая-то идет постоянно, новые фичи, новые баги, но вдруг понимаешь, что этот день сурка тебя уже достал!!! и тебя все задолбало, и надо срочно валить отсюда, пока в овощ не превратился. С другой стороны понимаешь, что на новой работе вполне может быть и начальник самодур и говнокод и постоянные переработки. Но в итоге все равно увольняешься.
Здравствуйте, Vladek, Вы писали:
V>Похожая тема про другое, а мне гораздо интереснее, почему вы сами решаете уйти или сменить место работы.
За время работы в компании, я обычно раз 10-20 успеваю решить что вот сил больше нет ухожу (причин море, включая фазу луны и то, что обед был не вкусный). Потом хожу по рынку, говорю с человеками из других компаний и понимаю что погорячился, силы есть, всё хорошо, т.к. вокруг сильно хуже. Бросаю это дело
Но иногда во время таких метаний попадается что-то, от чего сложно отказаться и происходит смена работы.
еще однажды видел такую прикольную вещь.
в компании работало несколько программистов-старожилов и они постарались вложиться в job security. то есть все сделать так, что без них вообще никто никогда не разберется как это делается. однако же, спустя достаточно много лет, они задолбались и наняли много свежих программистов, чтобы на них свалить саппорт, а сами больше уходя на менеджерские позиции. проблема была в том, что все было сделано так через жопу, что, несмотря на куда больший штат саппорта, количество проблем только росло от спринта к спринту. вылезла фундаментальная проблема, что заложенные изначально принципы "без нас никто не разберется" при росте компании поставили все процессы раком. и, в приниципе, тут бы взять старичкам и сделать все по-человечески, слушая фидбек новичков. но по сути нафиг им это надо? они и так были нужными, а теперь стали вообще критичными для компании. спринты же превратились в бесконечную борьбу с проблемами, которых вообще по идее быть не должно.
в итоге у всех сложилось впечатление, что "с этим надо что-то делать", но железобетонные спринты говорили только о том, что нужно очень быстро катить квадратное и никакой самодеятельности
люди реально в личной беседе понимали в чем проблема, но железобетонность спринтов не давала никакого шанса реально исправить проблему. для этого нужно было просто реально свободное время, а его вообще не было.
Здравствуйте, HFTMan, Вы писали:
IT>>Сколько у вас человек в команде и какого они уровня? HFT>Agile не масштабируется на команду больше 20 человек, ну с натягом 25 человек(совсем край), но это уже при отлаженном до швейцарских часов процессе. HFT>Оптимум не больше 15 человек.
Как пишут апологеты, оптимальный размер 6 +- 3, т.е. 3-9 человек. Больше 13-ти аджайл перестаёт работать совсем. По моим наблюдениям примерно так и есть. Думаю, это связано с тем, что в группе из пяти человек всегда найдётся минимум один балабол. И если в группе из 5-10 человек его (или пару таких) быстро заткнут и поставят на место, то при наличии таких 3-х и более у них образуется кворум и хрен ты их уже остановишь. Тем более, что в большом коллективе из 15 человек народ ведёт себя по-другому, более официозно, и воспринимает такую болтовню как что-то само-собой разумеющееся и складывается впечатление, что вот это и есть настоящий аджайл. В результате любой митинг превращается в бесконечный трёп нескольких балаболов.
У нас количество sprint participants периодически доходит до 27-ми. При этом чтобы высказаться по теме нужно вклиниться в бесконечный галдёж, куда тебя пускать никто не собирается. Можно только либо повысив голос и не очень культурно прервав докладчика, либо забить совсем и решить всё после митинга. Либо подождать. Но пока будешь ждать трындёж съедет на другую тему и ты будешь выглядеть в определённом смысле тормозом. В общем, веселуха. При этом большая часть народа сидит и откровенно зевает и занимается разглядываем экранов телефонов. Т.е. имеем типичное комсомольское собрание времён совка — 3-4 докладчика в президиуме и скучающую аудиторию, с нетерпением ожидающую концовку мероприятия.
HFT>Процесс разработки более масштабных проектов надо пилить именно на такие куски, чтобы части этого масштабного проекта разрабатывались командами именно такой численности.
Это всем известно. Не известен только правильный критерий распила. Как пилить будем? По функционалу? По этажам/странам где-кто сидит? По уровню/полу/рассе/сексуальной ориентации?
Пилить по функционалу, наверное, правильнее всего. Но это обязательно приведёт к удорожанию проекта, если его функционал не предназанчен для такого распила, увеличатся сроки согласований и простоев, появятся лэйеры, интерфейсы, сервисы, протоколы и пр. лабуда там, где оно нафик не нужно. Моё начальство во-время смекнуло и на такое не пошло, но пилить-то надо! Распилили. По регионам. Две команды, один пул задач. Т.е. формально у нас две команды, но по сути у нас только статус митинги отдельные, всё остальное всё равно делается одним колхозом.
HFT>Проекты были разные, и коробочные(несколько штук), и инфраструктурные(т.е. потребителями являются несколько команд коробочных продуктов), численность именно всей команды была от 6 до 20+ человек(в компании с кол-вом команд разработки в несколько десятков проектов и общей численностью R&D 2000+ человек).
Несколько проектов за какой срок? Если это коротенькие типовые проекты максимум на год, максимум два, то вполне возможно, что аджайл даже можно сюда притулить. Особенно, если проекты типовые.
HFT>Самый большой по кол-ву участников проект был в таком составе: менеджер проекта, два архитектора в пике, потом один (потому что потребителей нашей условно облачной инфры было чуть ли не десяток других команд и много надо действительно подумать над архитектурой), тим-лид команды разработки(он же и ведущий программер был, хотя по факту мог быть еще один ведущий), несколько синьоров, несколько обычных девелоперов, парочка джунов, тим-лид команды автотестирования, несколько синьоров автотестеров/просто автотестеров(по факту они программеры же, но пишут автотесты, а не бизнес-код), один-два аналитика(часто обслуживали не только наш проект), один-два дизайнера(тоже обслуживали несколько проектов), это те, кто конкретно работали над проектом. Но при этом еще были из бизнес-дивизиона персоналии, выступающие как заказчики продукта(они на нашу текучку вообще не завязаны были), отделы эксплуатации и тех.поддержки, которые этот самый продукт в продакшене эксплуатировал и саппортил(куча народа, которая кучу же и других проектов обслуживала, а не только наши).
И как вы распределяли задачи между джуниорами и синьорами/архитекторами. Аджайл ведь предполагает, что в команде все равны и любой из команды может выбрать себе задачу по душе. Это, кстати, ещё одна аджайл бредятина. Типа разбиваем задачу на несколько частей. Первую часть берёт на себя какой-нибудь джуниор или криворучка. Вторую часть — ручки из жопки или "бывший кобольщик/жалко выгнать старичка". И так далее. И вот когда 95% задачи уже типа сделано, то начальник, понимая, что это — жопа, выдёргивает какого-нибудь синьёра и поручает ему всё нахрен переписать, только по-тихому, чтобы не обидеть джуниора/криворучку/ручку-из-жопки/старичка. Ведь у нас калабарейшин и тим билдинг. Люди могут обидеться, а так с людями нельзя. Раньше их никто к этой задаче не подпустил бы. Тот же самый синьёр сделал бы её в одно рыло в более короткий срок и один раз. Но в аджайл это никак низя.
HFT>Не первая попытка порвать с кровавым энтерпрайзом, но надеюсь окончательная, надоел он мне, чем меньше людей участвует в проекте, тем мне с некоторых пор комфортнее и приятнее работать по причине минимизации кол-ва политики в работе.
Проблема не в самом энтерпрайзе. Точнее не в задачах, которые там решаются. Проблема в том, что большое начальство, проникшись идеей, начинает её педалировать с максимальным старанием. Хотя это и понятно. Модная инициатива — хороший бонус. Только пихается это без понимания того, что по сути аджайл — это методология для мелких типовых проектов, в которых намечается или уже сформировался определённый кризис производства. Нормальному проекту никакой аджайл не нужен и не поможет.
Если нам не помогут, то мы тоже никого не пощадим.
самая большая проблема аджайла в том, что он удивительно зажимает тебя рамками решений, то есть он вообще не гибкий
условно говоря, тебе приводят машину, клиент жалуется, что при торможении свист. проводится диагностика. вердикт — нужно менять колодки. тебе поручают эту задачу.
ты снимаешь колеса, лезешь, и видишь, что там вообще не то — там нужно менять и диски и тормозные шланги и, может еше и пару суппортов. тут бы по уму сразу же провести перепланирование. вместо этого ты уже подписался под замену колодок и ровно это с тебя и будут спрашивать. и ты по сути занят бесполезной работой, когда реально нужная работа перекидывается в другой спринт. и эту работу может взять другой человек им тут он вдруг понимает, что задние тормоза-то барабанные, он с ними работать не умеет. и тут бы ему задачу перекинуть сразу на кого-то другого, но не может, он за это уже взялся просто без понимания. и опять он не может это сделать, потому что спринт.
Здравствуйте, Antidote, Вы писали:
A>Мда, мрак При работе удалённо всё наверное ещё хуже, все заняты своими делами, а балаболы болтают. Хотя конечно всё зависит от менеджера, иногда можно и не совсем культурно обрывать таких
Меренджер не имеет права никого прерывать. Всем рулит скрам-мастер. Это ещё одна неведома аджайл-зверушка. По идее, скрам-мастер — это что-то типа секретаря/администратора/модератора. Его задачи: проведение митингов, организация взаимодействия тим-мемберов. В принципе, он вообще может не знать ни предметной области, ни даже азов программирования. Одна из вещей, которые ни в коем случае не должен делать скрам-мастер — это назначть задачи людям. Но я не видел ни одной команды, где это правило соблюдалось бы. Как правило за скрам-мастера либо начальник, либо тим-лид, либо кто-то претендующий на эти роли.
A>Код-ревью не помогает? Парное программирование? Каждодневный контроль сделанного и обсуждение следующих шагов? Лучше ж людей учить, чем делать из них пятую ногу собаки, не?
Всё это есть, кроме, прости господи, парного программирования. Но это всё имеет весьма опосредованное отношение к аджайлу. Аджайл изначальный — это всего лишь манифест, состоящий из 4-х ценнойстей и 12-ти принципов. И если на них внимательно посмотреть, то авторы этого творения решали одну единственную задачу — перенести часть ответственности за проект на заказчика. Что есть правильно. Туповато/хитрожопые заказчики могут выпить из команды все соки, если начинают продавливать свои хотелки в середине проекта, которые придумывают на ходу от балды. А так всё чётко — ребята, мы всё делаем вместе с вами и для вас и именно так как вы хотите. А ниже мелким шрифтом — "но платить, суки, вы будете не за результат, а за процесс, т.е. за все ваши хотелки и перделки". Посмотри теперь на все эти наивно-мечтательные принципы с этой точки зрения и ты офигеешь как всё просто.
Так вот. Это я отвлёкся. Вёрнёмся к код-ревью. Современный аджайл сформировался на этих принципах, это так, но затем к нему приложили руки комерсанты и бизнесмены. А именно блогеры, писаки от IT и главное крупные консальтинговые компании, поставляющие теперь своих тренеров-недоучек в изрядном объёме за бешеные деньги тем, кто таким образом может сконвертировать столь модную инициативу, например, в неплохой бонус (заметьте, ни слова об откатах). Естественно, что в такой ситуации 4 ценности и 12 принципов смотрятся как-то бедненько и с трудом тянут лишь на скелет. Но ведь скелет есть и всё, что осталось — это нарастить сначала мяска, потом натянуть кожу, надеть на результат нижнее бельё, штаны и шапку, костюмчик и бронежелет. Ещё не помешает комбинезон танкиста и лётчика, а также сверху скафандр космонавта и подводника. И вот у нас уже есть что предложить клиенту!!! Ах да. Ещё обязательно нужно объявить всё это удивительно гибким, но при этом не дать возможности ничего менять, введя в аджайл обязательные церемонии.
К чему я это? В аджайле из полезного нет абсолютно ничего нового (кроме "ценностей"). Всё тобой перечисленное аджайлом узурпировано и нагло присвоено и существовало за долго до него. И главное — всё это можно спокойно использовать и без аджайла.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Vladek, Вы писали:
V>Похожая тема про другое, а мне гораздо интереснее, почему вы сами решаете уйти или сменить место работы.
А знаешь, интересно получается! Теоретические причины смены работы и жизненные — это две большие разницы.
В жизни:
1) Первая работа на пол-ставки в замшелом КБ. И все нравилось, а потом КБ закрылось.
2) Работодатель обещал повышения зп. и не выполнил. Вместо этого всем принудительно ввел 10-часовой рабочий день. Я поссорился и ушел.
3) Я переехал в Москву.
4) Кризис, работодатель уволил 25% сотрудникав и уменьшил зп на 25%. Оставшиеся работали за двоих. Я вначале терпел, потом нашел новую работу (но не ссорился, потому что стал умнее)
5) Я счастливо работал 7(!) лет, но потом контору накрыли американские санкции. Ликвидация предприятия.
6) Нормально работал, но получил предложение от старых друзей и переехал в Германию.
7) В Германии надоело — вернулся в Москву.
Это — практические причины.
А теоретические — все те же самые: денег не повышают, выжимают все соки, микроменеджерят, технологии отстой, начальство дурное, много говонокода, много легаси по которому утрачены знания и т.д.
Но как ни странно, теория расходится с практикой кроме пункта кроме "выжимают как лимон за маленькую зарплату"
Здравствуйте, Sharov, Вы писали:
S>Люди и их взаимодействие и есть процесс(ы). Как одно может быть важнее другого, будучи тождественным?
Процесс взаимодействия людей должен подстраиваться под этих самых людей. Не надо людей загонять в жесткие формальные рамки.
Здравствуйте, IT, Вы писали:
IT>К чему я это? В аджайле из полезного нет абсолютно ничего нового (кроме "ценностей"). Всё тобой перечисленное аджайлом узурпировано и нагло присвоено и существовало за долго до него. И главное — всё это можно спокойно использовать и без аджайла.
Там точно ничего нового, только этот странный карго-культ создали, как мне кажется, с целью решить проблему, которую стандартные методологии не решают. А именно проблему отсутствия качественных управленцев. Если взять любую классическую методологию, будь то водопад какой или RUP, там везде крайне важен менеджер проекта. Это не просто формальная роль в виде прослойки между разработчиками и заказчиком для совещаний и получения люлей, а реальный специалист в области планирования. При этом в АйТи управляющие роли просто высиживают АйТи-специалисты, а потом даже PMBOK не удосужатся прочитать. Ну а если у тебя нет управленца, но хоть как-то надо планировать, то остается только поручить это коллективному разуму в надежде что в команде найдется кто-то достаточно любознательный и ответственный что бы менеджер мог перестать быть проектным менеджером и всем гордо говорить что он просто менеджер.
А так как подавляющее большинство современных АйТи проектов типовые, то они довольно легко поддаются управлению через коллективный разум. Казалось бы, дело становится действительно плохо, когда компания сталкивается с объемным и не типовым проектом, но даже тут Аджайл спасает. Так как за все отвечает команда, т.е. никто, то и спросить за провал не с кого, а так как все так старались, так старались, то и даже премию можно получить.
Так что я думаю, что пока в АйТи деньги будут литься рекой, как это сейчас происходит, Аджайл будет с нами.
Похожая тема про другое, а мне гораздо интереснее, почему вы сами решаете уйти или сменить место работы.
Я убежден, что работник всегда внутренне мотивирован на работу и всегда работает на пределе своих возможностей. Работодатель работника может только демотивировать.
Мои демотиваторы:
1. Деньги. Ну тут всё ясно, ищешь где больше платят.
2. Бюрократия. Ежедневные отчёты заказчику, ежедневные отчёты посредникам, митинги, трекеры времени, графики. Отношение как к фрилансеру на почасовой оплате, который часто врёт.
3. Микроменеджмент и ограничение инициативы.
4. Говнокод и культура разработки, в которой его сложно исправлять.
5. Экзотика в технологиях, нетранслируемый опыт.
Здравствуйте, sts, Вы писали:
sts>Здравствуйте, Vladek, Вы писали:
V>>5. Экзотика в технологиях, нетранслируемый опыт. sts>что такое "нетранслируемый опыт"?
Вероятно, неликвидные знания. Которые можно продать только этому работодателю, и то не долго.
Здравствуйте, kaa.python, Вы писали:
KP>Здравствуйте, IT, Вы писали:
IT>>НИИ — это детский сад, кустарщина и самопальщина. IT>>Agile — это бюрократия возведённая в абсолют, в ранг религии, с подведённой под это дело теорией.
KP>С CMMI уровеня 4 и выше сталкивался? Вот уж где бюрократия, Аджайл на этом фоне детский сад
Чуть булкой с повидлом не подавился, эко Вас потаскало по конторам
Здравствуйте, RonWilson, Вы писали:
RW>А что запомнилось больше всего? ну помимо битья розгами, приковывания цепями?
Мы тогда до CMMI 4 не дошли, да и не пытались особо если честно. Но я был впечатлён уровнем рекомендуемой бюрократии. У нас тогда даже тренера были, которые изучали те процессы что есть и рекомендовали как стремиться к светлому будущему. Правда я свалили сильно до его наступления, если оно, конечно, когда-то и пришло
Здравствуйте, __kot2, Вы писали:
__>и опять он не может это сделать, потому что спринт.
С другой стороны, если уложил спринт в 3 дня и закрыл свои поинты, то можешь смело оставшееся время пинать покрышки и вешать лапшу на статус всяким скрам-мастерам.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Sharov, Вы писали:
S>Я не понимаю эту фразу S>
S>Люди и взаимодействие важнее процессов и инструментов.
S>Люди и их взаимодействие и есть процесс(ы). Как одно может быть важнее другого, будучи тождественным?
Слева в этой фразе "Люди и их взаимодействие" — это процессы ad hoc, а справа "процессы и инструменты" — это то, как их задизайнил какой-нибудь спец. по процессам в компании. В общем, не одно и то же.
Смысл самой фразы такой: не надо гонять разработчика по семи кругам ада и согласовывать цвет кнопки с тремя начальниками и двумя вице-президентами, а просто поменять цвет по просьбе пользователя (и как можно скорее).
Здравствуйте, IT, Вы писали:
IT>НИИ — это детский сад, кустарщина и самопальщина. IT>Agile — это бюрократия возведённая в абсолют, в ранг религии, с подведённой под это дело теорией.
С CMMI уровеня 4 и выше сталкивался? Вот уж где бюрократия, Аджайл на этом фоне детский сад
Здравствуйте, Sharov, Вы писали:
IT>>Ценности — это термин, который используется в вики. S>Я не понимаю эту фразу S>
S>Люди и взаимодействие важнее процессов и инструментов.
S>Люди и их взаимодействие и есть процесс(ы). Как одно может быть важнее другого, будучи тождественным?
К счастью, я не являюсь автором этого манифеста. Выше, я уже писал, что все эти люди и взаимодейсвия лишь ширма для того, чтобы перенести часть ответственности с одних на других. С менеджеров на инженеров. С разработчика на заказчика. Поэтому большого смысла в этом словоблудии искать не стоит.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Gt_, Вы писали:
TG>>Чем это отличается от RUP? Gt_>тем что сильно ниже риск ситуации описанной выше — когда неадекват исходя из своих представлений о job security два года проектирует хрень с квадратными колесами, а команда обречена этот абсурд имплементировать.
Не надо рассказывать страшилок. Никто так не делает.
Регулярные статусные встречи — это азы управления, а не изобретение agile-адептов последних лет.
Gt_>аджаил не требует спроектировать в мельчайших деталях абсолютно все заранее и прибить схему данных на десятилетия.
Здравствуйте, Vladek, Вы писали:
V>Похожая тема про другое, а мне гораздо интереснее, почему вы сами решаете уйти или сменить место работы.
V>Я убежден, что работник всегда внутренне мотивирован на работу и всегда работает на пределе своих возможностей. Работодатель работника может только демотивировать.
V>Мои демотиваторы:
V>1. Деньги. Ну тут всё ясно, ищешь где больше платят. V>2. Бюрократия. Ежедневные отчёты заказчику, ежедневные отчёты посредникам, митинги, трекеры времени, графики. Отношение как к фрилансеру на почасовой оплате, который часто врёт. V>3. Микроменеджмент и ограничение инициативы. V>4. Говнокод и культура разработки, в которой его сложно исправлять. V>5. Экзотика в технологиях, нетранслируемый опыт.
— Предложили КРУТОЙ вариант, а у тебя просто нормальный или даже унылый
— Ты выгорел
— Продукт или бизнес никуда не движется (это не только про деньги, но и про амбиции)
— Имиграция, переезд
— Тебя не оценили и не повысили, как тебе бы хотелось
Здравствуйте, Vladek, Вы писали:
V>Похожая тема про другое, а мне гораздо интереснее, почему вы сами решаете уйти или сменить место работы.
менял проекты/работы по следующим причинам.
1) понимал, что контора затухает надо двигаться дальше и просто находил контору лучше — большинство раз( >10 ), из серии вырос и могу большего.
2) не оправдал ожидания работодателя (2 раза), в первом случае сам балбес в другом и я балбес и работодатель промазал.
3) попросил больше денег (1 раз) и это было давно
4) менеджмент оказался редкостным г-ном, конкретно подставили, в людях окончательно разочаровался.
Был проект, с реквизитным менеджментом, но он хоть работе не мешал и слава богу, потом его убрали.
Здравствуйте, Тёмчик, Вы писали:
Тё>Пример: в лицо на тебя не нападают, но при годовом ревью вешают чужих собак, и низко оценивают пипл скилл.
Как вообще это происходит? Типа каждый получает отчёт с результатом ревью: типа, у вас то и то, поэтому хрен вам, а не повышение. Да? Или откуда ты узнал о том, что у тебя в ревью?
Здравствуйте, Vladek, Вы писали:
V>Похожая тема про другое, а мне гораздо интереснее, почему вы сами решаете уйти или сменить место работы.
V>Я убежден, что работник всегда внутренне мотивирован на работу и всегда работает на пределе своих возможностей. Работодатель работника может только демотивировать.
V>Мои демотиваторы:
V>1. Деньги. Ну тут всё ясно, ищешь где больше платят. V>2. Бюрократия. Ежедневные отчёты заказчику, ежедневные отчёты посредникам, митинги, трекеры времени, графики. Отношение как к фрилансеру на почасовой оплате, который часто врёт. V>3. Микроменеджмент и ограничение инициативы. V>4. Говнокод и культура разработки, в которой его сложно исправлять. V>5. Экзотика в технологиях, нетранслируемый опыт.
У меня как-то так было на предыдущем месте, 3 года назад, но я оттуда свалил через 4 месяца работы. Заманили деньгами и позицией тех лида.
1. Платили очень хорошо, больше чем я сейчас получаю
2. Вход в офис по отпечатку пальца, все "покурить" трекаются как нерабочее время. Отчёт о проделанной работе с детализацией в 10 минут. И т.д.
3. Аналогично
4. Дикий фанатизм по аббревеатурам. Все без исключения классы, методы, переменные, модули назывались либо 3, либо 6 буквенной аббревеатурой, понять предназначение которой в большинстве случаев невозможно без глубокого чтения кода.
5. Собственный язык программирования с языком похожим на VB, своя сисема контроля версий без возможности мержа, своя "джира" в виде десктопного приложения времён Windows 3.11, своя IDE с отладчиком (ну тут она более-менее, ибо хорошо справлялась с задачами).
Здравствуйте, SaZ, Вы писали:
SaZ>4. Дикий фанатизм по аббревеатурам. Все без исключения классы, методы, переменные, модули назывались либо 3, либо 6 буквенной аббревеатурой, понять предназначение которой в большинстве случаев невозможно без глубокого чтения кода.
Взяли бы технического писателя на 500 и он бы вам создал словарь, это вполне решаемая проблема.
H>Как вообще это происходит? Типа каждый получает отчёт с результатом ревью: типа, у вас то и то, поэтому хрен вам, а не повышение. Да? Или откуда ты узнал о том, что у тебя в ревью?
Конечно же. Сначала сам пишешь всякое формальное и может быть даже и много, потом тебе пишут, потом результаты обсуждаешь с менеджером.
я два раза уходил сам через неделю работы
1) вместо программирования отправилив тестере, мотивируя что надо изучить систему
когда я понял что это не временно просто не пришел на работу в понедельник
2) рещил стать менеджером на железной дороге
вскоре понял что спина у меня не достаточно гибкая и мне нравиться программировать и ушел
Здравствуйте, Vladek, Вы писали:
V>Похожая тема про другое, а мне гораздо интереснее, почему вы сами решаете уйти или сменить место работы.
Надо оценивать перспективу. Вот о чем вы думаете, глядя на эти кирпичи список своих задач? Какая их них спасет мир или хотя бы одного хомячка.
V>Я убежден, что работник всегда внутренне мотивирован на работу и всегда работает на пределе своих возможностей. Работодатель работника может только демотивировать.
Коллеги тоже бывают не сахар. Впрочем, и это тоже работодатель, не хочет лучших искать. Получается, он во всем виноват.
Здравствуйте, Vladek, Вы писали:
V>Мои демотиваторы:
Переработки, естественно. В некоторых компаниях это считается просто нормальным — догнать и перегнать Америку до ближайших выходных, все остаются больше 8 часов каждый день и/или на выходных и бешено говнокодят с выпученными глазами.
. V>5. Экзотика в технологиях, нетранслируемый опыт.
6. Life/Work balance
Работаем чтобы жить или живем чтобы работать, далеко не для всех деньги являются определяющим фактором.
”Жить стало лучше... но противнее. Люди которые ставят точку после слова лучше становятся сторонниками Путина, наши же сторонники делают акцент на слове противнее ( ложь, воровство, лицемерие, вражда )." (с) Борис Немцов
Здравствуйте, kaa.python, Вы писали:
KP>Здравствуйте, RonWilson, Вы писали:
RW>>Чуть булкой с повидлом не подавился, эко Вас потаскало по конторам
KP>Но это было очень интересно!
А что запомнилось больше всего? ну помимо битья розгами, приковывания цепями?
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, Vladek, Вы писали:
V>>2. Бюрократия. Ежедневные отчёты заказчику, ежедневные отчёты посредникам, митинги, трекеры времени, графики. Отношение как к фрилансеру на почасовой оплате, который часто врёт.
IT>Написал бы одним словом — Agile.
Какой-то странный Agile однако, что строится прежде всего на доверии менеджера к компетенциям команды и примате общения над бюрократией.
Если что, у меня опыт работы с 2009 года в командах по Agilподобным методологиям(в основном Scrum/Kanban), прорва успешных ком.релизов коробочных продуктов не самой простой сложности, несколько инфраструктурных проектов, и всегда погрешности по ресурсам и срокам больше 5% никогда не были
Здравствуйте, Miroff, Вы писали:
M>Здравствуйте, kaa.python, Вы писали:
KP>>С CMMI уровеня 4 и выше сталкивался? Вот уж где бюрократия, Аджайл на этом фоне детский сад
M>Вообще-то Agile никак не противоречит CMMI. Более того, Agile это и есть CMMI-5
Ты втираешь какую-то дичь(с)
Agile это целое семейство методологий со своими погремушками.
Здравствуйте, HFTMan, Вы писали:
HFT>Какой-то странный Agile однако, что строится прежде всего на доверии менеджера к компетенциям команды и примате общения над бюрократией. HFT>Если что, у меня опыт работы с 2009 года в командах по Agilподобным методологиям(в основном Scrum/Kanban), прорва успешных ком.релизов коробочных продуктов не самой простой сложности, несколько инфраструктурных проектов, и всегда погрешности по ресурсам и срокам больше 5% никогда не были
Сколько у вас человек в команде и какого они уровня?
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, HFTMan, Вы писали:
HFT>>Какой-то странный Agile однако, что строится прежде всего на доверии менеджера к компетенциям команды и примате общения над бюрократией. HFT>>Если что, у меня опыт работы с 2009 года в командах по Agilподобным методологиям(в основном Scrum/Kanban), прорва успешных ком.релизов коробочных продуктов не самой простой сложности, несколько инфраструктурных проектов, и всегда погрешности по ресурсам и срокам больше 5% никогда не были
IT>Сколько у вас человек в команде и какого они уровня?
Agile не масштабируется на команду больше 20 человек, ну с натягом 25 человек(совсем край), но это уже при отлаженном до швейцарских часов процессе.
Оптимум не больше 15 человек.
Процесс разработки более масштабных проектов надо пилить именно на такие куски, чтобы части этого масштабного проекта разрабатывались командами именно такой численности.
Проекты были разные, и коробочные(несколько штук), и инфраструктурные(т.е. потребителями являются несколько команд коробочных продуктов), численность именно всей команды была от 6 до 20+ человек(в компании с кол-вом команд разработки в несколько десятков проектов и общей численностью R&D 2000+ человек).
Самый большой по кол-ву участников проект был в таком составе: менеджер проекта, два архитектора в пике, потом один (потому что потребителей нашей условно облачной инфры было чуть ли не десяток других команд и много надо действительно подумать над архитектурой), тим-лид команды разработки(он же и ведущий программер был, хотя по факту мог быть еще один ведущий), несколько синьоров, несколько обычных девелоперов, парочка джунов, тим-лид команды автотестирования, несколько синьоров автотестеров/просто автотестеров(по факту они программеры же, но пишут автотесты, а не бизнес-код), один-два аналитика(часто обслуживали не только наш проект), один-два дизайнера(тоже обслуживали несколько проектов), это те, кто конкретно работали над проектом. Но при этом еще были из бизнес-дивизиона персоналии, выступающие как заказчики продукта(они на нашу текучку вообще не завязаны были), отделы эксплуатации и тех.поддержки, которые этот самый продукт в продакшене эксплуатировал и саппортил(куча народа, которая кучу же и других проектов обслуживала, а не только наши).
Сейчас все проще в процессе разработки, и команда сильно меньше, мне кровавый энтерпрайз надоел до одури, т.к. работа стала кучкой типовых задач, типовых решений, типовых архитектур, типовых сложностей, никаких НИОКРов, хождения по граблям нехоженных задач, никаких с нуля написанных инструментов, коих никто не писал, а они нужны, проще говоря-работа не приходя в сознание надоела сильно, а мои инновации обсуждались и рубились Да не только мои, сейчас из команды, с кем работал еще 3 года назад, мало кто уже остался в Компании, да и надоела сама предметная область.
Как итог, вернулся к той предметной области, которую с 2004 года мусолю как хобби, а потом несколько лет как единственная работа(пока в 2009 году не поплохело несколько)-алготрейдинг с latency arbitrage ну и пока краешком HFT(надеюсь скоро уже не краешком будет ).
Не первая попытка порвать с кровавым энтерпрайзом, но надеюсь окончательная, надоел он мне, чем меньше людей участвует в проекте, тем мне с некоторых пор комфортнее и приятнее работать по причине минимизации кол-ва политики в работе.
Здравствуйте, IT, Вы писали:
IT>Как пишут апологеты, оптимальный размер 6 +- 3, т.е. 3-9 человек. Больше 13-ти аджайл перестаёт работать совсем. По моим наблюдениям примерно так и есть. Думаю, это связано с тем, что в группе из пяти человек всегда найдётся минимум один балабол. И если в группе из 5-10 человек его (или пару таких) быстро заткнут и поставят на место, то при наличии таких 3-х и более у них образуется кворум и хрен ты их уже остановишь. Тем более, что в большом коллективе из 15 человек народ ведёт себя по-другому, более официозно, и воспринимает такую болтовню как что-то само-собой разумеющееся и складывается впечатление, что вот это и есть настоящий аджайл. В результате любой митинг превращается в бесконечный трёп нескольких балаболов.
IT>У нас количество sprint participants периодически доходит до 27-ми. При этом чтобы высказаться по теме нужно вклиниться в бесконечный галдёж, куда тебя пускать никто не собирается. Можно только либо повысив голос и не очень культурно прервав докладчика, либо забить совсем и решить всё после митинга. Либо подождать. Но пока будешь ждать трындёж съедет на другую тему и ты будешь выглядеть в определённом смысле тормозом. В общем, веселуха. При этом большая часть народа сидит и откровенно зевает и занимается разглядываем экранов телефонов. Т.е. имеем типичное комсомольское собрание времён совка — 3-4 докладчика в президиуме и скучающую аудиторию, с нетерпением ожидающую концовку мероприятия.
Мда, мрак При работе удалённо всё наверное ещё хуже, все заняты своими делами, а балаболы болтают. Хотя конечно всё зависит от менеджера, иногда можно и не совсем культурно обрывать таких
IT>И как вы распределяли задачи между джуниорами и синьорами/архитекторами. Аджайл ведь предполагает, что в команде все равны и любой из команды может выбрать себе задачу по душе. Это, кстати, ещё одна аджайл бредятина. Типа разбиваем задачу на несколько частей. Первую часть берёт на себя какой-нибудь джуниор или криворучка. Вторую часть — ручки из жопки или "бывший кобольщик/жалко выгнать старичка". И так далее. И вот когда 95% задачи уже типа сделано, то начальник, понимая, что это — жопа, выдёргивает какого-нибудь синьёра и поручает ему всё нахрен переписать, только по-тихому, чтобы не обидеть джуниора/криворучку/ручку-из-жопки/старичка. Ведь у нас калабарейшин и тим билдинг. Люди могут обидеться, а так с людями нельзя. Раньше их никто к этой задаче не подпустил бы. Тот же самый синьёр сделал бы её в одно рыло в более короткий срок и один раз. Но в аджайл это никак низя.
Код-ревью не помогает? Парное программирование? Каждодневный контроль сделанного и обсуждение следующих шагов? Лучше ж людей учить, чем делать из них пятую ногу собаки, не?
Здравствуйте, IT, Вы писали: IT>С другой стороны, если уложил спринт в 3 дня и закрыл свои поинты, то можешь смело оставшееся время пинать покрышки и вешать лапшу на статус всяким скрам-мастерам.
"закрывать спринты любой ценой" тоже как правило нифига не работает.
был у меня такой случай
один чел с названием принципал в должности что-то сделал, убедил начальство что это очень нужное и полезное и свалил его на наш отдел "для внедрения", а сам переключился на другую задачу. начальство, убежденное, что спринт по разработке закрыт, выдал нам на внедрение 2 недели, что, в принципе, разумно
однако глянув на сие поделие я вдруг выяснил, что нифига оно не работает и очень тяжело отлаживается. и я напрямую сказал начальству, что реально внедрение у нас займет полгода (причем даже не я этим занимался) начальство не поверило, я же не принципал. через месяц дебага и попыток заставить эту хрень работать хоть как-то, начальство доперло, что это реально еще пилить и пилить. я настаивал на то, чтобы аффтара снова включить в проект, потому что логика там была какая-то совсем невменяемая с принципиальными ошибками из-за которых она в принципе не могла работать. высокое начальство, понимая что внедрением и не пахнет, через пару месяцев накатало письмо аффтару с вопросами почему оно нифига не работает, несмотря на то, что он уже отчитался о выполении и вообще занят теперь другим делом. на глазах изумленной публики принципал просто отмазался реально просто наврав о том, что там все работает, но есть некоторые ньюансы, но к ним ко всем есть воркэраунды.
вместо того, чтобы переключиться на реально полезное дело он был просто занят тем, что просто нагло врал, всячески пытаясь обосновать, что спринт закрыт, он по нему отчитался и больше к нему возвращаться он не будет. короче, реально стремная история была.
Здравствуйте, __kot2, Вы писали:
__>вместо того, чтобы переключиться на реально полезное дело он был просто занят тем, что просто нагло врал, всячески пытаясь обосновать, что спринт закрыт, он по нему отчитался и больше к нему возвращаться он не будет. короче, реально стремная история была.
Эта история замечательно подтверждает моё мнение, что аджайл — это рай для балаболов, аферистов, мелких и крупных врунишек, прочих мерзавцев, подлецов и нигадяев. Зато для чётких пацанчиков типа нас с тобой — это один большой демотиватор.
Если нам не помогут, то мы тоже никого не пощадим.
__>самая большая проблема аджайла в том, что он удивительно зажимает тебя рамками решений, то есть он вообще не гибкий __>условно говоря, тебе приводят машину, клиент жалуется, что при торможении свист. проводится диагностика. вердикт — нужно менять колодки. тебе поручают эту задачу. __>ты снимаешь колеса, лезешь, и видишь, что там вообще не то — там нужно менять и диски и тормозные шланги и, может еше и пару суппортов. тут бы по уму сразу же провести перепланирование. вместо этого ты уже подписался под замену колодок и ровно это с тебя и будут спрашивать. и ты по сути занят бесполезной работой, когда реально нужная работа перекидывается в другой спринт. и эту работу может взять другой человек им тут он вдруг понимает, что задние тормоза-то барабанные, он с ними работать не умеет. и тут бы ему задачу перекинуть сразу на кого-то другого, но не может, он за это уже взялся просто без понимания. и опять он не может это сделать, потому что спринт.
и что в штатах табу создать новый таск и отослать на анализ, а бессмысленный таск закрыть ?
имхо, как раз в аджайл это как-то разлуливается цивилизованно, а вот в вотерфоле уже все. скинуть на кого-то не выйдет.
Здравствуйте, Gt_, Вы писали: Gt_>и что в штатах табу создать новый таск и отослать на анализ, а бессмысленный таск закрыть ? Gt_>имхо, как раз в аджайл это как-то разлуливается цивилизованно, а вот в вотерфоле уже все. скинуть на кого-то не выйдет.
постепенно в такой системе все начинает крутиться вокруг тасков, их количества и скорости закрытия. никто не хочет создавать новые таски, тем более, как я уже замечал, они в этот спринт все равно не влазят, планирование уже закончено
вообще, эта система спринтов достаточно сильно демотивирует. сколько не делай — тасков меньше не становится. никакого просвета не видно. и хуже того, что реально важные задачи обладают сильной неопределенностью и просто совершенно непонятно что с ними делать в терминах спринта.
__>еще однажды видел такую прикольную вещь. __>в компании работало несколько программистов-старожилов и они постарались вложиться в job security. то есть все сделать так, что без них вообще никто никогда не разберется как это делается. однако же, спустя достаточно много лет, они задолбались и наняли много свежих программистов, чтобы на них свалить саппорт, а сами больше уходя на менеджерские позиции. проблема была в том, что все было сделано так через жопу, что, несмотря на куда больший штат саппорта, количество проблем только росло от спринта к спринту. вылезла фундаментальная проблема, что заложенные изначально принципы "без нас никто не разберется" при росте компании поставили все процессы раком. и, в приниципе, тут бы взять старичкам и сделать все по-человечески, слушая фидбек новичков. но по сути нафиг им это надо? они и так были нужными, а теперь стали вообще критичными для компании. спринты же превратились в бесконечную борьбу с проблемами, которых вообще по идее быть не должно. __>в итоге у всех сложилось впечатление, что "с этим надо что-то делать", но железобетонные спринты говорили только о том, что нужно очень быстро катить квадратное и никакой самодеятельности __>люди реально в личной беседе понимали в чем проблема, но железобетонность спринтов не давала никакого шанса реально исправить проблему. для этого нужно было просто реально свободное время, а его вообще не было.
ну по мне как раз кейс про преимущество аджайла. спринты позволяют вести бизнес, тогда как с вотерфолом такой бизнес бы встал. в вотерфоле девелоперы бы были вынужденные пилить квадратную хрень надизайненную полными неадекватами 2 года назад, с гораздо меньшими что либо изменить в планах перспективами. скорее всего окончилось бы убийством тех неадекватов.
если проектом рулят неадекваты с целью job security, не суть важно что за методология. у нас вот не совсем аджайл, но с всякими грумингами и спринтми. если видим, что катим квадрат, нет проблем в ближайший спринт натолкать тасков на анализ и может даже мелкие прототипы. если не вдаваться в крайности и рулит процессом адекват, то вполне можно тасками на анализ, на прототипы, делать нормальный и продуманный дизайн, прежде чем фигачить саму фичу.
Gt_>и что в штатах табу создать новый таск и отослать на анализ, а бессмысленный таск закрыть ?
Ну в общем-то возможно. Вот только попадет в лучшем случае в следующий спринт, ибо на этот спринт все расписано
Gt_>>и что в штатах табу создать новый таск и отослать на анализ, а бессмысленный таск закрыть ? S>Ну в общем-то возможно. Вот только попадет в лучшем случае в следующий спринт, ибо на этот спринт все расписано
да, попадет в следующий спринт и без спешки будет проанализирован, а реализация еще позже. было бы странно все бросить и переключится на такой таск и уж тем более набрасывать на аджаил, который именно такие вещи разруливает близко к оптимальному сценарию.
V>Похожая тема про другое, а мне гораздо интереснее, почему вы сами решаете уйти или сменить место работы.
V>Я убежден, что работник всегда внутренне мотивирован на работу и всегда работает на пределе своих возможностей. Работодатель работника может только демотивировать.
V>Мои демотиваторы:
V>1. Деньги. Ну тут всё ясно, ищешь где больше платят. V>2. Бюрократия. Ежедневные отчёты заказчику, ежедневные отчёты посредникам, митинги, трекеры времени, графики. Отношение как к фрилансеру на почасовой оплате, который часто врёт. V>3. Микроменеджмент и ограничение инициативы. V>4. Говнокод и культура разработки, в которой его сложно исправлять. V>5. Экзотика в технологиях, нетранслируемый опыт.
я почти всегда (раз 12) увольнялся по единой причине "work-life balance"
бабло это лишь инструмент, а работать на работе — это способ получить бабло
если есть какой-то интерес или миленькие сотрудники — это лишь приятный бонус
если бабло есть, то лучше займусь чем сам хочу — вне работы
KP>За время работы в компании, я обычно раз 10-20 успеваю решить что вот сил больше нет ухожу (причин море, включая фазу луны и то, что обед был не вкусный). Потом хожу по рынку
никогда не понимал,
как это — сил нету, и при этом продолжая работать они ещё и ходят по рынку
Здравствуйте, IT, Вы писали:
IT>Всё это есть, кроме, прости господи, парного программирования. Но это всё имеет весьма опосредованное отношение к аджайлу. Аджайл изначальный — это всего лишь манифест, состоящий из 4-х ценнойстей и 12-ти принципов. И если на них внимательно посмотреть, то авторы этого творения решали одну единственную задачу — перенести часть ответственности за проект на заказчика. Что есть правильно. Туповато/хитрожопые заказчики могут выпить из команды все соки, если начинают продавливать свои хотелки в середине проекта, которые придумывают на ходу от балды. А так всё чётко — ребята, мы всё делаем вместе с вами и для вас и именно так как вы хотите. А ниже мелким шрифтом — "но платить, суки, вы будете не за результат, а за процесс, т.е. за все ваши хотелки и перделки". Посмотри теперь на все эти наивно-мечтательные принципы с этой точки зрения и ты офигеешь как всё просто.
Что за ценности?
IT>Так вот. Это я отвлёкся. Вёрнёмся к код-ревью. Современный аджайл сформировался на этих принципах, это так, но затем к нему приложили руки комерсанты и бизнесмены. А именно блогеры, писаки от IT и главное крупные консальтинговые компании, поставляющие теперь своих тренеров-недоучек в изрядном объёме за бешеные деньги тем, кто таким образом может сконвертировать столь модную инициативу, например, в неплохой бонус (заметьте, ни слова об откатах). Естественно, что в такой ситуации 4 ценности и 12 принципов смотрятся как-то бедненько и с трудом тянут лишь на скелет. Но ведь скелет есть и всё, что осталось — это нарастить сначала мяска, потом натянуть кожу, надеть на результат нижнее бельё, штаны и шапку, костюмчик и бронежелет. Ещё не помешает комбинезон танкиста и лётчика, а также сверху скафандр космонавта и подводника. И вот у нас уже есть что предложить клиенту!!! Ах да. Ещё обязательно нужно объявить всё это удивительно гибким, но при этом не дать возможности ничего менять, введя в аджайл обязательные церемонии.
Чего-то я не понял про связь код-ревью и 4 ценностей. Т.е. изначально было код-ревью, а потом вокруг наворотили?
Здравствуйте, kaa.python, Вы писали:
KP>А так как подавляющее большинство современных АйТи проектов типовые, то они довольно легко поддаются управлению через коллективный разум. Казалось бы, дело становится действительно плохо, когда компания сталкивается с объемным и не типовым проектом, но даже тут Аджайл спасает. Так как за все отвечает команда, т.е. никто, то и спросить за провал не с кого, а так как все так старались, так старались, то и даже премию можно получить.
Не может же не быть в команде старшего, вот с него и спросят.
Gt_>ну по мне как раз кейс про преимущество аджайла. спринты позволяют вести бизнес, тогда как с вотерфолом такой бизнес бы встал. в вотерфоле девелоперы бы были вынужденные пилить квадратную хрень надизайненную полными неадекватами 2 года назад, с гораздо меньшими что либо изменить в планах перспективами. скорее всего окончилось бы убийством тех неадекватов.
А как по аджайлу можно задизайнить хоть что-то серьезное?
Здравствуйте, Sharov, Вы писали:
S>Здравствуйте, Gt_, Вы писали:
Gt_>>ну по мне как раз кейс про преимущество аджайла. спринты позволяют вести бизнес, тогда как с вотерфолом такой бизнес бы встал. в вотерфоле девелоперы бы были вынужденные пилить квадратную хрень надизайненную полными неадекватами 2 года назад, с гораздо меньшими что либо изменить в планах перспективами. скорее всего окончилось бы убийством тех неадекватов.
S>А как по аджайлу можно задизайнить хоть что-то серьезное?
я же вроде разжувал: если видим, что катим квадрат, нет проблем в ближайший спринт натолкать тасков на анализ и может даже мелкие прототипы.
т.е. в аджаил у тебя будет нормально потрачено время на дизайн, на прототипы и только после этого непосредственно разработка, если прототип доказал пользу. что может быть более эффективно ?
Здравствуйте, Gt_, Вы писали:
Gt_>т.е. в аджаил у тебя будет нормально потрачено время на дизайн, на прототипы и только после этого непосредственно разработка, если прототип доказал пользу. что может быть более эффективно ?
Если сам процесс дизайна занимает очень долго,еще до прототипирования, имеет смысл говорить об agile? Я просто не вижу там фаз, которые можно разбить на спринты. Длительная монотонная умственная деятельность, ну или там, где много времени надо до первого прототипа.
Здравствуйте, Hobbes, Вы писали:
Тё>>Пример: в лицо на тебя не нападают, но при годовом ревью вешают чужих собак, и низко оценивают пипл скилл.
H>Как вообще это происходит? Типа каждый получает отчёт с результатом ревью: типа, у вас то и то, поэтому хрен вам, а не повышение. Да? Или откуда ты узнал о том, что у тебя в ревью?
Здравствуйте, Sharov, Вы писали:
S>Не может же не быть в команде старшего, вот с него и спросят.
Может, еще как может! Он как бы формально может и есть, но не то что бы старший, и не то что бы за что-то отвечающий. Так как все решения принимает команда
Gt_>>т.е. в аджаил у тебя будет нормально потрачено время на дизайн, на прототипы и только после этого непосредственно разработка, если прототип доказал пользу. что может быть более эффективно ?
S>Если сам процесс дизайна занимает очень долго,еще до прототипирования, имеет смысл говорить об agile? Я просто не вижу там фаз, которые можно разбить на спринты. Длительная монотонная умственная деятельность, ну или там, где много времени надо до первого прототипа.
разбивается на стадии, на модули, сервисы — проектируется часть, заполняется бэклог и поехали. все как наши далекие предки делали, по маленьким шагам. ты же не думаешь, что студент Торвальдс 3 года рисовал дизайн ? оракл первую (version 2) версию за 1.5-2 года выкатили в прод. в этом плане ничего не поменялось в серьезных проектах. да и какой может быть дизайн длиной в года, если в феврале фирмы имели одни потребности, а в апреле противоположные, да и фреймворки большую часть задач в конфигурирование превратили.
Здравствуйте, Gt_, Вы писали:
Gt_>разбивается на стадии, на модули, сервисы — проектируется часть, заполняется бэклог и поехали. все как наши далекие предки делали, по маленьким шагам. ты же не думаешь, что студент Торвальдс 3 года рисовал дизайн ? оракл первую (version 2) версию за 1.5-2 года выкатили в прод. в этом плане ничего не поменялось в серьезных проектах.
Да, всё так.
Тогда закономерный вопрос: нафига было придумывать новый термин (agile) для того, что и так раньше делали?
Здравствуйте, Gt_, Вы писали:
S>>А как по аджайлу можно задизайнить хоть что-то серьезное? Gt_>я же вроде разжувал: если видим, что катим квадрат, нет проблем в ближайший спринт натолкать тасков на анализ и может даже мелкие прототипы. Gt_>т.е. в аджаил у тебя будет нормально потрачено время на дизайн, на прототипы и только после этого непосредственно разработка, если прототип доказал пользу. что может быть более эффективно ?
S>>>А как по аджайлу можно задизайнить хоть что-то серьезное? Gt_>>я же вроде разжувал: если видим, что катим квадрат, нет проблем в ближайший спринт натолкать тасков на анализ и может даже мелкие прототипы. Gt_>>т.е. в аджаил у тебя будет нормально потрачено время на дизайн, на прототипы и только после этого непосредственно разработка, если прототип доказал пользу. что может быть более эффективно ?
TG>Чем это отличается от RUP?
тем что сильно ниже риск ситуации описанной выше — когда неадекват исходя из своих представлений о job security два года проектирует хрень с квадратными колесами, а команда обречена этот абсурд имплементировать.
аджаил не требует спроектировать в мельчайших деталях абсолютно все заранее и прибить схему данных на десятилетия.
плюс тучи мутных митингов типа, где с командой можно обсудить квадраты и боль от них.
__>в итоге у всех сложилось впечатление, что "с этим надо что-то делать", но железобетонные спринты говорили только о том, что нужно очень быстро катить квадратное и никакой самодеятельности
Ну классика же.
-Мужики, вы чего там страшно ругаетесь?
-Да вот, тупой пилой бревна пилим.
-Так остановитесь и наточите!
-Некогда, пилить же надо!
Или:
-вы чего так с ведрами бегаете?
-да воду надо носить, а ведра дырявые, вот чтоб не все вылилось по дороге, приходится бегать.
-так заделайте дырки-то!
-да ты че, воду носить надо!
Gt_>ну по мне как раз кейс про преимущество аджайла. спринты позволяют вести бизнес, тогда как с вотерфолом такой бизнес бы встал. в вотерфоле девелоперы бы были вынужденные пилить квадратную хрень надизайненную полными неадекватами 2 года назад, с гораздо меньшими что либо изменить в планах перспективами. скорее всего окончилось бы убийством тех неадекватов.
Хе-хе. "Вы должны писать код так, словно сопровождать его будет склонный к насилию психопат, знающий, где вы живете". Хе-хе.
Здравствуйте, TG, Вы писали:
TG>Здравствуйте, Gt_, Вы писали:
Gt_>>разбивается на стадии, на модули, сервисы — проектируется часть, заполняется бэклог и поехали. все как наши далекие предки делали, по маленьким шагам. ты же не думаешь, что студент Торвальдс 3 года рисовал дизайн ? оракл первую (version 2) версию за 1.5-2 года выкатили в прод. в этом плане ничего не поменялось в серьезных проектах.
TG>Да, всё так. TG>Тогда закономерный вопрос: нафига было придумывать новый термин (agile) для того, что и так раньше делали?
Здравствуйте, Vladek, Вы писали:
V>Похожая тема про другое, а мне гораздо интереснее, почему вы сами решаете уйти или сменить место работы.
Ну чего, всё правильно ты описал...
Есть ещё один пункт -- личные обстоятельства жизни, несовместимые с данной работой.
Но это как бы не анализируемо, вне статистики.
Если нам не помогут, то мы тоже никого не пощадим.
При работе удалённо всё наверное ещё хуже, все заняты своими делами, а балаболы болтают. Хотя конечно всё зависит от менеджера, иногда можно и не совсем культурно обрывать таких 
