Настоящий Agile

[ksi]

А что такое Agile и почему он у всех на устах? Я название, конечно, слышал, но что это такое и главное для чего нужно не знаю, стыдно сказать

[VovaK98]

А что такое Agile и почему он у всех на устах? Я название, конечно, слышал, но что это такое и главное для чего нужно не знаю, стыдно сказать

И не забивайте себе моск.
Если достаточно долго сидеть на берегу реки, то труп Agile (и иже с ними) eventually проплывет мимо.

[Vladimir Kr.]

Agile, нужен ли девелору? а теории может быть. На практике когда на 4 девелопера наняли 4 тестера, 3 бизнес аналиста, теам ледера, прожект ледера, скрам мастера и 2 химиков как саппорт . За 2 месяца написали 30 сториес типа ' хочу красивую табличку в IE'. а теперь 2 недели разбираемся как стори поинтс в жире посчитать . Никакого дезайна, и некто не знает что дальше? Зато стендап каждый день. Очень это похоже на тот анекдот про бардель где кровати переставляют вместо того чтобы бля...й поменять.

Sent from my SM-G950U using Tapatalk

Я уже писал выше что ритуалы типа стендапа и артефакты типа стори поинтов это все фуфло. На деле, главным образом работают всего две практики. TDD и pair programming. Это мой личный опыт, как собственника компании (который одновременно и программист), который просрал некую сумму собственных денег на разработке. Спорить и убеждать никого не хочу, лень мне банально. Ветку я стартанул, потому что хотел узнать широко ли практикуют то, что мне близко и интересно в Америках. Оказалось что тоже не очень.

TDD и pair programming, работает, но в строго ограниченных дозах на проекте - т.е. на критически важных компонентах, но это не Agile.

Agile который работает это вот это: "Working software over comprehensive documentation"
т.е. там где релизят продукт по компонентам до того, как ТЗ на них подписано, и само ТЗ это скорее руководство к действию, чем строгое определение - смело называют себя agile. А то что при этом 3/4 манифеста игнорируется, никого не смущает.

стендап, это просто утренняя планерка (5-10 минут), основное назначение для девелопера - разрулить блоки, для пм-а посмотреть как идет процесс (инструмент микроменеджмента).
стори поинты, в простейшем случае позволяют запланировать работу на спринт. а так-же могут использоваться, как метрика для оценки изменения производительности команды.

[mister-X]

Ажаил для менеджмента еще одна попытка контролировать работников. При этом начальству есть возможность оправдывать свой непрофессионализм новыми "технологиями". Реально ажаил полезен толко в команде профессионалов без нахлебников и имеющих равные доли в прибыли.

Sent from my SM-G950U using Tapatalk

[nyekimov]

Agile, нужен ли девелору? а теории может быть. На практике когда на 4 девелопера наняли 4 тестера, 3 бизнес аналиста, теам ледера, прожект ледера, скрам мастера и 2 химиков как саппорт . За 2 месяца написали 30 сториес типа ' хочу красивую табличку в IE'. а теперь 2 недели разбираемся как стори поинтс в жире посчитать . Никакого дезайна, и некто не знает что дальше? Зато стендап каждый день. Очень это похоже на тот анекдот про бардель где кровати переставляют вместо того чтобы бля...й поменять.

Sent from my SM-G950U using Tapatalk

Где есть 4 тестера на 4 разработчика? Где бы не работал, куда на собседование бы не ходил, везде на тестерах экономят, хотят, чтобы разработчик тестировал свой код, юнит тесты это отдельно, надо чтобы еще делал регрешн тест, разрабатывая новую фичу или фикся дефект, чтобы ничего другого не сломалось. Вообще оно как бы и понятно с одной стороны, ты должен знать продукт, который разрабатываешь, но с другой, когда на родине я сам или макс вдвоем делали проекты, то естественно знали все фичи от корки до корки, а тут когда столько бардака и туева хуча народа, то просто ну невозможно становится знать все нюансы проектов.
У нас даже недавно было собрание по очередной реорганизации процесса разработки, модель управления командой / проектами (читай аджайл) меняется наверное чаще, чем фичи)) Так вот уже прям вписали, что разработчик должен тратить время на тщательное тестирование, и когда один из разработчиков возразил, что ну глаз становится замылен, ум у разработчика часто не заточен под вбить хрень или понажимать кнопки в другой последовательности, начальство сказало - мы платим вам за это! ничего не хотим слышать! Хотим зеро дефектс и точка!
Компания не то чтобы гадюшник, хотя кому как.

[nyekimov]

А вот скажите, знатоки оджайла, говно под названием Jira - это для этого самого оджайла? А то мы вроде как его теперь практикуем, по слухам, и так совпало, что это убожество Jira ч ним появилась. Или это совпадение?

Это совпадение. Жира - тикет система (вполне неплохая сама по себе). Кажется в 2012 году к ней плагином прикрутили jira agile plugin - достаточно быстро сляпаное на коленук, отчего более аджайл жыра не стала. В вашем случае это, скорее всего, совпадение. Ну или же какой-то новонанятый scrum master притащил это с собой, потому как он её пользвал на предыдущей работе. Опять же жыра не имеет ни малейшего отношения к аджайлу.

