. V>5. Экзотика в технологиях, нетранслируемый опыт.
6. Life/Work balance
Работаем чтобы жить или живем чтобы работать, далеко не для всех деньги являются определяющим фактором.
”Жить стало лучше... но противнее. Люди которые ставят точку после слова лучше становятся сторонниками Путина, наши же сторонники делают акцент на слове противнее ( ложь, воровство, лицемерие, вражда )." (с) Борис Немцов
Здравствуйте, kaa.python, Вы писали:
KP>Здравствуйте, IT, Вы писали:
IT>>НИИ — это детский сад, кустарщина и самопальщина. IT>>Agile — это бюрократия возведённая в абсолют, в ранг религии, с подведённой под это дело теорией.
KP>С CMMI уровеня 4 и выше сталкивался? Вот уж где бюрократия, Аджайл на этом фоне детский сад
Чуть булкой с повидлом не подавился, эко Вас потаскало по конторам
Здравствуйте, kaa.python, Вы писали:
KP>Здравствуйте, RonWilson, Вы писали:
RW>>Чуть булкой с повидлом не подавился, эко Вас потаскало по конторам
KP>Но это было очень интересно!
А что запомнилось больше всего? ну помимо битья розгами, приковывания цепями?
Здравствуйте, RonWilson, Вы писали:
RW>А что запомнилось больше всего? ну помимо битья розгами, приковывания цепями?
Мы тогда до CMMI 4 не дошли, да и не пытались особо если честно. Но я был впечатлён уровнем рекомендуемой бюрократии. У нас тогда даже тренера были, которые изучали те процессы что есть и рекомендовали как стремиться к светлому будущему. Правда я свалили сильно до его наступления, если оно, конечно, когда-то и пришло
Здравствуйте, 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(надеюсь скоро уже не краешком будет ).
Не первая попытка порвать с кровавым энтерпрайзом, но надеюсь окончательная, надоел он мне, чем меньше людей участвует в проекте, тем мне с некоторых пор комфортнее и приятнее работать по причине минимизации кол-ва политики в работе.
Здравствуйте, 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>Не первая попытка порвать с кровавым энтерпрайзом, но надеюсь окончательная, надоел он мне, чем меньше людей участвует в проекте, тем мне с некоторых пор комфортнее и приятнее работать по причине минимизации кол-ва политики в работе.
Проблема не в самом энтерпрайзе. Точнее не в задачах, которые там решаются. Проблема в том, что большое начальство, проникшись идеей, начинает её педалировать с максимальным старанием. Хотя это и понятно. Модная инициатива — хороший бонус. Только пихается это без понимания того, что по сути аджайл — это методология для мелких типовых проектов, в которых намечается или уже сформировался определённый кризис производства. Нормальному проекту никакой аджайл не нужен и не поможет.
Если нам не помогут, то мы тоже никого не пощадим.
самая большая проблема аджайла в том, что он удивительно зажимает тебя рамками решений, то есть он вообще не гибкий
условно говоря, тебе приводят машину, клиент жалуется, что при торможении свист. проводится диагностика. вердикт — нужно менять колодки. тебе поручают эту задачу.
ты снимаешь колеса, лезешь, и видишь, что там вообще не то — там нужно менять и диски и тормозные шланги и, может еше и пару суппортов. тут бы по уму сразу же провести перепланирование. вместо этого ты уже подписался под замену колодок и ровно это с тебя и будут спрашивать. и ты по сути занят бесполезной работой, когда реально нужная работа перекидывается в другой спринт. и эту работу может взять другой человек им тут он вдруг понимает, что задние тормоза-то барабанные, он с ними работать не умеет. и тут бы ему задачу перекинуть сразу на кого-то другого, но не может, он за это уже взялся просто без понимания. и опять он не может это сделать, потому что спринт.
Здравствуйте, __kot2, Вы писали:
__>и опять он не может это сделать, потому что спринт.
С другой стороны, если уложил спринт в 3 дня и закрыл свои поинты, то можешь смело оставшееся время пинать покрышки и вешать лапшу на статус всяким скрам-мастерам.
Если нам не помогут, то мы тоже никого не пощадим.
Если нам не помогут, то мы тоже никого не пощадим.
