SCRUM. У кого на работе считают, что используют?
Преимущества
- Программисты в команде через какое-то время действительно станут "взаимозаменяемыми"
- Менеджеры с удовольствием воспринимают что теперь можно каждые 2(3, 4, смотря какая длина спринта) недели меять задания, приоритеты, вносить что-то новое
- в конце разработки продукт будет ближе к хотелкам клиента, которые он в начале не может даже представить, не то что озвучить.
- Цикличностью и постоянным общением с заказчиком (как минимум на ревью)
- Спринты короткие, по результатам спринта, которые демонстрируются клиенту можно уточнить предыдущие хотелки и получить новые.
- Модность помогает продать скрам. Убедить клиента что ему НАДО найти время на то, чтобы участвовать в ревью после каждого спринта и на то что ему НАДО обсуждать истории с ПО
Недостатки
- Нудные ежедневные митинги
- Сложности при заключении договоров. Scrum в принципе не подразумевает наличие фиксированного бюджета и фиксированного технического задания, что затрудняет юридическое оформление такого рода договоренностей;
- Большое количество исключений. Специалисты в этой области считают данную методологию неприменимой для работы с государственными заказами, а также совершенно нерабочей при низкой квалификации команды, заниженных сроках работ или бюджете, некомпетентном менеджере проекта. В то время как другие методологии позволяют завершить проект при подобных условиях, хотя и на низком уровне;
- Узкая специализация методов. Так, например, если использовать Scrum при разработке сайтов, этапы дизайна и контента уже будут выходить за рамки методологии и требовать совершенно иного подхода.
Требования к реализации
1 роль скрам мастера (СМ) - это тот, кто следит за ходом проекта и помогает команде решать проблемы.
1 роль продукт овнера (ПО, владелец продукта) - тот, кто решает вопросы концепции продукта и составляет бэклог
5-7 ролей разработчика - скрам-команда — исполнители конкретных проектов
Полная команда:Минимум 6 человек, максимум 9
Скрам команда должна быть полностью независимой и подчинятся исключительно ПО. Все взаимодействие с внешним миром происходит также только через него.
Роль СМ может и должен выполнять один из разработчиков.
Больше инфо –ссылки:
Иллюзия эффективной разработки
Scrum. Революционный метод управления проектами». Книга за 15 минут
https://habr.com/company/makeright/blog/297250/
ТОП-10 ошибок, которые делают 90% Scrum-команд
https://scrummasters.com.ua/blog/top-10-fails-of-scrum-teams
Скрамгайд 2017
А если в конструктор параметр надо передать?
Если надо передать параметр, то это уже другой разговор. А зачем писать лишний код, когда параметры не нужны? :)
так из описания понял.
Тестируется функция, которая генерит пароли (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
имелось в виду, что надо еще додуматься до теста в подобной ситуации, потому как материал длиной в десяток см просто физически не смог бы передвигаться по данной линии.
до этого теста не надо было бы додумываться. До него додумались китайцы. Тебе надо было бы только симлировать данные, чтобы исправить ошибку и убедиться, что исправление это не будет удалено в будущем :)
делают программу стабильной.
Остается открытым вопрос, а какая нам нужна стабильность и сколько мы готовы за это заплатить?
Был я как то на проекте контроллера управления легковой машиной. Так там пару строчек изменить могло и пару недель длится.
Вначале меняешь дизайн, затем два человека должны сделать ревью, после этого меняешь код и опять ревью, потом идешь к стенду и тестируешь, протоколы "в папочку".
Кое кто и на машине с лэптопом ездил на тестовой трассе.
В этом случае вы бы за милую душу исправили эту ошибку
Неа Во первых это не ошибка, а изменение условий эксплуатации, причем неописанных. Так что проблема не наша, хотите изменений - нет проблем делаем дополнение к договору на сумму Х и исправления ваши.
до этого теста не надо было бы додумываться.
Речь то шла о тестах до появления "ошибки", а не после того как стало известно что это за проблема возникла.
Во первых это не ошибка, а изменение условий эксплуатации, причем неописанных. Так что проблема не наша, хотите изменений - нет проблем делаем дополнение к договору на сумму Х и исправления ваши.
Так зачем же ты тогда привел этот пример в качестве ошибки и невозможности эту ошибку поймать?
Речь то шла о тестах до появления "ошибки", а не после того как стало известно что это за проблема возникла.
Речь шла о тестировании в целом. "Ошибка", которая стала известна до возникновения проблемы - это известный юз-кейс, и не является ошибкой :)
Да ладно, ничего особо сложного в этом нет :) хотя интернет пестрит ужасными историями 😀
Да ничего особо ужасного и не надо. Первое что делает любой программизд, никогда не читающий никакую документацию - лепит в один коммит код из всех подключенных через subtree проектов.
Хотя... Я забываю всё время, что мы же о c# на виндусях говорим. Как там зависимости проектов определяются... Может и действительно проще приучить с subtree работать.
git submodule
попробовал не получается, говорит что путь неправильный у субмодуля. Как там каталоги должны быть правильно "составлены"
Я пробовал так:
c:\all\systemA\prj1 - локальный репо как главный проект
c:\all\systemA\prj2 - локальный репо как субмодуль