Ниоткуда со стороны никаких скрамных мастеров не приходило.
Но вот тикеты почему-то стали заводить не в багзилле теперь, а в джире, и это совпало со стендапами (митинги такие - по-теории, вроде, стоять нужно, и прямо каждый день).
Что в джире не нравится:
1. суперперегруженный интерфейс, и ничего не понятно;
2. машина состояний тикета какая-то странная - вместо new/reopen - fixed - verified, какие-то названия причудливые. И в добавок не понятно, чего надо нажимать, чтобы перейти из одного состояния в другое.

Состояния все настраиваются, у нас к примеру проблема в том, что каждый менеджер ставит свои состояния, которые он считает ключевыми, и потом разбирайся, что от тебя нужно.

А если джира одна конфигурация и состояния интуитивны - open -> in progress -> in review -> ready for test -> validating -> closed / reopened. Или нечто в таком стиле, то очень удобно работать, тем более когда доски нормально настроят, наглядно видно, кто над чем работает в конкретный момент времени, закончил свои задачи, идешь берешь все то, что открыто и ни за кем не закреплено.

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

У нас ее внедряли, потому что менеджер где то вычитал, что физическое прикосновение якобы дает ощущение чего то там. Он сам подходил, двигал тикет и такой - How it feels? Мне хотелось его спросить - ты идиот? Так физ доска была в довесок к жире, естественно никто ее особо не обновлял. И так она месяца через три была расформирована. Сам менеджер потом сказал - я думал эта затея и недели не продержится, а смотрите сколько прожила. Мой вопрос о его адекватности опять всплыл в голове. Ну ничего не поделаешь с этими "эффективными" чтецами чего попадется под руку для "эффективного" управления командой

[nyekimov]

Agile, нужен ли девелору? а теории может быть. На практике когда на 4 девелопера наняли 4 тестера, 3 бизнес аналиста, теам ледера, прожект ледера, скрам мастера и 2 химиков как саппорт . За 2 месяца написали 30 сториес типа ' хочу красивую табличку в IE'. а теперь 2 недели разбираемся как стори поинтс в жире посчитать . Никакого дезайна, и некто не знает что дальше? Зато стендап каждый день. Очень это похоже на тот анекдот про бардель где кровати переставляют вместо того чтобы бля...й поменять.

Sent from my SM-G950U using Tapatalk

Я уже писал выше что ритуалы типа стендапа и артефакты типа стори поинтов это все фуфло. На деле, главным образом работают всего две практики. TDD и pair programming. Это мой личный опыт, как собственника компании (который одновременно и программист), который просрал некую сумму собственных денег на разработке. Спорить и убеждать никого не хочу, лень мне банально. Ветку я стартанул, потому что хотел узнать широко ли практикуют то, что мне близко и интересно в Америках. Оказалось что тоже не очень.

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

[caltrain]

Но как еще работает это парное программирование?

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

[Nostradamus]

Главное - чтобы спали отдельно (см. мой топик про сожительство)
А то может родиться нечто неведомое и невероятное ...

[se888]

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

Мне лениво тратить на это время. Есть масса ресурсов и книг, первоисточники именно в Америке. Авторы например Роберт Мартин, Рон Джеффрис, Кент Бек.

[Komissar]

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

Мне лениво тратить на это время. Есть масса ресурсов и книг, первоисточники именно в Америке. Авторы например Роберт Мартин, Рон Джеффрис, Кент Бек.

Спросили же о вашем личном опыте...

[kyk]

Главное - чтобы спали отдельно (см. мой топик про сожительство)

я ж предлагал с китаянкой, тогда всё пучком

[se888]

Спросили же о вашем личном опыте...

Мой опыт ничем не отличается от опыта всех остальных практикующих. Это же не космос какой-нибудь. Это обычное развитие навыков коммуникаций. Во всех командных видах спорта есть тренировки в парах и работа на площадке в парах. В хоккей не играли? На тренировке обязательно час отводится парной работе. Защитник с защитником, защитник с нападающим. Сегодня Иванов с Петровым отрабатывают проход от ворот в зону соперника. Завтра Семенов с Ивановым отрабатывают отход из зоны соперника в среднюю зону и разворот к контратаке. То же самое и в программировании.

[Ann4Ann]

Спросили же о вашем личном опыте...

Мой опыт ничем не отличается от опыта всех остальных практикующих.

ну фу. как раз у практикующих у ВСЕХ все очень по разному. от "отлично налажено" до "сборище пустозвонов".
сейчас стало совсем непонятно зачем вы эту тему открыли - после предыдущего ответа выглядит как похвастаться тем, что книжку по аджайлу осилили....

[nyekimov]

Спросили же о вашем личном опыте...

