Ну вот а физически как это выглядит? Вот я создал класс/проэкт.
Дальше-то что? Как этот Agile выглядит в жизни?

Здравствуйте, Аноним, Вы писали:

А>Ну вот а физически как это выглядит? Вот я создал класс/проэкт.
А>Дальше-то что?
Вот пошаговая инструкция:
1. Проходишь собеседование
2. Получаешь оффер
3. Спрашиваешь про сабж
4. Если пользуют то соглашаешься и дальше сам все увидишь. Если нет — goto #1

Здравствуйте, Аноним, Вы писали:

А>Ну вот а физически как это выглядит? Вот я создал класс/проэкт.
А>Дальше-то что? Как этот Agile выглядит в жизни?
Agile это процесс разработки (организации задач, тестирования, планирования т.п.). К Java никакого отношения не имеет.

Здравствуйте, Аноним, Вы писали:

А>Ну вот а физически как это выглядит? Вот я создал класс/проэкт.
А>Дальше-то что? Как этот Agile выглядит в жизни?

Демонстрирую разницу на пальцах:

Обычный подход
10:03 Приходишь на работу, включаешь компьютер, открываешь jira, выбираешь из списка задач какие-нибудь поинтереснее (поважнее, попроще, whatever), назначаешь их на себя, начинаешь их делать
19:17 Заканчиваешь последнюю задачу, выключаешь компьютер, идешь домой

Agile-подход
10:03 Приходишь на работу, бегом взбегаешь на четвертый этаж, быстро-быстро раздеваешься, попутно вспоминая, что же ты делал вчера
10:04 Заскакиваешь в совещательную и получаешь от собравшихся там втык за то, что на четыре минуты опоздал на стэндап-митинг
10:08 Пытаешься не зевать, слушая внезапно возникший в ходе стендапа спор тимлида с дизайнером относительно цвета кнопок и размера шрифтов
10:11 До тебя доходит очередь рассказывать о планах на сегодня и вчерашних заслугах. Ты понимаешь, что уже успел об этом забыть и получаешь еще один втык от тимлида
10:18 Выходишь из совещательной, включаешь компьютер, находишь задачу в своем личном списке, начинаешь ее делать
11:34 К тебе подходит коллега Вася, спрашивает, не ты ли случайно делаешь задачу №1234 и сколько ты еще планируешь этим заниматься. Ты в это время делаешь задачу №1201, но ему очень нужно, чтобы ты срочно сделал №1234, т.к. у него без этого функционала работа стоит. Говоришь, что тебе осталось работы на три часа, просишь подождать до послеобеда или забрать №1234 и сделать ее самому.
12:28 Подходит тимлид и говорит, что юнит-тест, который ты написал четыре месяца назад только что упал с ошибкой и ты, как автор теста, должен этот баг непременно пофиксить, т.к. посадил его, по всей видимости, тоже ты. Причем сделать это надо срочно, т.к. сегодня пятница и в выходные он будет выкатывать новый спринт.
13:02 Находишь косяк в коде коллеги Толи, внезапно проявившийся из-за неумелого рефакторинга кода коллегой Гришей. Фиксишь, успешно прогоняешь тест, сообщаешь об этом тимлиду. "Давай быстрее коммиться, только сперва обновись и прогони все тесты!" — отвечает он.
13:04 Делаешь svn update, и огребаешь конфликты в только что исправленном коде: оказывается коллега Боря час назад наткнулся на тот же неработающий тест, молча исправил ошибку и пять минут назад закоммитил свой вариант.
13:08 Прогоняете тесты на машине Бори, ты откатываешь свой вариант фикса, наливаешь чашку кофе и возвращаешься к задаче №1201.
13:21 Появляется коллега Вася, спрашивает, когда ты начнешь делать №1234. Отвечаешь "по № 1201 работы еще часа на два, так что если с обедом — к 16:00 закончу и начну №1234".
13:42 К тебе подходят Вася с тимлидом и последний интересуется, в чем у тебя проблема с №1234. Говоришь, что проблем нет, т.к. ты ее еще не делал. Он отвечает, чтобы ты бросал все свои задачи и срочно вместе с Васей переключался на №1234, т.к. от нее зависят №1235 и №1237, которые обязаны попасть в сегодняшний билд. А чтобы вам работалось быстрее — он советует при решении этих задач программировать в паре. Идете за васин комп, садитесь рядом, начинаете программировать.
13:54 Коллега Вася кричит "время обед!", хватает за шкирку коллегу Вову, под ручку дизайнершу Оленьку — и они вместе убегают жевать суши в дальнюю кафешку. Ты с Борей и Гришей идешь в ближнюю.
14:41 Возвращаешься с обеда, садишься за компьютер. К тебе подходит тимлид и спрашивает, что уже решено из №№ 1234, 1235 и 1237. Говоришь, что вы еще только начали и что Вася еще не вернулся с обеда
15:02 Вася возвращается с обеда, критикует код, который ты начал писать без него. Удаляете, начинаете переделывать так, как ему кажется правильным.
15:18 Тимлид зовет всех в совещательную заниматься покер-планированием следующего спринта
16:23 Возвращаетесь из совещательной, садитесь снова писать №1234
18:10 Заканчиваете №1234, обновляетесь, прогоняете тесты и начинаете искать кого-нибудь, кто может сделать code review. Все, как назло, заняты — на дворе вечер пятницы, все хотят побыстрее свалить домой.
18:31 Коллега Гриша делает вам review, вы пытаетесь закоммититься и огребаете конфликты с модулем коллеги Вовы, который сегодня работал с девяти и потому уже ускакал на футбол
18:43 Разгребаете последний конфликт, прогоняете еще раз тесты, коммитите №1234 и начинаете делать №№ 1235, 1237.
21:54 Коммитите №1237, звоните домой тимлиду, хватаете шапки и бежите в районный супермаркет за пивом, чтобы расслабиться после трудового дня.

