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

[Aliya_S]

Ясно и просто про сложное — фирменный почерк нашего нереально обаятельного Кости Гусева.

[SophiaShirokova]

Привет, Aliya_S! Спасибо за комментарий, автору приятно!

[taksebe]

Но… это же просто пересказ теории, и так уже разжёванной с разных сторон. Тут нет вообще ничего своего — настолько, что не очень верится, что автор действительно юзал Скрам.

Зачем? Почему это на Хабре? Ревью, Песочница, где вы все? За что?

[SophiaShirokova]

Привет, taksebe! Спасибо за комментарий! Практическое применение будет рассмотрено во второй части статьи:)

[taksebe]

А она точно будет?

[SophiaShirokova]

12 ноября 2020 года она вышла здесь

[taksebe]

А чего не на Хабре?))

[SophiaShirokova]

Диверсификация контента

[taksebe]

Как теперь красиво непрохождение ревью на Хабре называется))

[Ktator]

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

Ну так и как же быть в потоке? Из вашей статьи понятно только то, как быть в аудио (и видео!) потоке: заменить скайп на зум. И ещё то, что вы умеете пересказывать книжку.

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

Если вдруг кто не слышал.

Студент сдает зоологию. Знает только про блох. На экзамене
достается вопрос про собак. Судент начинает:
— Собаки это млекопитающие, покрыты шерстью. В шерсти водятся блохи…
дальше все про блох…
Препод:
— Ладно молодой человек, расскажите про кошек.
Студент:
— Кошки это млекопитающие, покрыты шерстью. В шерсти водятся блохи…
дальше все про блох…
Препод:
— Давайте-ка про рыб.
Студент:
— Рыбы это не млекопитающие. Шерстью не покрыты. Покрыты чешуей, но если
бы они были покрыты шерстью, то в ней бы водились блохи…

[SophiaShirokova]

Здравствуйте, Михаил! Спасибо за то, что уделили время прочтению. Надеемся, что вторая статья — практическая, понравится Вам больше! Мы будем стараться совершенствовать наши материалы.

[korg1994]

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

[G-Kostya]

Дискутировать! Выше я писал про оценку задач и как мы приходим к единому мнению. Участвует вся команда, даже если обсуждается компетенция разработчика, тестировщик может задавать простые вопросы — почему этот вариант/решение лучше?

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

Каждая проблема или конфликт имеет причину. Разберитесь в ней, проговорите с командой, примите общее решение. Как писал Гэвин Кеннеди — Договориться можно обо всём!

[Schurikken]

Ну, ребят, мне как начинающему БА полезно было перечитать ту же теорию Скрам, но на примере работы реальной команды. Так что от себя — плюсую. И не судите строго автора по первой статье)

[SophiaShirokova]

Добрый день, Schurikken! Спасибо за оценку!