расскажите, как это у вас выглядит, и как "переходили на скрам", и как тепеь выглядят яйца?

У меня на прошлом проекте был скрам. Но что-то пошло не так, и в результате 20-25% рабочего времени тратилось на митинги :)

А на предпредыдущей работе ввели скрам и там было все эффективно.

Сейчас у нас от скрама только стэндапы.

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

Короче говоря, если у вас думают, что введение скрама улучшит качество кода, то этого не произойдет :D

Мы бились где-то полтора года пока не начало получаться. Проблема часто встречается - совмещение должностей. Тимляйтер играл ПО. Первого скрам мастера он выжил, второй был экстерн, которому платил тимляйтер. Пока мы не эскалировали до уровня руководителя всего IT, всё шло хм... Хреново. Потос нам дали третьего мастера, который наконец-то не зависел от ПО, и мог его поставить на место. С тех пор потихоньку всё стало лучше. Теперь у нас почти всегда выполняются DoD, истории не впихиваются посередине спринта, пока не будут готовы критерии, истории в спринт не включаются... В общем теперь нормально. Покрытие тестами растет, У нового кода почти всегда > 80%, ошибки не так часто лезут. На чём еще экономят - на документации. Я продавил чтобы хотя бы Changelog писали, а потом меня ПО с проекта таки сдвинул :) Так что другой документации нет...

Могу сказать что код у нас читаемей чем у отлелов, которые по водопаду с 120-и страничными "Pflichtheft"-ами пишут (из которых страниц 90 - кто его написал, с кем согласовал и сколько часов запланировал на реализацию

Простите, что встреваю,

пожалуйста, если не лениво, разъясните что конкретно скрам-мастер делает? Я много гуглил, и не понял, но ни разу воочию не видел и совершенно не могу понять чем он от Project Manager, Product Owner и Software Architect отличается, вернее зачем он при наличии оных нужен.

Спасибо!

понятно, что на качество кода сильнее влияют другие факторы, а не название "новейшей технологии".

многоие манагеры покупаются на то, что это - agile development, а кто ж откажется от того, чтобы разработка занимала только половину отведенного времени? : )

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

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

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

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

Ну продакт онер не должен быть частью команды разработки :) Это очень важно именно это у нас в предыдущей конторе нарушалось.

В принципе, никто не зартавляет брать весь скрам в том виде, как он описан в книжках ;) Возьмите часть. Например, стэндап - очень полезная штука. Желательно, чтобы была реальная доска с задачами на спринт.

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

скрам-мастер - буфер между командой и "внешним миром". Т.е. все враимодействите между командой и всеми остальными должно быть только через скрам-мастера.

Product Owner - человек, который заказывает разработку и этот человек не должен быть частью команды.

Ага, а все так просто оказалось! Спасибо большое, moose и Программист, что просто и понятно разъяснили. Про оунера - я как-то слышал, даже однажды в его шкуре был, но вот факт, что еще есть скрам - для меня всегда было загадкой, ведь по сути Project Manager управляя, Software Architect наставляя, и секретарша поднося всегда и во все времена выполняли задачу скрама.

Но теперь я знаю это модное словечко, и буду понимать чем и почему эта должность отличается.

Большое спасибо за простое и понятное объяснение!

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

> формализация задач (где это возможно) - всегда полезная весчь.

это верно, и в умелых руках приносит реальную пользу, спасибо большое за классное сравнение!

Мы бились где-то полтора года пока не начало получаться.

То бишь хотите сказать что теперь довольны?

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

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

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

опять я со своим дурацким вопросом... можно???

Скажите, пожалуйста, правильно ли я понимаю, что агильная методика очень хорошо ложится на R&D, когда есть грубо говоря примерный бюджет, есть рабочие руки, есть желание что-то получить, но что именно, и как именно получать никто еще не знает, только есть критерий - "хорошо", то бишь получилось, или так себе?

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

1) Скрам-мастер должен быть с железными яйцами :) (ну или продакт онер должен понимать свою роль и не вмешиваться в процесс работы команды)

2) Продакт онер должен быть вне команды и не должен быть начальником над скрам-мастером и над командой.

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

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

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

Спасибо, уважаемый Программист, что отетили, но мы тут уже про агильность говорили?

Скрам, как много в этом слове.... и как его можно извращать...

Видел "Скрам" на разных фирмах и разных проектах.

Самое отвратительное, когда методы скрама суют туда, где он вообще не подходит, просто ради того, чтобы всем рассказывать, что у нас скрам.

Самый ужасный Скрам:

Был внедрен новым начальником IT просто "с ноги", чтобы ему было, что предъявить. Сам начальник в разработке не участвовал, но играл частично роль скрам-мастера и просто пиздобола, которому везде надо было профилироваться.

Скрам-мастером был один из разработчиков, никаких прав фактически не имел, кроме как вести стэндап. Стэндап проходил до 1,5 часов каждый день, с присутствием ПО и вечными дискуссиями, а что именно нам надо делать.

ПО было сразу 3! Три, Карл! У каждого свои интересы. В зависимости от нужд фирмы задания из спринтов вынимались и добавлялись, спринты при нужде продлевались на неделю, иногда две.

Параллельно со спринтом всегда было дохрена саппорта по другим проектам. В общем был кромешный звездец.

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

Самый разумный Скрам:

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

Были и несколько промежуточных вариантов и даже "Scrumban" - как нечто среднее между Scrum и Kanban.

В целом из своего опыта могу сказать, что все сильно зависит от фирмы и проекта.

Если проектов несколько, то скорее всего скрам накроется постоянной борьбой приоритетов.

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

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

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

Хорошо иметь архитектора, который помогает ПО проработать все его хотелки технической поддержкой. Редко бывает ПО, который сам понимает все тонкости и возможные варианты.

Agile - это всего лишь модное слово, за которым скрываются разные методолории управления проектом (aka временем). Это ни секунды не золотой грааль, с появлением которого все сразу станет хорошо.

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

Например, в моем текущем проекте agile'ные методологии (например скрам) работать не будут, т.к. никакого планирования просто нет, а появляющиеся процессы нарушаются потому что "мы всегда так работали".

Но это не значит, что процессы эти нельзя вводить где-то в других местах. Также и в R&D, где-то аджайльные методики будут работать, а где-то нет. И зависит это пожалуй не столько от темы R&D, сколько от вводящего и от участников.

Самое отвратительное, когда методы скрама суют туда, где он вообще не подходит, просто ради того, чтобы всем рассказывать, что у нас скрам.

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

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

То бишь хотите сказать что теперь довольны?

Почти. Не хватает документации (ПО не даёт на нее время, давит на разработчиков) и UI-Тестов (по той же причине). Из-за чего временами насинают не так работать фильтры, сортировка или вообще кнопка не то делает. Упс, не то зарефакторили.

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

Яростно плюсую "ПО не должен быть руководителем разработчиков и мастера".

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

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

И (по-моему самое важное, ну или такое же важное как ПО) менеджеры (stakeholder) должны понимать что такое скрам. Что он им дает и чего лишает. Иначе не взлетит. Будут прожирать всё время - "а составьте мне отчет какие фичи будут реализованы к 01.06, а какие к 01.12".

Во-первых огромное спасибо, что классно и на пальцах рассказали!!!

> Scrum и Kanban.

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

В интернетах куча инфы и сравнений двух методик.

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

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

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

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

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

Продакт онер должен быть вне команды и не должен быть начальником над скрам-мастером и над командой

Вот это как раз и тяжело представить. Кто же конкретно он должен быт? Заказчик как правило, не имеет нужных технических навыков. А те кто имеет, пишут такое что разобраться сложнее.

А если продукт "свой", то и ПО должен быть из фирмы.

Пока увидел два критерия:

- тип проекта(ов). Для большого количества проектов методика неэффективна

- размер команды. Для малых размеров (границы?) методика неэффективна

нп.

у нас от скрама только такое: раз в неделю сгоняются все на митинг (человек 30) и каждый по очереди говорит чего сделал за неделю или чего сейчас делает. Редко кто скажет больше чем "писал юнит тесты для..." или "занимался исправлением ошибок" - короче - более одного предложения.

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

А зачем тогда баг треккер? Всё видно кто, что делал и сколько времени потратил. Туда же и "новое" загоняется.

Поэтому то непонятен смысл регулярных митингов.

Вот это как раз и тяжело представить. Кто же конкретно он должен быт? Заказчик как правило, не имеет нужных технических навыков. А те кто имеет, пишут такое что разобраться сложнее.

Если фирма более или менее крупная, то такое представить совсем не сложно. Напимер на роль продакт онера отлично подходит аналитик (у нас в одной из фирм этот человек назывался product manager). Это человек, который собирает хотелки у клиентов и формирует из них user stories (в той фирме product manager писал Plichtenheft на каждую фичу). Человек этот, не был частью команды и фактически исполнял роль продакт онера (все это было в доскрамовое время :D)

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

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

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

- тип проекта(ов). Для большого количества проектов методика неэффективна

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

- размер команды. Для малых размеров (границы?) методика неэффективна

Я бы сказал, что наоборот :) Для команд из более, чем 10 человек скрам легко превратится в кучу скучных собраний. Да даже уже 10 - много. Граница наверное где-то в районе 5-7 человек.

Если фирма более или менее крупная

То бишь еще одно ограничение?

Накладывается похоже и еще одно одно - один проект на 5-7 человек

Еще раз, скрам - это методика управления временем

Со множеством ограничений...

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

Совершенно не важно сколько там проектов Важно, чтобы можно было выделить небольшие задачи.

То бишь если, "у меня" десятки проектов, которые может сделать один два человека за относительно короткое время, то методика будет также эффективна?

То бишь еще одно ограничение?

Не совсем. Дело в том, что в более или менее крупной фирме проще найти человека, который бы мог исполнять роль продакт онера и при это не был бы частью команды. Впрочем, сейлы есть (почти) везде :) Но в каком-нибудь стартапе будет трудно разделать роли. Только и всего. Впрочем, некоторые части скрама вполне можно применять. Например task board + stand up, как мне кажется, очень сильный инструмент, который дает прозрачность и контроль работы.

Накладывается похоже и еще одно одно - один проект на 5-7 человек

Ну вот команда из 5-7 человек - это пожалуй ограничение. Опять же, это ограничение позволяет повысить эффективность работы по скраму. Но это не означает, что нельзя сделать скрам в команде из 30 человек ;)

То бишь если, "у меня" десятки проектов, которые может сделать один два человека за относительно короткое время, то методика будет также эффективна?

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

Еще раз, скрам - это методика управления временем
Со множеством ограничений...

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

Это не ограничения, это "параметры, при которых методика эффективна". Если у вас один разработчик в проекте вам не нужен скрам. Если у вас 50 человек в проекте (и они реально не разделены на группы и подгруппы, а все взаимозаменяемы) и у вас до это как-то работает - вам не нужен скрам. Вы только на ежедневный стэндап (daily) будете часа 2 тратить.

То бишь если, "у меня" десятки проектов, которые может сделать один два человека за относительно короткое время, то методика будет также эффективна?

Смотря что вы понимаете под "эффективностью". Станут ли 2 человека программировать быстрее? Нет. Ускорится ли весь цикл разработки (time to market)? А кто его знает, зависит от того, как это организовано сейчас. Если сейчас клиент звонит напрямую разработчику и тот через 15 минут разговора начинает кодить, как только написал - сразу деплоит, то всё станет значительно медленнее. Но появится документация хотя бы кто когда и какие хотелки клиента реализовал. Станет код "лучше"? Смотря как вы определите DoD (definition of done) и насколько строго будете проверять на соответствие.

Скрам просто методика разработки, не "золотое решение" для всех проблем. Стоит ли его использовать зависит от того, чего вы хотите добиться.

Осторожно, образное сравнение! :)

Какой метод передвижения эффективнее: пешком, на велосипеде, на машине, на поезде или на самолете? Смотря куда и как быстро вам надо добраться. В булочную - пешком, в магазин за большими закупками - на машине. В Таиланд - самолёт. Будет ли эффективно "передвижение на машине"? Смотря куда ехать собрались, сколько груза с собой, что важнее - скорость, комфорт, и те де и те пе.

Например task board + stand up, как мне кажется, очень сильный инструмент

Ежедневный митинг с доской что ли?

https://www.scrumdesk.com/daily-scrum/

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

А где же тогда митинги, доска, ПО, СМ и прочая атрибутика?

Хотя даже что понимать под "подзадачей" тоже не просто определить. Что будет являться результатом?

повысить эффективность работы по скраму

И как энто можно измерить?

Или по другому. Как мне узнать что использование Скрама в данной конкретной ситуации даст какой либо выигрыш?

Какой метод передвижения эффективнее: пешком, на велосипеде, на машине, на поезде или на самолете?

Так в этом то и проблема, это все и представить можно и пробовалось и хоть как то знаешь.

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

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

Тут такое дело... Можно выделить... ну, назовём их "маркеры". Точный и полный список я нигде не видел, в разных статьях проскакивает. И из личного опыта. Может кто ещё что добавит, мне было бы интересно.

1. Гибкость. (пожалуй, самый главный) Как часто в процессе разработки будут вносится изменения в требования.

Если ваш клиент с самого начала твёрдо уверен в том, что ему нужно, или вы делаете одно и то же с небольшими косметическими изменениями в 100-й раз, скрам не нужен. Берите водопад / критический путь (critical path) / канбан.

Если клиент хочет "чтобы оно вот где-то тут так, а потом - вздыыышь! и всё сиреневое! И кнопку!" - скорее всего скрам вам сильно поможет.

2. Организация. Готовы ли вы к изменениям в организации. Если нет - забудьте про скрам, не взлетит. Про "правильный" размер команды уже говорили, что 5-7. Имхо, скорее 5, чем 7. 3 - мало. И надо будет менять организацию, чтобы создать такие команды. Без тим ляйтера! (сколько у нас было воплей по этому поводу...) Если одна команда должна работать одновременно с несколькими проектами, сможете ли вы найти ПО, который сможет отвечать за все эти проекты? Два и более ПО (бывает) это труба.

3. Личные качества. Готовы разработчики брать на себя ответственность и принимать решения? Многие программисты в скраме работать не могут. Они воспринимают только приказы сверху а обсуждать решения с коллегами и потом принимать решение не в состоянии (а чо он мной командует? да кто он такой чтобы решать!). У них этакая вера во всезнающего и безупречного тимлида. "Начальстворианство" :)

Готовы будущие ПО понимать что их постановку задач могут (и будут) обсуждать, задавать вопросы вроде "а зачем это вообще" да и просто объяснять им почему такая постановка задачи неправильная.

Готовы менеджеры отказаться от красивых графиков релизов "через 6 месяцев будут реализованы следующие фичи"?

4. Размер проекта. Если время разработки проекта 1-2-3 недели - не стоит затеваться со скрамом (но тут скорее противоречие с 1-м пунктом, так быстро делается то, что в начале хорошо известно).

5. Срок жизни проекта. Если лепится страничка, которая через 6 месяцев точно будет заменена чем-то другим, то вам обычно наплевать на качество кода, распределение знаний о проекте по команде, документацию. Скрам не нужен.

6. Требования к качеству (понятный, легко изменять) кода / документации. В скраме есть Definition of Done (DoD). Можно задать требования к выполненной истории очень жёстко, прописать какую документацию надо править, какие тесты обязательно выполнять. Если вам всё это не надо - то и скрам вам может быть не нужен.

Имхо, важные - первые три пункта. Если они у вас выполняются, скрам поможет организовать разработку. От привычки обсуждать истории на рефайнменте (если ПО готов воспринимать критику, а не "я - начальник, ты - дурак") до чётко отработанного процесса деплоймента (с DevOps хорошо уживается). Программисты в команде через какое-то время действительно станут "взаимозаменяемыми" и не будет такого что спец по БД заболел/ушёл в отпуск, никто его базу не трогает, боится. Вырабатываются привычки делать ревью, проверять документацию коллеги - а понимаю ли я её, а вдруг он чего забыл.

"Щупать" удобно на каком-нибудь исследовательском проекте. Когда дают время месяцев 6, задачу в общих чертах (а напишите нам анализатор логов, а что конкретно он анализировать будет - посмотрим) и команда пробует а как оно будет - работать с микросервисами (например). Потому что нет давления "штоп к 1-му все блестело и переливалось!" и действительно часто меняется что же надо сделать.