Как можно легко заметить — процесс программирования по гибкой методологии получается гораздо насыщеннее, интереснее и продуктивнее. К тому же можно целыми днями страдать фигней (ну ты же не сделал №1201, а №1234 отдал коллеге Васе — так что в понедельник все будут в этом уверены). А главное — постоянно есть бонус в виде свежего пива!

Здравствуйте, Пацак, Вы писали:

П>Демонстрирую разницу на пальцах:

П>Обычный подход
...

П>Agile-подход
...

П>Как можно легко заметить — процесс программирования по гибкой методологии получается гораздо насыщеннее, интереснее и продуктивнее. К тому же можно целыми днями страдать фигней (ну ты же не сделал №1201, а №1234 отдал коллеге Васе — так что в понедельник все будут в этом уверены). А главное — постоянно есть бонус в виде свежего пива!

Ваша демонстрация очень однобокая.
Создается в впечатление, что ни ревью, ни конфликтов при комите, ни падающих тестов, ни командной работы в "обычном" подходе нет.
А это не совсем так.
В вашей демонстрации показано неумение команды работать со всем вышеперечисленным.
Это бывает. Но все это совсем не результат применения Agile или любой другой методологии.
А у Вас весь негатив оказался только в описании второго подхода.
Поэтому и вывод у Вас получился как минимум странным.
И если это не стеб а описание реальной ситуации, то там в списке очень серьезных проблем выбор методологии похоже на самом последнем месте

Здравствуйте, robin_of_the_wood, Вы писали:

___>Ваша демонстрация очень однобокая.

Ну я надеялся, что сарказм будет заметен.

___>Создается в впечатление, что ни ревью, ни конфликтов при комите, ни падающих тестов, ни командной работы в "обычном" подходе нет.
___>А это не совсем так.

