Вхід і реєстрація
Розробка · 21 квітня 2017, 16:48 6680
Alina D, Product Manager в SUBJ:

Помогите перевести команду на стори поинты

Всем привет! Помогите перевести команду на стори поинты. Вроде бы в теории все довольно легко и просто. Но возникает вопрос, как и кто все-таки должен оценивать задачи. У меня 3 разработчика и 2 мануальных тестировщика, т.е. команда в принципе не может быть кросс-функциональна, т.к. тестировщики не кодят. Сработает ли вообще здесь скрам? И как оценить задачу? В прокер планировании принимают участие только разработчики и ставят свои оценки, а остальные просто смотрят? Или же тестировщики тоже принимают участие?Финальная оценка — это разработка с учетом тестирования? Буду благодарна за ответы.

P.S. Также буду благодарна за ссылочки с реальными кейсами

Підписуйтеся на Telegram-канал «DOU #tech», щоб не пропустити нові технічні статті

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Grez 25.04.2017 19:11

Просто делайте разные таски\планирование для девов и тестировщиков. Ежедневный срам и доску — можно оставить общей.

Відповісти
Підтримати
Oleksandr Kostiukevych Product Owner 24.04.2017 12:53

По початковому переходу, розписую під впливом вже даних вам в коментарях порад:
Метод № 1. Вибираете одну комплексну вже виконану задачу, яку добре знає та розуміє вся команда, середньої складності. Призначаєте їй значення в 5 story point’ів. Порівнюєте з нею всі інші наступні задачі, і призначаєте їм відповідне відносне значення, вибираючи його з ряду Фібоначчі (до якого ще додайте на початку значення 0.5). Вище ніж 8 story point’ів старайтесь не призначати, дробіть такі задачі на менші.
Метод № 1, покращений. Виберіть не одну задачу-еталон, а створіть цілу еталонну сітку — табличка, стовпчики якої відповідають значенням з ряду Фібоначчі. Розподіліть по цим стовпчикам певну кількість вже розроблених задач, це і буде ваша еталонна сітка складності. Під час оцінювання нових задач буде значно простіше зрозуміти, до якого значення все-таки ближче нова задача, порівнюючи з кількома еталонами, а не з одним.

Важливо, треба слідкувати щоб розробники не намагались закласти в оцінку задач якісь свої персональні здібності чи швидкість. Оцінка має бути відносно складності самої задачі, а не того, хто конкретно її буде виконувати.

Метод № 2, провальний. Постановіть, що тепер 1 година чи 1 день будуть називатись сторі пойнтом. Коли хтось під час оцінки буде за звичкою казати «3 години», виправляйте його — «3 сторі пойнти, не плутай», і по-змовницьки підморгуйте.

По процесу оцінювання: оцінюють всі, оцінюють весь об’єм роботи, включно з тестуванням.

Відповісти
Підтримати
Ivan Tumanov JS Dev 24.04.2017 12:51

помню как в команду из 4 девов пытались внедрить менеджера с какимито страшными словами вроде «скрам» и «сторипоинты», он ушел по собственному желанию через месяц)

Відповісти
Підтримати
Vasily Karpets CTO 22.04.2017 13:20

ОМГ! Скрам, покер планирование, стори поинты... Вы работать собираетесь?

Відповісти
Підтримати
anonymous 22.04.2017 01:33

Зачем? Вы же менеджер, у вас есть беклог, вот через него и работайте. Делаете задачи по размеру до 1-2 дней, если делает дольше — пингуйте, спрашивайте есть ли траблы. А покер и поинты это все мишура.

Відповісти
Підтримати
Mykola Gurov тролль 22.04.2017 00:46
Но возникает вопрос, как и кто все-таки должен оценивать задачи.
Команда. Вся. Целиком.
У меня 3 разработчика и 2 мануальных тестировщика, т.е. команда в принципе не может быть кросс-функциональна, т.к. тестировщики не кодят.
боюсь, вы в принципе не понимаете что такое кросс-функциональная команда. А может и команда вообще.
Финальная оценка — это разработка с учетом тестирования?
финальная оценка — это относительный размер сложности того, что задача (user story) полностью готова, принята и подготовлена к релизу. В идеале, и выложена на продакшн, но тут уже зависит от delivery процесса.
В прокер планировании принимают участие только разработчики и ставят свои оценки, а остальные просто смотрят?
нет, смысла в просто смотрении нет. Стейкхолдеры интересуются «почему так много, а что можно убрать чтобы было проще?» Девелоперы спрашивают тестировщиков почему такие большие эстимейты и как можно сделать тестирование проще. Тестеры удивляются такому низкому эстимейту девелоперов, ведь столько обсуждали историю — значит сложная, да и тест кейсов уйма. И т.п.
Відповісти
Підтримати
Artem Kunyk Senior Software Engineer 22.04.2017 00:04