Ну или идти в уже существующую команду, смотреть сможете ли втянутся.

В одиночку "щупать" - бессмысленно.

P.S. Сейчас перечитал, как-то сумбурно у меня ночью получилось... Ну, если б ребёнка спат не укладывал бы то вообще не написал бы.

Ежедневный митинг с доской что ли?

Он самый.

А где же тогда митинги, доска, ПО, СМ и прочая атрибутика?

Все 20 подзадач на доске. Каждый день эти подзадачи во время стэнд апа переходят из одного состояния в другое.

ПО, СМ и прочее можно в маленькой команда опустить, все равно один человек не сможет грамотно совмещать.

Хотя даже что понимать под "подзадачей" тоже не просто определить. Что будет являться результатом?

Что является результатом определяет команда. Для этого придумали целый термин - DoD (Definition of Done).

И как энто можно измерить?
Или по другому. Как мне узнать что использование Скрама в данной конкретной ситуации даст какой либо выигрыш?

Можешь ввести какой-нибдуь KPI (ну там количество новых строк в день или можешь следить за тем, чтобы burn chart постоянно убывал) ...

В конце-концов, в скраме предусмотрена ретроспектива, где команда может решить, что можно изменить и как улучшить процесс, ну или что стало хуже и скрам надо нахрен убрать :D

Готовы будущие ПО понимать что их постановку задач могут (и будут) обсуждать, задавать вопросы вроде "а зачем это вообще" да и просто объяснять им почему такая постановка задачи неправильная.

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

Готовы менеджеры отказаться от красивых графиков релизов "через 6 месяцев будут реализованы следующие фичи"?

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

Ну и в остальном. Все таки скрам - это управление временем, поэтому его можно реализовать не только при разработке ПО.

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

Аналогично. Но меня обвиняли в том что я ПО хочу в плохом свете выставить.

Надо сказать не без причин. Если человек пишет критерий выполнения / Akzeptanzkriterium как "muss wie erwartet funktionieren" а на вопрос "и что это должно означать" округляет глазки и отвечает "ну это же очевидно!" и это не в первом и не десятом спринте, то кто он после этого?

Но мой пример вдохновил одного коллегу. Меня из команды выдавили, теперь он "плохие" вопросы задает и "замедляет процесс ненужными дискуссиями". :)

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

Выделенное - главное. Невозможно за 3 или 6 месяцев обещать что будет в релизе (commitment). Можно предположить. Основываясь на актуальной скорости спринта и на бэклоге. Но! В бэклоге может быть много неоцененных, зависящих друг от друга историй. Могут быть еще не прошедшие рефайнмент. Да просто "декларации о намерениях" даже без критериев. И тогда предположения становятся совсем шаткими. А высказывания вроде "наверное сможем" менеджеры не воспринимают и махом переделывают в "команда обещала". Каждый раз призодится в письмах начальству такое отлавливать.

Менеджеры с удовольствием воспринимают что теперь можно каждые 2(3, 4, смотря какая длина спринта) недели меять задания, приоритеты, вносить что-то новое. Что каждые 2 недели у них будет новый релиз. Но когда им объясняешь что именно из-за этого я не могу гарантировать никаких сроков реализации конкретной фичи - "не понимают как так может быть". Изображают дурачка, ведь "если надавить посильнее то всё эти программисты в срок напишут".

Пожалуй самое толковое для меня, спасибо.

Если клиент хочет "чтобы оно вот где-то тут так, а потом - вздыыышь! и всё сиреневое! И кнопку!" - скорее всего скрам вам сильно поможет.

чем?

2. Организация. Готовы ли вы к изменениям в организации.

ради чего? Не думаю, что есть много фирм, согласных на какие то крупные изменения ради "призрачной мечты"

обсуждать решения с коллегами и потом принимать решение не в состоянии

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

А на самом деле было полезно и нам нравилось, потому как потом обдумываешь и приходит более лучшее решение.

Готовы будущие ПО понимать что их постановку задач могут (и будут) обсуждать, задавать вопросы вроде "а зачем это вообще"

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

5. Срок жизни проекта. Если лепится страничка

Подобных проектов, как то не попадалось.

6. Требования к качеству (понятный, легко изменять) кода / документации.

А при чём здесь скрам? Задать и так всё можно. Только сроки всегда были важнее всего остального

DevOps хорошо уживается

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

Ну или идти в уже существующую команду, смотреть сможете ли втянутся.

менять работу ради Скрама? - спасибо не надо.

Программисты в команде через какое-то время действительно станут "взаимозаменяемыми"

Как то очень сомневаюсь. В любую "большую часть" нужно вначале "въехать", а для этого нужно время.

Пока так и не увидел ни единого преимущества Скрама для себя

ПО, СМ и прочее можно в маленькой команда опустить, все равно один человек не сможет грамотно совмещать.

А как же тогда определить - "Я работю по скраму"

Все 20 подзадач на доске. Каждый день эти подзадачи во время стэнд апа переходят из одного состояния в другое.

зачем еще на это время тратить?

Что является результатом определяет команда. Для этого придумали целый термин - DoD (Definition of Done)

Зачем мне новые термины, нужен конкретный пример. Не вижу я адекватного определения.

Можешь ввести какой-нибдуь KPI (ну там количество новых строк в день

реально что то высчитать достаточно затруднительно.

Даже такой бессмысленный показатель как строки в день - отчего он будет зависеть от применения/не применения Скрама?

Если клиент хочет "чтобы оно вот где-то тут так, а потом - вздыыышь! и всё сиреневое! И кнопку!" - скорее всего скрам вам сильно поможет.
чем?

Тем что в конце разработки продукт будет ближе к хотелкам клиента, которые он в начале не может даже представить, не то что озвучить. А потому с таким клиентом любой нецикличный метод разработки обречен на провал.

Как поможет скрам? 1. Цикличностью и постоянным общением с заказчиком (как минимум на ревью). и 2. тем что скрам это "модно".

Подробнее:

1. Спринты короткие, по результатам спринта, которые демонстрируются клиенту можно уточнить предыдущие хотелки и получить новые. И внезапно из "и всё сиреневое!" получается "когда пользователь нажимает кнопку 'Отправить данные', появляется диалоговое окно, запрашивающее подтверждение, а вся рабочая область приложения становится неактивной. Гравичеки это отображается в "затемнении" рабочей области, наложении "сиреневой дымки".

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

Т.е. наша задача упрощается - из клиента надо выбить достаточно информации чтобы создать "ходячий скелет" (walking skeleton) приложения. А потом ему демонстрируется результат разработки, и он может внести свои "сверхважные" замечания (вроде "перенести кнопочку налево", "сделать заголовок больше", "а тут не красный а оранжевый") и чувствовать себя влияющим и командующим всем и все. И это делает его счастливым до одури :) А пока он счастливый, расслабившийся и тепленький, его пытает ПО на тему "а теперь давайте уточним что вы имели в виду под "вздыщь!". И сразу на бумажку. (Ну, или в тикет в джире). Через две (3,4) недели всё повторяется но уже с новыми фичами. Снова собираем сверхценные замечания, меняем оранжевый обратно на красный, кнопочку пхаем посередине, и выясняем а что должно происходить когда пользователь нажмёт на эту кнопочку. Причес через пару спринтов клиент может и передумать что же будет происходить при нажатии, потому что увидит что он по-другому себе всё представлял.

По умному "fast feedback loops". Мы получаем новую информацию от клиента как реакцию на нашу проделанную работу намного раньше (в каждом спринте).

В водопаде у такого клиента, после того как он напишет даже самой подробное ТЗ, остаётся слишком много времени чтобы у него в голове всё переделалось на новый лад. А ТЗ он сам читать никогда не будет, не барское это дело. Чукча писатель а не читатель. В результате, через год разработки ему показывают что-то, пусть даже на 100% соответствующее ТЗ, а клиент жутко обижен и недоволен - это совсем не то что он имел в виду (потому что то, что он имел в виду за этот год в его голове поменялось раза 3). Всё, проект прошел плохо, клиент недоволен, деньги платить не хочет, потому как уверен что его непрвильно поняли ("что вы мне тычете этим ТЗ, всем понятно что под `удаление аккаунта` я имел в виду что он пропадает из таблички с результатом поиска") и те де и те пе.

2. Модность помогает продать скрам. Убедить клиента что ему НАДО найти время на то, чтобы участвовать в ревью после каждого спринта и на то что ему НАДО обсуждать истории с ПО. "Вы же знаете насколько лучше становится результат разработки, если применяется скрам, а в нём предписано что вы обязательно должны участвовать, чтобы контролировать соответствие разработки вашим представлениям и пожеланиям".

ради чего? Не думаю, что есть много фирм, согласных на какие то крупные изменения ради "призрачной мечты"

Вы не поняли. Изменение организационной структуры это не требование. Это "маркер эффективности". Можно и без него. Но в большинстве случаев это повысит эффективность скрама. Если разработчики из разных отделов, и у руководителей отделов есть другие проекты - у скрам мастера прибавляется седых волос. Он каждый день будет отбиваться от "но Вася нам срочно нужен в другом проекте, у нас критическая ошибка. Да, мы помним что мы обещали что следующие 2 недели он работает в скрам-команде, но это форс-мажор, мы не могли его предвидеть!". И такое будет каждый день. Без преувеличений (почти :)) А выдергивание разработчика рушит план на спринт. Что не добавляет радости ни ПО ни клиенту ни команде. Потому что прибежит ПО или ещё какой проект-менеджер и будет полчаса есть мозг на тему "ну вы же понимаете, мы же взяв истории в спринт пообещали клиенту что мы их реализуем, и ему они все очень важны, ну поднапрягитесь, мы понимаем что то что Васю выдернули из проекта это очень плохо, и то что вы недовольны этим, но вы же отличная команда, вы справитесь!". И это бесит. А когда такое происходит постоянно, настроение в команде падает ниже плинтуса. Качество, скорость - всё падает в разы.

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

А на самом деле было полезно и нам нравилось, потому как потом обдумываешь и приходит более лучшее решение.

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

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

Если бы всё было так просто, и вокруг были только адекватные люди, мы бы при коммунизме жили. Чудесного решения "как из кучи моральных уродов сделать команду разработчиков" скрам не предлагает.

А при чём здесь скрам? Задать и так всё можно. Только сроки всегда были важнее всего остального

Вооот! Вот именно этому скрам и противодействует. 1. Какие фичи в каком релизе выйдут не прописваетя. 2. Тикеты с невыполненым DoD нельзя включать в релиз. И команда может послать ПО, когда он начнёт что-то требовать, вроде "не пишите тесты, и так всё понятно". И нормальный мастер их поддержит.

Но это работает только если, как я раньше писал, менеджеры и руководство понимает что скрам даёт, и от чего при сраме надо отказаться. Иначе ПО идёт жаловаться к руководству и руководство "разрешает" команде "не выполнять DoD для истории X". Но потом то же руководство не хочет понимать - а чо это у нас ошибки попёрли. А потому что ПО понравилось такое классное решение. И теперь в каждой задерживающейся задаче "разрешает" не выполнять DoD. И команда уже не спорит, потому что знает что спор ничего не даст. Простейшее противодействие со стороны команды - тупо начать оценивать "стоимость" историй выше. Чтобы в спринт вошло меньше историй и реже "разрешали" не выполнять DoD.

Как то очень сомневаюсь.

Дело ваше. Есть люди, которые в том что земля круглая сомневаются. Бывает. Конечно, кто-то больше любит в графике ковыряться, кто-то БД. Но внедрённые ими в проекте решения будет понимать вся команда.

Пока так и не увидел ни единого преимущества Скрама для себя

Ну так он вам,может, и не нужен. Это нормально.

Как поможет скрам? 1. Цикличностью и постоянным общением с заказчиком (как минимум на ревью). и 2. тем что скрам это "модно".

А почему это должен быть именно скрам?

На модность абсолютно плевать.

А потом ему демонстрируется результат разработки

ну так это и так можно сделать. Это был вроде главный аргумент у Ralf Westphal-а, когда он пытался мне доказать необходимость Скрама.

По умному "fast feedback loops". Мы получаем новую информацию от клиента как реакцию на нашу проделанную работу намного раньше (в каждом спринте).

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

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

В водопаде у такого клиента, после того как он напишет даже самой подробное ТЗ

В принципе мне по барабану водопад, скрам или еще что.

Главная цель - как сделать процесс разработки более эффективным в каком-то конкретном случае.

Пока что приходится для каждого конкретного случая использовать что "то специализированное".

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

у скрам мастера прибавляется седых волос. Он каждый день будет отбиваться

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

И это бесит. А когда такое происходит постоянно, настроение в команде падает ниже плинтуса

безусловно - это реалии. Только как Скрам в этом помогает так и не доходит.

Не важно как вы будете проводить обсуждения

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

Вооот! Вот именно этому скрам и противодействует

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

понимает что скрам даёт, и от чего при сраме надо отказаться

Вот как раз именно с этим я и пытаюсь разобраться. Что с какой стороны ложить на чашу весов

Но внедрённые ими в проекте решения будет понимать вся команда.

отчего - из-за постоянных обсуждений?

Ну так он вам,может, и не нужен. Это нормально.

Вот именно это и непонятно, отчего он мне ни разу не понадобился. Что именно я не понимаю? Или просто проекты были какие то особенные?

Отлично получилось. И ваще ты пишешь очень хорошо. Сразу видно пользу скрама и опыт написания доков :)

А почему это должен быть именно скрам?

Потому что мы его обсуждаем. Можно взять другой метод. Можете придумать свой метод, это не сложно. Сложено объяснить зачем он остальным нужен.

На модность абсолютно плевать.

Зря. Я пояснял в чём тут преимущество. Предупреждаю - для ультра-модных пацанов скрам уже не вариант. Agile is dead и всё такое.

ну так это и так можно сделать.

Вообще всё в жизни можно "делать и так". Только обычно не делают. Аргумент вроде "а зачем нам ПДД, преимуществ в нём я не вижу, ведь останавливаться на красный свет можно и так".

Каждый день по малому кусочку?

А откуда вы взяли про каждый день? Обычно после завершения спринта, на ревью (1 раз в 2-6 недель). Если у клиента подгорает что-то срочное, можно и сразу после завершения тикета показать.

которые соответствуют нашим выдуманным ДОД ему нафиг не нужны.

Это вы так думаете. DoD по-хорошему отражает требования клиента. Чем дороже ошибки и чем долгоживущее проект - тем строже DoD. Но клиента DoD не интересует. Это наш "внутренний" перевод его требований к качеству кода/документации/<подставить нужное>.

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

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

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

Вы, наверное, не поняли. Критическая ошибка в другом проекте. Человек из команды A (организационно, у него тимляйтер Херр Мюллер) откомандирован в скрам-команду проекта B. Спринт планируется исходя из 2-х недельного присутствия этого человека. В середине спринта прибегает его шеф (Мюллер) и с криками "всё пропало, все болеют, рожают и по командировкам" загружает нашего откомандированного. Итого: косяк в планировании Херра Мюллера приводит к проблемам в скрам-проекте B. А так как такое случается всегда, команду проекта B это бесит.

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

Руководство решило внедрять скрам или где? Решило - пусть сидит и не отсвечивает. Это внутреннее дело команды. Что руководство вообще делает на обсуждении? Скрам предписывает что на рефайнменте присутствуют только ПО, члены команды и скрам мастер. Можно (но не обязательно) приглашать технических экспертов. Лучше без них. И обсуждение лучше уже без эксперта (его время дорого да и не надо уме наши внутренние споры слушать). Претензии предъявлять имеет право только команда и скрам-мастер. За пределы команды ругань не выходит - у нас фильтр в виде ПО. А на ревью мастер любую ругань прервёт, потому как обсуждение проблем не формат этого митинга. О как.

Ну так тогда он будет на фирме просто запрещен.

Так и не внедряйте. Кто же вас заставляет? Если у вас и так проблем нет и все проекты выполняются в полном объёме и в срок, то зачем что-то менять? У нас в одном проекте руководство признало, что если бы мы его делали как раньше, по нашему водоподо-подобному процессу, он бы до завершения не дожил бы. Потому как за 2 года 4 раза поменялись приоритеты. И то то в 2016 считалось самым важным, в 2017 оказалось вообще не нужным.

Может, проще описать какие у вас проблемы в проектах? А мы (кто скрамом пользовался) прикинем поможет ли он тут.

