Перейти к содержанию
Поиск
    

mplata

Свой
 Профиль  Обзор контента

  • Постов

    792

  • Зарегистрирован

  • Посещение

  • Победитель дней

    2

 Тип контента 

Сообщения, опубликованные mplata

  1. Опубликовано · Пожаловаться

    11 hours ago, one_eight_seven said:

    Так посмотрите выступления на конференциях, подкасты на тематических каналах. Равно как и людей, которые  в консультирующих конторах работают, которые тоже всё уже понимают, но вынуждены пользоваться инфоцыганщиной, потому что эффективные менеджеры наконец прочитали третью книгу в своей жизни, и сейчас у них модно читать про агиле, и вот хотят они, чтобы то, что им построят, называли агиле, потому что так модно.

    Причем тут мода не понимаю. Видимо крупнейшие ИТ компании следуют моде в ущерб прибыли. 

  3. Опубликовано · Пожаловаться

    3 hours ago, gin said:

    Заказчик - это представитель сторонней организации? Если сторонней, то как вообще он может быть руководителем вашего разработчика? Ведь для разработчика есть должностная инструкция, в ней указано кому он подчиняется. И это явно должен быть человек не сторонний.

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

    Заказчик может быть любым. Внешним или внутренним. Это ничего не меняет .

    24 minutes ago, kpv said:

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

     

     

     

     

     

    Скамить можно все. И это дешевле обходится, чем рекламации и вечная разработка.

  4. Опубликовано · Пожаловаться

    3 minutes ago, kpv said:

     

    Если у разработчиков всё хорошо, и они всё сделали и это даже прекрасно работает. 

    Вот я как раз про то, что заказчик для разработчика это по сути его руководитель. Разработчик сделал, оно работает , мол какие претензии к разработчику. А по факту изделие и вся эта предварительная разработка никому не нужна. Потому что каждый сидел в своей норке и делал то что сказали. И теперь разгебает уже руководитель. 

    У нас как раз такой ситуации не может возникнуть. Из за того что скрам работает. Все в курсе происходящего и все прекрасно понимают куда двигаются. В том числе скрам-мастер который у нас как раз разбирается. А не просто секретарь референт. 

  5. Опубликовано · Пожаловаться

    15 hours ago, Yuri7751 said:

    Ну и? А тут работающая система! Все шуршат, генерятся отчёты со страшной силой, совещания, графики... И, что замечательно, есть мальчики для битья, которых можно возить мордой по столу без риска сорвать проект - те же скрам-мастера или как их там. Лепота! Если б я был директором, непременно какую-нибудь такую херню внедрил

    Это да... целых невыносимых 10-15 минут на встречу каждый день (из дома например), где ты рассказываешь в том числе почему не удалось то или иное, где тебе помогают решить твой же вопрос. При этом вместо того, чтобы тебя загрузить отчетами скрам-мастер делает это за тебя (сволочь просто). А в конце спринта тебя даже унизительно хвалят, показывают выполненный фронт работ и ты берешь следующий блок работ причем совершенно несправедливо ты набираешь ровно столько, сколько реально можешь успеть, чтобы не ночевать на работе и выходные проводить с семьей, а не с начальником на телефоне. Просто жуть какая-то. 

    9 minutes ago, one_eight_seven said:

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

    Протокол разногласий не противоречит скраму. 

  6. Опубликовано · Пожаловаться

    4 hours ago, dxp said:

     А кузов, двигатель, трансмиссию -- это всё на старте надо предусмотреть. И никак это ТЗ на мелкие задачи не разбивается. 

    Почему не разбивается? Очень даже разбивается. И скрамить можно легко. Даже внедрение дизеля на авто бензиновый. Только задач будет больше чем при добавлении свистелок и начать придется не с почти готового авто как в случае покраски, а с более раннего этапа. 

    Пока действительно против те, кому придется реально работать. Хочется сесть и разрабатывать что-то долго чтобы никто не отвлекал и в таком инкубаторе провести как можно больше времени. А потом когда придет время сдавать проект не сдать его в срок или сделать все не так. Зато спокойно и никто не мешает. 

    Например, вот простейшая задача - пусть заказчик просит сделать ПИД регулятор температуры (четкое ТЗ, сроки). Сделали и даже прекрасно работает! Но компонент который применен (неважно какой) больше не выпускается или что гораздо чаще встречается компонент только только вышел и еще не поступил в продажу или достать его крайне сложно (зато все на современной элементной базе). В итоге например за 3 месяца зарплату проели, а прибор никому не нужен. А причин не принятия прибора в серию может быть несколько (вплоть до нетехнологичности производства). То есть затраты вырастают, сроки прошли, все матерятся, заказчик недоволен, требует вернуть деньги. Разработчика это никак не коснется, оттудваться будет руководство, юристы и т.п. Зато было комфортно сидеть 3 месяца и решать задачу, никакой суеты. 

  7. Опубликовано · Пожаловаться

    2 hours ago, Карлсон said:

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

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

     

    Если хотите мы можем у Вас запустить скрам, провести пару спринтов и далее Вы сами. 

  8. Опубликовано · Пожаловаться

    1 minute ago, Карлсон said:

    В общем, как всегда одна болтология. Никто адекватно пример разобрать и показать, куда там скрам вводить, не в состоянии 🙂

    Так пожалуйста. 

    Можем предложить консультацию по введению скрама. Месяц поработать с Вами. Не в форуме же 

    • Sad 1
    • Downvote 1

  9. Опубликовано · Пожаловаться

    1 hour ago, gin said:

    И еще одно замечание - по поводу ТЗ. Почему скрам-мастера и прочие аджайл-коучи его так не любят и всячески избегают. Ведь ТЗ - это не какая то бумажка, которой можно подтереться. Нет, это документ, причем юридически значимый документ, который и в судебных спорах может использоваться если что. И вот, дорогой скрам-мастер, если ты поставил свою подпись под требованиями ТЗ - буде ласка исполняй. Это ответственность, от которой вся эта 'эффективная братия' бежит как от огня. Тут уже не прокатят разговоры про командную ответственность, не получится свалить свои косяки на Васю-программиста или Петю-тестировщика. Поставил свою подпись - тебе и отвечать за косяки!

    Я уж и не говорю, что самостоятельно написать ТЗ они никогда и не смогут, хотя это вполне нормальная работа для главного конструктора или главного инженера. Опыта и знаний у них нет, только общие слова. А общие слова в документе не нужны, конкретика нужна.

    Без ТЗ, как мой коллега выше сказал, результат хз. Это основной документ. 

    47 minutes ago, kpv said:

    то есть всё сводится к банальному контролю за исполнителями?

    Одна из функций скрам. Да и вообще любой системы управления. 

  10. Опубликовано · Пожаловаться

    20 minutes ago, тау said:

    я против скрамов в разработке. Поучаствовал еще лет 10 назад. Пустая трата времени , имхо. 

    Вопрос к организации процесса, уже обсуждали. на боинге в поле не сядешь.

    Ну и конечно когда все грамотно выстроено приходится работать интенсивнее, а это не всем нравится. 

  11. Опубликовано · Пожаловаться

    2 hours ago, kpv said:

    и тут приходит заказчик и говорит: нужен ещё младенец 🙂

     

     

    Ну если заказчик платит, то почему нет. ))) а если серьезно, то если транслировать Ваш вариант в железо, то это все почти с нуля. К реальной жизни это имеет слабое отношение. 

    А вот в процессе НИР и НИОКР может возникнуть ситуация, где нужно менять что-то и вот тут то как раз гибкость очень нужна. Об этом я и говорю. 

  12. Опубликовано · Пожаловаться

    10 hours ago, Карлсон said:

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

    Вот есть у вас, например, задача: разработать портативный блок индикации на основе 128х128 rgb oled с поворотно-нажимным энкодером и питанием от двух АА, с блютусом, который получает данные от какого-то датчика и просто периодически отображает эту цифру на экране. Никаких требований по ЭМС, защитам, стойкостям и прочему нет. Дизайн тоже не нужен. Температура эксплуатации консьюмерская, время работы сколько получится. У вас в наличии в компании такие специалисты, как: конструктор механики, схемотехник, тополог, программист, снабженец, монтажник.

    Как вы в рамках своего скрама или эджайла построите взаимодействие этих людей и на какие задачи разобьете всю работу?

    Вас принять в скрам команду? ))

  13. Опубликовано · Пожаловаться

    11 hours ago, kpv said:

    я картинку для такого случая даже нашёл 🙂 как быстро сделать такую материнку (в левом нижнем углу)

    Нож в руках убийцы это орудие убийства, нож в руках шеф-повара инструмент создания шедевра. Скрам это инструмент. 

    и наличие красок не делает владельца художником. 

    Picture background

    Picture background

     

  14. Опубликовано · Пожаловаться

    6 hours ago, dxp said:

    Конечно -- некомпетентность руководства в вопросах управления ко всему этому и приводит. В первую очередь -- к внедрению скрама.

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

    6 hours ago, dxp said:

    ну, скрам требует проводить ежедневное собрание (дейлик) -- то это превращается в профанацию, потерю времени и снижение мотивации.

    у нас собираются по расписанию, это может быть каждый день, а может быть через день, в зависимости от проекта. И представьте себе, люди сами ждут этой встречи! Возможно скрам-мастер это ключевое, возможно результат работы кажджого виден даже если он (результат) небольшой, возможно что-то еще, но тем не менее. 

    6 hours ago, dxp said:

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

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

     

    6 hours ago, dxp said:

    И из них ещё изрядный процент тщеславных мудаков

    абсолютно согласен!!

     

    6 hours ago, dxp said:

    В заключение можно отметить, что история знает немало примеров эффективного управления сложными проектами задолго до появления скрамов. Авиация, судостроение, космос, атомная отрасль. И на Западе, и в СССР.

    Да, покойный мой родственник запускал Буран и он полетел. Горжусь им. 

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

  15. Опубликовано · Пожаловаться

    On 5/19/2024 at 3:40 PM, dxp said:

     

    Если в какой-то конторе ввели Scrum, это по факту и по сути является ничем иным как росписью руководства этой конторы в собственной управленческой несостоятельности. Не больше, не меньше.

     

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

     

    On 5/19/2024 at 3:40 PM, dxp said:

    Ну, собрались и поговорили. Наговорились, устали, ничего не решили

    - собственно это было основным (разговор ради разговора это главная ошибка неопытных или самолюбивых управленцев, которые управленцы ради управления). Все остальное уже косвенно говорит о том, что Вы сталкивались с непрофессиональным менеджментом. И последняя фраза: 

     

    On 5/21/2024 at 10:02 PM, Maksim_2444 said:

    Scrum - по сути является ничем иным как росписью руководства этой конторы в собственной управленческой несостоятельности.

    тому прямое подтверждение. 

    При нормально выстроенной системе такой мысли не возникает. 

  17. Опубликовано · Пожаловаться

    2 minutes ago, esaulenka said:

    Вы почитайте, что-ли, что это за алгоритм такой. Никто не обещал, что генератор случайных чисел не выдаст подряд десяток одинаковых значений. Да, вероятность ОЧЕНЬ маленькая, но ненулевая. Вероятность "два одинаковых значения в произвольных местах" - очевидно выше, и тоже далеко ненулевая.

     

    Я не математик ни разу, но это легко доказывается на практике.

      Reveal hidden contents 
    #include <random>
