Agile
Перефразируя поговорку, можно сказать, что "кто в скраме работал, тот в цирке не смеется" 
Забавные бывают зрелища. Мне лично нравится, когда сертифицированных девиц с десятками фломастеров и стикерами всех цветов нагонят и давай все вместе юзер стори грумить в хвост и в гриву, выясняя по три часа какого цвета должна быть кнопка. Вопросы собственно реализации и архитектуры считаются слишком низкими и недостойными обсуждения.
А вообще, скрам придумали для случаев, когда есть куча народу, где 50% не хотят работать, а еще 50/% не могут..Но результат какой-то выкатить надо. Работа примерно как на зоне. Построения с перекличкой. Коллективная (без)ответственность. Начальник в дела заключенных не встревает. Смотрящий пахан (скрам мастер) следит за порядком и чтобы у всех бензопила работала. В принципе, это в среднем помогает в смысле, что лучше что-то, чем ничего. Но серьезных команд, которые клепают серьезный софт в скраме я не видел (максимум это канбан).
А вы не помните что за фирма?
Я персонально не занимался переходом на агил, но по бюро валялась куча рекламного материала от этой фирмы. Нсли что то осталось, я могу посмотреть. Но почему этот вопрос? Я вообще не вижу технических проблем в организации процесса. Просто есть команда, которая давно и крепко сидит на своем месте. И агил не решает автоматически проблемы в процессе программирования. Более того. Если проблемы не поняты и не проанализированы, то агил их усугубляет. Имхо.
И вот тут должен был возопить скрам мастер: "доколе!" И где он у вас?
Доколе что? Тим чем дальше, тем меньше на себя берет. Небольшие задания получают большое количество пунктов. Если спринт не выполняется, то все скромно стоят потупив глаза. И называют кучу обьективных причин.
Карго-культ. "Заседает" тоже команда а не кто-то.
Да верно. Но придумать название это не решить проблему. Раньше каждый получал индивидуальное задание от шефа и индивидуальные звездюли. Или кстати индивидуальную благодарность. Шеф был полностью задействован в процессе. Теперь есть команда. Ну выпендрился я и пару раз вытянул спринты. Ну и что? Команда свое дело сделала, это никто не заметил, а команда теперь ждет, что я САМ буду брать все проблемные тикеты. То есть сам дурак.
Почему в часах нельзя?
Потому что если из скрама выкинуть всю фигню, то получится водопад. Так что без фигни нельзя, это не по правилам.
А фокус-фактор? Разве после каждой итерации не принято считать фокус-фактор?
Я не считаю. Ага, хотел спросить. Как этот параметр расчитывается и как его можно использовать для поднятия производительности?
Алгоритм Agile покера как раз на выходе даёт именно количество часов.
Ага, хотел еще спросить. Что это конкретно значит?
И агил не решает автоматически проблемы в процессе программирования. Более того. Если проблемы не поняты и не проанализированы, то агил их усугубляет. Имхо.
Основая проблема как обычно в понимании инструментария :)
Скрам - это методология управления временем и внедрение скрама никак не может повлиять ни на качество кода, ни на что-либо еще.
Менеджерам льют в уши, что с введением скрама улучшается качество кода. Помню, на предыдущей фирме перед введом скрама была куча заседаний и назначений на роли. И все в один голос говорили "сейчас у нас есть проблемы с надежностью кода, но как только будет введен скрам, так сразу мы решим все проблемы". И самое смежное, что все менеджеры (в том числе и с техническим бэкграундом) свято в это верили.
Скрам ввели, проблемы как были так и остались :)
Скрам - это инструмент для управления процессом разработки. И ничего более.
Нсли что то осталось, я могу посмотреть. Но почему этот вопрос?
Просто интересно, вдруг тоже с ними столкнуться придётся - хорошо знать что ожидать можно.
Я вообще не вижу технических проблем в организации процесса.
А зря. Вернее так - технических проблем (повесить доску, установить джиру и запланировать рефайнмент и ретроспективу) обычно и не возникает. Проблемы возникают с командой и начальством. С людьми. Всем надо свои привычные методы менять.
Во-первых надо набрать команду. Есть люди которые могут неплохо кодить, но которые просто не могут работать в скраме. Потому что а.) не любят брать на себя ответственность за что бы то ни было б.) не воспринимают решения равных им по положению, как обязательные к исполнению (ой, чё они там напридумали, все фигня). Им нужен командир. С крутым названием должности "Senior Super Mega Team Lead". Они радостно получают от него тупейшие задания, и исполняют их. Бухтя себе под нос, мол, вот дурак-то, вот ежели б я решал, я б всё по другому делал. Почему проект загублен? Низнаю... Мы всё делали как насяльника сказала.
Во-вторых начальство (проект менеджер, тим ляйтер, кто будет ПО играть) должно поменять своё отношение. Они не должны лезть в процесс. Иначе мантры о "вы сами решаете как вам удобнее" не сработают, расстройство одно будет. Они должны жить без "через 6 месяцев будет релиз с таким-то функционалом". ПО должен уметь говорить на равных с командой, а не "я так решил".
Любые методики не решают никаких проблем автоматически. Всё надо сначала научится использовать. В том же водопаде клиенты должны жить с длинным ТТМ (Time To Market), потому что 3 релиза до 2020 уже запланированы и на планировку потрачено 500 часов, никто объём 3-го релиза ради добавления новой кнопочки переопределять не будет. Чтобы добавить кнопочку - напишите-ка ТЗ на 30 листах, в которых чуть ли не названия класссов и методов уже пропишут и позицию кнопочки с точностью до пикселя при разных разрешениях экрана, а то если это не прописать то программисты такой фигни налепят, что вы.
Если проблемы не поняты и не проанализированы то любая методика или усугубит их, или исправит. Как повезёт. Если проблема заключалась в отношениях команда - тим ляйтер, то сделав из ляйтера ПО отношения команда - ПО только ухудшатся. Привели нового ПО, умеющего признавать ошибки - и вот уже команда работает совсем по другому.
Доколе что? Тим чем дальше, тем меньше на себя берет. Небольшие задания получают большое количество пунктов. Если спринт не выполняется, то все скромно стоят потупив глаза. И называют кучу обьективных причин.
Доколе процесс симулировать будем. Скрам мастер может на дейли настоять на том, чтобы кто-то взял приоритетный тикет (баг). Потому что выполнил свое - берёшь "сверху". Он должен, если это не поясняет сам программист, спросить почему тикет/подзадание у него висит уже третий день (обычно стараются делать субтаски для больших задание, так, чтобы эти таски были не дольше дня), может ему нужна помощь. Расстрельными подвалами или премиями он грозить не может, да и не должен. Если все отмалчиваются, он должен обсудить это с командой на реторспективе. Мол, последние спринты скорость в очках (sprint velocity, сумма очков у всех, сделаных с спринте заданий) росла, а количество заданий падало. Как вы думаете, почему?Почему 2 месяца назад "добавить чекбокс" было оценено как 2 очка, а в этом спринте "убрать кнопку 'отменить'" - в 5 очков? Усложнился проект? Может пора потребовать от ПО сделать спринт с рефакторингом? Что мешает нам быть такими же эффективными как 2 месяца назад? И эти вопросы задаются не в воздух. Каждый участник должен дать на них свои ответы.Тут уже просто так не отмолчишся. И даже со стороны (я сам скрам-мастером никогда не был) хорошо видно кто действительно что-то хочет исправить а кто просто отсиживает время.
Скрам мастер может выгнать ПО с любого совещания, если тот начнёт выяснять "почему Вася взял тикет с багом и облажался". Но может и посоветовать начальству разогнать команду, потому как она не работает.
Теперь есть команда. Ну выпендрился я и пару раз вытянул спринты. Ну и что? Команда свое дело сделала, это никто не заметил, а команда теперь ждет, что я САМ буду брать все проблемные тикеты. То есть сам дурак.
Не-а. Команды нет. Если "соскрамники" не оценивают вклада, принимают это как "вот теперь и паши дальше" то никакой команды у вас нет. Есть группа. И решение для такого часто бывает одно - такого "тянущего" вынимают из команды и переводят (в идеале с повышением хотя бы на пару процентов) в другую команду с такими же "тянущими". В результате полушаем хорошую команду. А в старой, после удаления тянущего, может суммарно производительность тоже возрастёт, потому как такой тянущий может остальных бесить. Без него им морально легче. Бывает. Но начинать надо с обсуждения на ретроспективе. Мол, народ, а чего у нас такое, я тяну, а вы филоните? Так самому встать и спросить непросто. Хороший скрам-мастер должен сам поднять эту тему. Личные отношения важны в любом коллективе. Даже при водопаде. Но в водопаде о них говорить не принято - это дело тим ляйтера а не процесса.
Да верно. Но придумать название это не решить проблему.
А решение это долготянущийся процесс. Всегда легче сломать, а вот исправлять потом месяцами надо - пока доверие не появится. Если команда не хочет работать в скраме - так и не надо. Можно попытаться набрать новую. Если не сможешь понять почему же они саботируют. А можно поманить морковкой - мол, сделаем 1-ю версию к 01.12 - всем по 50% месячного оклада. Можно в команде устроить срач - премия на (допустим) 5 человек команды выписывается 15 штук, но кто конкретно сколько получит - решайте сами. Хорошо людей вскрывает. Как в детском саду :)
Во-первых надо набрать команду.
Гм. Это Германия. Приличная по размерам фирма с профсоюзом. Куда девать нас, раздолбанную кучку кодеров? Можно придушить втихаря, но уволить практически нереально.
Остальное все правильно потому что очевидно. Но со временем за годы команды курвятся. А набирать работников только на проект нереально, ну только если екстернов.
Они должны жить без "через 6 месяцев будет релиз с таким-то функционалом". ПО должен уметь говорить на равных с командой, а не "я так решил".
Мы уже релиз 3 раза сдвигали. Мы - это команда! (Я там потом в тексте везде на "группу" заменил, но тут "команда" звучит круче.)
В том же водопаде клиенты должны жить с длинным ТТМ
У нас неправильные клиенты. Они не хотят радоваться процессу разработки и смотреть как их прога обрастает функтионалом. Они точно знают, что хотят и хотят ЭТО к конкретной дате. Сволочи. Причем они дату релиза не назначают, а вежливо спрашивают - а когда это реально. Славо богу, что мы хозяины своего слова - как дали дату релиза, так и передвинули. Немного утрировано, но думаю понятно
Скрам мастер может на дейли настоять на том, чтобы кто-то взял приоритетный тикет (баг).
Скрам мастер может настоять на чем угодно. В одном конкретном случае это даже может сработать. Но тогда только дураки будут закрывать тикеты без оглядки на то, что еще простого и интересного осталось на доске.
Если все отмалчиваются, он должен обсудить это с командой на реторспективе. Мол, последние спринты скорость в очках (sprint velocity, сумма очков у всех, сделаных с спринте заданий) росла, а количество заданий падало. Как вы думаете, почему?
И вот тут самое смешное. Кого он спрашивает если все отмалчиваются? Вы социализм не застали? Смотрите, есть толпа за все ответственных людей. И никого конкретно. ВСЕ знают почему. Но ни один дурак не скажет. А зачем?
Люди просто не хотят работать. И из-за групповой игры не видно кто. Идиоты, которые пытались выпендриваться, быстро ставились на место. Еще раз, вы социализм не застали? Очень похоже. Если БАМ, УРА и лозунги, то молодой и наивный коллектив можно заставить работать. Но опытное и циничное болото спасут только расстрелы.
Но может и посоветовать начальству разогнать команду, потому как она не работает.
Всех не перевешаете! И тут командная игра плюс профсоюз. Если конкретный чел не
работает, ему выписывают маннунг. Потом расстреливают. Если пара бездельников развратила группу? Вы не можете всем паушально выписать коллективный маннунг. Значит разогнать можно только с повышением.
Мол, народ, а чего у нас такое, я тяну, а вы филоните?
Ну во-первых никто не филонит. Все носятся как в жопу заведенные. Например обсуждение новой функции старого модуля. В 57-й раз. А то, что функтионалитета нет, то просто не судьба. Кроме того я конечно дебил, но не настолько, что бы спросить у толпы "а чего у нас такое, я тяну". Понятно, что проблема не в группе. Проблема в дураке, который тянет. И это надо как то исправлять. Меня в жизни пару раз исправляли. Как то неохота приключений на задницу.
Кроме того я неконфликтный. Я программист и ниразу не организатор. Это не мои проблемы.
И решение для такого часто бывает одно - такого "тянущего" вынимают из команды и переводят
Да вы что? Где это? Кто это такoй дурак, что бы последнего идиота, на котором висят все тикеты, из группы убрать(сейчас речь не о бо мне, я не настолько глуп)? Скрам мастер? Тот, которого и так раком за производительность ставят? И остаться с остальными ? Слабо верится.
Ссоры, получается писсимистично
Ну, алгоритм Agile-покера, это когда каждый выкидывает рубашкой вверх карту со своим предполагаемым количеством часов. Потом, тот, кто выкинул максимальное значение обсуждает с тем,кто вымокинул минимальное значение (остальные молчат). В результате приходят к соглашению. При этом как правило в этот момент и происходит решение кто берет эту задачу.
Задач типа "жопа" в agile быть не может в принципе. Значит либо это не agile либо речь вообще не о программировании.
Ну, алгоритм Agile-покера, это когда каждый выкидывает рубашкой вверх карту со своим предполагаемым количеством часов.
Часы по классике использовать запрещено. Запрещено прямо, есть обоснование. Вы конечно можете пользоваться часами, но это отступление от канонов.
Задач типа "жопа" в agile быть не может в принципе. Значит либо это не agile либо речь вообще не о программировании.
Клиент внезапно видит чужие данные. Допустим даже сделал скрин. Нефига непонятно, откуда начинать. Понятно, что лажа с сессиями, но какими? ДБ? Аппликатионсервер? А чужие данные это жопа. И тот, кто возмет этот тикет должен будет
1. найти проблему, которую нельзя репродуцировать
2. Найти решение, которое гарантировано проблему решит. Причем время тикает.
Я понимаю, что группа в агиле такую задачу получить не может, они же идеальные программисты
и даже не какают.
Во-первых присоединюсь к совету бежать.
Во-вторых повторюсь что успешность внедрения скрама зависит не от техники, а от людей. И если люди - дрянь, скрам противопоказан. Потому что предполагает взятие на себя ответственности и желание что-то сделать хорошо.
И вот тут самое смешное. Кого он спрашивает если все отмалчиваются? Вы социализм не застали?
Каждого члена команды спрашивают по отдельности. Типа каждый пишет 3-5 пунктов, что по его мнению уменьшает продуктивность, а потом по очереди выходят к доске, лепят свои 5 листиков на неё, и 3-5 минут рассказывают что именно имеется в виду под пунктами. Потом похожие пункты группируются и смотрят, какая кучка самая большая - узнаём какая проблема воспринимается большинством. Вы такого никогда на ретроспективе не делали?
И как тогда отмалчиваться? Ничего не писать? Или "меня всё устраивает, проблем не вижу"?
Ну во-первых никто не филонит. Все носятся как в жопу заведенные. Например обсуждение новой функции старого модуля. В 57-й раз. А то, что функтионалитета нет, то просто не судьба.
Такого в скраме быть не может. User Story уже обсуждена, принята командой в работу, никаких обсуждений больше нет (обычно, мало ли, в процессе реализации может всплыть ошибка планирования), только реализация. Тикеты на один день. Не сделал за день - берём тикет на заметку, не сделал за 2-й, подключаем ещё одного человека. Не сделали за третий ставим вопрос о профессиональном соответствии - вы же сами эти тикеты планировали, что они за 1 день реализуемы, как так?
Да вы что? Где это? Кто это такoй дурак, что бы последнего идиота, на котором висят все тикеты, из группы убрать(сейчас речь не о бо мне, я не настолько глуп)? Скрам мастер? Тот, которого и так раком за производительность ставят? И остаться с остальными ? Слабо верится.
Ну, это вам просто с адекватным менеджментом работать не приходилось. Так-то вместо 4-х команд, работающих хреново, из которых ещё и валят на другие фирмы лучшие программисты, делается 1 хорошая и 3 не сильно хуже (которые могут стать лучше). И из 1-й хорошей команды программисты не убегают. Профит. Скрам мастер, конечно, такие решения не принимает. И ПО тоже. Это должно руководство отдела/фирмы решать. Скрам мастер должен уметь заметить такое состояние и посоветовать руководству.
Хорошей команде - дополнительный бюджет, пару тысяч, которые она сама может решить как потратить - на тим-ивент в Берлин на концерт съездить, или проектор себе из потолка опускающийся в комнату заказать (только наличными выплачивать нельзя :)). Будут хреновые возмущаться - мол,
а нам, отвечать что а вам - как Катаеву. В смысле "вы еще не показали вашей способности корректно работать в рамках скрама и принимать ответственные, взвешенные решения." Потому про ваши 2 тысячи решило руководство - вы на них получите очень важный для вас курс "я у мамы дурачок" "основы агильной разработки". Или сами уйдут или пара человек зашевелится. Их опять в следующую "нормальную" команду. Может сработать.
Ну, алгоритм Agile-покера, это когда каждый выкидывает рубашкой вверх карту со своим предполагаемым количеством часов.
Чушь. Карты с очками.
При этом как правило в этот момент и происходит решение кто берет эту задачу.
Чушь. Кто делает решается в тот момент, когда её из спринт-лога возьмут.
Задач типа "жопа" в agile быть не может в принципе.
Критические ошибки. Могут.
1. найти проблему, которую нельзя репродуцировать
2. Найти решение, которое гарантировано проблему решит. Причем время тикает.
1. Если уже известно что нельзя репродуцировать, то решение вообще-то простое. Мы не знает что происходило, делаем три (5,7) подзадач - "проверить работу с сессиями в A/B/C/..." с тайм-боксом, скажем 8 часов. Нашли подозрительное - правим, не нашли, говорим что не знаем от чего ошибка, соответственно исправить её не можем, и предлагайте решения - переписать логику, отключить функционал, разбросать разных пользователей по разным серверам/БД ну или что ещё придумаете. И договариваетесь с ПО.
2. С чего бы? Вы не пробовали разговаривать с ПО? Может его устроит что вы понавтыкаете логов, чтобы если такая ошибка вдруг всплывёт ещё раз, повысить шансф понять из-за чего.
-----
Ой, легко...
Просто представь ситуацию, в которой никто не может указать количество поинтов для таска...
Просто большой таск и целиком его не охватить...
Хммм... примерчик...
Есть спецификация на XSD-схемы.
Есть конвертер в код.
В конвертере есть баг - выпадает Circular Reference.
Ну и сколько его лечить?
ЖопААААА!!!! хоть с агилом, хоть без...
1. найти проблему, которую нельзя репродуцировать
2. Найти решение, которое гарантировано проблему решит. Причем время тикает.
Как можно решить проблему, если ты не можешь ее репродуцировать?
Если появляется проблема, которую нельзя репродуцировать, то есть 2 варианта развития событий:
1) инвестировать фигзнаетскольковремени в то, чтобы научиться репродуцировать проблему.
2) сказать, что проблему репродуцировать нельзя, а значит этой проблемы не существует :D
FocusFactor -- это отношение реально затраченных часов к запланированным. Чем больше слаженность команды -- тем выше вы фокус-фактор.
Фокус фактор рассчитывается в конце каждой итерации.
В начале разработки это обычно коэффициент 0.3, начиная с 4-ого месяца это может быть 0.7