отчего - из-за постоянных обсуждений?

И из-за них тоже. Но в основном из-за принципа разработки. Истории разбиваются на задачи (стараемся чтобы длина не превышала один день) и если так получилось, что в истории три задачи, связанные с БД, никто не будет ждать 3 дня, пока гуру БД их выполнит. Их будут делать параллельно, долбая его вопросами. В результате когда такое случится в первый раз все 3 задачи займут больше времени, на 3-4-5 раз, все будут сделаны за 1 день. Задача скрам-мастера донести до команды понимание того, что нельзя специализироваться только на своём и игнорировать всё другое. Иначе будут пробки. А если наш гуру БД заболеет на две недели? Что, вообще ни одной истории не сделаем? Почти все вводят или pair programming или code review. Тоже способствует распространению знаний (и заставляет скрежетать зубами недалёких ПО :)). У нас было выбито 1 час в спринте на "обмен знаниями". Если кто-то в процессе разработки своей задачи начинал делать что-то новое (новый фреймворк, ранее неиспользуемый дизайн пэттерн, еще что) то на дэйли он об этом говорил, и до конца спринта проводили короткий ликбез.

Или просто проекты были какие то особенные?

Как уже говоил выше - расскажите про ваш типичный проект. Может и особенные.

На моей предыдущей работе скрам был ну... в 80% проектах не нужен.

Я уже лет пять пытаюсь руководству объяснить прелести technical writer... Недавно мне сказали - тебе надо, ты им и будь. Я сказал что тогда буду на русском писать доки. Чтобы не вспоминать в очередной раз какого рода Socket :)

А как же тогда определить - "Я работю по скраму"

Определишь как "Я работаю с элементами скрама".

зачем еще на это время тратить?

Затем, что доска очень хорошо показывает кто чем занимается и в какой стадии находится, есть ли какие-то проблемы итд.

Зачем мне новые термины, нужен конкретный пример. Не вижу я адекватного определения.

Конкретного примера не будет :) Тут у каждого свой список. Но, я уверен, когда ты говоришь "я это задание выполнил" ты подразумеваешь, что 1) код работает, 2) тесты зеленые, 3) код в репозитории, 4) изменения задокументированы, 5) что-то еще Так что для того, чтобы не было такого, что один подразумевает одно, коллега другое, а шеф третье и предлагается формализовать определение выполненого задания. Все очень просто, не должно быть никаких "это очевидно", все должно быть записано :)

реально что то высчитать достаточно затруднительно.

На самом деле нет. У каждой задачи есть предполагаемое время исполнения и есть фактическое время исполнения, оба этих параметра видны на burn-down chart. И это вполне себе нормальная оценка процесса. Так что глядя на серию burn-down chart'ов можно делать выводы относительно того, как работает команда.

Прежде всего спасибо за поддержку и за ответы.

К сожалению, ситуация не такая простая как может показаться.

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

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

Сложено объяснить зачем он остальным нужен.

именно в этом и проблема

А откуда вы взяли про каждый день?

не имею понятия, откуда то пришло, что именно "большая скорость показа" дает преимущество.

перевод его требований к качеству кода/документации

Это тоже никак не доходит - как методика может изменить качество кода или добавить документации.

Если разработчик "мыслит" плохим кодом, то изменить это непросто.

Я не знаю что вы имеете в виду под "голым теоретическим скрамом"

Это то о чём можно прочитать, типа этого

https://habr.com/post/247319/

https://4brain.ru/blog/scrum/

https://te-st.ru/2017/07/04/12-terms-of-scrum/

Расскажите, как выглядит ваш типичный проект?

В данный момент есть различные группы проектов. Но все они не являются исключительно "софтовыми", всегда есть завязка на оборудование и связанные компоненты (типа БД заказчика)

В одной группе проекты от 1 чел./мес. до 4..6

В другой группе "постоянные" проекты, которые только могут дорабатываться под конкретные требования, до 1 ч/м иногда там что то и меняется.

А так как такое случается всегда, команду проекта B это бесит.

А как может быть по другому? Ресурсы всегда в недостатке.

За пределы команды ругань не выходит

Это мое замечание было вообще не в контексте скрама. просто случай который запомнился.

скрам был ну... в 80% проектах не нужен

вот именно правила, "когда не нужен/нужен" и хочется как то формализовать.

Но, я уверен, когда ты говоришь "я это задание выполнил" ты подразумеваешь

Проблема несколько в другом.

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

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

4) изменения задокументированы

А что конкретно под этим имеется в виду?

И это вполне себе нормальная оценка процесса.

Стандартная оценка, стандартного процесса.

Недавний пример: в вторник под окочание рабочего дня система как то работала, одна часть немного дурела, планируемое время еще пару часов. В среду утром "покрутили винтики" на части которая дурела, итог - система перестала запускаться вообще. В четверг пришел ПЛС программист исправил. Итог - систему удалось запустить только в пятницу.

Пример буквально сегодня. Клиент напомнил об ошибке - разбор с проблемой пару часов. Но одна тонкость, для этого нужна рабочая версия клиента к ДБ2. Полдня убил на попытки ее восстановить никакой продвижки. И подобных случаев довольно много.

Это тоже никак не доходит - как методика может изменить качество кода или добавить документации.Если разработчик "мыслит" плохим кодом, то изменить это непросто.

А как ПДД могут изменить поведение водителя на дороге или уменьшить количество аварий?

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

Если разработчик косячит это создаёт проблемы для команды. Самоорганизующаяся, помните? Команда может общаться с разработчиком, объяснять что не так. Вплоть до того, что его заменят, если сильно упёртый.

Если вся команда такая - то DoD они соберут соответствующее. Для долгоживущих проектов стоит задавать определённые "базовые" требования снаружи команды. А то эти придурки через год разбегутся а рподолжать развивать и поддерживать - нам.

В одной группе проекты от 1 чел./мес. до 4..6

А сколько потом проекты из первой группы поддерживаются? Заказчики требования к документации предъявляют?

В другой группе "постоянные" проекты, которые только могут дорабатываться под конкретные требования, до 1 ч/м иногда там что то и меняется.

Я так понимаю что у вас каждый проект и доработку "постояного" делает один человек? Вас это устраивает? По 3-5 человек над одним проектом / доработкой не работаете?

А как может быть по другому? Ресурсы всегда в недостатке.

Может быть по-нормальному. Когда Вася больше не в отделе Херра Мюллера, и он Васе лично ничего приказывать не может. Если у Мюллера жуткие проблемы он идёт к скрам-мастеру и ПО проекта B и просит у них, если есть возможность, выделить ему время разработчика(ов) из проекта B. Если ПО готов пожертвовать историей (или несколькими) и убрать их из спринта, то задача передается команде. Спринт уменьшили, тресса нет.

Т.е. вместо

Мюллер -(командует)-> Вася -(извиняется)-> команда -(извиняется)-> ПО -(давит на команду, чтобы всё равно всё успели)-> команда

У нас общение идёт так:

Мюллер -(просит)-> ПО -(объясняет свое решение команде, убирает истории из спринта)-> команда (делегирует Васю или делают всёвместе)

Жирным помечены те, кому такое общение добавляет стресса.

И очень часто (внезапно!) никому уже не нужен Вася, оказывается всё не так срочно! Потому что Херр Мюллер больше не может командовать как его левая пятка захотела, а должен просить и объяснять почему так срочно, и срочнее ли это чем истории в спринте. И выясняет он это на своем уровне (с ПО) а не с подчинённым.

Умно это называется "убрать конфликт интересов" :)

вот именно правила, "когда не нужен/нужен" и хочется как то формализовать

Всё можно сделать без скрама. Чесслово. Когда стоит его вводить я старался описать в "когда скрам эффективен".

Главное - если клиенты недовольны тем, как реализованы их требования (мы хотели не это) надо вводить методику с коротким (быстрым) циклом. Скрам самое известное.

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

Задача "на неделю" должна быть быть разбита минимум на 5 подзадач.

Что значит "функционал появится только по окончанию сборки всех частей"? Очевидно, что функционал есть у каждой из частей. В конце концов есть юнит-тесторование, при котором наличие других частей - это скорее вред, чем польза. Так что каждая часть может (и должна) быть протестирована независимо от других. А после того, как будут сделаны все части, надо будет провести тестирование всех частей вместе - интеграционное тестирование.

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

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

А что конкретно под этим имеется в виду?

Каждый понимает свое. Для кого-то достаточно заполненых summary тэгов, кому-то надо еще дополнить chaneslog.txt, где-то надо зачекинить в определенном месте все е-мылы и документы по данной теме. Никаких правил тут нет :)

И подобных случаев довольно много.

К чему эи примеры? На скрам-доске все задержки моментально видны, а также понятны причины задержек. И если какая-то из запланированных задач не будет сделана, то сразу понятно почему. Более того, становится заранее понятно, что команда не успевает сделать все запланированное и тогда можно как-то реагировать.

Вплоть до того, что его заменят, если сильно упёртый.

Не всегда это возможно, особенно если он "выше по рангу".

А сколько потом проекты из первой группы поддерживаются?

Исправление ошибок неограниченно, а любые новые хотелки рассматриваются как "новый проект"

Заказчики требования к документации предъявляют?

Иногда хотят "руководство пользователя", для всех "постоянных" проектов оно и так имеется в комплекте на нескольких языках.

По 3-5 человек над одним проектом / доработкой не работаете?

А смысл? По скорости не критично обычно, и к клиенту все команду не пошлешь.

Когда Вася больше не в отделе Херра Мюллера

А есть только один отдел Херра Мюллера?

Главное - если клиенты недовольны тем, как реализованы их требования (мы хотели не это)

Они просто не подписывают "завершение контракта", но такого еще не попадалось.

Всё можно сделать без скрама.

ну так именно из-за этого все и началось. Еще ни разу не попалось проекта "когда скрам эффективен".

Не всегда это возможно, особенно если он "выше по рангу".

В скрам-команде все одинаковы по рангу. Кроме студентов :)

Исправление ошибок неограниченно, а любые новые хотелки рассматриваются как "новый проект"

Ок. Т.е. можно представить себе как один долгий, незакрытый проект, в котором время от времени (но не постоянно и не регулярно) появляются новые требования, так?

Иногда хотят "руководство пользователя", для всех "постоянных" проектов оно и так имеется в комплекте на нескольких языках.

Руководство пользователя можно и один раз к релизу писать. А что вы делаете, когда просыпается с новой хотелкой старый клиент, которому последний раз что-то делали два года назад, а человек, который делал проект для этого клиента уже ушёл с фирмы?

А смысл? По скорости не критично обычно, и к клиенту все команду не пошлешь.

Смысл в скорости, в случае необходимости и в распространении знаний о проекте. Да и ошибки 2-3-м искать легче, каждый свою идею опробует, друг с другом поговорили и идея родилась. Или у вас все проекты типовые? Вроде - проект 1 "настроить PLC c 4-мя датчиками давления и 1-м влажности", проект 2 - "настроить PLC c 2-мя датчиками давления и 2-мя влажности"?

А есть только один отдел Херра Мюллера?

Почему? Сколько угодно отделов. Речь о том что разработчиков срам-команды надо выводить из отделов. Они работают в скрам-команде. И больше нигде и ни на кого.

но такого еще не попадалось.

Ну значит у вас всё хорошо. Зачем дёргаться?

Еще ни разу не попалось проекта "когда скрам эффективен".

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

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

Пожалуй стоит открыть новую тему "вред и польза от юнит тестов"

Невозможно все стричь под одну гребенку.

Вот был проект, довольно долгий. Там данные от устройства передавались по СОМ порту и декодировались. Это была одна из важных функций. Были отдельные тесты для "декодера" и была сделана система для генерации потока данных через СОМ порт, был даже человек который какое то время только и писал сценарии тестирования. Но это было необходимо, так как различных устройств было довольно много, партии устройств были довольно крупные и устройства не могли запросто выдавать неверные данные типа "30 февраля". Реализация всей системы заняла несколько недель, не считая кучи сценариев и того что через какое то время пришлось все сценарии перекраивать, так как в устройствах что то изменилось.

Теперь допустим есть другой проект, только для одного заказчика который выполняет какую то важную работу и как бы между прочим получает данные о весе через СОМ порт (которые впрочем можно ввести и вручную). Будем ли мы городить все тоже самое для этого проекта?

Ну и нужно, чтобы вся команда следовала TDD.

зачем? и почему не допустим BDD?

не может быть одного решения на все случаи жизни.

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

Каким образом из положения бумажек видно "почему"?

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

В скрам-команде все одинаковы по рангу

Это типа "сферического коня в вакууме"?

А команда откуда берется и где "живет"?

Т.е. можно представить себе как один долгий, незакрытый проект, в котором время от времени (но не постоянно и не регулярно) появляются новые требования, так?

Можно и так, только новые требования - это не перенести кнопочку на страницу 3

А что вы делаете, когда просыпается с новой хотелкой старый клиент, которому последний раз что-то делали два года назад

открываем репозиторий скачиваем проект и меняем. Хотя опять таки, не все всегда одинаково.

Есть старая прога которая может работать исключительно под 32 битной ОС. Пришла хотелка 64 бита - пришлось писать по новой.

Смысл в скорости, в случае необходимости и в распространении знаний о проекте

Важное замечание о проекте - в единственном числе.

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

А чтобы только понять как работает более сложная система счет может идти на дни. Так что говорить о скорости исправления ошибки "в параллель" говорить не приходится.

Или у вас все проекты типовые?

разные есть.

Вот например один из них посложнее.

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

Вариант попроще, когда есть только одно устройство и измерения проводит один человек. Еще проще - вариант без PLC

Они работают в скрам-команде. И больше нигде и ни на кого

такого мне еще не попадалось, да и представить как то сложно

Зачем дёргаться?

Так уже говорил, не ради текущих задач конкретно. Есть нечто, что не совсем понятно, хочется разобраться. Когда это пригодится и как, не имею понятия.

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

Пока что я не вижу у вас проектов, где был бы нужен скрам.

Так именно об этом и говорил. Да и фирма - не "софтовая".

Пожалуй стоит открыть новую тему "вред и польза от юнит тестов"

Ну вреда от юнит тестов нету никакого :D Так что ветку можно не открывать ;)

Вот был проект, довольно долгий. Там данные от устройства передавались по СОМ порту и декодировались. Это была одна из важных функций. Были отдельные тесты для "декодера" и была сделана система для генерации потока данных через СОМ порт, был даже человек который какое то время только и писал сценарии тестирования. Но это было необходимо, так как различных устройств было довольно много, партии устройств были довольно крупные и устройства не могли запросто выдавать неверные данные типа "30 февраля". Реализация всей системы заняла несколько недель, не считая кучи сценариев и того что через какое то время пришлось все сценарии перекраивать, так как в устройствах что то изменилось.

Теперь допустим есть другой проект, только для одного заказчика который выполняет какую то важную работу и как бы между прочим получает данные о весе через СОМ порт (которые впрочем можно ввести и вручную). Будем ли мы городить все тоже самое для этого проекта?

Я, честно говоря, не совсем понял твой пример :D

Насколько я понял, у вас есть генератор сообщений, есть COM порт и есть декодер, вы все это собираете и тестируете. И почему-то называете это все юнит-тестом :D Это не юнит-тест, это интеграционный тест. Юнит-тестом тестироался бы только декодер и никаких потоков данных через COM порт. Да и вообще никаких портов и привязок к железу или к другим компонентам. Тестируя декодер мы исходим из того, что все остальные компоненты работают правильно и не нуждаются в тестировании.

Например, у нас есть такой процесс:

ПО снимает данные с датчиков -> обрабатывает эти данные -> посылает в COM порт -> принимаются данные из COM порта -> декодируются.

Очевидно, что тут минимум 5 юнитов, каждый из которых должен быть протестирован независимо от других. Так наприме, декодер не должен уметь справляться с ситуацией, когда прервалось соединение COM порта. За обеспечение работы по передаче данных отвечают модули "посылает в COM порт" и "принимаются данные из COM порта".

В другом варианте все тоже самое. COM порт не при чем. От слова совсем.

Поэтому в другом проекте мы ничего не будем городить, мы просто возьем уже оттестированные модули "посылает в COM порт" и "принимаются данные из COM порта" и нам будет начхать от куда взялись данные из COM порта или их ввели в ручную.