Кросс функцирнальность достигается на уровне команды, а не отдельных персоналий. Т.е. команда может теоретически все делать

Відповісти
Підтримати
max dz 21.04.2017 23:02

Сделать 1 стори-поинт равным 1 часу — переход на стори-поинты проходит для команды легко и незаменто. :)

К тому же, клиенты/заказчики будут довольны — когда планирование/оплата работы будет в часах, а не в неких конкретно-командо-зависимых сущностях.

П.С. Разрабов и тестеров держать/менеджерить, по-отдельности.

Відповісти
Підтримати
Олексій Пєніє 21.04.2017 23:37

И промах по оценке гарантирован на 100%, правильно можно будет только угадать. Либо если сам проект уровня конструктора лего, когда все составляющие известны и обкатаны — но тогда и команда не нуждается в управлении, достаточно одного ленивого манагера и план на стену.

Відповісти
Підтримати
max dz
max dz 22.04.2017 00:11

Первые спринты делать замеры, насколько промахнулись (при этом, оценку команды можно множить скажем, на 2 или даже на 3).

А далее, оценку команды уточнять, уже более достоверными поправками.

Відповісти
Підтримати
Олексій Пєніє
Олексій Пєніє 22.04.2017 23:21

К тому моменту все эстимэйсты с заказчиком уже согласованы. Проблема кроется в другом: сами отношения с заказчиком крайне вероятно совсем не скрамовые. А какие? Правильный ответ — в лучшем случае вотерфолл, в худшем (и наиболее вероятном) — сэйлз: «моё дело продать, а что я при этом наобещал — разгребайте сами, свой процент я уже забрал из предоплаты».

Відповісти
Підтримати
max dz
Oleksandr Kostiukevych Product Owner 24.04.2017 12:25

Це якраз найгірший варіант, який відповідає панівному у нас підходу «як так запровадити Scrum, що нічого по суті не змінювати, але щоб він типу був». Навіщо називати години сторі пойнтами? В чому перевага цього перейменування?

Відповісти
Підтримати
max dz
max dz 24.04.2017 19:57

Абстрактные стори-поинты в неких «командных способностях» — это ад и общекомандный мазохизм. Кроме того, издевательство над заказчиком.

Відповісти
Підтримати
Oleksandr Kostiukevych
Oleksandr Kostiukevych Product Owner 25.04.2017 12:43

Не дійшло — що означає «сторі-пойнти в способностях», зокрема в командних?
Щодо іншого:
1. Сторі пойнти в конкретному проекті — не абстрактні, а умовні та відносні.
2. Для замовника пекло і знущання — не умовні сторі-пойнти, кількість яких він чітко розуміє після місяця роботи, а розробники, які на першому етапі тотально недооцінюють задачі, а на наступному взагалі категорично відмовляються давати оцінки. Основна перевага story point’ів — точніші, зваженіші оцінки за рахунок відносності і прив’язки до досвіду команди, poker-пленнінгу — зняття персонального тиску з розробників завдяки командному формату оцінювання, що в результаті йде на користь замовнику, бо дає можливість розробникам думати не про самозахист, а про продуктивність команди. І ще одна величезна перевага — це швидкість оцінювання, яка зростає багатократно.

Відповісти
Підтримати
max dz
Grez 25.04.2017 19:17

Суть стори поинта в осознании того факта что работа программеров недетрменирована. Если чел сказал что фича займет 3 дня, это вовсе не означает что она будет готова через 3 дня.
Для менеджера гораздо удобнее формат если чел сказал «фича А займет 3 дня, фича Б займет тоже 3 дня» то это означает что обе фичи будут готовы через две недели.

Відповісти
Підтримати
max dz
Олексій Пєніє 21.04.2017 22:56

