Ага, ну посчитал он оставшиеся - сказал - вот тут еще можно впихнуть, а эффективность? То есть вот то что напланировали неделю назад - насколько получилось попасть в сроки?

Попробовать можно, но платформ нет, есть только хэнгаутс на максимум 6 голосов (?) с трансляцией в youtube

А чем плох хенгаутс?

6-ю людьми

Этого мало?

Не знаю, предполагаю что да

Обычно на вебинарах один или два спикера максимум

@indiscipline перефразирую давайте свой вопрос - кто отвечает за точность прогнозов и взятых обязательств - систеым или люди?

дык тут конференцию заявили, для вебинара-то ок

@indiscipline перефразирую давайте свой вопрос - кто отвечает за точность прогнозов и взятых обязательств - систеым или люди?

слишком образно, не совсем понимаю, можете в задачах и часах перефразировать?)

конференцию онлайн? увлеклись дистанционной работой :)

Могу, есть информационная система, которая говорит когда проект завершится с высокой точностью, а есть люди, которые делают оценку

вот ваша система она с чем работает :)

и умеет ли прогнозировать на основе статистических данных

Тут конечно должен преследовать вопрос - у вас как работа по fix price или t&m, и если по t&m, то в принципе вопрос можно снять

Наша система не умеет, она для планирования загрузки на спринт, но она работает с данными из джиры (часы, оценки итд), с которыми же работают плагины для джиры типа BigPicture c гантами, роадмапами и всем, чем угодно. Работа у нас как по фиксу, так и по t&m, в зависимости от проекта. Поэтому и интересуюсь решениями, что неизвестных при такой работе бывает очень много, и кто как научился их закрывать.

А проблема эта острая?

Ну, нет предела улучшениям. Справляемся, конечно, но как было бы круто волшебную систему получить, которая бы всем управляла в одном месте.

Проблема в том, что сейчас на рынке зоопарк сервисов для закрытия разных дыр и проблем, и они все между собой не всегда дружат, и не всегда могут помочь минимизировать ручную работу.

Решаема ли проблема более точного прогноза сроков - абсолютно точно да.

Идет вкупе со снятием с людей обязательства точно оценивать сроки и учитывает разного рода неизвестности,внося небольшую погрешность :')

вопрос, насколько велика погрешность оценки при этом )

Ну примерно как прогноз погоды

Лучше чем разработчики :D

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

Вообще тема интереная, но мне больше интересно насколько это болит. Много ли команды тратят на оценку, насколько это эффективно и болит ли настолько что пора искать решения

Решение - есть, знаем как. Можно пообщаться со мной на эту тему в приват, если есть коммерческий интерес.

http://focusedobjective.com

теория тут, никакой магии

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

👍

Всем привет, кто сегодня на лесс митапе?

Вот так вот :)

А никто ещё не интегрировал https://www.activecollab.com ?

А никто ещё не интегрировал https://www.activecollab.com ?

Использовал его 5 лет назад, когда он был полным клоном Basecamp. С тех пор, конечно, проект очень сильно изменился )

Agile на крупных интеграционных проектах :)

А кто-нибудь может отзыв дать или подсказать где почитать про Agile в инфраструктурных проектах? Какой фреймворк наиболее эффективен? Замысел создать одну команду и множество инфраструктурных проектов через неё пропускать.

Имхо смотрите Максима Дорофеева и его джедайскую технику. Это проще и сердитей, зато для инфраструктурных задач самое то

Имхо смотрите Максима Дорофеева и его джедайскую технику. Это проще и сердитей, зато для инфраструктурных задач самое то

чтооо?)))

А кто-нибудь может отзыв дать или подсказать где почитать про Agile в инфраструктурных проектах? Какой фреймворк наиболее эффективен? Замысел создать одну команду и множество инфраструктурных проектов через неё пропускать.

напишите подробнее, что у вас входит в понятие "инфраструктурный проект"?