зачем?

У TDD есть один большой плюс - заставляет продумать удобство используемого интерфейся до того, как начинаешь писать функционал.

и почему не допустим BDD?

BDD подходит для описания системных или интеграционных тестов. Описание всех тест-сценарием на BDD займет слишком много времени, да и сопровождать такие тесты гораздо сложнее. ИМХО. Если у тебя другой опыт - это ж только плюс :D

Каким образом из положения бумажек видно "почему"?

Каждое утро команда собирает у доски и каждый из членов команды отвечает на 3 вопроса: 1) что было сделано вчера? (передвигая бумажку) 2) какие возникли друдности? (увеличивая время на задачу) и 3) что планируется делать сегодня? (передвигая бумажку)

Таким образом сразу становится понятно, почему какая-то задача занимает больше времени.

1) что было сделано вчера? (передвигая бумажку) 2) какие возникли друдности? (увеличивая время на задачу) и 3) что планируется делать сегодня? (передвигая бумажку)

А в конце вся команда отвечает на вопрос - нет грозит ли нам невыполнение спринта.

Это типа "сферического коня в вакууме"?

Это типа объективная реальность данная нам в ощущениях. В скрам команде никто никем не командует. Анархия - мать порядка. Если не считать скрам-мастера членом команды. Потому как он может командовать на митингах.

А команда откуда берется и где "живет"?

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

Можно и так, только новые требования - это не перенести кнопочку на страницу 3

Ну так требования ничем не ограничены. Вернее не так - надо чтобы их могли хоть как-то озвучить. Вот только недавно доделали задачу - сделать консольные команды для программки со сложным гуем. Теперь Jenkins может скриптами тестировать и передачу сообщений по нашему ESB (к вопросу у гуях и консоли :))

открываем репозиторий скачиваем проект и меняем. Хотя опять таки, не все всегда одинаково.

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

Есть старая прога которая может работать исключительно под 32 битной ОС. Пришла хотелка 64 бита - пришлось писать по новой.

Оффтоп: Правда всё? Не какие-то части, связанные с чем-то хардварно близким, пару типов переименовать, или я не знаю, какие-нибуть расширения использовать чтобы вектора перемножать, а действительно всё? Как же вы там живёте под виндусями-то... Программку, без привязки к хардварю, написанную на 32-х битном линуксе, заставил компилироваться на 64-х битном солярисе - насколько помню только несколько хедеров и имён типов поменять пришлось. На солярисе uint32_t по другому назывался вроде бы. Забыл уже... А попозже вообще без проблем стало. Главное архитектуру в configure не забывать задавать. Ну и писать программки надо задумываясь о том что их на разных архитектурах собирать будут, не без этого.

Важное замечание о проекте - в единственном числе.

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

А чтобы только понять как работает более сложная система счет может идти на дни. Так что говорить о скорости исправления ошибки "в параллель" говорить не приходится.

Это вам так неправильно кажется. У нас скрам-команда "Утилиты" отвечает ммм... проектов за 12. Если ничего не забыл. В одном спринте могут быть задания для нескольких проектов. Тяжелее всего тут ПО - ему решать что важнее, для какого проекта что они делают сейчас, а какой подождёт до следующего спринта. Все 6 человек более-менее разбираются во всех 12 проектах. Т.е. им не надо рассказывать что это за проект, где его документация и кого можно поспрашивать если сам не можешь разобраться. Пока что 2 (скорее 3) не рискнут что-то сильно менять в проектах с Eclipse RCP, еще парочка не полезет ковыряться в одном новом проекте, там слишком много SQL-я а они с ним на вы. Ну так и команде меньше года. Еще через годик подтянутся. Но и теперь не сидят и не ждут если кто-то в отпуске, в командировке или болеет.

такого мне еще не попадалось, да и представить как то сложно

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

Похоже мы смотрим с различных позиций.

Я с позиции что скрам команды никогда не было на фирме. Вы с позиции, что она (они) уже давно есть.

В скрам команде никто никем не командует

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

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

И вы через два года знаете что и зачем там делал предыдущий программист?

Конечно нет. Но в принципе этого часто и не нужно. Достаточно найти место, которое нужно править.

Правда всё? Не какие-то части, связанные с чем-то хардварно близким, пару типов переименовать

Во первых, зачем тащить за собой динозавров.

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

Ну и соответственно весь концепт был довольно старым. Новый сделан под WPF на других принципах.

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

ну расскажите это лет 20 назад разработчику ориентированному исключительно на винду.

Вы вот задумываетесь сейчас, как будет компилить вашу прогу на 128 бит

У нас скрам-команда "Утилиты" отвечает ммм... проектов за 12

И скорее всего это проекты поддержки к основному проекту.

А теперь умножьте это на "х" и размажьте их всех лет на 10 хотя бы. Теперь добавляем, что большая часть проектов не требует никаких изменений. Какой проект проснётся и когда не знает никто, даже сам заказчик.

Вопрос в задачке - сколько программистов какие проекты должны заранее изучать, что быть как пионэр "усегда готов"?

В котором начальник ПО, но который не может принимать никаких решений по персоналу. Зарплата, найм, увольнение - за это отвечает другой менеджер.

никогда подобной структуры и близко не попадалось.

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

Ну вреда от юнит тестов нету никакого

Это смотря с какой стороны посмотреть. С одной стороны - маслом кашу не испортишь. А с другой, от килограмма масла может и поплохеть.

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

Насколько я понял, у вас есть

Видимо плохо пояснил. Речь шла о совершенно разных проектах в совершенно разных фирмах, в разных временных интервалах.

И почему-то называете это все юнит-тестом

Сорри, как то незаметно смешалось. Делалось и то и другое.

За обеспечение работы по передаче данных отвечают модули "посылает в COM порт" и "принимаются данные из COM порта".

У нас концепция немного разная. За обеспечение работы по передаче данных отвечает "модуль обмена" и в первом случае это мог быть и СОМ порт и "синий зуб" и фиг знает что.

В другом варианте все тоже самое.

В том то и дело что нет. Для первого случая нужен был пулемет в доте, для второго достаточно и пистолета в руке.

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

мы просто возьем уже оттестированные модули

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

Кроме того, нам нужен модуль "весов АБС", в котором обмен занимает несколько строк и асинхронный обмен просто противопоказан.

нам будет начхать от куда взялись данные из COM порта

Это в общем случае так. А вот когда все конкретное, то ситуация меняется.

Вот на фирме все работало, а у заказчика ну никак.

У TDD есть один большой плюс - заставляет продумать удобство используемого интерфейса до того, как начинаешь писать функционал.

А как быть если интерфейсов/классов многие десятки и зачастую не знаешь заранее сколько и каких там будет функций. А есть ООП TDD?

Либо в итоге, часть которая была предложена полностью аннулируется, так как хотелось совсем другое, но оно просто не было описано, потому как было "и так понятно".

Я с позиции что скрам команды никогда не было на фирме. Вы с позиции, что она (они) уже давно есть.

3 года назад на нашей фирме не было ни одной скрам-команды. Теперь 2 постоянных и еще 2 на временных проектах. Т.е. когда проект закончится - команда разойдётся, перераспределится назад по своим отделам, а может новый проект нагрузят. Пока неизвестно.

Да, стоит, наверное добавить. Когда у нас начали носиться со скрамом я был против. Потому что был уверен что у нас как раз структурных изменений не осилят. И первый год была полная жопа. Но благодаря руководству "разработки" всё таки нашему ПО настучали по пальцам, и теперь он хоть и тимляйтер всех программистов из наших 2-х постоянных скрам-команд, но общается как ПО. Пока что никого не уволил :) Хотя рефайнменты с ним всё еще тяжело проходят.

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

Именно так. Но ещё раз - начальник на время эксперимента "лишается" своего/своих подчиненных. Иначе не взлетит.

Вы вот задумываетесь сейчас, как будет компилить вашу прогу на 128 бит

Сейчас? Ни на секунду. Напишут новую JVM и всего делов. С x32 на x64 перешли безболезненно.

Раньше - не сильно. Огромных проектов да еще и близких к хардвари на сях я не писал. Аккуратнее с заголовками просто надо и gcc компилирует и на 32 и на 64 и на арм. так что и с переходом на 128 прошло б без особых проблем, наверное.

И скорее всего это проекты поддержки к основному проекту.

Ну, если сильно притянуть за уши то да. От генерации кода из UML и собственного расширения JUnit-а, до архивации данных (штоп всё по закону) и описания документов для массовой печати / автоматического распознавания. Тоже всплески активности бывают. Вот утилитку для контроля за MQ каналами 3 года не трогали, а недавно командный интерфейс потребовали.

Вопрос в задачке - сколько программистов какие проекты должны заранее изучать, что быть как пионэр "усегда готов"?

Ответ на задачку прост - 5 лучше чем 1. Потому что шансов что через нцать лет на фирме из 5 останется хоть один, кто старый проект знает повыше чем для 1-го. Какие проекты? Для которых появляются задачи, разумеется. "Про запас" можно если текущих задач мало, люди простаивают, почему бы нет. С того же васика на что-то приличное перевести.

никогда подобной структуры и близко не попадалось.

Что логично, ведь вы никогда не работали со скрамом. А она и у тех, кто скрам использует не всегда присутствует.

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

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

Без всяких разрешений от ПО / скрам мастера. Но я про такие только слышал. Лично не видел.

Вы - ПО. Нет "начальника команды". А руководство ресурсами поднимается на уровень выше - к Gruppen- или Abteilungsleiter-у.

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

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

Тут можно смирится, что ради одного небольшого изменения придется править полсотни тестов.

Если ты какой-то интерфейс переименовал или поменял сигнатуру какой-то функции, то на это должны быть веские основания. Но это никак нельзя отнести к "небольшим изменениям". Или ты считаешь, что "небольшое изменение" - это когда изменено до 10 символов? :)

Речь шла о совершенно разных проектах в совершенно разных фирмах, в разных временных интервалах.

Какая тогда связь между этими примерами?

У нас концепция немного разная. За обеспечение работы по передаче данных отвечает "модуль обмена" и в первом случае это мог быть и СОМ порт и "синий зуб" и фиг знает что.

Ну т.е. "модуль обмена" - это контракт, которым описываются правила передачи данных (aka просто набор интерфейсов), а "посылаем в COM порт" - это реализация этого набора. Таким образом, для тестирования, скажем, декодера, никакие данные никуда передавать не нужно. Нужены только интерфейсы.

А как быть если интерфейсов/классов многие десятки и зачастую не знаешь заранее сколько и каких там будет функций. А есть ООП TDD?

Конечно. Не вижу тут проблемы.

Либо в итоге, часть которая была предложена полностью аннулируется, так как хотелось совсем другое, но оно просто не было описано, потому как было "и так понятно".

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

теперь 2 постоянных и еще 2 на временных проектах

4х5 - это минимум 20 программистов, +еще десяток на подхвате вероятно - софтовая фирма среднего размера видимо.

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

Сейчас? Ни на секунду. Напишут новую JVM и всего делов.

ну так и тогда никто не задумывался - работает и хорошо. А что Васик в конце концов пойдет за Коболом никто и сейчас не верит у нас из руководства.

Ответ на задачку прост - 5 лучше чем 1.

ага 5х10 проектов, по дню допустим = 50 ч/д и никто не выстрелил - выбросили в пропасть 50ч/д, при том что через полгода/год нужно все повторять но новому. Смысл?

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

И сами закупают себе компьютеры

Ага и держат еще свою ИТ инфраструктуру, секретаршу и бухгалтера.

Такая значит Скрам фирма, вполне допускаю, что может и такое быть. Но меня там уж точно не будет.

Даже есть CI нет, тесты все равно нужны

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

Без CI можно запустить раз после всех изменений в сложной части.

Но опять таки от типа проекта сильно зависит.

Если ты какой-то интерфейс переименовал или поменял сигнатуру какой-то функции

для этого вообще не нужно менять тесты, они изменятся автоматом

"то на это должны быть веские основания" почему? Было например "Anzahl" стало "Count", либо просто буква не та.

это контракт, которым описываются правила передачи данных (aka просто набор интерфейсов)

Это парадигма давно в мусоре у нас валяется. Есть модуль и есть список сообщений.

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

Это уже интересно, а как проверить, что будет делать наш декодер если ему придет дата 29 февраля в любой год например?

ООП TDD

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

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

Но до этого мы уже написали пару десятков тестов, что с ними делать?

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

Конечно! А как может быть иначе? :) Я перед каждым коммитом запускаю все тесты локально. Благо, что юнит-тесты исполняются очень быстро :)

для этого вообще не нужно менять тесты, они изменятся автоматом

Ну это совсем не обязательно.

"то на это должны быть веские основания" почему? Было например "Anzahl" стало "Count", либо просто буква не та.

Потому что в случае, если ты уже выпустил интерфейс, то изменение сигнаруры ведет к потере обратной совместимости. Не знаю как у тебя на работе, а я уже очень много раз сталкивался с тем, что начальство хотело выкатить фикс, но при этом не хотело устанавливать новую версию. И тогда надо было заменить 1-2 dll'ки простым copy-paste.

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

Это парадигма давно в мусоре у нас валяется. Есть модуль и есть список сообщений.

Зря она у вас в мусорке :) Эта парадигма позволяет использовать модули как блэк боксы и комбинировать их по необходимости. Например заменять один модуль (связь с реальным COM портом) другим (например сгенерированным NSubstitute'ом).

Это уже интересно, а как проверить, что будет делать наш декодер если ему придет дата 29 февраля в любой год например?

А в чем проблема? Делаешь 2 теста:

1) создаешь экземпляр декодера и пишешь в него 29 февраля 2020г. Получаешь ответ и проверяешь правильность ответа.

2) создаешь экземпляр декодера и пишешь в него 29 февраля 2018г. Получаешь ответ и проверяешь правильность ответа.

Все.

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

Не понял, ссылочку на что?

Но до этого мы уже написали пару десятков тестов, что с ними делать?

Изменение в требованиях - это достаточно веская причина для того, чтобы изменить тесты.

Странная у нас беседа получилась...

- А расскажите-ка чойта эта скрам такое?

- ...

- Не, это мне не нужно

- Бывает

- Не, ну все же о нём говорят, а мне не нужен. А где нужен-то? А что даст?

- Вот тут и тут нужен, даёт то-то и то-то.

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

У вас всё хорошо, проблем никаких, все проекты завершаются в срок и все требования выполняются. Радуйтесь! И ничего не меняйте! Я такого пока что не видел. Лично вам на вашей работе скрам не нужен.

Странная у нас беседа получилась...

может для вас и странно а для меня было полезно - спасибо.

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

И если раньше подобные объявления мог читать, то сейчас сразу отбрасываю

"arbeitest Du in agilen Entwicklungsprojekten...Starke Mitwirkung in agilen Ritualen und Prozessen"

проблем никаких

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

Конечно! А как может быть иначе?

Очень даже может быть иначе. Так как нет однозначных решений для всех ситуаций. Я уже пытался привести примеры.

Когда был проект "с тестами" был специальный "ночной тест" на пару часов вроде, а может и больше, уже не помню.

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

А если не существует понятия "выпустил интерфейс"?

Я уж не говорю о случаях, когда одна и тебя библиотека используется несколькими продуктами

еще одна интересная тема.

Есть проекты А,Б,С которые используют "стандартную" либу Х (забудем даже что их имеется несколько взаимосвязанных)

Продукты "меняются" очень неравномерно А довольно часто, Б реже, а С раз в пару лет может быть. Соответственно Х может меняться довольно часто.

Есть одно важное требование - А,Б,С должны компилироваться в любой момент времени без ошибок и не требовать повторного тестирования.

Решения?

Эта парадигма позволяет использовать модули как блэк боксы и комбинировать их по необходимости

Надоели разлапистые дубы, если понятно о чём речь. А также раздумья как передать инфу из модуля А в модуль Б - так как они не имеют и не должны иметь "прямой связи".

Все тоже самое можно делать и с "новым" модулем + то что имплементацию можно менять как угодно, неизменным остается только "ид" команды и ее значение.

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

Одно ограничение - нет "истинного" реал тайм обмена между модулями и/или системой. Но для нас это 1-2% когда действительно надо.

Был на одном проекте любитель интерфейсов. Практически все классы имели "зеркальный" интерфейс, вся иерархия классов почти дублировалась иерархией интерфейсов и т.п. и т.д.