В такой команде мягко скажем делать нечего. На 3 разраба — 2 мануальщика и 1 менеджер? Что-то мне подсказывает, что при переводе на канбан можно оставить только 3 разрабов, стадию альфа-теста ликвидировать, и привлечь заинтересованного тестера со стороны заказчика.

Почему так: львиная доля тестирования — избыточна. И расходы на него явно выше чем расходы на риско ошибок.

Согласись, делать стори-поинты — это делить шкуру неубитого медведя. А делать канбаны — это таки убивать медведя по кусочкам. В чём разница: один лишний поинт разрушает всю иерархию системы, равно как и попытка расставить приоритеты. В то же время лишний канбан — нормальное явление, проект развивается органично. Но при этом неумолимо растёт качество — вместе со сроком сдачи.

Стори-поинты имеет смысл делать только тогда, когда нужен результат на срок. А качество — если успеваете. Иначе говоря, качество «на два с плюсом по пятибальной». Притом плюс — за счёт костылей.

С канабанами нельзя оценить конечный срок — поток запросов как правило бесконечен, столь же бесконечен как цикл саппорта и готовность заказчика добивать проект до победного конца. Но прекрасно оценивается срок полуготовности, а все отклонения от срока — очень предсказуемы и видны заранее. Это позволяет отдать предсказание заказчику и заставить его принять решение. Но есть вариант что сунет голову в песок — но это будет означать что в случае скрама проект был бы убит, а в случае канбан-подобных систем — всего лишь задача о жёстких переговорах о «мелкой» задаче. Однако проект будет жив, и будет жив сколько нужно, и будет предсказуем в любой стадии — включая передачу другой команде, другому менеджеру, и даже другому заказчику.

Недостаток канбан-подобных систем — низкая конфликтность. Конфликты априори выносятся за пределы системы, считаются человеческим фактором.

Скрам — является конфликтом сам по себе, это само ядро системы. В результате за пределы системы выносится эмоциональная составляющая конфликтов, они становятся табу, и система разрушает сама себя. Получается, что скраму хорошо поддаются челленджи, когда результат может получиться, а может нет, и все об этом знают. Как только вероятность результата признаётся либо утверждается 100% — скрам становится стрессом, и производительность падает в разы, иногда практически до 0. На такие команды жалко смотреть.

Відповісти
Підтримати
Grez 22.04.2017 05:07
Почему так: львиная доля тестирования — избыточна. И расходы на него явно выше чем расходы на риско ошибок.
Я наблюдаю подобное мнение со стороны бизнеса. Это какойто звиздец. Продукт всегда получаеться очень глчный и бажный, и никто проблемы не видит, ни заказчик, ни менеджмент, ни сами программисты.
Відповісти
Підтримати
Олексій Пєніє
Олексій Пєніє 22.04.2017 23:23

Если бы бюрократические методологии тестирования работали — мы бы жили в идеальном мире. А реальный мир таков, что единственный способ добиться качества — закладывать его в проект. Но никак не полагаться на массовый контроль, который всё равно даст на выход говно, но дороже на 40%.

Да поможет вам дедушка Дэминг.

Відповісти
Підтримати
Grez
Grez 25.04.2017 19:21

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

Відповісти
Підтримати
Олексій Пєніє
Sergii Kudriavtsev Senior Software Developer в Lemonade 24.04.2017 13:54
Продукт всегда получаеться очень глчный и бажный, и никто проблемы не видит, ни заказчик, ни менеджмент, ни сами программисты.
Если продукт при этом успешно приносит бабло, то who cares?
Відповісти
Підтримати
Grez
Vadim Kopanev Architect 24.04.2017 14:06

Есть еще куча упущенного бабла

Відповісти
Підтримати
Sergii Kudriavtsev
Alina D Product Manager в SUBJ: 24.04.2017 16:18

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

что касается заинтересованного тестера — у нас он такой и есть, т.к. компания продуктовая и заказчик внутренний, все работают на интерес компании.

Відповісти
Підтримати
Олексій Пєніє
Олексій Пєніє 24.04.2017 17:50

Прелесть канбана в том, что можно избавиться от основных издержек в управлении. Задачи не сыпятся потоком, но разбиваются на потоки. И прекрасно поддаются оптимизации, когда они канбаны.

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

