Даже если их не скрещивать, все-равно все что выведено за скобки методологии просто забывается и перестает применяться. Консультанты Scrum говорят "как общаться", но не говорят "что нужно сделать чтобы получить качественный код."
S_A для выполнения прогнозирования выполнения проекта на самом деле столько всего и не нужно. В интеллектуальной сфере где задачи относительно схожие есть «скорость выполнения задач» и «скорость добавления задач» (XP, Agile) на основе которых можно делать прогнозы.
Если у проекта есть риски, то в план добить работы связанные с уменьшением риска или явно заложить буфер расписания и бюджета на известные риски. То есть тоже будет известная цифра для прогноза. А на совсем неизвестные события, где сработает неизвестный риск (Мерфи напомнит о себе) закладывается стандартный буфер критической цепи проекта (см CCPM, TOC)
Таким образом самая простая модель будет такая:
D = (( ((E + R)/ (Vi — Va) ) * Bs * Bb) / T) * W
D — расчетная календарная длительность
E — оцененный, наиболее вероятный объем проекта
Vi — скорость выполнения задач, сколько работы выполнено за календарное время
Va — скорость добавления задач, сколько добавили неизвестной работы за календарное время
R — известные риски, в оцененных чел/днях с учетом вероятности возникновения
Bs — буфер расписания 50% длительности
Bb — буфер бюджета, 50% оцененного объема
T — размер команды
W — пересчет рабочих дней в календарные, с учетом праздников
И её можно посчитать в Excel.
shtorman Касательно SaaS — уже есть, BiPulse использует схему моделирования для рекомендаций что делать руководителю проекта.
Это хороший комментарий Тимофей, а есть ли у Вас какие нибудь свои рецепты ускорения развития разработчика? Как научить его думать правильно?
как понять, как этот класс делить?
Мой рецепт такой, что если есть понимание что делить надо, то наиболее оптимально это разделение по ролям. И даже если разработчик будет вначале плодить слишком много классов это можно быстро вылечить, за счёт тех же обоснований «почему ты считаешь что это должно быть отдельным классом?»
Отвечая на Ваш вопрос, касательно фундаментальности статьи:
Возможно, мне не удалось правильно донести свою мысль и Ваши ожидания от статьи разошлись с реальностью. Однако у всяких паттернов есть ключевые условия их возникновения как и у антипаттернов. Именно их и хотелось рассмотреть и начать какую-то конструктивную дискуссию именно о простых базовых принципах, применимых в качестве отправной точки при аудите дизайна (вместо «у тебя здесь божественный объект — исправь»). Однако, к сожалению, не увидел от Вас, коллега, ни одного конструктивного комментария.
Что касается способа «RTFM паттерны»:
Коллега, Вы серьезно уверены что молодой специалист, почти без стажа работы, сможет удержать в голове все паттерны и антипаттерны?
Моя практика показывает, что беглый просмотр паттернов/антипаттернов без продолжительных навыков их применения не дает хорошего эффекта.
Поэтому, повторю вопрос: какой способ Вы считаете приемлемым для быстрого обучения навыкам хорошего дизайна молодых специалистов, кроме способа «RTFM паттерны»?
И, я полагаю, что у Вас, есть хороший опыт в аудите дизайна проекта и проведении рецензирования кода. Какими критериями Вы руководствуетесь при принятии решения, хороший дизайн проекта или нет и его нужно переписать?
Да, это вопрос хороший, но, по моему мнению, он является следствием из того «что он должен делать?», Ведь, для того чтобы что-то делать нужно что-то знать. Хотя верно и обратное, не нужно чего-то знать чтобы что-то делать. Начинающие разработчики могут путать цели класса и его знания пытаясь запихнуть дополнительные знания в класс не сообразующиеся с его назначением.
Цель данной статьи было не перечисление антипаттернов, а пресечение их возникновения. Для того чтобы понять систему шаблонов проектирования нужно уже освоить базу языка. Так, как это более высокий уровень абстракции. Но несколько простых вопросов могут помочь в критической оценке создаваемого дизайна без знания всех паттернов и антипаттернов.
Для познания возможностей языка программирования нужно минимум 3 года, для познания паттернов и особенностей их применения еще 2 года. Таким образом, я хороший специалист с навыками проектирования должен иметь стаж не менее 5 лет. И то, если его кто-то наставлял на путь истинный.
Коллега, какие более быстрые способы обучения навыкам хорошего проектирования с нуля Вы знаете?
«Цель-3» она про внедрение ERP, мне показалась не такой интересной, хотя и раскрывает вопрос «сколько денег принесет внедрение?». А вот «Новая Цель» сильно лучше. Однако проработка решений лучше видна в книжке «Выбор».
Список литературы я специально не стал полным делать, чтобы задать ключи для поиска, так как литературы много и она разная.
Концепция CxxTest для которого предназначен CxxMock, не позволяет делать зависимость от дополнительных библиотек. А потом и смысла нет, добавлять целую библиотеку ради кода на ~30 строк (примерный размер решения для выполнения метода).
Не совсем важно, как именно человек раньше работал. Важно как надо работать сейчас… В общении, люди не склонны переспрашивать собеседника «все ли понятно?», потому что ожидают что, то что они говорят должно быть всем понятно, что со временем приводит к синдрому «ежупы» («и ежу понятно»). Или, в свою очередь, делаются неверные выводы на основе неверных предпосылок
Навык переспрашивания «А правильно ли я понял что....?» развивается дополнительно, но как правило только у манагеров и бизнес-аналитиков. А рядовые сотрудники как правило до этого ДАО не дорастают, ибо не требуется.
На собеседовании обычно проверяется необходимый технический скилл, а не образ постановки задач в предыдущей компании.
1. Да. позволяет. И только этот режим поддерживается.
2. Передаются и сохраняются. главное чтобы указатель не умер в процессе теста. Проверяются значения указателей. Если хочется как-то по другому, то нужно писать свой перегруженный CxxTest::equals() который проверит значения по указателю.
3. Потокобезопасности нет, не было необходимости. Обычно модульные тесты выполняются в одном потоке. Если для теста требуется стросс-тестирование на потоках, то тут лучше делать ручной мок-объект, потому что иначе поведение будет не предсказуемое и CxxMock будет генерить ошибки через один из-за нарушения последовательности вызовов. Второй аргумент отсутствия — платформозависимость, CxxTest платформонезависим., поэтому CxxMock также следует этому принципу кроме требований к RTTI.
Тогда дело скорее всего кроется в том, что он НЕ ХОЧЕТ брать ответственность на себя. Возможно здесь имеет смысл выяснить почему он не хочет брать ответственность на себя и что с этим можно сделать проработав дерево текущей реальности (еще один инструмент ТОС). Очень интересно с помощью инструментов ТОС моделировать переговоры.
Заказчик не любит думать об информационной системе которую ему надо, у него всяких других дел как правило выше крыши. Вот представь что нужно одновременно контролировать поставки, контракты, сроки заключения договоров, обязательства… а тут приходишь ты и начинаешь спрашивать какие-то вопросы о которых надо подумать… Ну нафиг! «у меня нет времени об этом думать» будет самый простой выход и ситуации.
Я в таких случаях, прорабатываю 2 наиболее вероятных варианта понимания требований заказчика и задаю вопрос в виде: А правильно ли я понял что нужно «решение А» или вы имели ввиду «решение Б»? Тут сильно думать уже не так требуется, нужно выбрать один из двух вариантов, если они подходят, или Заказчику придется сделать поправку «Нет, я не это имел в виду....» и тогда он уточнит что же он имел ввиду. и после проработки и анализа новых данных повторяем. Но следует учесть, что если заказчик изначально отказывается то и в подходе с согласованием из вариантов нужно на него не сильно давить, и возможно пакетировать все вопросы требующие решений в 2-3 встречи.
Хороший вопрос содержит 90% ответа (с) народная мудрость.
Если возникает конфликт между желанием заказчика добавить фичу и сложностью ее внедрения или не пониманием целесообразности, то тут также может помочь проработка дерева будущей реальности. С выяснением ответов на вопрос «К чему приведет внедрение этой фичи?» и «Какие реальные потребности клиента/пользователя решит новая фича?».
Результатом проработки этих сценариев и последствий будет или согласие по необходимости внедрения или иное, альтернативное решение. Вполне возможно, что то нужно клиенту это не совсем то что он просит сделать в системе.
За ссылку спасибо, не знал что такое есть, и в итоге сделал свой инструмент как раз чтобы работать по описанной методике.
О календарном планировании, можете пример привести на какие вопросы он лучше отвечает и в какой ситуации? Или это про конфликт ресурсов и связанное с ним изменение очередности выполнения работ на ресурсе?
Я вижу, что при рассмотрении детального плана можно учитывать риски каждой задачи, что в случае неоднородных проектов (производство, разработка ПО, поставка и другие) будет иметь смысл ибо неоднородность проекта приводит неоднородности рисков. Но в таком случае, я бы развел на отдельные этапы работ с независимым расчетом, что приводит опять к простому сценарию для каждого этапа.
Напомните, о каких колбасках идет речь? Если диаграмма критической цепи с учетом буферов (БДР, БСП), то я считаю что настолько детальное планирование имеет смысл только при очень большой конкуренции за ресурсы и сильных рисках именно на доступности ресурса.
Но если буфера на цепи упрощать, то мы получим буфер проекта который отслеживается весьма просто. Но он больше отвечает на вопрос о здоровье проекта, а не предполагаемых затратах.
Если у проекта есть риски, то в план добить работы связанные с уменьшением риска или явно заложить буфер расписания и бюджета на известные риски. То есть тоже будет известная цифра для прогноза. А на совсем неизвестные события, где сработает неизвестный риск (Мерфи напомнит о себе) закладывается стандартный буфер критической цепи проекта (см CCPM, TOC)
Таким образом самая простая модель будет такая:
D = (( ((E + R)/ (Vi — Va) ) * Bs * Bb) / T) * W
D — расчетная календарная длительность
E — оцененный, наиболее вероятный объем проекта
Vi — скорость выполнения задач, сколько работы выполнено за календарное время
Va — скорость добавления задач, сколько добавили неизвестной работы за календарное время
R — известные риски, в оцененных чел/днях с учетом вероятности возникновения
Bs — буфер расписания 50% длительности
Bb — буфер бюджета, 50% оцененного объема
T — размер команды
W — пересчет рабочих дней в календарные, с учетом праздников
И её можно посчитать в Excel.
shtorman Касательно SaaS — уже есть, BiPulse использует схему моделирования для рекомендаций что делать руководителю проекта.
Мой рецепт такой, что если есть понимание что делить надо, то наиболее оптимально это разделение по ролям. И даже если разработчик будет вначале плодить слишком много классов это можно быстро вылечить, за счёт тех же обоснований «почему ты считаешь что это должно быть отдельным классом?»
Тимофей, а какой Ваш рецепт в этом случае?
Возможно, мне не удалось правильно донести свою мысль и Ваши ожидания от статьи разошлись с реальностью. Однако у всяких паттернов есть ключевые условия их возникновения как и у антипаттернов. Именно их и хотелось рассмотреть и начать какую-то конструктивную дискуссию именно о простых базовых принципах, применимых в качестве отправной точки при аудите дизайна (вместо «у тебя здесь божественный объект — исправь»). Однако, к сожалению, не увидел от Вас, коллега, ни одного конструктивного комментария.
Что касается способа «RTFM паттерны»:
Коллега, Вы серьезно уверены что молодой специалист, почти без стажа работы, сможет удержать в голове все паттерны и антипаттерны?
Моя практика показывает, что беглый просмотр паттернов/антипаттернов без продолжительных навыков их применения не дает хорошего эффекта.
Поэтому, повторю вопрос: какой способ Вы считаете приемлемым для быстрого обучения навыкам хорошего дизайна молодых специалистов, кроме способа «RTFM паттерны»?
И, я полагаю, что у Вас, есть хороший опыт в аудите дизайна проекта и проведении рецензирования кода. Какими критериями Вы руководствуетесь при принятии решения, хороший дизайн проекта или нет и его нужно переписать?
Для познания возможностей языка программирования нужно минимум 3 года, для познания паттернов и особенностей их применения еще 2 года. Таким образом, я хороший специалист с навыками проектирования должен иметь стаж не менее 5 лет. И то, если его кто-то наставлял на путь истинный.
Коллега, какие более быстрые способы обучения навыкам хорошего проектирования с нуля Вы знаете?
Список литературы я специально не стал полным делать, чтобы задать ключи для поиска, так как литературы много и она разная.
Навык переспрашивания «А правильно ли я понял что....?» развивается дополнительно, но как правило только у манагеров и бизнес-аналитиков. А рядовые сотрудники как правило до этого ДАО не дорастают, ибо не требуется.
На собеседовании обычно проверяется необходимый технический скилл, а не образ постановки задач в предыдущей компании.
2. Передаются и сохраняются. главное чтобы указатель не умер в процессе теста. Проверяются значения указателей. Если хочется как-то по другому, то нужно писать свой перегруженный CxxTest::equals() который проверит значения по указателю.
3. Потокобезопасности нет, не было необходимости. Обычно модульные тесты выполняются в одном потоке. Если для теста требуется стросс-тестирование на потоках, то тут лучше делать ручной мок-объект, потому что иначе поведение будет не предсказуемое и CxxMock будет генерить ошибки через один из-за нарушения последовательности вызовов. Второй аргумент отсутствия — платформозависимость, CxxTest платформонезависим., поэтому CxxMock также следует этому принципу кроме требований к RTTI.
Или ты уже это пробовал?
Я в таких случаях, прорабатываю 2 наиболее вероятных варианта понимания требований заказчика и задаю вопрос в виде: А правильно ли я понял что нужно «решение А» или вы имели ввиду «решение Б»? Тут сильно думать уже не так требуется, нужно выбрать один из двух вариантов, если они подходят, или Заказчику придется сделать поправку «Нет, я не это имел в виду....» и тогда он уточнит что же он имел ввиду. и после проработки и анализа новых данных повторяем. Но следует учесть, что если заказчик изначально отказывается то и в подходе с согласованием из вариантов нужно на него не сильно давить, и возможно пакетировать все вопросы требующие решений в 2-3 встречи.
Хороший вопрос содержит 90% ответа (с) народная мудрость.
Результатом проработки этих сценариев и последствий будет или согласие по необходимости внедрения или иное, альтернативное решение. Вполне возможно, что то нужно клиенту это не совсем то что он просит сделать в системе.
О календарном планировании, можете пример привести на какие вопросы он лучше отвечает и в какой ситуации? Или это про конфликт ресурсов и связанное с ним изменение очередности выполнения работ на ресурсе?
Я вижу, что при рассмотрении детального плана можно учитывать риски каждой задачи, что в случае неоднородных проектов (производство, разработка ПО, поставка и другие) будет иметь смысл ибо неоднородность проекта приводит неоднородности рисков. Но в таком случае, я бы развел на отдельные этапы работ с независимым расчетом, что приводит опять к простому сценарию для каждого этапа.
Но если буфера на цепи упрощать, то мы получим буфер проекта который отслеживается весьма просто. Но он больше отвечает на вопрос о здоровье проекта, а не предполагаемых затратах.