А в чем проблема? Делаешь 2 теста:1) создаешь экземпляр декодера и пишешь в него

никакие данные никуда передавать не нужно

проблема в этом - bold & italic

Хотя теперь понял - речь о физической передаче данных.

Но тут проблема простая - юнит тесты работают, а система все равно сбоит.

Не понял, ссылочку на что?

на ООП TDD. Как начав с тестов получить структуру классов.

Изменение в требованиях - это достаточно веская причина для того, чтобы изменить тесты.

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

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

Кто знает. Вы проблем с процессом разработки не озвучивали.

Это парадигма давно в мусоре у нас валяется. Есть модуль и есть список сообщений. ... А также раздумья как передать инфу из модуля А в модуль Б - так как они не имеют и не должны иметь "прямой связи".

Ааа.. Вы хотите сказать что вы используете шину сообщений? А определение формата сообщений разве не сравним с определением интерфейса?

Вы проблем с процессом разработки не озвучивали.

Так если методика в принципе неприменима.

Давайте подсчитаем, команда 5 человек + 1 ПО + 1 СМ=7. Ладно считаем ПО где то, что то совмещает, СМ в команде. Минимум 5. То есть каждый день тикает 5х оплата.

Проект допустим 25 ч/д, сделает ли команда его за неделю? А если проект на неделю то будет ли он готов за день?

А если два проекта идут одновременно? Один нужно сдавать в Японии, другой в Америке. Берем вторую команду или пусть первая переключается? Кто будет на сдаче проекта и как оперативно решать возникающие проблемы? А что делать если софт работает только исключительно возле устройства которое занимает метров 20 квадратных и расположено оно на другой фирме. Причем для позвонить нужно часто выходить из зала где расположено устройство.

А параллельно еще несколько проблем от клиентов по старым проектам. Кто их должен решать?

Вы хотите сказать что вы используете шину сообщений?

Можно и так определить.

А определение формата сообщений разве не сравним с определением интерфейса?

Параллелей можно проводить много. Сообщение это просто POCO объект.

на ООП TDD. Как начав с тестов получить структуру классов.

-----

Во-первых, терминология, не "на ООП TDD", а TDD в ООП реализации.

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

не "на ООП TDD", а TDD в ООП реализации.

Как для меня так это две разные вещи - именно ООП TDD

Как будет выполнятся реализация - не TDD не регламентирует

Тогда какой смысл начинать с тестов, когда вначале интересует именно правильная реализация

Нет, вы рассказываете про проблемы, которые могут произойти если будете использовать скрам и которые вы сами себе выдумали.

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

Параллелей можно проводить много. Сообщение это просто POCO объект.

А интерфейс это просто интерфейс. У вас всё тот же контракт. Просто описаный не интерфейсом а разными классами сообщений. Надо сказать что с EventBus-ом тесты писать даже проще чем с интерфейсами.

А вот что с EventBus-ом плохо так это скалируемость. В смысле роста числа классов сообщений. Сначал их 10, через год 100. Никто нигде не описывает для чего он ввёл сообщение TemperatureIncrement. И мы погрязаем в 2-х антипаттернах:

1. Неправильное повторное использование сообщений.

Разработчик добавляет функцию в управляющий гуй - "изменение температуры срабатывания тревоги". Ему как-то надо от гуя передать модулю мониторинга новое значение. Он находит сообщение TemperatureIncrement и радостно его использует. Конечно же, не тратя н-цать часов на то чтобы проверить а где оно используется сейчас, а кто и при каких условиях его бросает. В результате, модуль получающий сообщение от датчика температуры, видит повышение и кидает TemperatureIncrement, который радостно обрабатывается мониторингом и вместо того, чтобы бить тревогу, просто увеличивает порог срабатывания. Примерно понятно в чем проблема?

2. Дублирование сообщений.

Порывшись в классах сообщений, и не догадавшись что P12RsSig5V это то, что ему нужно, программист делает новое сообщение DoorOpened (которое и посылается когда на 12-м пине повышается напряжение до 5 вольт).

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

Да, я понимаю, у вас такого никогда не было и не будет, потому что над проектами работает один человек 1-2 месяца.

У вас всё тот же контракт

Это есть смотреть с одной маленькой стороны. Модуль имеет еще все что нужно ему для работы

А вот что с EventBus-ом плохо так это скалируемость.

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

Модуль имеет одну функциональность которая не имеет тенденции к увеличению.

Разработчик добавляет функцию в управляющий гуй - "изменение температуры срабатывания тревоги". Ему как-то надо от гуя передать модулю мониторинга новое значение.

Совершенно другой подход.

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

>делает новое сообщение DoorOpened

не может быть отдельного сообщения такого типа - это все статус устройства

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

А при интерфейсах такого не будет....

А при интерфейсах такого не будет....

Теоретически может быть. Практически система должна быть просто гигантская. Просто вместо 100 сообщений у нас (грубо, обычно как-то меньше получается) 10 интерфейсов с 10-ю методами.

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

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

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

если будете использовать скрам и которые вы сами себе выдумали

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

Просто вместо 100 сообщений у нас (грубо, обычно как-то меньше получается)

Если модуль имеет 100 сообщений это просто "неправильный" модуль на него слишком много чего возложено, больше 10-ти я даже и не упомню.

10 интерфейсов с 10-ю методами

минимум 20 различных файлов со своей иерархией.

Как я уже говорил, не может быть одного универсального решения на все случаи жизни. Если бы кто раньше мне сказал, когда я был на одном проекте, вот смотри какое удобное решение Х, мы его практически во всех проекта используем - Я бы спорил с ним до упада, потому как это решение совсем не годилось бы для моего тогдашнего проекта.

И смотрел бы на это решение именно с позиций текущего и предыдущего проектов и оно бы реально казалось полнейшим Г.

Насколько удобнее общаться когда никто не понимает что же оппонент имеет в виду

Это уже как говорится, другой конец палки.

Если есть что то, похоже на что то известное, то совсем не обязательно, что это что то будет точно соответствовать тому что определяется известным.

-----

Методика TDD - сначала - тесты. Под них подгоняется код. Требования к коду - удовлетворять написанные тесты. На качество и продуманность имплементации - насрать.

На качество и продуманность имплементации - насрать.

А если наоборот, тогда как?

Хотя меня уверили что ООП ТДД имеется....

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

Так вы ничего руководству не продадите. Вы должны приходить и говорить - смотрите, у нас есть проблема 1 и 2. Их обе обещает решить скрам, засчёт того-то и того-то. Может, попробуем у насего внедрить?

А разбирать вымышленные проблемы мне, честно говоря, неинтересно. Скрам вам не нужен, помогать вам не надо. А самоутверждаться "я могу найти решение для любой проблемы" не надо мне. Мне реальных хватает. Как объяснить двум программистам, никогда не писавших сложных проектов на мейвене, что в сложном проекте очень удобно разбивать на мелкие модули... У них проблем-то нет, вернее они сними никогда не сталкивались.

Если модуль имеет 100 сообщений это просто "неправильный" модуль на него слишком много чего возложено, больше 10-ти я даже и не упомню.

Я не говорил про модуль, посылающий 100 сообщений. Я про суммарные 100 сообщений. 20 модулей, каждый от 3 до 7. В сумме чтобы правильно писать нам надо помнить про все 100 сообщений. Чтобы не дублировать. А если мы эти сообщения через что-то внешнее персылаем, вроде MQ сервера, то тут и за форматом следить придется.

минимум 20 различных файлов со своей иерархией.

Это на каковском языку? Или это в визуальной студии такие ужасы? Но вообще не важно. Хоть по 5 файлов на интерфейс. Нам их править очень редко надо. Слышали такое - "код пишется один раз а читается 100"?

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

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

P.S. дебажить Objective C это лютый трындец.

Так вы ничего руководству не продадите.

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

Для начала нужно иметь хотя бы 5 человек которые бы работали совместно над одной задачей относительно продолжительное время. Или?

В сумме чтобы правильно писать нам надо помнить про все 100 сообщений.

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

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

Это на каковском языку?

По идее на любом. Есть интерфейс - декларация и должна быть имплементация. Можно засунуть и в один физический файл, но смысла это никак не меняет

Объявлять всю парадигму программирования с контрактом (с интерфейсами) валяющейся в мусорке и замененой лучшей - шиной сообщений - в корне неверно.

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

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

На тучи сообщений уже накалывались.

точно также как и на тучи интерфейсов. Всего должно быть в меру.

почти все на сях, яве и скриптах.

сорри, C# как то незаслужено забыт

Можно было еще и форт или Ruby вспомнить

Для начала нужно иметь хотя бы 5 человек которые бы работали совместно над одной задачей относительно продолжительное время. Или?

Для начала надо определить проблемы, с которыми вы хотите бороться. Чтобы найти решение именно для этих проблем. И пытаться продать это решение руководству.

В один момент я "разбираюсь" только с одним модулем и все сообщения "сидят" внутри одной программы.

Во-во. Типичный ответ на вопрос "а почему ты не посмотрел что точно такое же сообщение уже бросает другой модуль".Хм... Или мы под шиной сообщений понимаем разные вещи. Я думал у вас модули друг с другом общаются сообщениями.

А вот что вы под " все сообщения "сидят" внутри одной программы" имели в виду я, честно говоря, не понял.

Есть интерфейс - декларация и должна быть имплементация.

Имплементция меня не интересует. Их может быть 1 а может быть 100. Когда декларируешь интерфейс об имплементациях не думаешь.

И наоборот - а если быне было интерфейса, код из класса, его имплементирующего, что, изчез бы? Код был бытак или этак. Так что в решении с контрактом (интерфейсом) вы добавили 1 файл. Сам интерфейс.

точно также как и на тучи интерфейсов.

Про такое не слышал. Основная проблема с интерфейсами, имхо, это то, что ты не знаешь где взять его реализацию. Часто решается применением Dependency Injection. Которая тоже может подкинуть парочку веселых сюрпризов.

сорри, C# как то незаслужено забыт Можно было еще и форт или Ruby вспомнить

Под сями я имел в виду все - от ansi c до c# и objetive c.

Форт с руби... Тогда уж питон. Да и пыхыпы их обоих делает в разы. А так можно и смолтолк, хаскел и смл вспомнить. Свои 0,0001% они имеют.

А если наоборот, тогда как?

----

Тогда не ТДД.

По крайней мере реализация требований написанных тестов может быть не на ООП-языке...

Тогда не ТДД.

Да ты шо, как же без него можна Это так круто, что вначале тесты.

Ладно фиг с ним...

Вот у меня есть допустим требование: начало процесса измерения должно обеспечиваться нажатием кнопки старт

Не доходит как тест на это написать, какой результат он должен проверять?

Для начала надо определить проблемы

никак не пойму почему они должны быть на первом месте? Что это меняет?

Допустим, хотим улучшим качество кода и документации, вы указывали что одно из преимуществ.

Следующее то все равно будет - а что тебе для этого надо?

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

"а почему ты не посмотрел что точно такое же сообщение уже бросает другой модуль"

А другой модуль не может в принципе бросать такое же сообщение, а если сообщение и совпадает, например "ошибка", то реакция все равно может быть другой.

Или мы под шиной сообщений понимаем разные вещи

Я не искал определения, но судя по тому что здесь написано, почти совпадает

https://studopedia.ru/9_122535_shina-soobshcheniy.html

Я думал у вас модули друг с другом общаются сообщениями

А к модулю нет другого пути или послать ему сообщение или подписаться на его сообщения. Константы еще разрешено пользовать определенные в "заголовке" модуля

А вот что вы под " все сообщения "сидят" внутри одной программы" имели в виду

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

Внутренняя структура программа состоит из различных модулей. Допустим: модуль весов, базы данных, логики работы и пр. Там же "сидит" и менеджер сообщений и все сообщения проходят через него. Иначе говоря, все сообщения между модуля находятся как бы внутри одной программы.

Про такое не слышал

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

Так что в решении с контрактом (интерфейсом) вы добавили 1 файл

совершенно верно, из-за этого и получается минимум 2х "классов"

под с-ями я имел в виду все - от ansi c до c# и objetive c.

как то сложно до этого додуматься. Я бы ожидал от вас какого то понятия типа "процедурные языки"

Не доходит как тест на это написать, какой результат он должен проверять?

-----

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

Только не спрашивай меня как оно определит нажатие физической кнопки,,, :)

Я уже пытался привести примеры.

С примерами у тебя не получилось ;)

Когда был проект "с тестами" был специальный "ночной тест" на пару часов вроде, а может и больше, уже не помню.

Тесты в этом проекте не были юнит-тестами. Это было все что угодно, интергационные или системные тесты, но не юнит-тесты. Юнит-тесты быстрые. Всегда. Если юнит-тест долго исполняется, то это с вероятностью 99% не юнит-тест и с вероятностью 1% - плохой тест (и его надо переделать)

А если не существует понятия "выпустил интерфейс"?

Тогда ты пишешь либо самую первую версию, либо в стол.

Есть проекты А,Б,С которые используют "стандартную" либу Х (забудем даже что их имеется несколько взаимосвязанных)
Продукты "меняются" очень неравномерно А довольно часто, Б реже, а С раз в пару лет может быть. Соответственно Х может меняться довольно часто.
Есть одно важное требование - А,Б,С должны компилироваться в любой момент времени без ошибок и не требовать повторного тестирования.
Решения?

Решение - не нарушать обратную совместимость.

Не совсем понятно, что ты понимаешь под "не требовать повторного тестирования"? Перед каждым релизом нужно в любом случае проводить полный тест. А вот в процессе разработки можно исходить из того, что библиотека Х работает правильно и так, как от нее ожидают проекты А, Б и С и, соответственно, в процессе разработки этих продуктов библиотека Х вообще никак не используется. Просто потому что, описанные для библиотеки Х требования (контракты) известны всем проектам и они (проекты) используют именно эти контракты.

Что нужно, чтобы все это работало:

1) Нужен контроль за версиями релизов библиотеки Х.

2) Нельзя изменять существующие контракты.

3) Можно добавлять новые контракты.

А также раздумья как передать инфу из модуля А в модуль Б - так как они не имеют и не должны иметь "прямой связи".

Если между модулами А и Б нет прямой связи, то ничего не надо передавать из А в Б ;) Что-то ты тут пытаешься мудрить ;)

Был на одном проекте любитель интерфейсов. Практически все классы имели "зеркальный" интерфейс, вся иерархия классов почти дублировалась иерархией интерфейсов и т.п. и т.д.

Ну заставь дурака богу молиться ;)

Но тут проблема простая - юнит тесты работают, а система все равно сбоит.

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

Как начав с тестов получить структуру классов.

TDD описывает использование контрактов. Что там у тебя за структура классов - никто не знает. Но при этом, используя TDD разработчик вынужден заранее продумать как используемые интерфейсы, так и структуру классов. Более того, при написании теста все эти интерфейсы и классы автоматически проверяются на понятность и простоту использования.

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

Конечно! Так же как если ты писал этот код по Pflichtenheft, то вместе с кодом придется тебе выкидывать текст из Pflichtenheft, апдейтить Wiki и бог знает какие еще действия, чтобы обновленные код соответствовал существующей документации.

никак не пойму почему они должны быть на первом месте? Что это меняет?

Это меняет отношение к предлагаемому новшеству. На "а давайте сделаем ещё лучше!" вы в 99,9% получите ответ "а зачем?".

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

Допустим, хотим улучшим качество кода и документации, вы указывали что одно из преимуществ.

Следующее то все равно будет - а что тебе для этого надо?

Ну если вы ко мне с таким придёте и в ответ на "что тебе для этого надо" скажете "скрам!" - я вас выгоню. Может не ссаными но тряпками.

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

-----

Для этого, как не сложно это для понимания, надо именно терять заказчиков.

Ну, видимо, наличие отсутствия процесса до нажатия кнопки

И что мне это даст? А если процесса нет?

Тесты в этом проекте не были юнит-тестами - Юнит-тесты быстрые. Всегда.

Странная у вас логика. Если я тестирую например функцию y=f(a,b,c) - это будет юнит тест или нет?

А если функция вычисляется от нескольких секунд до нескольких минут это быстро или нет.

А если каждый параметр вариируется с шагом 0.5 или с шагом 0.01 будет разница или нет?

Тогда ты пишешь либо самую первую версию, либо в стол.