Мой опыт ничем не отличается от опыта всех остальных практикующих. Это же не космос какой-нибудь. Это обычное развитие навыков коммуникаций. Во всех командных видах спорта есть тренировки в парах и работа на площадке в парах. В хоккей не играли? На тренировке обязательно час отводится парной работе. Защитник с защитником, защитник с нападающим. Сегодня Иванов с Петровым отрабатывают проход от ворот в зону соперника. Завтра Семенов с Ивановым отрабатывают отход из зоны соперника в среднюю зону и разворот к контратаке. То же самое и в программировании.

Короче практического опыта нет.

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

[ksi]

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

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

[se888]

ну фу. как раз у практикующих у ВСЕХ все очень по разному. от "отлично налажено" до "сборище пустозвонов".
сейчас стало совсем непонятно зачем вы эту тему открыли - после предыдущего ответа выглядит как похвастаться тем, что книжку по аджайлу осилили....

Если бы вы прочитали с чего началась тема, вы бы знали зачем я ее открыл.

[se888]

В спорте как бы две команды соревнуется, всегда есть соперник, поэтому отрабатывать нападение и защиту надо парно. Совершенно не вижу аналогии с разработкой ПО.

В спорте, еще есть по меньшей мере взаимодействие партнеров внутри команды.

То, что вы не видите аналогий, это не моя проблема. Я никого и ни в чем не убеждаю и не собираюсь тратить время на такое бесполезное занятие.

[se888]

Вообще странная практика, фактически в 2 раза уменьшается количество рабочих рук.

Считаете что программирование сродни копанию канав? Чем больше рук, тем лучше результат?

[_Lenchik]

это не моя проблема. Я никого и ни в чем не убеждаю и не собираюсь тратить время на такое бесполезное занятие.

Наверно это и есть главный подход в аджайле или в стиле управления у эффективных менеджеров - при предложении говорить по существу вопроса идет ответ в стиле - "ты что идиот, элементарных вещей не понимаешь?"

[ksi]

Вообще странная практика, фактически в 2 раза уменьшается количество рабочих рук.

Считаете что программирование сродни копанию канав? Чем больше рук, тем лучше результат?

Ну в принципе это как всегда ресурсы аллоцируются - все эстимайты считаются в man/month. Мне казалось, что все современное развитие идет в ту сторону, чтобы максимально упростить программирование, сделать его рутиной, с которой может справится кто угодно.

[se888]

Наверно это и есть главный подход в аджайле или в стиле управления у эффективных менеджеров - при предложении говорить по существу вопроса идет ответ в стиле - "ты что идиот, элементарных вещей не понимаешь?"

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

[se888]

Ну в принципе это как всегда ресурсы аллоцируются - все эстимайты считаются в man/month. Мне казалось, что все современное развитие идет в ту сторону, чтобы максимально упростить программирование, сделать его рутиной, с которой может справится кто угодно.

Это вы про учет затрат. А вы попробуйте эффективность оценить.

[nyekimov]

Наверно это и есть главный подход в аджайле или в стиле управления у эффективных менеджеров - при предложении говорить по существу вопроса идет ответ в стиле - "ты что идиот, элементарных вещей не понимаешь?"

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

Может быть потому что вопрос был задан прежде? И вы ни раз сказали, что не видите смысла кому то что то объяснять. Зачем вопрос вообще на форума задавали? Показать свой ум?

Кстати перечитал ваш первый пост, которым вы начали тему, вам уже тут писали, что парное программирование это не обязательный аттрибут, и вообще атрибут только agile xp, чаще всего команды используют код ревью. Который на моей практике работает в разы лучше в большинстве случаев. Вы же вообще ни одного примера из мира разработок не привели, все приводите какие то сомнительные аналогии, то спорт, то копать.

PS. Мне вся эта ситуация напоминает эджайл тренеров теоретиков, которые ничего в жизни практически не написали, но зато теоритически они то знают, как команда должна жить. "Вы не правильно работаете! Давайте мне ваши денюжки, я вас научу как надо". Только я бы 99% таких гнал ссаными тряпками.

Мне друг так недавно рассказывал, как у них на работе неделю рассказывали новую методику разработки, дядька белый американец, который родом из Австралии, так вот ездит по фирмам и втирает свою теорию. Самое что мне понравилось, это то что он неделю с командой провел и поехал дальше. Никакого контроля и ведения команды на результат. Типо мавр сделал свое дело, мавр может уходить. Мне очень интересно, это тупо отмывание денег или начальство реально думает, что неделя лекций чем то реально сможет помочь команде заметно.
Это как ходило шуточное видео про тренера всяким новым модным направлениям, где он им говорил, что вы лохи деньги заплатили, поэтому теперь пойдете и сделаете вид, что получили за это что-то полезное и обязательно порекомендуете меня друзьям. Чтобы они тоже попали на этот развод.

[rialtoma1]

Больше всего меня в аджайле раздражют скрам мастера. Как постоянные, так и консультанты. Один такой консультант наm recently втирал, что нет такого понятия - не хватает времени на какой-то tech debt, не хватает, надо остаться после работы (они даже ужин дадут) и сделать. У менаы сейчас с work / life balance плохо, но тут я совсем @@@@@@
Уважение вызывают люди, которые делают - пишут код, дизайн и тп, а не чешут языком целыми днями по поводу defenitions of done, burndown charts graphs etc