Сучасна диджитал-освіта для дітей — безоплатне заняття в GoITeens ×
Mazda CX 5
×
  • Канада для IT-шника. Aлгоритм и стоимость переезда

    Я так понимаю, что теперь проще делать универсальный питальник 110-220 чем делать разные питальники для разных регионов.

  • Канада для IT-шника. Aлгоритм и стоимость переезда

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

  • Почему методология не спасет ваш проект

    Что за внутренний клиент? И что там насчет требований?

  • Почему методология не спасет ваш проект

    Эх, и снова мой любимый аутсорсинг головного мозга. Убери «заказчик» и «требования» — и от статьи вообще ничего не останется...

    Підтримав: Dmytro Fedorchak
  • Міністр фінансів про ІТ ФОП (грудень 2019)

    В Германии такой вариант есть, но есть и нюанс: «ФОП» не может работать только с одним «заказчиком» — это расценивается как уход от налогов.

    Підтримав: Oleg Leschinsky
  • Навушники з активним шумодавом

    ха, и правда! спасибо, заказал )

  • Навушники з активним шумодавом

    тех уж нет — не могу ничего сказать, а на 35 нету (и даже кабель с тремя контактами)

  • Навушники з активним шумодавом

    Ничего интересного в контексте обсуждения наушников.

  • Навушники з активним шумодавом

    Но, кстати, сидеть в наушниках-шумодавах без всякой музыки, только под шумодавом — достаточно странно, надо к такому привыкать. Сходу мозг чувствует что «что-то не так», и требуется некоторое время на адаптацию.
    Ходить по улице / кататься на велике местами просто опасно.

    Підтримав: Ievgen Safronenko
  • Навушники з активним шумодавом

    В один прекрасный день у нас в команде встал выбор — все в большом опенспейсе или в нескольких разных комнатах. Мы выбрали опенспейс + купили всем bose qc25 (35 тогда еще не вышли). Сработало отлично — во-первых, это очень хорошие наушники с отличным подавителем, так что находиться в относительно шумной комнате стало заметно комфортнее. Во-вторых, люди, которые сидят в наушниках не реагируют на всякие разговоры и не подключаются к ним — от этого разговоров вообще в целом стало меньше.

    (Если б им еще микрофон — вообще супер-девайс был бы!)

  • Привлечение инвестора (ангел/венчур) — как, где, когда?

  • ІТ-спеціалісти на початку нульових: СЕО на «Жигулях», розробка «змійки», зарплата 600 грн. Фотоогляд

    Тесен мир!

    В 10 классе у меня появился свой собственный ключ от школьного компьютерного кабинета, а в 11 классе мне открыли трудовую книжку и официально трудоустроили в родной школе — я получил полставки лаборанта при кабинете информатики.

    Если я все правильно понимаю, это моя школа, и именно благодаря Андрею в этом самом кабинете «в порядке факультатива» сидела и определенная группа школьников, имевших тягу к компьютерам, а среди них и я. Спасибо, Андрей!

  • С чего лучше начинать поиск инвесторов для стартапа?

    Мне кажется, главный вопрос — это насколько правдоподобно предположение, что люди станут учить в обмен на учение (мне кажется, что «учителей» на порядки меньше, чем «учеников»), ну и цена привлечения таких пар.

    Підтримали: Dmitry, Gennady Dogaev
  • С чего лучше начинать поиск инвесторов для стартапа?

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

  • «Демократія — в шумі даних» — фільм про те, як створювали GDPR (18+)

    Чувак, тебе только что уже прямым сказали, что ты неправильно понял закон, а ты продолжаешь его критиковать? Фактически признав, что не читал и не разобрался?

    Підтримав: Maksym Ganenko
  • Definition of Done, или кто за что отвечает

    Да что это за мифические best practices выработанные для большинства кейсов? Которые еще и не требуют мнения заказчика? Ссылку? А то пацаны-то и не знают, бьются за что-то, новые подходы пробуют, экспериментируют зачем-то.

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

    Ну, если нужна была еще одна иллюстрация про АГМ и как не делать customer collaboration — то вот она.

  • Definition of Done, или кто за что отвечает

    Так что — есть всего, стало быть, три подхода —
    — херак-херак и в продакшен
    — сколько-нибудь долгую поддержку и развитие решения
    — всякого рода life-critical системы

    А чего ж методологий разработки в десять раз больше, если всего-то три типа проектов с понятными «как надо»?

  • Definition of Done, или кто за что отвечает

    Я считаю DoD отличным инструментом и значимым артефактом agile разработки. Той самой agile разработки, четверть манифеста которой заключается в принципе:

    Customer collaboration over contract negotiation

    И DoD, что характерно, является именно что разновидностью contract. И хотя коллаборация с клиентом намного важнее этого контракта — он все же есть в методологии, и польза его не вызывает сомнений. Мне кажется, это именно потому, что соглашение по поводу базовых терминов является основой здоровой customer collaboration. Чтобы фраза «it’s done» не вызывала в будущем боли несоответствия ожиданиям, а вызывала приятную улыбку взаимопонимания. И мне кажется, что это важный момент в понимании смысла и назначения DoD. Потому что тут может случайно произойти подмена. И, кажется, происходит.

    Есть такая штука — профессиональные деформации. Психологические паттерны, связанные с определенной работой. Работа в аутсорсинге тоже обладает своими характерными особенностями, с которыми приходится сталкиваться. И у тех, кто достаточно долго работал в аутсорсинге (а то и вообще всегда) может сложиться впечатление, что вся разработка софта — она вот такая, как в аутсорсинге, ну плюс-минус. Когда такие люди рассуждают о разработке вообще, не в контексте аутсорсинга — это хорошо слышно, потому что они проецируют свой аутсорсинговый опыт на видение разработки в целом. Я называю это Аутсорсинг Головного Мозга.

    И вот перед нами такая статья — о разработке вообще, о Definition Of Done — концепции, никак не связанной с аутсорсингом, не имеющей никаких аутсорсинговых коннотаций. Тем не менее, из стати хорошо слышно, что автор вовсе не практикует и не собирается практиковать customer collaboration! Более того, старается его минимизировать, и как раз считает, что DoD — это путь к минимизации коммуникаций (еще бы, она названа Болью в статье!).

    Так вот, мне кажется, что статья практически полностью про АГМ на примере DoD.

    Какие маркеры говорят от этом? Это, конечно, «Клиент» и «Заказчик», красной линией проходящие через статью. В разработке софта вообще есть, конечно, разные стейкхолдеры, и налаживание отношений между ними — сложное и важное дело, но именно в аутсорсинге (и другой сервисной разработке) эти роли так сильно акцентированы: ведь две компании пытаются работать вместе при совершенно разной парадигме бизнесов. Тут и продажи, и формирование ожиданий и контракт и приемка и все остальное — целое ремесло по работе с клиентом, которого... совсем нет в компании, которая сама себе разрабатывает. И Боль вокруг Клиента — это следствие аутсорсинга в куда большей степени, чем необходимости четкой работы стейкхолдеров в разработке вообще.

    Но самое ужасное, что по многим фразам становится ясно, что никто не умеет в customer collaboration!

    Например:
    — код написан;
    — юнит-тесты написаны и успешно выполнены;
    — код прошел ревью;
    — документация обновлена;
    — функциональное тестирование успешно завершено;
    — регрессионное тестирование успешно завершено.

    Чем больше и объемнее Definition of Done, тем более строгим оно считается. И тем больше нужно времени и усилий, чтобы наш функционал добрался до желаемого состояния «сделано». И тем выше вероятность, что функционал будет работать в соответствии с ожиданиями бизнеса.

    Это же ужасно. Посмотрите на предлагаемое DoD — в нем нет ничего, что можно трактовать как ожидание бизнеса. Разве бизнес хоть капельку волнует, был ли код ревью? Тут все меры — про минимизацию багов (и это тоже характерная фиксация аутсорсинга, кстати). При этом то, что бизнес могло бы волновать — тут начисто отсутствует: где «можно пощупать на стейджинге» или «выкачено на продакшн»? Покажите мне бизнес, который не волнуют эти вещи в критерии «готовности»?

    Почему так? Да потому что АГМ, и никто не хочет думать и говорить о проблемах кастомера. Почему я так думаю? А вот:

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

    Разве это выглядит как призыв к customer collaboration? Да это прямо противоположная движуха — мы к тебе не лезем и ты к нам не приставай. Может, показалось?

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

    В этом месте каждый уважающий себя адепт аджайла должен встать, махом перевернуть стол и крикнуть «bullshit!» — потому что это прямо противоположно принципу customer collaboration over contract negotiations.

    Вот примерно из этих соображений я пытаюсь аккуратно намекнуть — а что, если бы уберем аутсорсинг из этой статьи — что мы получим? Каков будет ответ на заглавный вопрос? Зачем нужен DoD если нет Клиента/Заказчика, а работа идет внутри одного коллектива? И окажется, что единственная фраза в статье, начинающаяся с «потому что...» это

    Потому что если ваш цех по производству Kotlin-пасочек станет хронически обгонять цех RxSwift-пасочек по причине отсутствующего или гораздо менее строгого Definition of Done, мобильная разработка рискует превратиться в храм боли. Боли при общении с Клиентом.

    И это слабенькое понимание роли DoD — зато сильный знак огромной проблемы в общении с Клиентом. Ну и попытка решить ее с помощью всех доступных средств, годных или нет.

    Знаете, какой еще характерный маркер АГМ?

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

    Аутсорсинг так яростно продает «экспертизу, комплиментарную вашему пониманию бизнеса», что и сам в это верит — что мир устроен по принципу чистых функций и должностных инструкций, и их можно докупать и совмещать как ликвидные универсальные ресурсы. А это только защитный механизм в аутсорсинге, и ничего общего с customer collaboration не имеет.

    Такие дела.

    Підтримали: Igor Evmushkov, Anastasia Checherska
  • Definition of Done, или кто за что отвечает

    DoD — это вопрос из серии как надо делать

    Как надо кому?

    Или, простите, есть «как надо» одно на всех годное?

  • Definition of Done, или кто за что отвечает

    Есть человек из бизнеса, и есть команда, которая в бизнесе не разбирается.

    Это чудесный мир картонных чучелок, где ты или туда или обратно и все (относительно) просто.

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

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

    Ты готов встать между ними с плакатом «Источником DoD должна быть технология, а не бизнес» и выдать им нарукавные повязки «ЧТО» и «КАК»? Или, возможно, двум интеллигентным людям с разносторонним опытом есть о чем поговорить на равных и прийти к понятному и прозрачному взаимному соглашению?

    Затем, что мы должны договориться до одинакового понимания одинаковых вещей.

    Золотые слова! Но почему же одинаковое понимание вещей всенепременно должно проистекать от технокоманды?

← Сtrl 123456...90 Ctrl →