Э, вы ж не о том. Конфликты, падающие тесты, внезапно обнаруженные недоработки, необходимость что-то дописать/переделать и т.п., конечно, бывают везде. Но у agile-методик есть неприятная особенность — если ими бездумно (или слишком фанатично) пользоваться, то подобные вещи оборачиваются авралами, которые начинают повторяться чуть ли не в каждый спринт. И если в случае классического подхода поработать до ночи раз в два-три месяца перед дедлайном — это не такая уж большая сложность, то еженедельные пятничные посиделки очень быстро задалбывают до невозможности. Особенно ярко это проявляется, когда руководитель проекта не вкуривает разницу между завершением спринта и зеленым свистком для выкладывания новой версии в продакшен. И когда планирование задач на неделю начинается словами "в этот спринт мы должны все сделать, потому что заказчику я обещал это к следующему вторнику". После чего уже можно сразу идти и запасаться пивом — вероятность того, что в пятницу будет вышеописанный аврал и пиво под вечер тебе пригодится, после таких слов вырастает обычно почти до ста процентов.
С другой стороны, если руководитель адекватный, то работать по agile, конечно, гораздо приятнее. Тут не поспоришь — драйв от постоянного улучшения продукта и ощущение вовлеченности в общее дело ни в какое сравнение не идут с рутинным многонедельным копанием в недрах "родного" модуля. И, собственно, выше я с этим нисколько не спорил — меня просто удивляет, насколько легко весь этот позитив может превращаться в банальную соковыжималку...

___>А у Вас весь негатив оказался только в описании второго подхода.

Ну я надеялся, что сарказм будет заметен.

Здравствуйте, Blazkowicz, Вы писали:

B>Agile это процесс разработки (организации задач, тестирования, планирования т.п.). К Java никакого отношения не имеет.

Тема в Java попала явно по ошибке ТС.
Да и обсуждалась она уже неоднократно насколько я помню.
Хотя иногда случается, что разработчики с хорошим опытом за плечами с сабжем сталкиваются только вот сейчас или сравнительно недавно.
И вот мнения таких людей возможно будут многим интересны.
Может стоит тему перенести из Java в более подходящее место?

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

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

П>С другой стороны, если руководитель адекватный, то работать по agile, конечно, гораздо приятнее.

Начали за здравие, кончили за упокой. Таки оказалось, что дело не в подходе, а в руководстве. Вот с такой формулировкой я более чем согласен.

Здравствуйте, SkyDance, Вы писали:

SD>Начали за здравие, кончили за упокой. Таки оказалось, что дело не в подходе, а в руководстве. Вот с такой формулировкой я более чем согласен.

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

Здравствуйте, SkyDance, Вы писали:

SD>Наличие этой фразы автоматически превращает Agile в "обычный подход".

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

SD>Кстати, я правильно понимаю, что по "обычному варианту" обед с Васей и дизайнершей Оленькой не положен?

За день до дедлайна? Бывает и такое, чего ж. Тут как в том анекдоте про студенческий ад с гвоздями. В случае с agile (или с "agile", если угодно) он наступает каждую неделю. Кому-то это нравится, а кому-то нет — это уж вопрос предпочтений.

SD>Начали за здравие, кончили за упокой. Таки оказалось, что дело не в подходе, а в руководстве.

И да и нет. Когда вождь заставляет туземцев строить самолеты из листьев и палок — проблема явно не только в вожде. По крайней мере сложно себе представить, что у него получится так же запросто провернуть что-то подобное не в Полинезии, а где-нибудь в Домодедово или на атомном авианосце.

Полная хрень, автор про Agile знает из статей на википедии, и явно путает Agile и Scrum.
В тексте просто каша из инженерных практик, фреймворков и инструментов разработки. Уважаемый, стоит ознакомиться вообще с принципами управления проектами, тогда у вас будут какие-то еще знания к подходам, кроме "Обычный подход" и "Agile-подход".
И да, TDD, итеративность, системы контроля версий и еще много-много чего используются при разработке проекта и по вотерфолу, и RUP, и (о боже!) даже PMI!

Здравствуйте, netfantom, Вы писали:

N>Полная хрень, автор про Agile знает из статей на википедии, и явно путает Agile и Scrum.

Здесь у вас открывается широкий простор для того, чтоб описать свое видение Agile и Scrum, а также их принципиальных отличий применительно к обсуждаемой теме. Без этого утверждение звучит слегка голословно, уж извините.

N>В тексте просто каша из инженерных практик, фреймворков и инструментов разработки.

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

N>И да, TDD, итеративность, системы контроля версий и еще много-много чего используются при разработке проекта и по вотерфолу, и RUP, и (о боже!) даже PMI!