напишите подробнее, что у вас входит в понятие "инфраструктурный проект"?

ИТ проекты с созданием, модернизацией инфраструктуры: сети передачи данных, центры обработки данных, видеонаблюдение, Телеком, гибридные и частные облака и т.п.

Имхо смотрите Максима Дорофеева и его джедайскую технику. Это проще и сердитей, зато для инфраструктурных задач самое то

Бегло ознакомился - ИМХО не то что хотел услышать. Мне важен контекст Agile

ИТ проекты с созданием, модернизацией инфраструктуры: сети передачи данных, центры обработки данных, видеонаблюдение, Телеком, гибридные и частные облака и т.п.

получается аутсорс инфраструктура? типовые проекты (у вас есть технология, как их делать, и профессиональная команда с небольшой текучкой)? У проектов есть бюджет/качество/срок завершения?

на чьей стороне потом поддержка? )

получается аутсорс инфраструктура? типовые проекты (у вас есть технология, как их делать, и профессиональная команда с небольшой текучкой)? У проектов есть бюджет/качество/срок завершения?

Сервисная компания (дочка) на крупном промышленном предприятии. Услуги в сопровождении и развитии всего ИТ. Проектов много, все по водопаду. Бюджеты, сроки, объемы в соответствии с классикой жанра

Проблема: матричная структура, частичное привлечение ресурсов и ресурсное планирование, карусели между различными проектами и операционной деятельностью, низкая мотивация команда и самоорганизации, частое перекидывание ответственности на смежные отделы.

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

на чьей стороне потом поддержка? )

Поддержка в этой же компании остается

Проблема: матричная структура, частичное привлечение ресурсов и ресурсное планирование, карусели между различными проектами и операционной деятельностью, низкая мотивация команда и самоорганизации, частое перекидывание ответственности на смежные отделы.

это не лечится только "низкоуровневым agile", матрица, неустойчивые команды и карусели сводят все плюсовые эффекты в ноль, в лучшем случае.

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

Типовой инфра-проект (даже если в нем "переменные", типа нагрузки на сеть, числа узлов, количества пользователей, требований к надежности и т.п.) = создание шаблонов, требований к качеству, работа с чек-листами, навешивание времени реакции на процессы.

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

В компании только-только стартовали похожие процессы: agile лаборатория (но там пока только софтовые и орг. проекты) и школа трансформации бизнеса.

Если команда будет устойчива, будет поддержка топов, сильные менеджеры, то можно за 6-12 месяцев "засетапить agile", взять из него лучшее и прокачать команду работать пободрее, и быстрее и душевнее по отношению к заказчикам :)

Если команда будет устойчива, будет поддержка топов, сильные менеджеры, то можно за 6-12 месяцев "засетапить agile", взять из него лучшее и прокачать команду работать пободрее, и быстрее и душевнее по отношению к заказчикам :)

Голос помощи и был с целью узнать какие фреймворк больше всего подходит и какие типовые ошибки существуют, чтобы их заранее обходить.

Всё-таки есть своя специфика в инфраструктуре, в отличие от софтовых проектов

типовые грабли: не выкидывайте сетап проекта, план проекта и чек-листы из-за того, что делаете "agile", собирайте обратную связь от участников команды проекта каждую неделю (условно, ретроспектива), учитывайте ее. Приучайте их распределять скоуп ближайшей недели самостоятельно. Делайте демо-созвоны с заказчиком с участием хотя бы ключевых членов команды. Звоните начальникам менеджеров проектов со стороны заказчика раз в 2 недели. Любите архитектора своего, кто дает оценки, и слушайте :) Не выжимайте нереальных оценок :)

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

Это из моих выстраданных болей по "гибкой инфраструктуре" :)

У "выделенной команды" всегда будет предел поддержки, рассчитайте его.

