Спасибо, наверное вы правы. Я использовал эту аббревиатуру, поскольку не хоте ориентироваться только на круг embedded разработчиков. Мне показалось, что AtoD будет понятнее.
Спасибо за комментарий.
Однако я с вами не согласен.
Сама технология так и называется Internet (не Intranet) of Things.
Конечно это сложнее, конечно больше проблем.
Но и преимущества существенны.
Точно так же нативное приложение на вашем ПК могут прекрасно работать, однако существует и SaaS.
Простите, но вы не внимательно читали :(
Я писал, чем занимаются тимы последние 2 дня — баги из беклога
Что касается 4го, тима, то действительно придется увеличивать размер спринта. Это решение имеет ограничения. Работает в размере общей команды 20-30 человек
Изменения размеров спринта, действительно не предусмотрены, но это не является минусом, на мой взгляд.
Коррективы по праздникам вносятся просто — сдвиг. Остальные изменения моделью скрама не предусмотрены и на мой взгляд ведут к анархии
Выделение тестеров в отдельную модель по скраму или кабану мне не кажется перспективной. Дело в том, что главная задача закрыть спринты команд и сделанная девелоперами разработка не может просто повиснуть — ее надо закрыть тестами. Поэтому они не отьемлемая часть спринтов девелоперов.
Но честно методика еще в разработке — я не нашел оптимального решения и главная моя проблема — разный велосити на разработку и тестинг тасков
Вопросы не простые.
У нас резервный день идет на:
— тесты для продакшен (но когда он наступает. то вообще все может рушиться и тимы берут Creative week, что бы не грузить тестеров)
— самообразование, например разделы автоматического тестирования
— документация, в часности создание новых тест кейсов
Если тестеры не успевают, тут та же проблема, что и не успевает тим в спринте. Во время планирования спринта задачи берутся с учетом времени на тестирование, так что это симтом плохого планирования спринта
В принципе идея та же — дискритизировать задачи и ограничить их поступление к тестировщикам. Предложенное мною решение имеет, как мне кажется, преимущество — девелоперы делают таски, как обычно и заэмаиневают их на тим QA. Для них картина процесса не меняется. Используется обычная система TFS (например Jira или Microsoft). Тим QA выбирает каждый день таски с разными метками тимов.
Мне кажется технологически это проще. Хотя up to you
Как правило приоритеты тасков не более трех. 80% попадают в одну категорию. Таски стараются быть предельно мелкими — принцип Agile. В этом случае за 1 день каждая команда может сделать несколько тасков. В итоге тим тестеров получает десяток тасков за 1 день. Функциональное тестирование даже в «сером» варианте занимает не менее часа (подготовка среды и пр.)
И все становиться совсем не очевидным
Типовые задачи встречаются довольно редко. Разве что при создании WEB сайтов, да и то для не очень требовательных клиентов. Любая разработка «с нуля», с одной командой, одним заказчиком и в одной сфере все равно будет проходить по разному — окружение меняется, человеческий фактор подводит и пр.
Интересно бы проанализировать динамику успешных и провальных проектов по годам. Хотя, мне кажется, здесь играет роль и стремительное увеличение самого числа проектов. Так же, играет роль и источник финансирования. Раньше это были достаточно серьезные фонды и инвесторы, а сейчас так же и студенческие группы.
У меня в голове, зреет статья по примеру конкретных рисков. Я думаю сделать вымышленный проект и попытаться на его примере создать модель управления. Надеюсь времени хватит :) Так что, если у кого есть желание участвовать или дать на разработку «учебный проект» — велком.
Действительно, во многом процесс управления основан на опыте. Но, вместе с тем, разработаны методики, минимизирующие риски. Описанный механизм, как раз и призван формализовать этот опыт.
Хотя идея создания такого блога мне кажется интересной.
Ну почему же рычажковые весы это нонсанс? Металлической частью был треугольник и его основа, на которой крепилось коромысло, сделанное из эбонита, как и сами чашки. Марку электронных весов конечно не знаю, но в 1984 году, если быть свовсем уж точным, они были на кафедре Химии МИИТа.
Спасибо, я нисколько на Вас не сержусь, вы правы со своей стороны, но я не хочу давать законченную модель. Эта работа моей юности 30ти летней давности. Тогда были и некоторые расчеты. За это время я поменял 3 страны и материалы утеряны, осталась только канва, которую я за один вечер и написал. Цель этой статьи, заинтересовать кого-нибудь проверить эксперимент и попробовать свои силы в расчетах. А вдруг кому-нибудь да будет интересно.
Попробуте, я буду рад узнать ваши результаты. Весы рычажковые были сдеоаны мною смостоятельно без металлических частей. Запас точности был 3й знак. Что только в 10 раз точнее полученных результатов. Так же взвешивал на весах кафедры Химии, но там электронные весы и вероютнее всего, внутри феромагнетики.
Постараюсь не затягивать :)
Однако я с вами не согласен.
Сама технология так и называется Internet (не Intranet) of Things.
Конечно это сложнее, конечно больше проблем.
Но и преимущества существенны.
Точно так же нативное приложение на вашем ПК могут прекрасно работать, однако существует и SaaS.
Я писал, чем занимаются тимы последние 2 дня — баги из беклога
Что касается 4го, тима, то действительно придется увеличивать размер спринта. Это решение имеет ограничения. Работает в размере общей команды 20-30 человек
Изменения размеров спринта, действительно не предусмотрены, но это не является минусом, на мой взгляд.
Коррективы по праздникам вносятся просто — сдвиг. Остальные изменения моделью скрама не предусмотрены и на мой взгляд ведут к анархии
Но честно методика еще в разработке — я не нашел оптимального решения и главная моя проблема — разный велосити на разработку и тестинг тасков
У нас резервный день идет на:
— тесты для продакшен (но когда он наступает. то вообще все может рушиться и тимы берут Creative week, что бы не грузить тестеров)
— самообразование, например разделы автоматического тестирования
— документация, в часности создание новых тест кейсов
Если тестеры не успевают, тут та же проблема, что и не успевает тим в спринте. Во время планирования спринта задачи берутся с учетом времени на тестирование, так что это симтом плохого планирования спринта
Мне кажется технологически это проще. Хотя up to you
И все становиться совсем не очевидным
Хотя идея создания такого блога мне кажется интересной.