Собственно этого здесь тоже никто не отрицает. Вы бы попробовали что ли внимательнее перечитать топик, вместо того, чтобы праведно агриться на знакомые слова.

Agile это фикция. Что важно — это средний IQ (читай: квалификация, опыт, ответственность) по команде, желание персонала работать и понимание целевой точки у руководителя. Всё остальное не имеет абсолютно никакого значения. Никакого. Абсолютно.

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

Берите на работу качественную рабочую силу, и будем вам счастье. Будете брать некачественную — будет несчастье, и бесполезно шаманить со способом планирования, назначения задач, контролем хода процесса и вообще с чем-либо. ("вы как ни садитесь, в музыканты не годитесь")

p.s. Руководитель естественно часть команды и его IQ надо учитывать в расчётах

Очевидно, что в основе всего человеческий фактор, что ключ к успеху — это люди. Но agile позволяет _повысить_ эффективность работы команды.
Если команда не эффективная, то и с agile она будет не эффективная.

Здравствуйте, Andreo_K, Вы писали:

A_K>Agile это фикция. Что важно — это средний IQ (читай: квалификация, опыт, ответственность) по команде, желание персонала работать и понимание целевой точки у руководителя. Всё остальное не имеет абсолютно никакого значения. Никакого. Абсолютно.

A_K>Одну и ту же команду заставьте работать по разным методологиям — результат будет совершенно одинаковый. Одинаково хороший или одинаково плохой — зависит от среднего IQ по команде.

A_K>Берите на работу качественную рабочую силу, и будем вам счастье. Будете брать некачественную — будет несчастье, и бесполезно шаманить со способом планирования, назначения задач, контролем хода процесса и вообще с чем-либо. ("вы как ни садитесь, в музыканты не годитесь")

A_K>p.s. Руководитель естественно часть команды и его IQ надо учитывать в расчётах

BB>Очевидно, что в основе всего человеческий фактор, что ключ к успеху — это люди. Но agile позволяет _повысить_ эффективность работы команды.

Несмотря на то, что сам являюсь сторонником и проповедником Agile, таки отмечу — эффективность команды сам по себе Agile не повысит. Да и не в этом цель. Предсказуемость — вот что важнее и вот что является ключевым свойством.

Здравствуйте, SkyDance, Вы писали:


SD> Предсказуемость — вот что важнее и вот что является ключевым свойством.

Предсказуемость чего?

A_K>Предсказуемость чего?

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

Здравствуйте, Пацак, Вы писали:

П>Agile-подход
П>10:03
...
П>21:54

Странно как-то вы все описали. Что мешает при возникновении одновременных задача попросить тимлида приоретизировать, а в 7 вечера пойти домой? Или кодер, работающий при обычном процессе от звонка до звонка, благодаря аджайлу становится энтузиастом-трудоголиком? Так это же хорошо.

Здравствуйте, dleo, Вы писали:

D>Странно как-то вы все описали. Что мешает при возникновении одновременных задача попросить тимлида приоретизировать, а в 7 вечера пойти домой?

Вариантов много. Самый примитивный — например тимлид физически может быть где-нибудь в другом городе/стране, а фраза "тимлид подходит" на самом деле обозначает, что он внезапно становится на 15 минут online в скайпе.

D>Или кодер, работающий при обычном процессе от звонка до звонка, благодаря аджайлу становится энтузиастом-трудоголиком? Так это же хорошо.

Чего ж хорошего-то? Нервные клетки не восстанавливаются, как ни крути.

Здравствуйте, Andreo_K, Вы писали:

SD>> Предсказуемость — вот что важнее и вот что является ключевым свойством.

A_K>Предсказуемость чего?

Например, благодаря Agile я точно знал, что проект который начали делать 6 месяцев назад обещая закончить за два месяця — не будет сделан и через 6 следующих месяцев, несмотря на обещания закончить через два (на момент предсказания). И вуаля — в кои это веки прогнозы сбылись. И теперь я точно могу сказать (благодаря Agile), что хотя проект обещают выдать в продакшен уже через 4 месяца (на текущий момент), что он не будет готов в этом году.