мы, будучи выделенной командой инфраструктуры, "канбанились", но на менеджера все равно падает нагрузка следить за сроками, получалось такое иногда ручное управление.

Канбан себя оправдал? Команда была в одном месте или территориально распределеная?

распределенная

скорее, оправдал.

И да, вопрос который меня мучает - кто должен быть PO?

у вас "сервис инфраструктуры", не выкидывайте PO со своей стороны. Вы отвечаете по контрактам, у вас должна быть роль внутреннего "РО-представителя заказчиков".

Если контракты ведут какие-то биздевы, то менеджер команды+координатор команды = ваш РО

и управляют приоритетами в бэклоге/ведут внешнюю коммуникацию.

биздевы в этом случае - прокси менеджеры, которые приносят добычу и выполняют роль передастов/точек давления (фактически, представляют поддержку менеджерам во время проекта).

у вас "сервис инфраструктуры", не выкидывайте PO со своей стороны. Вы отвечаете по контрактам, у вас должна быть роль внутреннего "РО-представителя заказчиков".

"у вас должна быть роль внутреннего "РО-представителя заказчиков".- м.б. имелось в виду ВНЕШНЕГО РО?

нет, внутреннего. Он представляет интересы внешнего заказчика, являясь при этом членом инфра-команды.

нет, внутреннего. Он представляет интересы внешнего заказчика, являясь при этом членом инфра-команды.

Ок, спасибо! Может быть все-таки есть что-то поизучать для систематизации мыслей? )) В любом случае ваши доводы были очень полезными

Ок, спасибо! Может быть все-таки есть что-то поизучать для систематизации мыслей? )) В любом случае ваши доводы были очень полезными

я поищу, но, честно говоря, мне в свое время в смысле книжек опираться было не на что. Я собирала микс практик по service design&operations + PMBoK+agile principles+operation management+IT architecture + опыт в хайлоад хостинге. Всякие гуру ITIL читала, вроде IT Skeptic, доклады по инфре с международных конференций слушала. Общалась с командами Global Infrastructure, которые поддерживали энтерпрайз на 80 000, часть проектов которого мы сопровождали.

в материалах конференции High Load можно порыться, там бывали интересные доклады по теме.

Ок, спасибо! Может быть все-таки есть что-то поизучать для систематизации мыслей? )) В любом случае ваши доводы были очень полезными

если пришлете e-mail, поделюсь заметками из evernote по канбану и инфре, оригиналы уже удалили по ссылкам.

Нашелся, кстати, вот такой склад видео с devopsdays в разных городах мира: https://vimeo.com/devopsdays/albums, enjoy twimc

Всё-таки есть своя специфика в инфраструктуре, в отличие от софтовых проектов

Для инфраструктурных проектов лучше юзать канбан из agile методологий!:) оценить некоторые задачи релевантно не всегда получается

Agile на крупных интеграционных проектах :)

Как строитель могу подтвердить, что на крупных стройках происходит что-то похожее. Хотя про agile там мало кто слышал. 😆

Все утро и с наступающим Новым Годом! Может кто-нибудь посоветует статьи по проведению Performance review сотрудника? ( или выскажет свое мнение), буду очень благодарен

Всем привет! Занимаюсь созданием ботов для telegram. 🤖 Хочу найти единомышленников или тех кому интересна эта тема, есть тут такие? Могу вам подкинуть кучу полезных ботов от чистого сердца.😆 Так как опасаюсь, что любые ссылки здесь воспримут как рекламу... Пишите в личку пообщаемся. 😊

привет! я занимаюсь ботами, правда больше как менеджер проетков с мс бот фреймворком :)

Vsem privet;)

A few years ago, Ron Jeffries, the guy who invented story points (and also signed the Manifesto for Agile Software Development), apologized for inventing them. Jim Highsmith, another signer of the Manifesto, said "Velocity is Killing Agility" and advised teams to focus on customer outcomes, not calculating velocity.