Может тогда определимся с понятием "выпустил интерфейс"?

Решение - не нарушать обратную совместимость.

и тогда все будет шоколадно?

что ты понимаешь под "не требовать повторного тестирования"?

Проект "А" был оттестирован 3 года назад, теперь мне его надо просто компильнуть по новому, заказчик имя фирмы поменял.

1) Нужен контроль за версиями релизов библиотеки Х.

Git подойдет? Плавно переходим к сопутствующей проблеме.

Либа Х лежит в репо1, проект С в репо2 нужна одна новая ветка, так как менятся будет и то и другое

2) Нельзя изменять существующие контракты.

А если нужно тогда как? делать новые интерфейс IAbc2?

Если между модулями А и Б нет прямой связи, то ничего не надо передавать из А в Б

заказчику объяснить сможете отчего его хотелку нельзя сделать?

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

примерчик мона? Простейший пример, есть прога, нужно ввести число А и Б, по нажатию кнопы получить сумму. Все должно происходить "на экране" - "визуально"

и бог знает какие еще действия

И что все удается держать синхронно?

Это меняет отношение к предлагаемому новшеству.

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

А вот предложение "а давайте исправим проблему, из-за которой мы в прошлом году 2-х заказчиков потеряли"

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

Потерять заказчика можно только из-за цены.

скажете "скрам!" - я вас выгоню. Может не ссаными но тряпками.

Вот для этого я хотел список минимальных "требований" для скрама

Поднимите CI которое будет гонять юнит тесты после каждой правки

Как вы это себе представляете для Х проектов? Постоянно подключать новые проекты и отключать старые? А что делать если интернета нет у заказчика для нас? Никто не пускает сторонних в локальную сеть, гостевой влан есть далеко не всегда, а для позвонить нужно идти на улицу.

Начните мерять покрытие кода тестами.

Был такой бзик на одном проекте.

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

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

И не совсем понятно какие технические проблемы вас интересуют. С чем бороться хотите?

Это в принципе не может быть из-за софта ... Хотя без софта это всего лишь груда металла.

Имхо тут противоречие... Вы уж определитесь.

Потерять заказчика можно только из-за цены.

А если вы к назначенному сроку софт не сделаете? Заказчик удовлетворится грудой металла? А стоимость разработки софта на цену проекта не влияет?

Как вы это себе представляете для Х проектов? Постоянно подключать новые проекты и отключать старые?

Нет, постучите в бубен и оно само всё сделается. Конечно подключать новые и отключать старые. Непонятно почему вас это пугает. У вас что, по 300 новых проектов в день появляется?

Был такой бзик на одном проекте.

Вот-вот. Тут бзик, там не надо, тут зачем это. У вас идеальная разработка идеальных проектов, которые не надо тестировать, не надо документировать и вообще - из-за софта заказчиков не потеряете, так что можно даже эти идеальные проекты вообще не делать. Вам скрам противопоказан.

И вообще скрам придумали учёные чтобы было что преподавать, на самом деле он никому не нужен и нигде не помогает. Как TDD и всё остальное, что вы в данный момент не используете.

это будет юнит тест или нет?

-----

Нет,

Если я тестирую например функцию y=f(a,b,c) - это будет юнит тест или нет?

Может будет, а может и нет. Зависит от того, что именно происходит в этой функции.

Пусть a - канал связи (не важно, Ethernet или COM), b - массив данных, с - количество данных, которые надо передать, y - результат передачи.

Так вот, если ты для a передашь реальные канал связи, то это уже совершенно точно никакой не юнит-тест.

А если функция вычисляется от нескольких секунд до нескольких минут это быстро или нет.

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

А если каждый параметр вариируется с шагом 0.5 или с шагом 0.01 будет разница или нет?

Не понял, какое влияние на функцию оказывают изменяющиеся параметры? Что именно ты хочешь тестировать?

Может тогда определимся с понятием "выпустил интерфейс"?

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

и тогда все будет шоколадно?

Как минимум решит большую часть проблем.

Проект "А" был оттестирован 3 года назад, теперь мне его надо просто компильнуть по новому, заказчик имя фирмы поменял.

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

Git подойдет?

Подойдет конечно. Надо только придумать, как там отслеживать "релизнутые" версии, например ставить тэги.

Либа Х лежит в репо1, проект С в репо2 нужна одна новая ветка, так как менятся будет и то и другое

Ты про разделение ответственности что-нибудь слышал? Либа Х, очевидно, является компонентой для проекта С. Значит работа должна выстраиваться так:

1) проект С создает требования для либы Х

2) либа Х реализует эти требования, производит тестирование по требованиям и выпускает (делает release) версия X.Y.1

3) проект С берет выпущенную версию либы Х и делает свои изменения.

В принципе, можно подойти к этому процессу не так строго и разрабатывать параллельно, т.е. проект С может базироваться на nightly build'е либы Х... но разработка либы Х все равно остается независимым от проекта С процессом. В то время как разработка проекта С зависит от либы Х. Короче говоря, либа Х как была в своем репо1, так и остается, также как и проект С и нет ни одной причины сливать их в одну ветку.

А если нужно тогда как? делать новые интерфейс IAbc2?

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

заказчику объяснить сможете отчего его хотелку нельзя сделать?

Я не понимаю проблемы. Если между А и Б нет никакой связи, то, соответственно, нет и информации. Т.е. либо делается связь, либо объясняешь почему эту связь нельзя сделать. В чем тут проблема?

примерчик мона? Простейший пример, есть прога, нужно ввести число А и Б, по нажатию кнопы получить сумму. Все должно происходить "на экране" - "визуально"

Примерчик чего? Примерчик тестирования функции, которая считает сумму?

Я бы сделал такое приложение на WPF. Соотвественно мне нужно было бы 1) ModelView (которое не надо было бы тестировать в виду отсутствия логики) 2) односторонний конвертер string to int (2 теста) и 3) модель с 1 функцией (для суммы одного теста будет достаточно). Для того, чтобы проветить, что все работает можно было бы сделать системный тест, который бы запускался ночью и кликал бы в нужные места.

И что все удается держать синхронно?

Нет конечно! В этом и прелесть тестов, что при изменении логики ты вынужден синхронизировать тесты.

Потому что в данный момент вы пытаетесь заставить меня продать вам скрам

Вообще то я никого на форумах ни к чему не принуждаю

Меня интересуют "технические проблемы" скрама....

То бишь, правила когда лучше применять, что для этого требуется, какие плюсы получаются при применении и т.п. Иначе говоря получить ясную картину о методологии, как впрочем и об остальных затрагиваемых темах.

А если вы к назначенному сроку софт не сделаете?

Такого не может быть в принципе - он может работать не совсем так или даже вылетать но для этого и есть inbetriebnahme.

Да и во многих случаях софт можно проверить только по месту, особенно когда к базе заказчика нужно подключаться

А стоимость разработки софта на цену проекта не влияет?

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

Непонятно почему вас это пугает

Временем и бессмысленностью, Зачем мне "СИ проект" на неделю или месяц?

на самом деле он никому не нужен и нигде не помогает

Это вы уже по гиперболе пошли - у нас метод "необходимой достаточности", что происходит у других я и пытаюсь понять.

Вообще то я никого на форумах ни к чему не принуждаю

Это вам так кажется.

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

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

Как-то так.

Такого не может быть в принципе - он может работать не совсем так

Круто. А если робот - манипулятор вместо того, чтобы брать коробочку, будет фигячить по ней кулаком это тоже "работает не совсем так"? :)

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

Ну. Опять же - вам не важно качество, документация, скорость разработки, возможность заменить программиста если один заболел или попал под машину... Потому что софт - всего 10 процентов от стоимости аппаратного комплекса. Только почему-то мне кажется что при этом забывается, что "без софта это груда металла".

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

Временем и бессмысленностью, Зачем мне "СИ проект" на неделю или месяц?

Ну вы же зачем-то хотели поднять качество кода на неделю или месяц. Хотя и правда, зачем оно...

что происходит у других я и пытаюсь понять.

Хм... Это каким же способом? Пытаясь переложить всё на свой опыт, про который я сказал что тут скрам не нужен? Не получится. Сложно понять что происходит у других в каждом втором предложении утверждая "так не бывает, потому что такого у нас нет, это ерунда, нам не надо, это бессмыслица".

Зависит от того, что именно происходит в этой функции.

скажем так - некая математическая функция. Все параметры вещественные числа.

Я таких функций еще ни разу не встречал.

Это не страшно, я тоже много чего не встречал. Гляньте хотя бы время вычисления "функций" класса NP или даже тригонометрическую функцию вызовите достаточное число раз.

я уверен, даже сложные расчеты можно поделить на части и протестировать отдельные элементы

У меня такой уверенности нет, но я не математик. Это они могут сказать возможно ли это и есть ли в этом смысл

Не понял, какое влияние на функцию оказывают изменяющиеся параметры?

http://nunit.org/docs/2.5/range.html

Так более понятно?

Выпустил интерфейс - это значит, что библиотека/сборка, в которой находится интерфейс получила свою версию

А если интерфейс находится в самом приложении тогда как? Или сборка предназначена исключительно для одного приложения?

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

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

Надо только придумать, как там отслеживать "релизнутые" версии, например ставить тэги

Это еще одна интересная проблема, особенно когда кто то успел "вклиниться". А как заказчик мне скажет прога с каким тэгом у него стоит?

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

Либа Х, очевидно, является компонентой для проекта С

либа Х является общей для Y проектов и если нужно делать серьезные изменения, то мы всегда делаем новую ветку.

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

Т.е. либо делается связь, либо объясняешь почему эту связь нельзя сделать. В чем тут проблема?

Для начала, второй вариант абсолютно непригодный. Заказчика не интересует как была построена твоя программа.

Остается именно искать как "правильно" сделать связь. Очень увлекающее занятие, особенно когда прога не твоя и результат нужен "завтра утром".

Примерчик чего? Примерчик тестирования функции, которая считает сумму?

нет, как написав вначале тесты я получу "классное" приложение. Никак не доходит смысл TDD подхода именно для создания приложения, а не кучи функций.

Соотвественно мне нужно было бы

А зачем мне для данного приложения MVVM?

Я сделаю "рыбу" - дополните? Просто интересно, я бы по другому делал. Но с WPF я начал относительно недавно.

Нет конечно! В этом и прелесть тестов, что при изменении логики ты вынужден синхронизировать тесты.

Тогда зачем держать столько Доков.

А в чем же конкретно прелесть?

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

Я с самого начала именно это и сказал

А если робот - манипулятор вместо того, чтобы брать коробочку, будет фигячить по ней кулаком

Опять таки, подобного никак не может быть, по многим причинам. Начиная с той, что роботы мы не программируем. Но даже программисту робота нужно будет очень постараться, чтобы добавить подобную функцию.

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

То бишь чудо скрам метод принесет это все на тарелочке с голубой каемочкой - так это нужно понимать?

Сложно понять что происходит у других в каждом втором предложении утверждая "так не бывает

А что, если я буду со всем соглашаться так я пойму быстрее?

Тест проект

Прикреплённые файлы

Я с самого начала именно это и сказал

А зачем мы с вами тогда так долго беседуем? Консенсус. Вам скрам не нужен, все разошлись.

Но даже программисту робота нужно будет очень постараться, чтобы добавить подобную функцию.

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

То бишь чудо скрам метод принесет это все на тарелочке с голубой каемочкой - так это нужно понимать?

Аскс! Выходишь в поле ночью, зарываешь 10 тысяч евро монетами в поле, посыпаешь солью говоришь три раза "скрам приди - проблемы забери" и ждёшь пока вырастет качество кода, документация и новые программисты. И, что характерно, всё на тарелочках да с голубыми каёмочками. А там только собирай! А то перезреют и убегут к конкурентам. Именно так это и работает.

А что, если я буду со всем соглашаться так я пойму быстрее?

Не-а. А вот если начнёте пытаться понимать - то да.

скажем так - некая математическая функция. Все параметры вещественные числа.

Расчет некой математической функции безусловно можно протестировать юнит-тестами.

Это не страшно, я тоже много чего не встречал. Гляньте хотя бы время вычисления "функций" класса NP или даже тригонометрическую функцию вызовите достаточное число раз.

Толи лыжи не едут, толи я ... :)

Пусть у тебя задача подобрать пароль из 8 случайных символов, задано, что пароль может состоять только из латинских букв и цифр и является case sensitive. Итого у нас алфавит 26*2+10=62 символа получается около 8лярдов комбинаций, т.е. это достаточно долгая функция.

Можно ли ее протестировать быстро?

Безусловно да. И делается это так:

1) у нас есть некий интерфейс, за которым есть определяющий правильность пароля модуль

2) у нас есть наша функция.

Что мы делаем:

1) делаем фейк-модуль.

2) делаем 1-й тест: наша функция посылает пароль "аааааааа" и получает от фейка - ОК, после чего функция завершается и возвращает "аааааааа". Тест проверяет, что возвращенная функция именно "аааааааа".

3) делаем 2-й тест: наша функция посылает пароль "аааааааа" и получает от фейка - FAIL, посылает пароль "аааааааb" и получает от фейка - ОК, после чего функция завершается и возвращает "аааааааb". Тест проверяет, что возвращенная функция именно "аааааааb".

4) делаем 3-й тест: нам надо убедиться, что наша функция полностью проходит по словарю и генерит все возможные варианты. Для это мы делаем следующее: а) надо надо сделать возможным заинджектить словарь (например выделив его в виртуальную функцию или сделать инициализацию в протектед конструкторе) и б) нам надо добавить возможность установления длины пароля. В тесте мы устанавливаем длину пароля в 2 символа, и устанавливаем словарь, скажем, в "aA1", фейку говорим, что он всегда должен возвразать FAIL. Проверяем, что фейк был вызван ровно 9 раз, также проверяем, что фейку были переданы пороли "aa", "aA", "a1",... "11".

5) 2-й тест можно удалить

6) можно добавить тест, который бы проверял настройки по умолчанию, т.е. полный алфавит и что длина пароля именно 8 символов.

Очевидно, что несмотря на то, что задача по подбору пароля - занимает много времени, тесты будут работать быстро ;)

Так более понятно?

Это синтаксический сахар, который позволяет параметризировать тест. Фактически, это несколько тестов, каждый из который быстр.

А если интерфейс находится в самом приложении тогда как?

Какая разница где? Приложение все равно имеет версию.

Или сборка предназначена исключительно для одного приложения?

Если сборка предназначена для одного приложения, то проблема обратной совместимости отсутствует.

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

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

Мне кажется, что ты сам не знаешь уже какую бы проблему придумать ;)

Это еще одна интересная проблема, особенно когда кто то успел "вклиниться".

Что значит "кто-то успел вклиниться"? У каждой компоненты своя ветка. Никаких вклиниваний там быть не может. В конце-концов, человечество изобрело code freeze.

А как заказчик мне скажет прога с каким тэгом у него стоит?

У заказчика есть номер версии. Теги заказчику ни к чему. Мэпить номер версии за тэг должен исполнитель, т.е. ты.

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

Гит умеет искать и по тэгам и по комментариям. Зачем нужно завязываться на хэш коммита я не понимаю.

либа Х является общей для Y проектов и если нужно делать серьезные изменения, то мы всегда делаем новую ветку.

Ну можно себе в ногу стрелять. Почему бы и нет?

Никак не доходит смысл TDD подхода именно для создания приложения, а не кучи функций.

В чем разница? Приложение же состоит из функций...

А в чем же конкретно прелесть?

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

Чтобы продемонстрировать работу NSubstitute я домавил еще пару тестов для ViewModel'и. Тесты эти проверяют, что проперти правильно устанавливаются и уведомляют WPF о том, что можно обновить Bingings.

Прикреплённые файлы

NSubstitute

Спасибо, еще не слышал. Начну с примера пожалуй.

пока студия обновляется.....

А вы что еще на НЕТ4.0 должны сидеть? Отчего проперти "по старинке" обновляете с именем?

В чем смысл инициализации viewmodel в XAML?

А зачем мы с вами тогда так долго беседуем?

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

Как будет чуть больше времени попробую систематизировать Ваши заметки.

Придумайте сами, что у вас может пойти не так из-за ошибки в вашем коде.

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

Кстати, вылет (OutOfMemory) до сих так и не удалось повторить. И тулзами гонял и "счетчик памяти" установил - не растет зараза и все.

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