Если вы уже столкнулись с необходимостью «убедить заказчика», и не готовы со всей жёсткостью поставить его перед фактом — скрам для вас будет убыточен, для персонала будет неоплаченным овертаймом, и как результат — сопротивление работе как таковой. Вы непредставляете, насколько сложно его будет преодолеть, если вы рефлекторно привьёте его команде.

С канбанами всё просто прекрасно: есть бага — есть канбан. И вклинить его можно любым приоритетом. И конечный срок может бесконечно отодвигаться, но это не значит что 90% выполненной работы не смогут приносить 100% отдачи заказчику, что он будет недоволен. Наоборот, с огромной вероятностью он откажет вообще постоянно отодвигающиеся низкоприоритетные задачи, разделит проект на составляющие, а взамен них даст новых хотелок. Как правило это означает длительный цикл саппорта, но де-факто с вашей стороны просто останется один человек, который будет вести финальную стадию проекта уже сам или с привлечением спецов на почасовой оплате.

Другими словами, если у вас не получается скрам с его юзер-сторями — вероятно что не нужно его натягивать. Сократите, сделайте что-то подобное (имитацию), и не делайте лишнего. Например, я знаю скрам-команду, которые обходятся без митингов — но ведут форум.

Есть ещё сотни и сотни систем автоматизации управления, незачем гоняться за классикой. Достаточно просто понимать принципы, ещё лучше — попробовать понять принципы заказчика. А они, как правило, просты и элементарны: нужна предсказуемость и резерв времени на текущие хотелки. Это значит, что всегда нужно брать в спринт частично низкоприоритетные задачи, которые можно отложить и даже [вы]бросить на полуготовности при вмешательстве в спринт.

Відповісти
Підтримати
Alina D
Beaver Green 21.04.2017 19:38

Разберем по-порядку:

1) Скрам — работает. Но скрам — это не только стори-поинты. И работает только если внедрять все в комплексе и правильно, а не выбирать отдельные куски или перекраивать процесс до неузнаваемости.

2) А вот «кросс — функциональные команды» по моему опыту как раз — не работают. Девелоперы плохо тестят, а тестировщики еще хуже фиксят баги.

3) Как оценить задачу в стори-поинтах?
Берем для начала пачку самых простых задач: поменять лейблу, поменять цвет, добавить тултип и т.д. Играем в «покер» что бы определить что будет относительной единицей — задачей в 1 стори поинт.
Более сложные задачи оцениваем относительно «единичной»: например подвинуть контрол на 2 пикселя это примерно как две лейблы поменять и т.д.
Если задача сложная и оценки расходятся — надо уточнять и разбивать а не ставить 100500 стори-поинтов «с потолка». Правила «покера» хорошо описаны — повторять все не буду.

4) Как увязать стори поинты с часами?
При планировании — эстимейтим в стори-поинтах. При закрытии таска — ставим реально потраченное время. Важно собирать максимум критериев по таску: в какой части, к чему относился, кто делал и т.д. Потому что, например, подвинуть на 2 пикселя в IE может быть в 10 раз дольше, чем в нормальном браузере. После набора достаточного объема данных уже можно считать и делать выводы. Мерять велосити команды и отдельных людей, искать проблемные места и т.д. Тиммемберам важно пояснить что это не для слежки и наказаний — что бы писали время честно. Советую блокеры заводить как отдельные таски. Например: у девелопера час ставились апдейты или собирался билд — он не должен это писать в текущий таск, а в отдельный. По итогам потом может, например, оказаться что 10% времени спринта уходит на банальное ожидание билдов.

5) В эстимейтах участвуют и двевелопероы и тестировщики. Каждые дают свою оценку: девелоперы — на заимплементить, тестрировщики — на протестить. Иногда оценки могут различаться в разы — это нормально. Иногда поменять одну строку — нужно перетестить все.

