Deutsch

Scrum

5450  1 2 3 4 5 6 7 все
alla0 патриот04.06.21 11:15
alla0
NEW 04.06.21 11:15 
в ответ Ashka_hash46 04.06.21 09:56
Так вот, тот, который fachlich (и с которым мы работали до сегодняшнего дня), тоже, как и Алла, удивлен, что до продукта, собственно, задачи не доходят. Все какие-то организационные моменты и технические необходимости. Я, как разработчик, понимаю, что если не починим основание, колдовать над фичами по меньшей мере нерационально.

Да я как раз понимаю необходимость чинить технику, инвестироватъ время в архитектуру итд. Я не понимаю, какие претензии могут быть о мне как к ПО, если в результате фичи продукта имплементируются очень медленно. Если мне выдали машину, которая ездит с максимально 50 км/час, и я не автомеханик и не шофер, а пассажир и навигатор, то не моя вина, что я прибуду к месту назначения позже назначенного срока. Значит срок назначен неверно, либо неверно выбрана техника. Но не я оба этих решения принимаю, зато я оказываюсь невинной жертвой. Которой выдвигают обвинения, что она выбрала неправильный маршрут, сбилась с пути итд. Но е-мое, если расстояние по прямой известно, и скорость известна, то какие могут быть основания для этих подозрений?


#41 
soarian коренной житель04.06.21 11:26
soarian
NEW 04.06.21 11:26 
в ответ Ashka_hash46 03.06.21 22:44, Последний раз изменено 04.06.21 11:38 (soarian)

Судя по тому, что Вы описывали ранее, я бы подумала что скрам, это то что вам нужно. Вы ответственны только за те задания, которые вы, реалистично оценив ауфванд, сами себе смогли "застолбить". Ни кто больше не сможет на вас что-то взвалить. Коллеги тоже не смогут, важные задания оставить на потом, потому как, если вы от них зависите, то ваши часы просто перестают тикать "blocked internal/external". И сразу станет заметно, что у вас, salopp gesagt, некому работать


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

Тёмные аллеи
#42 
soarian коренной житель04.06.21 11:45
soarian
NEW 04.06.21 11:45 
в ответ soarian 04.06.21 11:26

НП

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

Тёмные аллеи
#43 
  yurka_ffm знакомое лицо04.06.21 12:59
NEW 04.06.21 12:59 
в ответ alla0 04.06.21 11:15
Значит срок назначен неверно, либо неверно выбрана техника. Но не я оба этих решения принимаю, зато я оказываюсь невинной жертвой. Которой выдвигают обвинения, что она выбрала неправильный маршрут, сбилась с пути итд.

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

#44 
Ashka_hash46 патриот04.06.21 13:38
Ashka_hash46
04.06.21 13:38 
в ответ soarian 04.06.21 11:26
Судя по тому, что Вы описывали ранее, я бы подумала что скрам, это то что вам нужно.

Дай Бог! Я только "за" хоть какую-то системность. То, что не верю в реалистичность - это другое.


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

Вот именно это и смущает. В частности, сегодня вышла проверить почту, и уже вижу, как идёт первый спринт. Т.к. в июле первая крупная продажа нашего проекта в этом году, то начальство заинтересовано в минимальном качестве. И у тестировщиков "вдруг нашлось время". Соответственно, запланированные задания сместились под давлением вернувшихся из тестирования багов. А т.к. планировать, когда у тестировщиков будет "свободная минутка" мы не можем, то и включить потенциальное время на устранение багов в спринт не получается. Ладно, будем считать, что это просто первый блин комом 😉

Общественное мнение формируют не самые умные, а самые болтливые
#45 
alla0 патриот04.06.21 14:15
alla0
NEW 04.06.21 14:15 
в ответ Ashka_hash46 04.06.21 13:38, Последний раз изменено 04.06.21 14:16 (alla0)

Тестирование это отдельная тема. Вообще-то тесты должны быть интегральной частью разработки. И каждая фича должна перед деплойментом быть протестирована всеми возможными способами. Юнит-тесты вообще часть разработки, насколько я понимаю. В Build-Pipeline проходят тесты. Акцептанc-тесты, автоматические и мануальные. Автоматические систем-тесты, UI-Тесты. Это все должно быть частью процесса. То есть многое тестируют прямо разработчики. И после всех этих тестов и отправки апдейта клиентам, не должно обнаруживаться множества багов. Естественно, на системе клиента что-то может пойти не так из-за иных условий чем в системе разработки, но это все должно держатъся в рамках.

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

#46 
soarian коренной житель04.06.21 15:07
soarian
NEW 04.06.21 15:07 
в ответ Ashka_hash46 04.06.21 13:38, Последний раз изменено 04.06.21 15:09 (soarian)

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

Тёмные аллеи
#47 
Ashka_hash46 патриот04.06.21 22:16
Ashka_hash46
NEW 04.06.21 22:16 
в ответ alla0 04.06.21 14:15
если у вас просле проверки экстернами-тестировщиками все время начинает уходить на устранение багов, то значит в разработке что-то идет не так.

Логично. Мы латаем, то что сыпется на лету. Проект, написанный человеком-самоучкой, мы переняли после года с момента его увольнения. Документации нет, как должно работать - пытаемся угадать из кода. Видимо, не до всех углов добрались, раз до сих пор падает на тестировке. То, что на внутренней не упадет - знаю точно... До мая месяца нас было двое (кто помнит мою историю про быстрого/медленного коллегу - так медленного от нас убрали), и "мышление у нас одинаковое". Что встроили, то и протестили, а где ещё зацепит по касательной - видим не всегда. Надеялись, что с расширением команды - будет лучше тестирование, но "что там с командой" - я уже описала выше 😒