Вот даже примерчик, для вас:

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

А вот если начнёте пытаться понимать - то да

А что Вы можете как то измерить логику другого человека?

Что еще осталось непонятным:

-зачем нужен конвертер, если и так работает - пример

-зачем проверять проперти если можно обеспечить имя "автоматом" (nameof или атрибутом)

Прикреплённые файлы

Очевидно, что несмотря на то, что задача по подбору пароля - занимает много времени, тесты будут работать быстро

А какой смысл в тестирование фейка? Как же покрытие функции да и правильность результатов расчета?

Фактически, это несколько тестов, каждый из который быстр.

ну да 3 по 10 этого только тысяча, а 3 по 100 уже миллион

Если сборка предназначена для одного приложения, то проблема обратной совместимости отсутствует.

Так именно об этом я и говорил.

используемые компоненты должны быть закомичены в виде бинарников

ой, не хочется открывать новую дискуссию.

Берешь известную версию и собираешь продукт.

Для этого ее нужно иметь. Часто попадалось, что забывают/ешь все репо пометить.

Мне кажется, что ты сам не знаешь уже какую бы проблему придумать

А их не нужно придумывать, они сами появляются.

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

У каждой компоненты своя ветка. Никаких вклиниваний там быть не может

А что ни "мастера" ни "девелопмент" у вас нет?

Мэпить номер версии за тэг должен исполнитель, т.е. ты.

Как часто это нужно делать и как быть уверенным, что не допустил ошибки?

Зачем нужно завязываться на хэш коммита я не понимаю

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

Ну можно себе в ногу стрелять

А в чем ошибка делать новые ветки для изменений?

Приложение же состоит из функций...

У кого как. У меня в голове приложение прежде всего "состоит" из объектов и потоков данных. И пока не соберутся правильные объекты до функций особого дела нет.

А что Вы можете как то измерить логику другого человека?

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

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

А вы что еще на НЕТ4.0 должны сидеть?

Мы да, сидим на .Net 4.0

Отчего проперти "по старинке" обновляете с именем?

По привычке.

В чем смысл инициализации viewmodel в XAML?

Зачем писать код, когда можно засунуть в XAML? :D

-зачем нужен конвертер, если и так работает - пример

Ну для инта не нужен (хотя помню у меня как-то были проблемы и я должен был сделать конвертер, но условий уже не помню).

-зачем проверять проперти если можно обеспечить имя "автоматом" (nameof или атрибутом)

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

Ну и плюс к этому ты узнал о NSubstitute :)

А какой смысл в тестирование фейка?

Фейк никто и не тестирует. С чего ты это взял?

Как же покрытие функции да и правильность результатов расчета?

Покрытие данной функции будет максимально возможное. Ну и правильность соответственно. Какая разница генерить пароль в 2 символа или в 8? Правила одинаковые, логика тоже.

ну да 3 по 10 этого только тысяча, а 3 по 100 уже миллион

Ты это к чему?

Часто попадалось, что забывают/ешь все репо пометить.

Это потому что у вас нет процесса "релиза". С чек листом и четкой последовательностью действий :)

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

К тому же у вас, судя по всему, нет вменяемой системы сборки готовых продуктов.

А что ни "мастера" ни "девелопмент" у вас нет?

Есть конечно :) Но, в случае, когда либа Х используется несколькими продуктами, то для либы Х свои "мастер" и "девелопмент", а для продукта С - свои :)

Как часто это нужно делать и как быть уверенным, что не допустил ошибки?

Зависит от процессов, кто-то делает метки при каждом handover, кто-то только при release. Чтобы быть уверенным, что не допустил ошибку нужна автоматизация :) Тут уж кто во что горазд. кто-то использует Maven, на моих последних 2-х проектах мы делали такую систему под себя.

А в чем ошибка делать новые ветки для изменений?

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

тесты будут работать быстро ;)

-----

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

Для понимания - в vиндощом полиси есть понятие - число неудачных попыток до блокирования аккаунта.

А знаете как обычно реагирует человек

Иначе говоря - использование стандартного алгоритма во всех случаях, а если нестандартно, то неправильно.

Ну давайте попробуем Ваш путь - CI на 40 часовой проект, какие плюсы я получаю. И также какие минусы, по вашему мнению.

Мы да, сидим на .Net 4.0

У нас тоже долго было, но потом решили, что нефиг ХП больше поддерживать. Да и вин 7 уже тяжело стало найти.

Если вдруг захотите nameof пользовать - она выполняется runtime.

Зачем писать код, когда можно засунуть в XAML?

А если в конструктор параметр надо передать?

Но другой причины нет?

Фейк никто и не тестирует. С чего ты это взял?

так из описания понял.

Какая разница генерить пароль в 2 символа или в 8?

Не знаю особенности данной функции, но часто диапазон имеет решающее значение.

Ты это к чему?

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

Это потому что у вас нет процесса "релиза". С чек листом и четкой последовательностью действий

А можно примерчик вместе с вменяемой системой сборки, чтобы работала на любом компе, в любом месте при ограниченном времени без интернета.

А сливать общую либу со своим продуктом - выстрел себе в ногу

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

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

Возвращаясь к TDD.

Получается "вначале тест" не следует понимать буквально.

А пишем вначале все приложение, а после начинаем с этого?

        [TestMethod]
        public void Sum_2plus2_4()
        {
            // Arrange
            MainModel model = new MainModel();
            // Act
            int res = model.Sum(2, 2);
            // Assert
            Assert.AreEqual(4, res);
        }
        [TestMethod]
        public void Sum_2plus3_5()
        {
            // Arrange
            MainModel model = new MainModel();
            // Act
            int res = model.Sum(2, 3);
            // Assert
            Assert.AreEqual(5, res);
        }

Вот только не доходит чем это мне поможет сделать более лучшую реализацию.

И что говорит теория относительно данного вызова функции?

     [TestMethod]
        public void Sum_Test05()
        {
            // Arrange
            MainModel model = new MainModel();

            // Act
            int res = model.Sum(Int.MaxValue, int.MaxValue);

            // Assert
            Assert.AreEqual(-2, res);
        }

Начал собирать информацию - получил аж 4 страницы ворда. попробую по частям выложить

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

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

Scrum не требует внедрения каких-либо дорогостоящих инструментов. Схему методики Scrum вкратце можно описать следующим образом:

1. Для начала необходимо выбрать «Владельца продукта» — человека, обладающего видением того, что вы собираетесь создать или достигнуть.
2. Затем нужно собрать «Команду», в которую войдут люди, непосредственно выполняющие работу. Они должны обладать навыками и знаниями, которые помогут воплотить идею владельца продукта в жизнь.
3. Нужно выбрать «Скрам-мастера» — того, кто будет следить за ходом реализации проекта, обеспечивать проведение коротких собраний и помогать команде устранять препятствия на пути достижения цели.
4. Приступая к работе, нужно создать максимально полный список всех требований, предъявляемых к продукту или цели. Пункты этого списка должны быть расставлены по приоритету. Список носит название «Бэклог продукта». Он может развиваться и изменяться на протяжении всего срока реализации проекта.
5. Участники команды должны оценить по своей системе оценок каждый пункт на предмет сложности и затрат, которые потребуются для его выполнения.
6. Затем участники, скрам-мастер и владелец продукта должны провести первое скрам-собрание, на котором они запланируют спринт — определенное время для выполнения части заданий. Продолжительность спринта не должна превышать один месяц. За каждый спринт команда нарабатывает определенное количество баллов. Команда должна постоянно стремиться к тому, чтобы превзойти в новом спринте количество наработанных баллов за предыдущий спринт, то есть ее цель — постоянно превосходить свои собственные результаты — «наращивать динамику производительности».
7. Чтобы все участники были в курсе состояния дел нужно завести скрам-доску с тремя колонками: «Нужно сделать, или бэклог»; «В работе»; «Сделано». На доску участники клеят стикеры с заданиями, которые в процессе работы поочередно перемещаются из колонки «Бэклог» в колонку «в работе», а затем в «сделано».
8. Ежедневно проводится скрам-собрание. По выражению Джеффа Сазерленда «это пульс всего процесса Scrum». Суть его проста — ежедневно, на ходу, пятнадцать минут на то, чтобы все дали ответы на три вопроса: «Что ты делал вчера, чтобы помочь команде завершить спринт?», «Что ты будешь делать сегодня, чтобы помочь команде завершить спринт?», «Какие препятствия встают на пути команды?».
9. По завершении спринта команда делает его обзор — проводит встречу, на которой участники рассказывают, что сделано за спринт.
10. После показа результатов работы за спринт участники проводят ретроспективное собрание, на котором обсуждают, что команда делала хорошо, что можно сделать лучше, что можно улучшить прямо сейчас.

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

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

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

Критерии эффективности

• Гибкость. (пожалуй, самый главный) Как часто в процессе разработки будут вносится изменения в требования.
• Организация. Готовы ли вы к изменениям в организации. Если нет - забудьте про скрам, не взлетит.
• Личные качества. Готовы разработчики брать на себя ответственность и принимать решения?
• Размер проекта. Если время разработки проекта 1-2-3 недели - не стоит затеваться со скрамом
• Срок жизни проекта. При малом сроке жизни Скрам не нужен.
• Требования к качеству (понятный, легко изменять) кода / документации.

Эффективность предлагают измерять метриками

http://agilerussia.ru/practices/scrum-metrics/

Аккуратность оценки задачи - Насколько хорошо команда оценивает более детальные куски работы

Влияние затруднений - Угрозы для проекта и возможные причины задержек

Время выгорания – burnout time

Средняя скорость - Размер и количество пользовательских историй (и / или других пунктов бэклога продукта) , которые команда делает в среднем в типичном спринте

Проектное ETD (estimated time of delivery – оценочное время поставки) - Она дает нам грубую оценку (не гарантию) того, когда будет сделан весь бэклог (или если вам так нужно, часть его), базируясь на средней скорости команды

Преимущества

• Программисты в команде через какое-то время действительно станут "взаимозаменяемыми"
• Менеджеры с удовольствием воспринимают что теперь можно каждые 2(3, 4, смотря какая длина спринта) недели меять задания, приоритеты, вносить что-то новое
• в конце разработки продукт будет ближе к хотелкам клиента, которые он в начале не может даже представить, не то что озвучить.
• Цикличностью и постоянным общением с заказчиком (как минимум на ревью)
  • Спринты короткие, по результатам спринта, которые демонстрируются клиенту можно уточнить предыдущие хотелки и получить новые.
  • Модность помогает продать скрам. Убедить клиента что ему НАДО найти время на то, чтобы участвовать в ревью после каждого спринта и на то что ему НАДО обсуждать истории с ПО

Недостатки

• Нудные ежедневные митинги
• Сложности при заключении договоров. Scrum в принципе не подразумевает наличие фиксированного бюджета и фиксированного технического задания, что затрудняет юридическое оформление такого рода договоренностей;
• Большое количество исключений. Специалисты в этой области считают данную методологию неприменимой для работы с государственными заказами, а также совершенно нерабочей при низкой квалификации команды, заниженных сроках работ или бюджете, некомпетентном менеджере проекта. В то время как другие методологии позволяют завершить проект при подобных условиях, хотя и на низком уровне;
• Узкая специализация методов. Так, например, если использовать Scrum при разработке сайтов, этапы дизайна и контента уже будут выходить за рамки методологии и требовать совершенно иного подхода.

Требования к реализации

1 роль скрам мастера (СМ) - это тот, кто следит за ходом проекта и помогает команде решать проблемы.

1 роль продукт овнера (ПО, владелец продукта) - тот, кто решает вопросы концепции продукта и составляет бэклог

5-7 ролей разработчика - скрам-команда — исполнители конкретных проектов

Полная команда:Минимум 6 человек, максимум 9

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

Роль СМ может и должен выполнять один из разработчиков.

Больше инфо –ссылки:

Иллюзия эффективной разработки

https://habr.com/post/151294/

Scrum. Революционный метод управления проектами». Книга за 15 минут

https://habr.com/company/makeright/blog/297250/

ТОП-10 ошибок, которые делают 90% Scrum-команд

https://scrummasters.com.ua/blog/top-10-fails-of-scrum-teams

Скрамгайд 2017

https://blog.sibirix.ru/2017/12/26/scrumguide2017/

А если в конструктор параметр надо передать?

Если надо передать параметр, то это уже другой разговор. А зачем писать лишний код, когда параметры не нужны? :)

так из описания понял.

Тестируется функция, которая генерит пароли (aka последовательности символов).

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

Это да, но количество вызовов не долго сказываться на работе самой функции. А если такие зависимости есть, то надо думать как их тестировать.

А можно примерчик вместе с вменяемой системой сборки, чтобы работала на любом компе, в любом месте при ограниченном времени без интернета.

Все смешалось кони, люди :D

Одна из подобных систем - Maven. Как я уже говорил, на последних двух местах работы я занимался разработкой подобных систем. Там процессы были "зашиты". У нас было много команд, которые делали свои компоненты. Компоненты разрабатывались в разных командах и независимо друг от друга. Там, где были логические зависимости (компонента А использует компоненту Б) мы делали соответствующую запись в БД. Таким образом продукт собирался из "верхних" компонент, а все "нижние" компоненты автоматически включались в продукт. Надо сказать, что работали мы исключительно с готовыми бинарниками (т.е. в репозиторий коммителись уже готовые бинарники). Ну а дальше все просто, у каждого компонента есть статус. И есть определенная цепочка прохождения по статусам. Например "Build Successful -> In Test -> Test Successful -> Aproved -> Released" или "Build Successful -> In Test -> Test Failed" или "Build Successful -> In Test -> Test Successful -> Rejected" ну и так далее, там много было цепочек. Кроме того, у каждой компоненты был тип: Alpha, Beta, Release Candidat, Release. Ну и дальше надо было собрать продукт (инсталлятор), для этого некий менеджер говорил "собрать продукт типа Release со статусом Released" и вжжжжжжик все компоненты собирались :) Новые версии могли создавать только те люди, которые разрабатывали компоненту, менять тип и статус - тоже.

Сначала коллеги конечно возмущались, что мол они всегда не так работали, а тут новая система, но потом поняли, что так лучше, чем "завтра надо отправлять клиентам, поэтому работает до 6 утра" :)

Очевидно, что на любом компе, в любом месте и без интрАнета работать это и не будет. Собственно говоря и не должно, т.к. продукт собирается на фирме и система сборки продукта - это часть инфраструктуры разработчика. Заказчику с этой системой работать не нужно, а потому требования о "любом компе, любом месте и без интернета" не состоятельны.

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

Как ты говорил, либа Х используется как продуктом А, так и продуктом Б. Очевидно, что если каждый раз переносить все то в один продукт, то в другой (особенно если продукты эти развиваются параллельно), то встанет вопрос синхронизации либы Х. А это значит постоянные мерджы и конвликты в либе Х. Плюс к этому вечный риск того, что та или иная фича будет реализована в версии для продукта А и не будет реализована в версии для продукта Б. А это значит, что каждый продукт должен с особенной тщательностью. Я уж не говорю о том, что версии либы Х в разных репозиториях (и с разным функционалом) могут совпадать. Тогда вообще хвостов не найдешь.

Получается "вначале тест" не следует понимать буквально.

Желательно понимать буквально. Но мы живем в реальном мире :D

В идеальном мире сначала пишется тест Sum_2plus2_4 (), а функция Sum выглядит так:

public int Sum(int v1, int v2)
{
  return 4;
}

Потом добавляется тест Sum_2plus3_5() и функция Sum видоизменяется до:

public int Sum(int v1, int v2)
{
  return v1 + v2;
}

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

Вот только не доходит чем это мне поможет сделать более лучшую реализацию.

Простой пример: у тебя есть некий енкодер, который получает строку, шифрует, скажем DES'ом, ее и отправляет по COM-порту.

И вот этот энкодер написан:

public class SomeEncoder
{
  public void EncodeAndSend (string message)
  {
    using (DESCryptoServiceProvider cryptic = new DESCryptoServiceProvider())
    {
      cryptic.Key = ASCIIEncoding.ASCII.GetBytes("ABCDEFGH");
      cryptic.IV = ASCIIEncoding.ASCII.GetBytes("ABCDEFGH");
      using (MemoryStream ms = new MemoryStream())
      {
        using (CryptoStream crStream = new CryptoStream(ms, cryptic.CreateEncryptor(), CryptoStreamMode.Write))
        {
          byte[] data = ASCIIEncoding.ASCII.GetBytes("Hello World!");
          crStream.Write(data, 0, data.Length);
          SerialPort comPort = new SerialPort("COM1");
          comPort.Write(Encoding.Default.GetString(ms.ToArray()));
        }
      }
    }
  }
}

