Comments 38
Тут сложно не согласиться. По сути, изначально простой посыл «гибко подстраиваться под изменяющиеся требования» сейчас превратился в кучу ритуалов, участники которых зачастую нифига уже и не помнят, зачем оно всё создавалось.
Всё, что я вынес за годы практики и разного вида «у нас тут свой аджайл» сводится буквально к одному – хорошей команде при адекватном менеджменте аджайл (плюс другие фреймворки, позволяющие сделать процесс разработки и доставки управляемым) поможет стать еще лучше, остальным не поможет ничего.
Потому что принципы agile не реализуемы без дотошного высокоуровневого менеджмента.
Господам, наминусовавшим без контраргументов, и молчаливым читателям поясню:
Аджайл это ценности.
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
Эти ценности буквально говорят, что главное — качественный продукт кастомеру. Если ваши процессы мешают созданию продукта, то подвиньте их. Потому что «Working software is the primary measure of progress».
В хороших командах эти ценности позволяют в спорных моментах принимать правильные решения в пользу проекта.
В плохих командах эти ценности используют для защиты собственных интересов членами команды при срывах сроков и прочих проблемах.
Если представить все это как уравнение, то ценности и принципы — это коэффициент. Что умножаешь на этот коэффициент, то и получаешь в итоге, только в большем количестве.
Если команде с плохим менеджментом (менеджмент это не только менеджеры, которые ставят тасочки, это в целом культура и процессы в команде, уровень планиварония, отношение к проекту, понимание своих обязанностей), просто так взять и начать работать руководствуясь принципами гибкой разработки, то это чаще приведет к еще большему бардаку. Если в команде отсутствовало грамотное планирование, оно не появится, если просто поддержать эти ценности. Если у членов команды были проблемы с ответственностью и налаживанием процессов, то «individuals and interactions over processes and tools» будет использоваться как оправдание.
Как же придерживаться этих ценностей на практике и получать хороший результат?
Для этого можно посмотреть на вполне рабочий Scrum, который «аgile framework» — набор готовых инструментов, позволяющий работать, придерживаясь вышеуказанных ценностей. Набор описанных процессов и правил, следуя которым, вы будете делать продукт быстрее и с лучшим контролем качества, регулярнее доставлять продукт кастомеру и более гибко реагировать на изменения.
Почему Скрам позволяет работать по принципам Agile, можно понять, взглянув на его «внутренности». Там вдруг оказывается куча правил, которые нельзя нарушать, множество ограничений, ежедневные строгий контроль результата, постоянные митинги, тщательное планирование, ответственность каждого члена команды за результат. Скрам — это про хороший, внимательный к мелочам менеджмент.
Да, есть еще «пацанский» Scrum, когда команда просто переходит, к примеру, на спринты, оставив при этом все старые плохие привычки в процессах, и считает что этого достаточно. А потому статьи пишут, какие эти ваши скрамы с аджайлами говно.
Аджайл это хорошо, потому что это работа на результат. Чем слаженней команда, чем устойчивее процессы в ней и чем лучше дисциплина, тем больше подобные принципы помогают достичь желаемого результата. Потому что за гибкостью стоит слаженная работа, которая невозможна без дисциплины, хорошего менеджмента, планирования.
Аджайл это ценности.
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
Эти ценности буквально говорят, что главное — качественный продукт кастомеру. Если ваши процессы мешают созданию продукта, то подвиньте их. Потому что «Working software is the primary measure of progress».
В хороших командах эти ценности позволяют в спорных моментах принимать правильные решения в пользу проекта.
В плохих командах эти ценности используют для защиты собственных интересов членами команды при срывах сроков и прочих проблемах.
Если представить все это как уравнение, то ценности и принципы — это коэффициент. Что умножаешь на этот коэффициент, то и получаешь в итоге, только в большем количестве.
Если команде с плохим менеджментом (менеджмент это не только менеджеры, которые ставят тасочки, это в целом культура и процессы в команде, уровень планиварония, отношение к проекту, понимание своих обязанностей), просто так взять и начать работать руководствуясь принципами гибкой разработки, то это чаще приведет к еще большему бардаку. Если в команде отсутствовало грамотное планирование, оно не появится, если просто поддержать эти ценности. Если у членов команды были проблемы с ответственностью и налаживанием процессов, то «individuals and interactions over processes and tools» будет использоваться как оправдание.
Как же придерживаться этих ценностей на практике и получать хороший результат?
Для этого можно посмотреть на вполне рабочий Scrum, который «аgile framework» — набор готовых инструментов, позволяющий работать, придерживаясь вышеуказанных ценностей. Набор описанных процессов и правил, следуя которым, вы будете делать продукт быстрее и с лучшим контролем качества, регулярнее доставлять продукт кастомеру и более гибко реагировать на изменения.
Почему Скрам позволяет работать по принципам Agile, можно понять, взглянув на его «внутренности». Там вдруг оказывается куча правил, которые нельзя нарушать, множество ограничений, ежедневные строгий контроль результата, постоянные митинги, тщательное планирование, ответственность каждого члена команды за результат. Скрам — это про хороший, внимательный к мелочам менеджмент.
Да, есть еще «пацанский» Scrum, когда команда просто переходит, к примеру, на спринты, оставив при этом все старые плохие привычки в процессах, и считает что этого достаточно. А потому статьи пишут, какие эти ваши скрамы с аджайлами говно.
Аджайл это хорошо, потому что это работа на результат. Чем слаженней команда, чем устойчивее процессы в ней и чем лучше дисциплина, тем больше подобные принципы помогают достичь желаемого результата. Потому что за гибкостью стоит слаженная работа, которая невозможна без дисциплины, хорошего менеджмента, планирования.
хорошей команде при адекватном менеджменте аджайл (плюс другие фреймворки, позволяющие сделать процесс разработки и доставки управляемым)… просто не нужны!
Процессы нужны. Потому что какая бы классная не была бы команда, но люди например болеют или увольняются. И в такой ситуации если у вас сыгранная команда, но нет процессов, то Вам надо каждый раз «сыгрывать» команду заново когда приходят/уходят люди.
Или например такие вещи как увеличение фирмы/отдела. Что вы например будете делать если у вас вдруг из одной команды нужно сделать две, три, пять, десять потому что фирма растёт и растёт обьём работ?
Или например такие вещи как увеличение фирмы/отдела. Что вы например будете делать если у вас вдруг из одной команды нужно сделать две, три, пять, десять потому что фирма растёт и растёт обьём работ?
Если такое происходит часто — уволюсь. Нет, правда уволюсь. Разбивать сыгранную команду — преступно. Перемешивать разработчиков для «распространеня знаний» просто глупо. На выходе вы полцчите две несыгранные команды и издерганых разработчиков.
Чтоб два раза не вставать… Вам не кажется, что автор статьи пришел из какого-то культа? Там характерные фразы про завоевание, присвоение успехов и соответственно сваливание вины за неудачи, неприятие прямо противоположной точки зрения просто потому, что она явно противоречит его принципам и т.д.
Насчет правильноги и неправильного agile… Не, ребята, так не пойдет. Методология или есть или нет. Если есть, что отвественность за неудачи лежит именно на методологии, а не на том, что «ее неправильно применили». Неправильно применили потому, что методология допускает неправильное применение.
Ответ на вопрос почему программисты не хотят больше играть в agile прост — наигрались. Мы любим играть. Это в натуре у нас — пробовать все новое. Но так-же как и у детей как только стало понятно что это и зачем — разобрать, сломать и выбросить за ненадобностью. Так и с agile — новизна ушла, магия кончилась, интерес пропал. На самом деле разработчики гораздо больше понимают в разработке ПО, чем все эти мастера, коучи и консалтеры вместе взятые. Поэтому впарить то, что не дает весомых приимуществ, очень сложно. Оно может таже в итоге выгладеть «как положено» (зомби agile), но внутри все равно будет именно тот процесс, что выбран программистами.
По всему вышесказаному, считаю, что единственая методология — отсутствие таковой. Точнее команда всегда сама выбирает как ей работать. Очень правильно все описано в оригинальном варианте «programming mother...» / «пиши код...» (русский перевод настолько искажен, что лучше его вообще не читать).
Чтоб два раза не вставать… Вам не кажется, что автор статьи пришел из какого-то культа? Там характерные фразы про завоевание, присвоение успехов и соответственно сваливание вины за неудачи, неприятие прямо противоположной точки зрения просто потому, что она явно противоречит его принципам и т.д.
Насчет правильноги и неправильного agile… Не, ребята, так не пойдет. Методология или есть или нет. Если есть, что отвественность за неудачи лежит именно на методологии, а не на том, что «ее неправильно применили». Неправильно применили потому, что методология допускает неправильное применение.
Ответ на вопрос почему программисты не хотят больше играть в agile прост — наигрались. Мы любим играть. Это в натуре у нас — пробовать все новое. Но так-же как и у детей как только стало понятно что это и зачем — разобрать, сломать и выбросить за ненадобностью. Так и с agile — новизна ушла, магия кончилась, интерес пропал. На самом деле разработчики гораздо больше понимают в разработке ПО, чем все эти мастера, коучи и консалтеры вместе взятые. Поэтому впарить то, что не дает весомых приимуществ, очень сложно. Оно может таже в итоге выгладеть «как положено» (зомби agile), но внутри все равно будет именно тот процесс, что выбран программистами.
По всему вышесказаному, считаю, что единственая методология — отсутствие таковой. Точнее команда всегда сама выбирает как ей работать. Очень правильно все описано в оригинальном варианте «programming mother...» / «пиши код...» (русский перевод настолько искажен, что лучше его вообще не читать).
Разбивать сыгранную команду — преступно
Это может быть насколько угодно преступно, но это происходит повсеместно, даже в самых лучших фирмах. И часто действительно из необходимости и не по желанию самой фирмы. Люди болеют, увольняются, уходят на повышение и т.д. и т.п.
Фирма конечно может надеяться что сыгранная команда останется сыгранной на протяжении десятилетий, но как минимум по моему опыту каждые полтора-два года происходят какие-то изменения.
Насчет правильноги и неправильного agile… Не, ребята, так не пойдет. Методология или есть или нет.
Методология Agile как такового на самом деле очень гибкая и «разрешает» многое. Поэтому Аgile-процесс может быть кривым до невозможности и всё равно оставаться в рамках Аgile.
Ответ на вопрос почему программисты не хотят больше играть в agile прост — наигрались.
А вот тут надо говорить за себя. Я например всё ещё хочу в это играть. Потому что Agile далеко не идеален, но лучшей альтернативы я лично пока не вижу.
По всему вышесказаному, считаю, что единственая методология — отсутствие таковой. Точнее команда всегда сама выбирает как ей работать.
Извините, но это и есть Agile. И в нормальном Agile команда подстраивает процессы под себя. Но процессы всё равно есть и все в команде должны и им следовать. Ну или совместно их менять.
Знаком с компанией, в которой, по сути, разработка идёт по принципу "х**к, х**к, и в продакшн". Менеджмент гордо называет это аджайлом. Нет, есть Git, Bitbucket (правда, совсем не везде), есть код-ревью (правда, совсем не всегда), есть дев-сервера (на которых из-за специфики некоторые вещи не обкатываются)… TDD нет от слова "совсем". Кодовая база на миллионы строк кода (не считая библиотечного). Маленькая команда разработчиков, человек 6-7. Не все старожилы (самые старожилы давно куда-то улетели), не все сениоры и даже миддлы. А компания с 90-х растёт и процветает. У разработчиков работы всегда много, но почти никогда никто не стоит за спиной, допрашивая насчёт дедлайна. Никто не перерабатывает (супер-серьёзные деплои делают ночью, но это очень редко). В целом, все довольны жизнью. Такое, вообще, возможно, или они в сказку попали?
Есть такая штука — как человеческий фактор. Его нельзя полностью формализовать, несбыточна мечта менеджмента. Человек может горы свернуть, если правильно мотивировать, а можно излишней формалистикой вообще все ростки убить, даже самые последние. От себя могу сказать, что в период, когда этих умных «фраз» было меньше — делали больше: и заказчик был доволен и у нас клиентура росла. Может моложе были, не знаю. Не буду судить. Сейчас же, менеджмент все хочет контролировать и, в результате, «выплескивает из корыта и ребенка» — сам продукт собственно. То, что сам процесс формализовали — это хорошо. Но то, как по факту массово применили — плохо. Надо подходить ко всему, взвешивая за и против.
Agile — это просто неумеренно раздутый слон, которого пытаются продать даже в блошиный цирк. И пока продают, увы.
UFO just landed and posted this here
Agile Yahooтак толсто, что даже тонко.
Очень много букв :-), но, в общем, соглашусь.
Ещё добавлю фразу-вопрос одного топ-менеджера про то, зачем Agile'ом называть здравый смысл.
На мой взгляд, различные фреймворки (XP, Scrum, DSDM и т.п.) — это способы понять, о чём Agile, но беда в том, что некомпетентность всё развращает.
Всё по делу. Менеджмент ничего не понимает в разработке, но при этом ему нужно показывать свою значимость и видимость, а это реструктуризация, изменение системы управления. Поиграются на компании, и уходят в другую с повышением. Модная тема, которую топы используют в своих интересах. А вокруг консультанты рубят капусту. Хорошую идею Agile, как и социализм, испоганили и превратили в что-то нарицательное.
Организовать удачный agile — это как постичь Дзен: куча нюансов и тонкостей, бесполезно копировать чужой опыт и упражняться, всегда нужно помнить о сути. Коммерсанты развели ересь.
Agile — это слово маркетологов для привлечения клиентов. Как раньше .com, недавно биткоин и другие всем известные «волшебные» слова, от которых рука инвестора или топ-менеджера тянется к кошельку.
В основополагающих принципах Agile нет ничего нового и ранее до Agile никому неизвестного. А некоторые из них противоречат один другому согласно принципу выбери два из трех: Качественно — Быстро — Дешево.
Все ищут волшебную таблетку, которой в реальности нет и никогда не было. Думать надо самостоятельно и организовывать работу в соответствии с решаемыми задачами. Если есть для этого уже готовые подходящие методики и инструменты, их надо использовать. Только смотреть насколько они подходят именно вам, а не пихать всех подряд в прокрустово ложе одного из многих методов.
В основополагающих принципах Agile нет ничего нового и ранее до Agile никому неизвестного. А некоторые из них противоречат один другому согласно принципу выбери два из трех: Качественно — Быстро — Дешево.
Все ищут волшебную таблетку, которой в реальности нет и никогда не было. Думать надо самостоятельно и организовывать работу в соответствии с решаемыми задачами. Если есть для этого уже готовые подходящие методики и инструменты, их надо использовать. Только смотреть насколько они подходят именно вам, а не пихать всех подряд в прокрустово ложе одного из многих методов.
Есть лишь два метода разработки: хорошо организованный и дезорганизованный.
Революцию задумываются романтики. Реализуют фанатики. А плодами пользуются негодяи.
Так же используется agile.
Благими намерениями выстелена дорого в ад.
В ад похоже уже пришли.
Так же используется agile.
Благими намерениями выстелена дорого в ад.
В ад похоже уже пришли.
Agile стал мантрой: говори вслух про гибкую разработку и твори фигню!
У нас Agile — поэтому мы внесём критические правки в задачи спринта за 2 дня до релиза.
У нас Agile — средняя загрузка разработчиков по оцененому времени за спринт 600%.
У нас Agile — поэтому нет времени на документацию.
У нас Agile — и мы будем делать по 5-7 часовых встреч в день, работать — в любое остальное время.
Раньше это называлось «у нас хреновый руководитель».
У нас Agile — поэтому мы внесём критические правки в задачи спринта за 2 дня до релиза.
У нас Agile — средняя загрузка разработчиков по оцененому времени за спринт 600%.
У нас Agile — поэтому нет времени на документацию.
У нас Agile — и мы будем делать по 5-7 часовых встреч в день, работать — в любое остальное время.
Раньше это называлось «у нас хреновый руководитель».
Симптомы знакомы, но если по честному, то проблема не в том что Agile или Scrum это что-то плохое, а в том что люди делают непонятно что и называют это Agile/Scrum :)
П.С. По хорошему всё что Вы описали в нормальном Agile/Scrum не прокатывет потому что команда говорит на это всё четкое «нет» и делает по своему. А если команде не дают делать по своему и какой-то «руководитель» со стороны командует вам что делать, то какой это тогда Scrum?
П.С. По хорошему всё что Вы описали в нормальном Agile/Scrum не прокатывет потому что команда говорит на это всё четкое «нет» и делает по своему. А если команде не дают делать по своему и какой-то «руководитель» со стороны командует вам что делать, то какой это тогда Scrum?
И я о том же.
Наверное, скоро будут флажки выпускать, и чую, у всех компаний над входом в HRрню будет висеть одинаковый набор «корпоративные ценности, стрессоустойчивость, нацеленность на результат, Agile»
PS Причём, флажки будут грязными, потому что их повесят и забудут до Дня Компании.
А о сути флажков забудут ещё в процессе крепления этих флажков.
Наверное, скоро будут флажки выпускать, и чую, у всех компаний над входом в HRрню будет висеть одинаковый набор «корпоративные ценности, стрессоустойчивость, нацеленность на результат, Agile»
PS Причём, флажки будут грязными, потому что их повесят и забудут до Дня Компании.
А о сути флажков забудут ещё в процессе крепления этих флажков.
То, что я описал — это практически любой кровавый энтерпрайз с руководителем команды, который смирился.
Зайдите в крупный банк, процентов 70 любых проектов будет именно такими, заодно посмотрите на забавный жизненный цикл:
1. выпуск-без-тестов новых фич под «личную ответственность бизнеса»
2. критические ошибки на проде из-за 1 пункта
3. грязные разборки, где оказывается виновата виновата команда, потому что бизнес не мог оценить масштабов трагедии, команда должна была настоять на своём
4. смещение слишком принципиальных руководителей в замы и постановка своего человека, который будет выжимать команду
5. уходы ключевых людей из команды из-за п.4, про реальные роли которых новый руководитель не успел/не захотел узнать
6. goto 1
Нет, есть и хорошие команды, с правильными процессами и руководством, которое умеет показать бизнесу, что если мы ускоримся — будет писец, поэтому мы будем дальше работать по согласованному плану, но это явление не частое.
Зайдите в крупный банк, процентов 70 любых проектов будет именно такими, заодно посмотрите на забавный жизненный цикл:
1. выпуск-без-тестов новых фич под «личную ответственность бизнеса»
2. критические ошибки на проде из-за 1 пункта
3. грязные разборки, где оказывается виновата виновата команда, потому что бизнес не мог оценить масштабов трагедии, команда должна была настоять на своём
4. смещение слишком принципиальных руководителей в замы и постановка своего человека, который будет выжимать команду
5. уходы ключевых людей из команды из-за п.4, про реальные роли которых новый руководитель не успел/не захотел узнать
6. goto 1
Нет, есть и хорошие команды, с правильными процессами и руководством, которое умеет показать бизнесу, что если мы ускоримся — будет писец, поэтому мы будем дальше работать по согласованному плану, но это явление не частое.
Ну на мой взгляд с опытом приходит понимание когда в фирме, в которую тебе предлагаю вакансию, так обстоят дела. Или когда фирма начинает двигаться в этом направлении. И если такое ощущение есть, то надо сразу начинать искать другую работу.
На мой взгляд Scrum/Agile вполне себе работают если люди хотя бы пытаются чтобы они работали. То есть я нигде не видел 100% Scrum, но я вполне себе видел варианты, когда то что было вполне себе работало. И работало лучше чем «водопад» или отсутствие любых нормальных процессов.
На мой взгляд Scrum/Agile вполне себе работают если люди хотя бы пытаются чтобы они работали. То есть я нигде не видел 100% Scrum, но я вполне себе видел варианты, когда то что было вполне себе работало. И работало лучше чем «водопад» или отсутствие любых нормальных процессов.
Статью не осилил, после фразы
Многие уроки можно извлечь из таких гуманитарных наук, как позитивная психология, направленное самосовершенствование и решение-ориентированная терапияподступил ком к горлу, но комменты на удивление позитивные — никто не стал лить воду в стиле эджайл-коучей и скрам-мастеров
Потому что вложить своё знание в чужие головы невозможно, как ни старайся. Можно писать книги, можно говорить афоризмы, можно прибивать к дверям тезисы или издавать манифесты — не работает.
Единственный способ прийти к тем же ценностям, к которым пришли те 15 человек в 2001 году — это пройти путь, похожий на тот, который прошли они.
Единственный способ прийти к тем же ценностям, к которым пришли те 15 человек в 2001 году — это пройти путь, похожий на тот, который прошли они.
Кто-нибудь слышал об успешном применении гибких методов разработки (Agile) в любой не IT-шной компании? Ну скажем в отрасли машиностроения, энергетики, космоса. Или может кто слышал об успешном применении хотя бы в hardware-компаниях?
Agile предназначены для работы в условиях постоянно изменяющихся требований. Вы слышали о существовании инженерных команд в машиностроении, энергетике или космической промышленности, работающих в условиях постоянно изменяющихся требований? :)
UFO just landed and posted this here
Спасибо, я кажется понял — почти все маленькие частные компании в любой отрасли работают применяя гибкие методы (иногда сами того не зная). Иначе им не выжить. Вопрос в том есть ли успешный опыт применения в больших компаниях (сотрудников>100).
почти все маленькие частные компании в любой отрасли работают применяя гибкие методы (иногда сами того не зная)
Скорее нет, чем да. Agile — это не про «делать разные мелкие задачи», а про «делать одну крупную задачу, не имея полной проектной документации». Индивидуальный проект по изготовлению мебели, он не эджайл. Вы пришли к клиенту, согласовали проект, получили предоплату, и делаете в точности по проекту. Изготовили, отдебажили (где что не влезает или не совпадает с ожиданиями клиента), запустили в продакшен, получили оплату. Это просто короткоживущий, но ни разу не гибкий проект.
Почитайте Сазерленда (первую книгу). Он приводит пример компании, которая делает автомобили на заказ и работает по гибкой методологии. Я уже не говорю про то, что все эти практики в IT вдохновлены опытом Toyota, а Сазерленд выводит свою методику из того, чему его учили к военного летчика.
Sign up to leave a comment.
Кризис Agile. Что делать?