6) Тестирование и спринты. Вот это — тонкий момент. В теории задачи в течении спринта делаются, проверяются и бурндавн к концу выходит в ноль. На практике в начале спринта тестировать еще нечего, в середине — находят 100500 багов, к концу — девелоперы сидят ждут пока тестировщики что-то найдут. В последний день все лихорадочно «на лету» фиксят и перепроверяют — на полную проверку времени уже нет. Т.е. нагрузка — неравномерная и в результате зачастую в релиз идет не самая стабильна версия — а «подфикшенная» в последний момент.
Как с этим быть? Лично я видел несколько вариантов:
а) Разнести спринты девелопмента и тестирования. Т.е. 2 недели девелоперы девелопят — потом 2 недели тестеры тестят, а девелоперы фиксят найденные баги и делают следующие задачи. В результате каждые 4 недели выходит стабильная версия.
б) Автоматизация тестирования — девелопер только начинает имплементить а тестер параллельно начинает писать тесты. Фактически девелопер и тестер работают в паре. Когда готово — прогоняют тесты и закрывают задачу.
в) Отдельная команда тестировщиков. Пока идет спринт — за качество отвечает девелопер. Сам пишет юнити и автотесты для своей задачи. После релиза версия уходит в тестирование команде тестировщиков и они потом пишут баги, которые девелоперы берут в следующие спринты. В этом варианте тестировщики могут вообще не участвовать в скраме и эстимейтах.

В заключение: по моему опыту самое сложное — это перевести на стори-поинты клиента! Особенно если он не готов полноценно играть свою роль в скрам процессе. Без этого Скрам вместо процесса эффективного сотрудничества клиента и команды часто превращается в средство обмана и команды и клиента. Например: «у нас Скрам — поэтому не надо планировать архитектуру наперед», или «у нас Скрам — поэтому мы и не обещали что успеем все эти фичеры к клиентской выставке через 4 месяца». Гибкий процесс — это не значит бардак!

Відповісти
Підтримати
Дмитрий Мирошник Lead QA Automation Engineer 24.04.2017 12:25

Хорошо написал. Единственный комент к 6:

На практике в начале спринта тестировать еще нечего
На этом этапе пишутся тесткейсы, ручные или автоматизированные
в середине — находят 100500 багов
Кол-во багов, найденных за спринт, хорошо учитывается матстатистикой. За 1-е несколько спринтов их необходимо измерить, в дальнейшем — учитывать при оценке сложности задачи.
Их кол-во будет уменьшаться к концу проекта, в середине оно будет примерно постоянной величиной.
к концу — девелоперы сидят ждут пока тестировщики что-то найдут
Нет. Они берут таски из топа бэклога, если вдруг возникла ситуация, что все таски сделаны, все баги пофикшены и в мире наступил коммунизм и благодать :)
Відповісти
Підтримати
Beaver Green
Alina D Product Manager в SUBJ: 24.04.2017 16:22

спасибо за расширенный ответ! буду пытаться привнести это в команду безболезненно и пошагово :)

Відповісти
Підтримати
Beaver Green
Alex Fogol Software Developer, C/C++ Expert 25.04.2017 23:54
По итогам потом может, например, оказаться что 10% времени спринта уходит на банальное ожидание билдов.
А 15% на ведение всех этих отчётностей и протоколов. )) Реальная цифра кстати.
Відповісти
Підтримати
Beaver Green
Леголас Трандуилович 21.04.2017 19:14

А все как бы зависит. Это вообще-то решение, которое должна принять сама команда.

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

И как оценить задачу?
Самое простое для начала привязать пинты ко времени, с оговоркой что это временно, только на газ и только для оценки, назад пинты во время не конвертировать.
В прокер планировании принимают участие только разработчики и ставят свои оценки, а остальные просто смотрят?
Немного безсмысленно, тогда надо делить команду по полам и делать 2 отдельных планинг покера.
Финальная оценка — это разработка с учетом тестирования?
Ну так это зависит от вашего тима, от того какие задачи вы оцениваете и того как Вы построили процесс, и от вашего «definition of done».
В общем по классике — конечно с тестированием и с последующим багофиксом, иначе кому она нужна без всего этого? Это хорошо и потому, что все могут принять участие в планировании и потому как укрепляет ваши внутрикомандные связи. У нас часто бывало что девелоперы ставили маленькие оценки, а тестеры большие и задавали вопрос «а как вообще это можно протестировать?». Но все зависит от вашей конкретной сферы, вашей команды, вашего рабочего процесса. Это вещи которые должна решать сама команда ибо по канонам скрама команда владеет своим процессом.
Відповісти
Підтримати
Леголас Трандуилович 21.04.2017 19:22

Еще одно — нету смысла переводить команду на стори поинты. Классический совет по скраму — адаптировать его целиком, со всеми ограничениями, принципами и практиками. А не переводить на сторипоинты. Само собой делать это надо с головой.