Теперь надо протестировать эту функцию... В том виде, как она есть сейчас протестировать ее юнит-тестом невозможно.

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

Делаем интерфейсы:

public interface ICrypt
{
  byte [] Crypt (string message, string key);
}

public interface ITransport
{
  void Send (byte [] data);
}

Теперь изменяем наш класс:

public class SomeEncoder
{
  private ICrypt Crypt { get; set;}
  private ITransport Transport{ get; set;}

  public SomeEncoder (ICrypt crypt, ITransport transport)
  {
    Crypt = crypt;
    Transport = transport;
  }
  public void EncodeAndSend (string message)
  {
    byte [] cryptData = Crypt.Crypt ("Hello World!", "ABCDEFGH");
    Transport.Send (cryptData);
  }
}

После таких изменений функция поддается тестированию.

Стал ли наш код лучше? Однозначно да! Во-первых, он стал тестируем. Во-вторых, он сразу стал расширяемым, т.к. мы теперь не завязаны ни на алгоритм шифрования, ни на COM порт.

И все это благодаря юнит-тестированию :)

И что говорит теория относительно данного вызова функции?

А что тут говорить? Это обычный юнит-тест на поведение при пограничных значениях. Так сказать тест на отказоустойчивость.

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

Это видимо у вас так. А у нас именно так как я описал.

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

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

Очевидно, что если каждый раз переносить все то в один продукт, то в другой

В том то и смысл что этого делать не нужно ни в коем случае.

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

Плюс к этому вечный риск того, что та или иная фича будет реализована в версии для продукта А и не будет реализована в версии для продукта Б

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

Стал ли наш код лучше? Однозначно да!

Почему обязательно однозначно?

Первую функцию можно обозреть за довольно короткое время, во втором случае нужно вначале пройтись по всем частям.

Во-вторых, он сразу стал расширяемым, т.к. мы теперь не завязаны ни на алгоритм шифрования, ни на COM порт

Зачем делать то, что никогда не понадобится.

И все это благодаря юнит-тестированию

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

Ну разве, что одна функция не должна делать две разных задачи, но это пример, понятно.

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

Проверить работу софта без реального оборудования довольно затруднительно, так что основная работа происходит у заказчика.

Да это всегда пожалуйста! Но ведь это не значит, что собирать продукт тоже надо у заказчика ;) К заказчику надо ехать уже с готовым.

Продукт на фирме собирать практически бессмысленно.

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

Первую функцию можно обозреть за довольно короткое время, во втором случае нужно вначале пройтись по всем частям.

Вторую фунцию обозреть еще проще, т.к. всего две строчки. Шифруем и отсылаем. Функция эта больше ничего не делает и во втором варианте это читается. А в первом слишком много букв.

Зачем делать то, что никогда не понадобится.

Зачем, что это побочный эффект.Самое важное заключается в том, что 2-й вариант поддается тестированию, а 1-й - нет. А расщиряемость - это приятный бонус.

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

Зря не заметил. Все изменения я вроде бы объяснил. Интерфейсы я ввел для того, чтобы можно было делать Dependency Injektion. Используя интерфейсы мы можем лучше протестировать саму функцию и ее реакцию на ошибки. Например, ты задолбаешься тестировать поведение функции из 1-ого варианта, в случае если не получилось передать все данные (например если выдернули провод), используя DI это тестируется на раз. Кроме того, передача данных по реальному каналу (он еще должен быть! у меня на ноуте COM порта вообще нет) может занимать много времени, да и шифрование тоже может долго длиться, а нам надо протестировать енкодер. При этом нам не надо тестировать ни DESCryptoServiceProvider ни SerialPort - они работают правильно.

Так что изменения были вызваны исключительно необходимостью протестировать енкодер.

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

Все зависит от мотивации. Если бы ты сказал, что тебе это для тестирования, то врядли кто-нибудь стал бы возражать, что мол тестировать нам не надо :)

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

Помню, на прошлом проекте у нас один из клиентов разбил диск на партиции и партицию D скрыл правами доступа. Так, что видимые партиции у него были С и Е. А наша праграмма запрашивала все биски у системы, отфильтровывала fixed drives и если там был диск D, то мы использовали его для данных. И вот везде это годими работало, а у это клиента нет (диск находился, но при обращении к нему кидалось исключение). Понятно, что можно взять PC , разбить диск, закрыть D и протестировать работу (или поехать к клиенту и протестировать у него), но это все очень затратные способы. Я решил эту проблему юнит-тестом. Просто сделал обертку и кидал исключение. Все. Быстро и надежно. И никто никогда не удалит "непонятный код", т.к. есть тест и тест этот станет красным если удалить код.

Так что надобность в описанных мною изменениях в том, чтобы код был тестируем.

К заказчику надо ехать уже с готовым

Эти голубые мечты у меня тоже были вначале.

Но даже есть это и так, есть интернет стики и VPN

А в Китае не довелось бывать?

Пока пользовался VPN вечером из отеля какое то время работало. Как попользовался днем, все - заблокировали. Гугла там тоже нет, кстати.

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

Вторую фунцию обозреть еще проще, т.к. всего две строчки

Это смотря с какой стороны подойти. В первом случае сразу видно что СОМ порт и как пересылается и что там еще ошибка есть, а во втором случае надо это все искать.

Я не могу сказать априори какая функция лучше, все зависит от конкретной ситуации. И относительно тестирования тоже.

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

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

И если в одном варианте меня волнует, а что будет если шнур выдернут или неправильные данные придут, то во втором это просто не интересует.

у меня на ноуте COM порта вообще нет

Для это есть "сумочка" там переходник "УСБ-СОМ порт", есть еще и виртуальный СОМ порт

Если бы ты сказал, что тебе это для тестирования, то врядли кто-нибудь стал бы возражать

Могли бы и манунг кинуть - нецелевой расход рабочего времени и как следствие невыполнение задания в срок

но это все очень затратные способы

Все проблема в том чтобы понять отчего происходит ошибка у конкретного клиента.

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

Вот у нас на одном устройстве был световой барьер (луч света перекрывается или нет) для обнаружения перемещения кусков материала (довольно длинных кусков)

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

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

Исправилось перемещением датчика. Как это можно было покрыть тестами, я не представляю.

Так что всё очень зависит от конкретной ситуации.

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

Эх, хотелось бы что вы это на практике попробовали, с нашими устройствами и сроками.

Я могу потратить какое то время и написать эмулятор оборудования (кое где он и вправду есть) и прийти к устройству допустим через неделю, когда прога замечательно стала работать после всех тестов.

Но тут вдруг оказывается, что материал при подъеме дрожит сильнее чем предполагалось и сканер дает неправильные данные, а для исправления нужно переделать какую то механическую часть.

А потом оказывается, что данные приходят не так как предполагалось и надо алгоритм переделывать и т.п. и т.д.

А в Китае не довелось бывать?

Меня туда не посылают :D Но основные клиенты у нас в Макао и коллеги регулярно туда ездят. VPN там отлично работает :D

В первом случае сразу видно что СОМ порт и как пересылается и что там еще ошибка есть, а во втором случае надо это все искать.

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

Для это есть "сумочка" там переходник "УСБ-СОМ порт", есть еще и виртуальный СОМ порт

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

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

Забавно :)

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

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

Как это можно было покрыть тестами, я не представляю.

Тестами покрывают свой код, а тут надо было симулировать неправильное поведение датчика. И истелать это в коде гораздо проще, чем в Китае :) Собственно говоря, юнит-тестами отлично тестируются отказы переферии.

Специальный административный район Мака́о

Кстати, в Гонконге все тоже самое и Гугле есть и VPN.

Работа енкодера не зависит от пересылки данных через ком-порт.

А вот программисту нужно быстро получить обзор "состояния дел"

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

Опять таки зачем? (в "данном" конкретном случае)

Если появляется какой-то сбой в программе, то ищется проблема (в логах)

Имелось в виду просто сразу после сообщения об ошибке, логи еще нужно получить.

Т.е. ошибка в коде (если она была, ведь программа таки сбоила) не была исправлена

А можно объяснить какой смысл правки этой ошибки?

Устройство получает сообщение материал начал выход "из зоны", через 10 см материала приходит сообщение материал закончил выход из зоны, через там 0.5 см опять вход - то бишь полная белиберда которая в принципе не может быть. Можно в 2 часа ночи за пивом и на танке поехать - вдруг гранатометом обстреляют, а можно и пешком сходить - всё зависит от окружающей обстановки.

И не поймите меня неправильно - что мол я категорически против всяких тестов. Я всего лишь против "прямолинейного концепта" - вот есть хорошая штука и будем ее пользовать везде и всегда.

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

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

Опять таки зачем? (в "данном" конкретном случае)

Потому что именно реакция на сбои, а также способность восстанавливаться после сбоя, делают программу стабильной.

А можно объяснить какой смысл правки этой ошибки?

Я не могу тебе этого сказать просто потому что я не знаю ни ПО, ни области рименения, ни требований. Однако представь себе, что для того, чтобы поменять местоположение датчика пришлось бы перестраивать половину завода. В этом случае вы бы за милую душу исправили эту ошибку :D

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

до этого теста не надо было бы додумываться. До него додумались китайцы. Тебе надо было бы только симлировать данные, чтобы исправить ошибку и убедиться, что исправление это не будет удалено в будущем :)

делают программу стабильной.

Остается открытым вопрос, а какая нам нужна стабильность и сколько мы готовы за это заплатить?

Был я как то на проекте контроллера управления легковой машиной. Так там пару строчек изменить могло и пару недель длится.

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

Кое кто и на машине с лэптопом ездил на тестовой трассе.

В этом случае вы бы за милую душу исправили эту ошибку

Неа Во первых это не ошибка, а изменение условий эксплуатации, причем неописанных. Так что проблема не наша, хотите изменений - нет проблем делаем дополнение к договору на сумму Х и исправления ваши.

до этого теста не надо было бы додумываться.

Речь то шла о тестах до появления "ошибки", а не после того как стало известно что это за проблема возникла.

Либа Х лежит в репо1, проект С в репо2 нужна одна новая ветка, так как менятся будет и то и другое

git subtree или git submodule

Да не дай бог. Только руки исцарапают.

Просто ветка в "репо1" с новой версией "2.0.0" и ветка в "репо2", в которой будет использоваться 2-я версия.

Я надеюсь в мелкософте с определенными версиями dll-ек линковать не разучились...

Да ладно, ничего особо сложного в этом нет :) хотя интернет пестрит ужасными историями 😀

Если нет необходимости таскать с собой исходники всех либ, можно и бинарники таскать. Только через gut lfs 😀

Во первых это не ошибка, а изменение условий эксплуатации, причем неописанных. Так что проблема не наша, хотите изменений - нет проблем делаем дополнение к договору на сумму Х и исправления ваши.

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

Речь то шла о тестах до появления "ошибки", а не после того как стало известно что это за проблема возникла.

Речь шла о тестировании в целом. "Ошибка", которая стала известна до возникновения проблемы - это известный юз-кейс, и не является ошибкой :)

Да ладно, ничего особо сложного в этом нет :) хотя интернет пестрит ужасными историями 😀

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

Хотя... Я забываю всё время, что мы же о c# на виндусях говорим. Как там зависимости проектов определяются... Может и действительно проще приучить с subtree работать.

git submodule

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

Я пробовал так:

c:\all\systemA\prj1 - локальный репо как главный проект

c:\all\systemA\prj2 - локальный репо как субмодуль

Так зачем же ты тогда привел этот пример в качестве ошибки

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

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

Идея была еще в том, что как бы тесты не писали - подобную ситуацию предугадать довольно сложно. То бишь имея теоретическое 100% покрытие в программе остаются ошибки. Если ошибкой называть все, что работает не ожидаемым образом в любых ситуациях.

"Ошибка", которая стала известна до возникновения проблемы - это известный юз-кейс

так в том то и дело что это будет неизвестный юз-кейс

Prj2 должен быть внутри prj1. На то он и submodule :)

Prj2 должен быть внутри prj1

То бишь если не уставить субмодуль правильно, то весь проект2 попадет в репо проект1?

Я подумал, что это было решение для подобного распределения

c:\all\systemA\prj1 - локальный репо как проект1

c:\all\systemA\prj2 - локальный репо как проект2

c:\all\systemA\lib - локальный репо как библиотека к проекту х

https://git-scm.com/book/de/v1/Git-Tools-Submodule

Спасибо, хотя есть

https://git-scm.com/book/ru/v2/Инст�...

но это 17 страниц примеров, чтобы всего лишь понять принцип работы.

Пока удалось разобраться, что в репо субмодуля создается новая ветка для основного модуля и что основной модуль "полностью игнорирует" каталог субмодуля.

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

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

Ну и готовится к новым проблемам

http://alexanius-blog.blogspot.com/2012/04/git-submodule.h...

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

А я предупреждал что только руки исцарапают :)

Ну эта, молотком тоже можно себе палец отбить :-D

В гите хорошо, что нет ничего необратимого :-D

Похоже надо бинтовать пальцы и пробовать

лучше с subtree играйтесь. Имхо - проще.

тоже похоже не без изъянов

Subtree takes ages to sync, maybe the way we are using is not optimal. Can't remember how long it took last time because no one wants to do it, or just leave it there overnight.

но есть с чем играться

https://medium.com/@porteneuve/mastering-git-subtrees-943d...

Я как бы предупреждал что ни submodule ни subtree непросто использовать.

В 99,9% случаев, когда кто-то за них схватился, их на самом деле не надо было использовать. Просто надо научиться работать с версиями продуктов. И всё.

А кто то пробовал это под виндой?

https://github.com/ingydotnet/git-subrepo#readme

Что за команда "source"?

source /path/to/git-subrepo/.rc

Попробовал поиграться в репо из статьи

http://drive.delicious-insights.com/assets/git-subs-demo.z...

наткнулся на проблему(ошибка в гит?) которая в принципе все пользование субтрее перечеркивает. А именно - если сделать изменения в файле README.md plugin-а, а не как описано, то merge не происходит с main репо, получается конфликт двух "одинаковых файлов" один README.md plugin другой README.md main

Под никсами тоже самое происходит или нет?

Вроде концепт subtree и submodule стали несколько понятнее, но никак не могу найти преимуществ по сравнению с решением держать отдельные каталоги для каждого репо.

Что бы допустим, как в SVN можно было делать коммит сразу в несколько репо

Что за команда "source"?

Встроеная команда bash-а. Под мелкомягким cmd и повершелом работать, соответственно, не будет. Но вместе с git-ом идёт bash под именем git-bash. Вот в нём и под виндусями отработает.

Они добавляют в файл .bashrc строчку "source /path/to/git-subrepo/.rc" чтобы при каждом запуске шела выполнялись команды из /path/to/git-subrepo/.rc - добавляют каталог со своим расширением в PATH.

source filename [arguments]

идёт bash под именем git-bash

спасибо, чёт не подумал.

Глянул репо там одни скрипты, совершенно непонятен принцип "внедрения" новой команды.

Как будет время на работе попробую

эта команда - скрипт git-subrepo, которая лежит в lib. При вызове git abc гит ищет в path-е команду git-abc и запускает её.

Любой исполняемый файл в PATH вида git-blabla дает команду git blabla.

Ага, то есть используется все равно базовый набор команда Гита и все можно сделать и без этого расширения, только допустим за 10 команд, а не за одну.

В принципе, да.

Как пример можно посмотреть набор git flow.

Тогда непонятно где они запрятали в git-subrepo вызовы базовых гит команд.

искал что то подобное git команда ничего не нашел. Или нужно было искать что то другое?

Плохо искали

RUN git filter-branch ...
RUN git rev-parse HEAD ...

да есть такая буква

TTY=true FAIL=false RUN git filter-branch -f

смотрел только строки где git в начале, а что за язы? У файла нет расширения. Хотя по "fi" нашел - Unix Shell Scripts

TTY=true FAIL=false

Переменные окружения устанавливаются для вызова.

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

Мне больше нравится BDD. Помогает сразу дизайнить систему.