Настоящий 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]

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

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

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

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