Сучасна диджитал-освіта для дітей — безоплатне заняття в GoITeens ×
Mazda CX 5
×
Vice President в Intellias
  • Intellias виступив спонсором україномовного перекладу PMBOK Guide

  • Что делать, когда Scrum трещит по швам

    Дмитрий, не очень понял какие вопросы-ответы вы имели ввиду, как и идиому с «крестиком».

    В данной статье я описал наиболее популярные подходы организации работ нескольких команд над одним проектом/продуктом. Да, они все про Agile-разработку.

    Кейс по трансформации навел на мысль собрать информацию в одном месте. Я не собирался тут публиковать кейс стади.

  • Что делать, когда Scrum трещит по швам

    Если вы про LeSS, то на практике, из того, что я видел, более 4 команд выделяют Area Product Owner-ов.

  • Что делать, когда Scrum трещит по швам

    Если знаете более эффективный подход организации работы 40+ людей, поделитесь.

  • Что делать, когда Scrum трещит по швам

    Спасибо, за комментарий.

    Я не имел ввиду, что это не возможно, но, к примеру, PI Planning проводить по ремоуту менее эффективно. Многие клиенты свозят все команды в одну локацию, это дополнительные затраты на кост продукта.

  • Что делать, когда Scrum трещит по швам

    Да, есть. К примеру DevOps команды. Одна команда на несколько проектов. Обычно работа таких команд организовывается как сервис. Если жесткие SLA, тогда выстраивается процесс по ITIL практикам (Service Operation), более простой вариант — Kanban.

  • Что делать, когда Scrum трещит по швам

    Как показывает практика, на коммуникацию уходит до 30% времени. Если знаете более эффективный способ организовать работу 40+ людей, поделитесь.

    Підтримав: anonymous
  • Схватка двух ёкодзун: ITIL vs PMBoK

    Тут выбор невелик, все права на публикацию ITIL книг принадлежат AXELOS. Так что тут только такой вариант: www.axelos.com/...​foundation-itil-4-edition

    есть еще всякие адаптации, вроде таких: www.ebay.co.uk/...​11585761?iid=391649915880 но не могу посоветовать, что-то конкретное, читал только оригинальные книги.

    на Amazon есть такие опции:
    — www.amazon.com/...​fRID=7EJ1FMY940T88JWZZYVJ
    — www.amazon.com/...​fRID=7EJ1FMY940T88JWZZYVJ
    — www.amazon.com/...​Suite-ebook/dp/B00OYTB3VS
    — www.amazon.com/...​fRID=7EJ1FMY940T88JWZZYVJ
    — www.amazon.com/...​fRID=7EJ1FMY940T88JWZZYVJ

    Підтримав: Volodymyr Yatsevsky
  • Схватка двух ёкодзун: ITIL vs PMBoK

    Ну, я бы по-другому сказал. Change Management это процесс, который стоит подумать, чтобы он отвечал потребностям проекта. Вы промежете спланировать его таким образом, что если у Вас есть Hot Fix, он может пойти по упрощенному workflow. Если есть крупные изменения сущестущих изменений, то изменения должны быть оценены командой и Architect и Product Owner (которые входят в Change Control Board) утверждают, чтобы это изменение взяли в Backlog. Изменения в Schedule, Cost, Scope документируются и всем нужным stakholders вы высылаете уведомление. Если изменение имеет слишком большой импакт на Scope, Cost, Schedule мы идем за апрувом к спонсору проекта или к budget owner. Ну и т.д. Это как пример. Доставка изменений или CD это технический аспект работы, Integrated Change Control это процессный, чтобы мы не упустили, что наши изменения повлияли на дату релиза, остальной scope или cost проекта. Идея большинства agile подходов, это максимально упростить этот процесс, но тем не менее в том или инном виде он существует даже в Scrum, Kanban и пр. просто отдается на откуп PO и тут больше фокус на приоритизацию backlog.

  • Схватка двух ёкодзун: ITIL vs PMBoK

    Юрий, я исхожу из опыта работы в ИТ-аутсорсинговой компании, у нас более 600 проектов, на всех разные подходы, методологии и практики. Я не видел проекта, где применяются все 49 процессов из PMBoK или все 26 процессов в ITIL, думаю, это и нецелесообразно. Но отдельные практики из обоих подходов работают очень даже хорошо. Те проекты, где у нас есть SLA (обязательства перед клиентом решить его реквест определенной сложности за определенное время), практики из ITSM работают очень даже хорошо. Fixed-Price проекты могут использовать арсенал PMBoK. Многие проекты, могут использовать отдельные практики с обоих подходов.

    Если честно, я ни разу не слышал про удачную имплементацию CMMI. Под удачной имплементацией, я понимаю, та, которая принесла дополнительную ценность компании. Но не исключаю, что такое явление существует. Видел когда CMMI применяют для очень ограниченного куска бизнеса (один проект) для получения сертификации. Поэтому у меня немного скептический взгляд на ее счет.

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

    Спасибо за комментарий!

  • Схватка двух ёкодзун: ITIL vs PMBoK

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

    Когда мы утвердили, что сервису быть, прошли фазу дизайн и начали непосредственно разработку, тут уже работает Integrated Change Control из PMBoK. В зависимости от гибкости компании он может быть разным. Если мы говорим про Agile проект, который работает итерациями по Scrum, то CCB может состоять из Product Owner или PO и Architect. а процесс согласования может проходить во время одного митинга. Эта процедура отлично работает с Continuous Delivery.

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

    IMHO

    Підтримали: Oleksii Khorchev, Yuriy Nazarenko
  • Схватка двух ёкодзун: ITIL vs PMBoK

    Спасибо за комментарий. Действительно очень интересная тема

    PMBOK для разработки софта

    , спасибо за идею для следующей статьи.

  • Схватка двух ёкодзун: ITIL vs PMBoK

    Рад, что Вам понравилась, статья!

  • Схватка двух ёкодзун: ITIL vs PMBoK

    Хороший вопрос! Признаюсь честно, полного имени автора не знал, но википедия подсказала: «Диаграмма названа в честь одного из крупнейших японских теоретиков менеджмента профессора Каору Исикавы (яп. 石川 馨, ромадзи Kaoru Ishikawa), который предложил её в 1952 году (по другим данным — в 1943 году[1]) как дополнение к существующим методикам логического анализа и улучшения качества процессов в промышленности Японии». Детали можно почитать тут: uk.wikipedia.org/wiki/Діаграма_Ішикави

  • Путеводитель по сертификациям проектного менеджмента

    Спасибо за вопрос. Я считаю, что эти сертификации закрывают два разных вопроса. PMP — что должен знать Project Manager. Это общий словарь терминов и обще принятых Best Practicies. Это арсенал tools and techniques. PMI-ACP это ответ на вопрос как организовать процесс гибкой разработки IT продуктов (на самом деле там не только про IT, но если мы говорим про «айтишного ПМа»...). Если вы ищите ответ на вопрос, что лучше применить, на Вашем проекте Scrum или Kanban, какие церемонии у Вас должны быть на проекте и пр., тогда PMI-ACP, то что Вам надо. Если у Вас встала задача спрогнозировать Release, оценить риски на проекте, заключить правильную форму договора с подрядчиками или категоризировать заинтересованные стороны на проекте, ответы вы найдете в PMBoK, а подтверждением, что вы эти ответы знаете (или знали) как раз PMP.

    На мой взгляд обе сертификации релевантны для сферы ИТ.

  • Путеводитель по сертификациям проектного менеджмента

    На эту тему достаточно много информации, вряд ли у меня будет что добавить. Рекомендую эту статью:
    www.bmcsoftware.uk/...​l-cobit-introduction.html

    Підтримав: Микола Федчик
  • Путеводитель по сертификациям проектного менеджмента

    В этом направлении есть два варианта:
    1. Пройти курсы и получить сертификат (к примеру CSM). Я довольно долго работаю со Scrum и Kanban, достаточно много читал на эту тему и перебрал материалов при подготовке курсов в SoftServe. Я работаю в PMO и перед глазами есть живой пример около 500 проектов. Честно говоря, я сомневаюсь, что на курсах узнаю, что-то новое. Всегда, конечно, можно подчерпнуть что-то, уверен у тренеров, которые проводят такие курсы есть свои интересные кейсы, истории и способы подачи материала, но не уверен, что это стоит 500-1000$. Думаю, в моем случае ROI будет очень низким.
    2. Можно сдать сертификацию без прохождения курсов (PSM), но вряд ли еще один сертификат мне сильно поможет. В роли Scrum Master-а я в ближайшее время выступать не планирую, мои тренинги это вряд ли сделает лучше.

    ИМХО :)

  • Путеводитель по сертификациям проектного менеджмента

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

  • Путеводитель по сертификациям проектного менеджмента

    CSM и CSPO, требуют пройти курсы перед сертификацией, поэтому их гораздо больше рекламируют, те кто проводят эти курсы. Сам экзамен PSM сложнее и как правило свидетельствует про более глубокое понимание, но сертификацию знают не многие, ее никто особо не популяризирует в наших широтах. Можете давать HR-ам теперь ссылку на статью :)

    Підтримав: Alex Halkin
  • Путеводитель по сертификациям проектного менеджмента

    Спасибо, на самом деле, сам долго искал подобную статью, не нашел и решил написать.

← Сtrl 12 Ctrl →