#include <iostream>
#include <vector>
#include <algorithm>
#include <chrono>


int main()
{
    auto start_time = std::chrono::system_clock::now();

    //using rand_gen_t = std::mt19937_64;
    using rand_gen_t = std::mt19937;

    std::random_device rd;
    rand_gen_t rndgen{ rd() };

    std::vector<rand_gen_t::result_type> rndlist;
    for (size_t i = 0; i < 1000'000'000; ++i)
        rndlist.push_back(rndgen());

    std::sort(rndlist.begin(), rndlist.end());

    size_t count = 0;
    for (size_t i = 0; i < rndlist.size() - 1; ++i)
        if (rndlist[i] == rndlist[i + 1])
        {
            //std::cout << "found the same value " << rndlist[i] << " at " << i << "\n";
            ++count;
        }
    std::cout << "found " << count << " pairs\n";

    std::cout << "Time spent " << 
        std::chrono::duration_cast<std::chrono::seconds>(std::chrono::system_clock::now() - start_time).count() << " seconds \n";

}

     

    Для Мерсенна с 32-битным выходом среди миллиарда (!) значений совпадений... немало: 

    found 107892738 pairs
Time spent 160 seconds

    Для 64-битного варианта совпадений у меня не было, но это не значит, что их не будет в принципе.

     

     

     

    А какой период у Вас выбран?

  18. Опубликовано · Пожаловаться

    14 minutes ago, dxp said:

    Нет, скрам -- это методология ведения работы. А система следующий, более низкий уровень иерархии, система управления строится на основе методологии. Что не делает методологию системой.

     

     

    А какая у вас система?

  19. Опубликовано · Пожаловаться

    17 hours ago, dxp said:

    "Огласите весь список, пожалуйста"  ©

    Что вы понимаете под "системами управления проектами в электронике"? Какие знаете? Если что, то SCRUM -- это не система управления проектами вообще и уж точно не в электронике. 

    Система управления проектами -- это, например, Redmine. Альтернативная связка Jira+Confluence. Хотя я бы не назвал это именно "системой" управления, это просто багтрекер + вики.

    Скрам вполне себе система. 

    Вики также со мной согласна, и прекрасно работает далеко не только в программировании. 

    Самые основные для нас преимущества:

    1. Не даёт лодырничать

    2. Повышает вовлечённость всей группы в проект

    3. Позволяет быстро адаптироваться к новым реалиам или дополнениям. 

    4. Соблюдение сроков и ощущение ответственности каждого

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

    Вы ведь понимаете, что в процессе разработки можно столкнуться с чем-то неоптимальным и без переделок будет плохо совсем. Разработка как таковая это далеко не всегда разжеванное ТЗ, бывает есть только идея и общие представления. То есть работа над тем что никто не делал никогда, и включается этап НИРа. Если же ТЗ абсолютно однозначно и детально, то в этом случае скрам будет играть организационную роль. 

    Разумеется скрам для одного человека это мягко говоря странно. 

    • Upvote 1

  21. Опубликовано · Пожаловаться

    1 hour ago, destroit said:

    В смысле? Вы наёмный трудник, и вам сиё = неведомо ...ни бюджет, ни цели ... Та хрень, с бюджетом нуль ( требуется отследить температуру лудила, в нашем зоопарке), это свечка вна торте (требуется RFID идентификация, без излучения ). Вы когда перестанете бредить ? Нужна специальная тема ?! 

    Вам не надоело флудить?

    • Upvote 3

  23. Опубликовано · Пожаловаться

    2 minutes ago, mantech said:

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

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

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

    А контроль версий это отдельная тема. 

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

  24. Опубликовано · Пожаловаться

    20 minutes ago, fpga_student said:

    Для всех адекватных имхо это приговор. Да и фильтр заказчиков) своеобразный))

     

    Наблюдаю в работе креативного человека любителя менять ТЗ на ходу(( Как он вредит своему бизнесу не передать)

    Да фильтр, согласен, если ТЗ пересматривается радикально. 

    Но я не говорю, что ТЗ полностью поменялось, оно дополнилось, или скорректировалось например из за недоступности компонента (например с рынка РФ ушел Квиктел, а на него изначально ориентировались). А самое главное все прозрачно для всех. Не призываю использовать наш подход, но у нас он прижился и считаю правильным об этом сказать сразу.

×
×
  • Создать...