Мой совет насчет внедрения скрама — обязательно проводите настоящую ретроспективу. На ней анализируйте что вы делаете, что у вас получается, и имеет ли это смысл.

Відповісти
Підтримати
Леголас Трандуилович
Alina D Product Manager в SUBJ: 24.04.2017 16:26

почему хочу сторипоинты, потому что иногда задача завязана на других командах, например, дизайнерах, переводчиках и т.д. и не всегда можно оценить сколько займет по времени задача, т.к. еще и человеческий фактор учесть нужно. поэтому хочется оценить именно сложность задачи и как мне кажется стори поинты для этого подойдут

Відповісти
Підтримати
Леголас Трандуилович
Леголас Трандуилович 24.04.2017 18:30

Так не должно же быть задач завязанных на другие тимы в спринте, только то, что можно непосредственно делать. Ну и поинты они ведь так или иначе означают трудозатраты, если задача подразумевает «развязаться с другим тимом» её тоже ведь как-то оценивать надо.

Відповісти
Підтримати
Alina D
Alina D Product Manager в SUBJ: 21.04.2017 17:10

спасибо! для уточнения: т.е. стоит оценивать велосити команды не в целом, а по подкомандам исполнителей? т.е. к примеру тестировщики могут выполнить такой объем за спринт, а разработчики такой?

Відповісти
Підтримати
anonymous
Alina D Product Manager в SUBJ: 21.04.2017 17:14

спасибо огромное !

Відповісти
Підтримати
anonymous
Oleksii Pavlov Software Engineer 21.04.2017 16:54

Вот смотришь человеку в профиль на линкедине, а там и скрам и канбан и другие умные слова:)
Ну как так?)

Відповісти
Підтримати
Alina D Product Manager в SUBJ: 21.04.2017 17:01

можешь бросить ссылочки на этих людей, я напишу им в личку ))

Відповісти
Підтримати
Oleksii Pavlov
Alina D Product Manager в SUBJ: 21.04.2017 17:13

отличный профайл, я считаю ) написала в личку, чтобы про Кабан рассказали, а то ничего об этом в профиле не нашла )

Відповісти
Підтримати
anonymous
Alina D Product Manager в SUBJ: 21.04.2017 20:00

Во-первых, спасибо за внимательность, без таких людей бы проекты точно рассыпались ;)
Во-вторых, как указано в комментариях выше, скрам — это не только стори поинты и можно использовать комбинацию элементов различных фреймворков аджайла, которые наиболее подходят под команду, проект, заказчика и т.д.
Мой вопрос звучит непосредственно о стори поинтах, т.к. именно этот элемент мы не использовали ранее и пришли к нему сейчас, когда команда уже созрела
И в-третьих, людей, которые работают по чистому скраму можно пересчитать на пальцах. Но это не означает, что другие не могут быть сильны в методологии. И почему-то в них никто не тычет, когда они указывают в профилях «Скрам-мастер», не имея соответствующего сертификата.

И еще раз спасибо за язвительные комментарии, они всегда помогают людям становиться лучше. А методом проб и ошибок мы достигаем результатов. Всех целую :*

Відповісти
Підтримати
NewOne NewOne
Ivan Tumanov JS Dev 24.04.2017 13:29
чтобы про Кабан рассказали
это к зоологам :)
Відповісти
Підтримати
Alina D
Alina D Product Manager в SUBJ: 24.04.2017 15:49

ахахах, не заметила..ржу ))

Відповісти
Підтримати
Ivan Tumanov
Mobile 22.04.2017 01:58

ты еще не видел резюме разработчиков — там и ораклы и винформы и все все все, и в 90% случаев просто нет чела который это все может хоть както проверить

Відповісти
Підтримати
Oleksii Pavlov
Oleksii Pavlov Software Engineer 22.04.2017 02:18

Видел:) но я думал пм-ы честнее :))))

Відповісти
Підтримати
Mobile
max dz 22.04.2017 14:50
90% случаев просто нет чела который это все может хоть както проверить

А отзывы/рекомендации в письменном виде, от прошлых шефов — в Украине не приняты? На фирменном бланке компании, с подписью и прочими причиндалами, само-собой...

Відповісти
Підтримати
Mobile

Підписатись на коментарі

Не підписуватись
Скористайтесь акаунтом
×
з умовами використання сайту і політикою конфіденційності.