SCRUM. У кого на работе считают, что используют?
А почему это должен быть именно скрам?
Потому что мы его обсуждаем. Можно взять другой метод. Можете придумать свой метод, это не сложно. Сложено объяснить зачем он остальным нужен.
На модность абсолютно плевать.
Зря. Я пояснял в чём тут преимущество. Предупреждаю - для ультра-модных пацанов скрам уже не вариант. 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% проектах не нужен.
А как же тогда определить - "Я работю по скраму"
Определишь как "Я работаю с элементами скрама".
зачем еще на это время тратить?
Затем, что доска очень хорошо показывает кто чем занимается и в какой стадии находится, есть ли какие-то проблемы итд.
Зачем мне новые термины, нужен конкретный пример. Не вижу я адекватного определения.
Конкретного примера не будет :) Тут у каждого свой список. Но, я уверен, когда ты говоришь "я это задание выполнил" ты подразумеваешь, что 1) код работает, 2) тесты зеленые, 3) код в репозитории, 4) изменения задокументированы, 5) что-то еще Так что для того, чтобы не было такого, что один подразумевает одно, коллега другое, а шеф третье и предлагается формализовать определение выполненого задания. Все очень просто, не должно быть никаких "это очевидно", все должно быть записано :)
реально что то высчитать достаточно затруднительно.
На самом деле нет. У каждой задачи есть предполагаемое время исполнения и есть фактическое время исполнения, оба этих параметра видны на burn-down chart. И это вполне себе нормальная оценка процесса. Так что глядя на серию burn-down chart'ов можно делать выводы относительно того, как работает команда.
Прежде всего спасибо за поддержку и за ответы.
К сожалению, ситуация не такая простая как может показаться.
Для текущей работы работы Скрам никаким местом не пойдет, может быть только что полезное выдрать.
А вот что будет когда то, еще неизвестно. Да и интересен анализ прошлых проектов. Но в целом, хотелось бы иметь набор неких правил, когда использование скрама эффективно, а также его достоинства/недостатки с точки зрения убеждения руководства.
Сложено объяснить зачем он остальным нужен.
именно в этом и проблема
А откуда вы взяли про каждый день?
не имею понятия, откуда то пришло, что именно "большая скорость показа" дает преимущество.
перевод его требований к качеству кода/документации
Это тоже никак не доходит - как методика может изменить качество кода или добавить документации.
Если разработчик "мыслит" плохим кодом, то изменить это непросто.
Я не знаю что вы имеете в виду под "голым теоретическим скрамом"
Это то о чём можно прочитать, типа этого
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ч/д, при том что через полгода/год нужно все повторять но новому. Смысл?
А так как пришел заказ - разобрался и забыл. Не следует также забывать что без железа прогу то и попробовать нельзя нормально.
И сами закупают себе компьютеры
Ага и держат еще свою ИТ инфраструктуру, секретаршу и бухгалтера.
Такая значит Скрам фирма, вполне допускаю, что может и такое быть. Но меня там уж точно не будет.