• Gantt против Backlog
    0
    Помучить Гантт — это же интересно :)

    Это может привести к интересным идеям — например к чему-то типа Гантт 2.0. Где график Гантта как-то совмещен с каждодневными оценками.

    А с тем что «совремнный» Гантт — больше «форма планирования», согласен
  • Gantt против Backlog
    0
    Задача состоит в том, чтобы один бэклог автоматически трансформировать в один Гантт.

    Именно такая операция невозможна.

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

    Здесь рассматривается логика приложения. Представте, что мы находимся на странице плана итерации в режиме беклог. Что мы должны увидеть, если на этой странице пользователь нажимает кнопку «Gantt»?

    Не получится просто ему показать одну Гантт диаграмму. Ему таких диграмм нужно сгенерировать столько, сколько рабочих дней показано в одном бэклоге. Поскольку в Скраме каждый день мы все планируем заново.
  • Gantt против Backlog
    0
    Если я правильно вас понял, предлагается зафиксировать длительность задачи… Тогда в нашем случае мы получим на 6й день 6*8 / 16 = 300%… не работает…

    Во время спринта делается каждодневная оценка оставшегося времени по задаче. И некоторые задачи могут улетать за их первую оценку, сделанную во время планирования спринта. Это жизнь.

    Вот несколько примеров, чтобы выйти на общую точку понимания:

    задача сделана раньше плана:
    план — 24. Отчеты — 24 12 0

    задача совпала с планом:
    план — 24. Отчеты — 24 16 8 0

    задача не вписалась в план:
    план — 24. Отчеты — 24 28 20 12 4 0
    обычно такое случается, если находятся непредвиденные проблеммы с логикой или архитектурой.

  • Gantt против Backlog
    +1
    hours_left и required_left — мне кажется одно и то-же.

    Давайте посчитаем. Пусть первая (плановая) оценка задачи — 16 часов.

    Разработчик рапортовал такие оценки: 12 8 8 8 8 8 0. Тоесть, например он был переключен на другую задачу. Посмотрим какой процент получается на Гантте на 6й день: 6*8/(6*8 + 8) — это 86%.

    Чтобы этот эффект не наблюдался, мы должны каждый день перерисовывать Гантт.
  • 20 причин проводить обзоры кода
    +1
    Можно обыграть как отдельную «причину» также обоснование включения рефакторинга в беклог итерации (Пример в подходе Скрам).

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

    Здесь очень кстати сделать обзор кода и соорудить хорошо оформленный документ, описать драматичные моменты… Помогает договориться.
  • Два протокола управления проектами
    +3
    К сожалению не все так просто… В большинстве случаев заказчик на старте проекта имеет только набор идей того, что он хочет получить в результате проекта. Нету магической книги, из которой вы могли бы взять задачи, «разбить их, и имплементировать в стройной архитектуре». Описанная вами картина больше напоминает работу программиста над своим личным небольшим проектом.
  • Два протокола управления проектами
    0
    Ну вот, например, составили вы чудный план исследований, взяв за основу некоторую модель явления.

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

    Так где тут детерминантность?
  • Два протокола управления проектами
    +2
    Я пытался построить простую работающую модель. На самом деле, для некоторых проектов, наверное, придется схему интеграции 2х протоколов усложнять. Возможно, нужно будет добавить повторяющиеся фазы типа детерминант — эмпирика — детерминант, которые будут поддерживать каркас для длительных проектов.

    Это не простой вопрос… Нужно подумать…

    Спасибо за комментарий.
  • Два протокола управления проектами
    0
    Согласен, эти проблемы существуют и, наверное, являются общими для всех компаний, которые вводят Agile процессы в легаси структуру. Тут вопрос в выходе на новые горизонты рынка — нужно сохранить клиентов, которые привыкли к детерминантному процессу, и привлечь новых, кто ищет интерактив и готов идти по эмпирическому процессу.

  • Два протокола управления проектами
    +1
    >>… может иногда казаться что некоторые вещи делаются для галочки — для бухгалтерии, для бумажки и так далее. Но эти вещи важны и не понимание причин их побуждающих может привести к срыву проекта, финансовым потерям и так далее. На самом деле в них своя достаточно жесткая логика — минимизация рисков, поддержка коммуникаций и в целом достижение целей проекта, которые состоят не только в продукте, а в основном в удовлетворении нужд заказчика, частью которого есть продукт.

    Именно, я набил эту шишку, когда увлекся Скрам и убедил своего топ менеджера, что мы обойдемся вообще без артефактов детерминантного процесса и все проведем по модели *постоянное общение + частые оценки + 2-недельные итерации с презентациями*. Тот проект мы завалили…

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

    Поэтому я предлагаю «панцирь» процесса строить и поддерживать в детерминантном подходе, а внутренности — в эмпирическом.

    >>Спускаясь с теоретизирования, люди — разные. Одному может быть до фени те пять копеек что будут доплачены за доп.фичу по сравнению с ее выгодой, а другому для этого нужно согласовать изменение бюджета по 20-ти инстанциям и пофиг что от нее будет лучше и денег больше. Это нельзя не учитывать.

    Я не претендую на универсальное решение проблемы. У нас — а это небольшая команда из 35 разработчиков — стратегия сработала (по крайней мере один раз). Но вполне возможно, что она не годится для компаний-флагманов рынка с командами в 200 или 400 человек.
  • Два протокола управления проектами
    0
    Не могу с вами согласиться. Как может быть детерминированным процесс, построенный на серии черных ящиков?

    Возможно, вы имели ввиду микро-планы — такие как план расчетов методом Монте-Карло какой-нибудь мат. модели. Я имел ввиду макро-план — синтезировать новую керамику, устойчивую к перепадам температур и т.д. То есть планы, которые включают длительные промежутки времени и предполагают открытия новых эффектов.
  • Два протокола управления проектами
    +1
    >>В описанной ситуации с изменениями фич нет ничего с чем не справился CMM. Просто нужно соответствующее управление изменениями в скопе проекта. При этом правда нужно ПМ-у активно поработать.

    На мой взгляд, попытки объединить оба протокола под одной крышей уже велись, да и будут продолжаться. Возьмем хоть RUP. Тяжелый итерационный процесс, который позволяет жанглировать фичами. Он идеален для CMMI. Но вот не прижился…

    Может это прозвучит слишком пафосно, но я хотел сказать, что смешивать эти протоколы Не Надо. Как с вечным двигателем… Люди тратили свои жизни на постройку тысяч механизмов, которые должны были бы работать вечно. Но в физике есть жестокий закон сохранения энергии. Имеет смысл направить усилия в другом направлении…

    >>Отодвигать решение проблемы с классической тройкой время-деньги-обьем на этап завершения нехорошо

    Тут отодвигать такое решение не приходится, поскольку мы принципиально убираем из разработки понятие Большого Плана. Согласующая итерация проводится больше «для бухгалтерии». По замыслу, в этот момент уже довольный клиент бегает по презентациям и во всю использует продукт. На согласовующей итерации подчищаются баги и доделываются очень низкоприоритетные фичи, которые не вносят существенных искажений в понятие «объем».

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

    А вот это действительно самый опасный момент. Безусловно, все, и особенно клиент должны понимать условия игры. Мы клиенту предоставляем супер-сервис, но он морально и технически должен быть готов к нему. Если клиент делегирует все принятие решений на вас, не проявляет интерес к ранним версиям системы, то здесь лучше сразу идти по Водопаду.

    >>В целом имхо это просто разделение уровней — есть управленческий, где ПМ и его руководство с заказчиком, и выполняющий, где ПМ же, исполнители и представитель заказчика же. Они вполне могут иметь разные процессы, наиболее удобные участникам. Главное что бы работало.

    Я почти с вами согласен :)
    Я бы только слово «могут» заменил на «должны». Это и есть главный *месседж*, который я хотел отправить.

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

  • Два протокола управления проектами
    +4
    Я так понимаю, что у вас претензии к фразе: «революционных архитектурных решений — таких, как MVC и паттерны Фоулера».

    Я не собираюсь спорить на тему «cтарые или новые» MVC и слоистый паттерн. Статья в общем, о другом. Вы можете в этом месте вставить любую *новую архитектурную революцию* на ваш вкус и читать статью дальше.

  • Два протокола управления проектами
    +2
    Я не вижу тут противоречия на самом деле. Заказчик решил вкинуть мегафичу? На здоровье! Но при этом он, конечно, должен знать правила игры. Эта мегафича подвинет другие — с меньшим приоритетом. Заказчик может выбрать один из вариантов — либо бюджет увеличивается на вес оценки этой фичи — либо другим фичам не повезло в этот раз — они выходят за скоуп.
  • Два протокола управления проектами
    +2
    Спасибо за вопрос.

    Действительно, Скрам процесс может получить CMMI 3. Но это потолок. Уровни 4 и 5 получить нельзя, поскольку полный набор требований CMMI разработан из предположения детерминантного процесса.

    Кстати, вот в этой книге (по секрету — я нашел ее CHM в сети) — Agile Project Management with Scrum by Ken Schwaber  ISBN:073561993x Microsoft Press © 2004. — применению Скрам для CMMI посвящен небольшой раздел.
  • Два протокола управления проектами
    +3
    P.S. Термин тим лид я использовал для обозначения члена команды, который выполняет задачи «локального» менеджера (для 2-5 разрботчиков) и одновременно выполняет задачи по кодингу.
  • Два протокола управления проектами
    +5
    Когда я был тим лидом, меня очень напрягали оценки задач, которые приходили сверху. Сейчас я менеджер проектов, и в мои обязанности входит построение и поддержка правильного Процесса Разработки.

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

    Кроме того, каждый тим лид со временем становится менеджером проектов как правило. :)
  • Используй серую логику, Люк
    0
    >>«политика порой играет более важную роль в проекте, чем ...»
    Согласен. Особенно это ощущаю, работая в оффшорных проектах, где коммуникации существенно усложнены.

    Данный пост был пробой. Я получил очень богатый фидбек. И вам спасибо за ссылку. Буду пытаться систематизировать материал и выходить на предложения по процессу разработки.
  • Используй серую логику, Люк
    0
    По ЧБ логике военнопленный должен быть убит. Иначе он продолжит убивать солдат с вашей стороны.

    Я не обсуждал интеллект людей которые работают в ООН.

    Вообще, я предлагаю закрыть политические темы. Тема топика сложная и изначально я собирался ее рассматривать в разрезе проблем управления проектами.
  • Используй серую логику, Люк
    0
    Думаю что были и есть. Например, проявление гуманизма к военнопленным.

    Опять же, серая или ОК, нечеткая, логика заложена в нас органически. Вы не можете ее применять или не применять. Мы же не боремся с дыханием, например.

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

    В случае с Ираком, нам бы помогла международная организация, оперирующая СЛ и анализом мотивов политических элит разных стран. Тогда бы в случае с придуманным ОМП, она бы, учитывая реальный нефтяной мотив, наложила бы запрет на военную операцию.

    ООН не тянет на этот уровень. Сейчас практически любая страна с сильной экономикой может напасть на страну со слабой экономикой.

  • Используй серую логику, Люк
    0
    Если вам интересна лично моя позиция, то СЛ тут использовалась для недобрых целей.

    И многие это понимали, в том числе и в самих штатах.
  • Используй серую логику, Люк
    0
    А вот здесь мы «on the same page»!

    Согласен.
  • Используй серую логику, Люк
    0
    >>«доберемся поближе к нефтяным запасам на ближнем востоке» — вот это МОТИВ.

    А на словах — ОМП. Это моя модель.
  • Используй серую логику, Люк
    0
    Мы видим и понимаем проблему с вами одинаково, но используем разные слова…

    Вот мой подход: американские политики провели грубый ЧБ троллинг по поводу ОМП в Ираке. Они сказали, что штаты белые и пушистые (1) а Ирак — ось зла (0).

    Здравомыслящие люди не повелись — им помогла нечеткая логика.
  • Используй серую логику, Люк
    0
    Я как раз хотел сказать, что ЧБ логика — это несовершенный инструмент. В частности, его использование ведет к войнам и антагонизму культур. Человек в своем развитии пошел дальше — он мыслит в серой или, используя математический термин, в нечеткой логике.

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

    В посте это слово используется просто для обозначения цвета, который находится между белым и черным и имеет непрерывное множество градаций.
  • Используй серую логику, Люк
    0
    Спасибо за реф.
  • Используй серую логику, Люк
    0
    Мне кажется что мнение все-таки одно, а стратегий, как его передать словами — несколько.

    Когда вы чувствуете, что собеседник совсем по-другому мыслит о предмете или проблеме — вы можете начинать объяснять свою позицию с разных сторон. Это скорее много форм описания в ЧБ логике одного и того-же.
  • Используй серую логику, Люк
    0
    Поправил, спасибо.
  • Используй серую логику, Люк
    0
    Да, это то, что я пытался сказать. Спасибо за понимание.
  • Используй серую логику, Люк
    0
    Спасибо…

    Я вот подумываю над «нечеткой» серией… Еще очень много всего осталось за кадром.

    Например вот еще понятие «эксперт». Это закрепленный титул, который дает право принимать решения. А вам, как студенту, не приходилось слушать ерунду, произносимую профессором на лекции? Сейчас мы подходим к таким вещам примитивно — он либо профессор (1) либо не профессор (0). Давайте введем коэффициент профессора:
    — Здравствуйте, студенты, Я Блаб Блаблов, 0.01 профессора. По законодательству Земли все мои высказывания следует воспринимать с доверием 0.01. Я должен об этом заявить согласно статьи 1234 того же законодательства перед прочтением лекции.

    Тогда глядишь и профессор перед лекцией бы заглянул в википедию — что там нового случилось за последние 20 лет по его науке.

    Хабр не всем мне нравится, но его динамическая оценка — это модель того к чему, я думаю, мы придем через некоторое время…
  • Используй серую логику, Люк
    0
    Просто продолжение вашей концепции…

    news: PMI issues PMBOK 2020 8bit Edition.

    :)

    P.S. В каждой шутке есть доля правды…
  • Используй серую логику, Люк
    0
    Фуф. Ну хоть один радикально отрицательный комментарий.

    Я уж подумал что тема скучная… ;)

    О языке спорить не буду. У меня катастрофически не хватает времени на чтение художественных книг. Это сказывается…

    Насчет замены «серая» на «нечеткая» — уже разобрались.

  • Используй серую логику, Люк
    0
    Нет, речь шла о нечеткой логике. О математическом термине. Хотя с диалектической логикой пересечение наверное есть.
  • Используй серую логику, Люк
    0
    Очевидные вещи тут не доказываются. Обсуждается принципиальная проблема принципов по которым мы строим управление проектами.

    Я описал проблему, но решения у меня пока нет и не думаю что скоро появится — проблема слишком глубокая…

    Посмотрите еще этот комментарий.
  • Используй серую логику, Люк
    0
    ПМ — прямой перевод аббревиатуры PM (Project Manager). Я добавлю расшифровку в статью.
  • Используй серую логику, Люк
    0
    Я ответил здесь
  • Используй серую логику, Люк
    0
    >>К PMBOK прилагается так называемый кодекс этики, где 100% честность является основополагающим качеством ПМа.

    Вот в этом и проблема. Как только у одного из менеджеров появляется МОТИВ, он на протяжении 12 часов соорудит такое словесно-логическое облако, которое будет очень похоже на «честные мысли хорошего парня». И плюс к этом эмоциональный натиск, группа поддержки, 2-часовый разговор после 23.00 по скайпу.

    Я писал про такие ситуации, а не про банальную ложь.

    Статья в общем не о мне и о том что я часто лгу. Статья про несовершенство ПРИНЦИПОВ менеджмента и того-же PMBOK

  • Используй серую логику, Люк
    0
    Очень интересно…
  • Используй серую логику, Люк
    +1
    Я сократил разговор. Попытка обсудить детали была. Но я понял что у топа в тот момент не было мотива разбираться в деталях. Услышать то, что клиент сглупил — он явно не был готов. Я оценил ситуацию и решил воспользоваться серой логикой (или нечеткой) — я сказал то, что топ хотел услышать. Поверил ли он мне — не думаю. Иначе на следующий день не переспрашивал бы начали мы делать изменения или нет.

    В похожей ситуации в начале карьеры ПМ-а я шел до конца — тратил часы на бессмысленные войны. И в конце оказывался в черном списке.

  • Используй серую логику, Люк
    +2
    Я тут должен был наверное описать бекграунд этого разговора. Тогда бы стало все ясно.

    Речь идет о том, что клиент не сориентировался в логике работы админки сайта. Продукты вводились на отдельной странице — управление продуктами. Но до нее клиент не дошел. Он попробовал редактировать продукты прямо на странице, которая управляла статикой на странице продуктов. И не разобравшись — надавил на топа. Вместо того чтобы попробовать вникнуть в детали, топ перешел на уровень «абстрактного коня в вакууме» и начал рассуждать о том что клиент всегда прав.

    Я не собираюсь оспаривать фразу «клиент всегда прав» (хотя это больше иероглиф чем факт). Я против того чтобы обсуждать технические дела на таком «серьезном» уровне.

    Ну все ведь хорошо закончилось тогда ;)