Юнит-тесты вообще часть разработки, насколько я понимаю. В Build-Pipeline проходят тесты. Акцептанc-тесты, автоматические и мануальные. Автоматические систем-тесты, UI-Тесты. Это все должно быть частью процесса.

Это все - должно быть. Но этого нет. И времени, чтоб даже начать вкручивать хоть понемногу - тоже нет. Сейчас две крупные задачи до сентября, двух товарищей надо по-быстрому вработать (то есть объективно рассчитывать на их участие в проекте раньше декабря - не приходится), ещё один разработчик уходит в эльтерцайт. То есть остаюсь я "на все случаи жизни": текущие инсталляции, активная разработка/тестирование, введение новых коллег в материал и "срочное разруливание проблем клиента". Понимаю, что до автоматизированных тестов не дойду. Дай Бог мануальные своими силами провернуть.

Общественное мнение формируют не самые умные, а самые болтливые
#48 
Galant2 патриот12.06.21 17:57
Galant2
NEW 12.06.21 17:57 
в ответ alla0 04.06.21 11:08
И надостаток ресурсов с помощью скрама можно сделать более явным.

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

#49 
insea старожил14.06.21 10:43
insea
NEW 14.06.21 10:43 
в ответ Pikaboo 27.05.21 13:16
Нанимается скрам-мастер за кучу денег, который создаёт видимость бурной деятельности, генерит кучу бесполезных митингов и всем мешает.

А что ещё ему остаётся делать, чтобы своё существование оправдать. Мне кажется, скрам-мастер как отдельная должность имеет смысл только для ооочень большой организации. У нас фирма маленькая и стратег по совместительству скрам-мастер. Думаю, у него в неделю часа 3 на эту обязанность уходит. Был бы отдельный человек для этих целей, так точно бы всем только мешал, чтобы хоть как-то своё рабочее время занять.спок

#50 
alla0 патриот14.06.21 13:41
alla0
NEW 14.06.21 13:41 
в ответ insea 14.06.21 10:43, Последний раз изменено 14.06.21 13:44 (alla0)

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

#51 
  yurka_ffm знакомое лицо14.06.21 16:51
NEW 14.06.21 16:51 
в ответ alla0 14.06.21 13:41

Я подозреваю, что скрам-мастера ещё придумали, чтоб ПО быстрее крутил педали, их "экологические ниши" немного пересекаются.

#52 
alla0 патриот14.06.21 17:52
alla0
NEW 14.06.21 17:52 
в ответ yurka_ffm 14.06.21 16:51

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

#53 
MolMed знакомое лицо14.06.21 19:42
MolMed
NEW 14.06.21 19:42 
в ответ alla0 14.06.21 17:52

Ни разу не видел "чистого" скрам мастера. Всегда у него есть ещё и другие задания и роли. В том числе это может быть и Product Owner. Я вроде не на маленькой фирме работаю.

#54 
  yurka_ffm знакомое лицо14.06.21 19:42
NEW 14.06.21 19:42 
в ответ alla0 14.06.21 17:52

Так вы ж вроде жаловались недавно, что только скрам-мастер решает, что включить в спринт...

Но против таких козырей как модные платья не попрёшь, конечно.

#55 
Ashka_hash46 патриот14.06.21 23:30
Ashka_hash46
NEW 14.06.21 23:30 
в ответ yurka_ffm 14.06.21 19:42

Н.п.


Ну вот скрам, такой скрам 🙈


Первый спринт закрыли, ревью сделали, оценили наши успехи/провалы, распланировали второй. Сегодня старт. Утром в почтовом ящике письмо от ПО: "Ребята, косяк, тот проект, что мы устанавливаем 1.07 и уже протестировали - не соответствует заявленным требованиям клиента" 😯 Ну, мы ж не зря просили написать концепт перед началом разработки... Нам его "как-то там" написали, парень, который программировал именно эту часть, догадывался, что так будет, поэтому перед началом разработки все же представил детальную выкладку перед ПО, объяснив, что от чего зависеть будет и как он это сделает. Получил "добро", принялся за реализацию. И вот сегодня - сюрприз. Сюрприз ещё и в том, что парень через два дня уходит в эльтерцайт, знания по этой части проекта только у него (и, как водится, не задокументированные), мы в стадии активного старта другого проекта...


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


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

Общественное мнение формируют не самые умные, а самые болтливые
#56 
alla0 патриот14.06.21 23:59
alla0
NEW 14.06.21 23:59 
в ответ yurka_ffm 14.06.21 19:42
Так вы ж вроде жаловались недавно, что только скрам-мастер решает, что включить в спринт...

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


#57 
alla0 патриот15.06.21 11:29
alla0
NEW 15.06.21 11:29 
в ответ Ashka_hash46 14.06.21 23:30

А с какой целью ПО написал вам "Ребята, косяк, тот проект, что мы устанавливаем 1.07 и уже протестировали - не соответствует заявленным требованиям клиента"?

Цhего он от вас ожидает?


#58 
Pikaboo коренной житель15.06.21 12:53
Pikaboo
NEW 15.06.21 12:53 
в ответ Ashka_hash46 14.06.21 23:30

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

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

#59 
Van Doren коренной житель15.06.21 12:56
Van Doren
NEW 15.06.21 12:56 
в ответ alla0 15.06.21 11:29

Какой же он ПО? ПО и есть клиент.

#60 
1 2 3 4 5 6 7 все