Комментарии 99
Автор немножечко потролил конечно. :-)
Особенно радует начало:
и конец:
Особенно радует начало:
Я здесь не собираюсь никого разубеждать. Я хочу поделиться соображениями, почему большинству компаний аджайл действительно не подходит.
и конец:
Так что если вы заинтересованы в успехе проекта, используйте аджайл. Если вам важнее ваша зона комфорта — что ж, заварите кофе и приступайте к чтению новостей. Agile вам пока не подходит.
Когда увидел заголовок — ожидал увидеть какой нибудь разумный топик о недостатках Аджаила. Тут не немножко — тут автор сильно потролил — что ни абзац — везде подтекст — «если не хочешь успешного продукта — не надо использовать аджаил». Ни слова о недостатках — все перечисленные недостатки с подтекстом что это сплошные достоинства.
Простите, тут ва сами себя обманули. Я никаких недостатк ов не обещал.
Видимо, в головах у людей сложилось уже несколько стереотипов, какими должны быть статьи об аджайл, вот вы и ожидали топик о недостатках.
Видимо, в головах у людей сложилось уже несколько стереотипов, какими должны быть статьи об аджайл, вот вы и ожидали топик о недостатках.
> «Почему Agile вам не подходит».
Вы действительно считаете что по ссылке можно ожидать сплошной текст почему аджаил подходит? У вас в статье нет ни одной конструктивной критики аджаила — описаны одни достоинства — но только с саркастичным изложением. В комментари EvilShadow, в последнем обзаце гораздо больше конструктивных примеров почему действительно agail может не подходить, чем у Вас во всем тексте статьи.
Лично я хорошего мнения об аджаил, и практикуем уже в нескольких проектах. Знаю много плюсов и минусов. Учавствовал в нескольких успешных и провальных проектов как без аджаила так и с аджаилом. Ваша статья — еще одина сплашная хвалебная статья — коих уже много — только в саркастичном подтексте — «он вам не подходит если хотите завалить проект и вам плевать на проект и ваши личные интересы превыше всего».
Вы действительно считаете что по ссылке можно ожидать сплошной текст почему аджаил подходит? У вас в статье нет ни одной конструктивной критики аджаила — описаны одни достоинства — но только с саркастичным изложением. В комментари EvilShadow, в последнем обзаце гораздо больше конструктивных примеров почему действительно agail может не подходить, чем у Вас во всем тексте статьи.
Лично я хорошего мнения об аджаил, и практикуем уже в нескольких проектах. Знаю много плюсов и минусов. Учавствовал в нескольких успешных и провальных проектов как без аджаила так и с аджаилом. Ваша статья — еще одина сплашная хвалебная статья — коих уже много — только в саркастичном подтексте — «он вам не подходит если хотите завалить проект и вам плевать на проект и ваши личные интересы превыше всего».
Любая технология хорошо работает в тех обстоятельствах, для которых она придумана.
Поэтому вполне логично, что я описал, в каких обстоятельствах аджайл хорошо работает, а если у вас обстоятельства другие — тогда для вас он не работает. По-моему, всё абсолютно логично.
Скорее нелогично говорить «аджайл нам не подходит, потому что у нас такие-то обстоятельства», потому что таких «неподходящих» обстоятельств может быть сколько угодно, но это никак не приблизит к понимаю «правильных» обстоятельств.
В этом-то и состоит весь смысл статьи: я формулирую «подходящие» обстоятельства для аджайла не так, как это делают обычно. На мой взгляд, моя формулировка лучше помогает понять суть вещей, поэтому я и поспешил ей поделиться.
Поэтому вполне логично, что я описал, в каких обстоятельствах аджайл хорошо работает, а если у вас обстоятельства другие — тогда для вас он не работает. По-моему, всё абсолютно логично.
Скорее нелогично говорить «аджайл нам не подходит, потому что у нас такие-то обстоятельства», потому что таких «неподходящих» обстоятельств может быть сколько угодно, но это никак не приблизит к понимаю «правильных» обстоятельств.
В этом-то и состоит весь смысл статьи: я формулирую «подходящие» обстоятельства для аджайла не так, как это делают обычно. На мой взгляд, моя формулировка лучше помогает понять суть вещей, поэтому я и поспешил ей поделиться.
Я хочу сказать автору большое спасибо! Реально, очень интересный взгляд со стороны. Мысль очень глубока и иметь её ввиду очень важно! Я практиковал аджайл(и планирую практиковать дальше) и могу подтвердить что так оно и есть, как описано.
И тут нет тролинга — тут конструктивный трезвый взгляд на каждую из возможных проблем, о которой нужно знать!
И тут нет тролинга — тут конструктивный трезвый взгляд на каждую из возможных проблем, о которой нужно знать!
аджайл предписывает ежедневные утренние собрания
Так-то идея хорошая, но… это моё любимое время, когда я только пришёл на работу, заварил себе кофе — самое время полчасика пробежаться по новостям и свежим анекдотам.
То, что это утренние собрания — не более, чем рекомендация, на самом деле это просто самое оптимальное время для стендапа. но Аджайл не предписывает, что они должны проходить именно утром. Поэтому, если в компании большинству удобнее собираться в конце рабочего дня — без проблем.
А мы, например, у себя в команде проводим стендапы сразу после обеда. И тому есть несколько причин:
1. утром действительно хочется выпить кофе, прочитать пару новостей и, как это ни странно, заняться работой, потому что голова еще свежая, не захламлена офисным шумом и кучей багов. Именно поэтому до обеда производительность выше чем после обеда (по крайней мере в нашей команде).
2. большинство людей после обеда хотят либо спать, либо просто посидеть поклевать носом, повтыкать на какой-нить сайт. Одним словом, производительность в первые полчаса-час после обеда низкая, потому что кровь отливает к желудку и мозгу совсем не до мыслей. Стендап после обеда позволяет чуть-чуть взбодрить свой организм, не дать ему скатиться в режим дня «перед уходом».
3. на стендапе мы разбираем не что сделано вчера и что собираемся сделать сегодня, а какие ошибки исправлены вчера, что сделано до обеда и какие ошибки есть, которые надо исправить до вечера. Благодаря этому мы сами себя стимулируем четко сформулировать задачу на вторую половину дня.
4. после стендапа как раз самое время решать те проблемы, которые возникли утром, можно пару часов поработать в режиме парного программирования, либо заняться рефакторингом какого-нибудь фрагмента кода. В общем после обеда продуктивной разработки чего-то нового не получается.
1. утром действительно хочется выпить кофе, прочитать пару новостей и, как это ни странно, заняться работой, потому что голова еще свежая, не захламлена офисным шумом и кучей багов. Именно поэтому до обеда производительность выше чем после обеда (по крайней мере в нашей команде).
2. большинство людей после обеда хотят либо спать, либо просто посидеть поклевать носом, повтыкать на какой-нить сайт. Одним словом, производительность в первые полчаса-час после обеда низкая, потому что кровь отливает к желудку и мозгу совсем не до мыслей. Стендап после обеда позволяет чуть-чуть взбодрить свой организм, не дать ему скатиться в режим дня «перед уходом».
3. на стендапе мы разбираем не что сделано вчера и что собираемся сделать сегодня, а какие ошибки исправлены вчера, что сделано до обеда и какие ошибки есть, которые надо исправить до вечера. Благодаря этому мы сами себя стимулируем четко сформулировать задачу на вторую половину дня.
4. после стендапа как раз самое время решать те проблемы, которые возникли утром, можно пару часов поработать в режиме парного программирования, либо заняться рефакторингом какого-нибудь фрагмента кода. В общем после обеда продуктивной разработки чего-то нового не получается.
Интересно. Мы делаем по утрам для того, чтобы все приходили на работу вовремя.
А после обеда мы играем в настольный футбол.
А после обеда мы играем в настольный футбол.
А вот у нас как раз половина команды приходит к 8 часам, половина к 9. Не вижу смысла мучить свой организм — если человек выспался — он лучше работает.
Верно. Поэтому у нас все к 9.
А если человек вчера ночером ходил в кино с девушкой и хочет придти к 10? А если человек жаворонок и все равно просыпается в 6-7 утра и хочет придти с работы не в 18, а в 17 часов, чтобы больше времени уделить семье? В общем команда должна быть гибкой тоже, а не только методология.
Да ничего, эти проблемы легко решаются. Жаворонки приходят к 6. Главное, чтобы к 9 все были на месте.
Если конкретно сегодня кто-то чувствует себя плохо, то конечно, может прийти и позже. Главное тут, что все это воспринимают как исключение из правил. Если это будет происходить слишком часто, все это почувствуют.
Раньше я работал в компании, где разработчики могли приходить в любое время. И из гибкости превратилось в бардак! Сначала все приходили к 9, потом часть стала подтягиваться лишь к 10, потом часть к 11… В итоге всех собрать вместе раньше 11.30 никак не удавалось. И то ненадолго, потому что жаворонки уже и на обед идут. Так что дисциплина всё-таки нужна.
Если конкретно сегодня кто-то чувствует себя плохо, то конечно, может прийти и позже. Главное тут, что все это воспринимают как исключение из правил. Если это будет происходить слишком часто, все это почувствуют.
Раньше я работал в компании, где разработчики могли приходить в любое время. И из гибкости превратилось в бардак! Сначала все приходили к 9, потом часть стала подтягиваться лишь к 10, потом часть к 11… В итоге всех собрать вместе раньше 11.30 никак не удавалось. И то ненадолго, потому что жаворонки уже и на обед идут. Так что дисциплина всё-таки нужна.
ну так и почему бы не делать скрам/стендап/утреннее собрание как раз в 11:30.
а может попробовать еще какой-то вариант?
есть много проектов в которых команда распределенная и им как-то удается эффективно обмениваться информацией.
ведь бардак — это совсем не то что все делают работу когда им удобно.
бардак — это когда нет согласованности и ожидаемого результата.
затягивая гайки вы лишаете себя радужного чувства свободы.
оно конечно будет работать и даже хорошо, но не будет так привлекательно для людей.
в управлении есть такая штука — что контролируем, то и получаем.
введением обязательных часов на рабочем месте вы решаете вопрос согласования работ и обмена информацией внутри команды.
перед тем как принимать такие жесткие меры как ограничение свободы своих сотрудников попробуйте поставить задачу команде решить эту проблему.
возможно самое удобное время для этого — ретроспектива.
контролируйте принятые договоренности и отслеживайте результат чтобы дать обратную связь о том как все идет.
а лучше чтобы ребята сами контролировали свои обязательства.
это как-то вроде по взрослому и профессионально — отвечать за свои слова.
ну и уж если все-таки это не удалось, принимайте личное решение (но тогда это уже точно не agile :)
кстати, может получитья и так что команда сама решит ограничить себя обязательными часами.
agile он не о практиках, он о качественном продукте и эффективном взаимодействии.
поэтому если у вас не выходят стендапы или не работают итерации, может вам они и не нужны.
и цели которые достигаются этими практиками нужно решать как-то по другому.
а может попробовать еще какой-то вариант?
есть много проектов в которых команда распределенная и им как-то удается эффективно обмениваться информацией.
ведь бардак — это совсем не то что все делают работу когда им удобно.
бардак — это когда нет согласованности и ожидаемого результата.
затягивая гайки вы лишаете себя радужного чувства свободы.
оно конечно будет работать и даже хорошо, но не будет так привлекательно для людей.
в управлении есть такая штука — что контролируем, то и получаем.
введением обязательных часов на рабочем месте вы решаете вопрос согласования работ и обмена информацией внутри команды.
перед тем как принимать такие жесткие меры как ограничение свободы своих сотрудников попробуйте поставить задачу команде решить эту проблему.
возможно самое удобное время для этого — ретроспектива.
контролируйте принятые договоренности и отслеживайте результат чтобы дать обратную связь о том как все идет.
а лучше чтобы ребята сами контролировали свои обязательства.
это как-то вроде по взрослому и профессионально — отвечать за свои слова.
ну и уж если все-таки это не удалось, принимайте личное решение (но тогда это уже точно не agile :)
кстати, может получитья и так что команда сама решит ограничить себя обязательными часами.
agile он не о практиках, он о качественном продукте и эффективном взаимодействии.
поэтому если у вас не выходят стендапы или не работают итерации, может вам они и не нужны.
и цели которые достигаются этими практиками нужно решать как-то по другому.
Сложилось ощущение, что дисциплина вам нужна только ради дисциплины. Может и не нужно было ежедневно собирать всех вместе?
Интересно
> Мы делаем по утрам для того, чтобы все приходили на работу вовремя.
Т.е. с одной стороны вы боретесь за то, чтобы сотрудники отрабатывали своё рабочее время полностью.
Но
> после обеда мы играем в настольный футбол.
Простите, но у меня когнитивный диссонанс.
> Мы делаем по утрам для того, чтобы все приходили на работу вовремя.
Т.е. с одной стороны вы боретесь за то, чтобы сотрудники отрабатывали своё рабочее время полностью.
Но
> после обеда мы играем в настольный футбол.
Простите, но у меня когнитивный диссонанс.
Никакого диссонанса нет. На моей прошлой работе у нас был теннис, и множество людей регулярно в него рубились. Если человек приходит пораньше и уходит попозже, чтобы успеть и работу сделать и в теннис поиграть, то все отлично — как раз теннис это хорошая разминка. А те, кто ищут повод отлынивать от работы, и без тенниса найдут его — аська, вконтакт, твиттер… Теннис хоть полезнее для здоровья.
то есть, людей, которых кто-то ждёт дома, и которые стремятся вечером к близким, у вас в команде нет и не предполагается?
ну тут смотря как рубиться.
у нас тоже на работе есть настольный тенис.
одна-две партейки раз в 3 часа позволяет размяться и прочистить мозги.
А если в это время ещё и проветриваем помещение, то можно играть и двое на двое.
у нас тоже на работе есть настольный тенис.
одна-две партейки раз в 3 часа позволяет размяться и прочистить мозги.
А если в это время ещё и проветриваем помещение, то можно играть и двое на двое.
Поинт в том, что если человеку надо уйти домой пораньше, и он ответственен, он не будет посреди рабочего дня рубиться в теннис. Если он безответственный, то он и без тенниса найдет чем отвлечься, как я уже сказал.
На прошлой работе сложилось исторически так, что большинство людей приходили поздно и уходили поздно, даже семейные.
На прошлой работе сложилось исторически так, что большинство людей приходили поздно и уходили поздно, даже семейные.
Мы прововодим перед обедом и в групповом чате скайпа. Собрание в скайпе позволяет вернутся и перечитать итоги собрания в случае чего.
Именно так.
Положим, аджайл НЕ предписывает утренние собрание ни разу. Аджайл предписывает принцип — удовлетворение заказчика через регулярные частые поставки работающих версий продукта. Но, как всегда, есть масса тренеров, коучей и проповедников, которые начинают втирать, КАК правильно заниматься аджайлом, вместо того, чтобы ненавязчиво нести его ДУХ.
Некоторые из принятых практик аджайла, например, CI, безусловно полезны. Некоторые, такие как ежедневные утренние митинги, навязчивы, трудно организумы в реальности (если в команде больше 3-4 человек), и часто являются бессмысленной тратой времени.
Простая истина — митинг, в котором участвуют 10 человек, имеет смысл только если это либо обзорный kick-off митинг перед началом итерации, либо раз в неделю на короткое ревью того что сделано, или на ретроспекцию. Собирать ВСЮ команду КАЖДЫЙ день в одно и то же время обсудить статус — это бессмысленная трата времени и усилия на то, чтобы собрать людей вместе.
Проповедники аджайла часто не учитывают, что в реальной жизни собрать 7-8 человек на митинг — трудно.
Петя — сова, и лучше всего работает если ему удается работать с 12 дня до 10 вечера.
Аня — имеет маленького ребенка, и поэтому часто работает из дома (да, фуллтайм программисты в серьезных компаниях могут часто работать из дома), что не мешает ей быть отличным спецом.
У Васи больная спина, и два раза в неделю он ходит по утрам у к врачу.
У Лены в 8-9 утра часто идут звонки от заказчика, на которые он должны отвечать, и поэтому в это время она редко бывает доступна.
Костя живет в таком месте, что если ему ехать к 9 утра, то надо стоять в диких пробках и добираться до работы он будет час с лишним, а вот если он едет к 10-30, то добирается до офиса за 30 минут.
И что, собирать их всех вместе в одно и то же время? Зачем? Митинг из 7-8 человек в скраме, это митинг, где говорят в каждый момент времени скрам мастер либо один из участников, а остальные зевают, читают почту с телефона или работают с ноутов.
И зачем такое счастье?
Положим, аджайл НЕ предписывает утренние собрание ни разу. Аджайл предписывает принцип — удовлетворение заказчика через регулярные частые поставки работающих версий продукта. Но, как всегда, есть масса тренеров, коучей и проповедников, которые начинают втирать, КАК правильно заниматься аджайлом, вместо того, чтобы ненавязчиво нести его ДУХ.
Некоторые из принятых практик аджайла, например, CI, безусловно полезны. Некоторые, такие как ежедневные утренние митинги, навязчивы, трудно организумы в реальности (если в команде больше 3-4 человек), и часто являются бессмысленной тратой времени.
Простая истина — митинг, в котором участвуют 10 человек, имеет смысл только если это либо обзорный kick-off митинг перед началом итерации, либо раз в неделю на короткое ревью того что сделано, или на ретроспекцию. Собирать ВСЮ команду КАЖДЫЙ день в одно и то же время обсудить статус — это бессмысленная трата времени и усилия на то, чтобы собрать людей вместе.
Проповедники аджайла часто не учитывают, что в реальной жизни собрать 7-8 человек на митинг — трудно.
Петя — сова, и лучше всего работает если ему удается работать с 12 дня до 10 вечера.
Аня — имеет маленького ребенка, и поэтому часто работает из дома (да, фуллтайм программисты в серьезных компаниях могут часто работать из дома), что не мешает ей быть отличным спецом.
У Васи больная спина, и два раза в неделю он ходит по утрам у к врачу.
У Лены в 8-9 утра часто идут звонки от заказчика, на которые он должны отвечать, и поэтому в это время она редко бывает доступна.
Костя живет в таком месте, что если ему ехать к 9 утра, то надо стоять в диких пробках и добираться до работы он будет час с лишним, а вот если он едет к 10-30, то добирается до офиса за 30 минут.
И что, собирать их всех вместе в одно и то же время? Зачем? Митинг из 7-8 человек в скраме, это митинг, где говорят в каждый момент времени скрам мастер либо один из участников, а остальные зевают, читают почту с телефона или работают с ноутов.
И зачем такое счастье?
для большинства разработчиков собственный комфорт важнее, чем работающий софт, чем успех компании и всё прочее.
Каковы подлецы! Конечно, они не являются владельцами бизнеса и им от успеха компании ни холодно ни жарко, но где же корпоративный дух???
И наконец, один из самых больших мотиваторов — это, как ни странно, живое общение с клиентом. Сравните: когда к вам приходит начальник и спрашивает: «Ну что, наконец-то доделал?», и когда к вам приходит клиент и говорит: «Вау, вы это сделали! Это то, что надо, спасибо!»
Или когда к вам приходит клиент и говорит: «И это всё, что вы сделали???», убивая тем самым мотивацию. И это нормальная позиция, клиент в разработке ничего не смыслит (и не должен, не его это дело), ему невдомёк, что за двумя видимыми изменениями скрываются десятки незаметных для него. С клиентом должны общаться специально обученные люди, а разработчик должен общаться с тем, кто может адекватно формулировать хотелки. И это далеко не всегда сам клиент, а часто его технически подкованный представитель. Разработчик должен разрабатывать, а не практиковаться в социологии и маркетинге.
1. Не надо передёргивать, я не говорил, что подлецы. Я никого не осуждаю, просто констатирую факт.
2. Что зачит «должен — не должен»? Я говорю о своём опыте: у нас разработчики общаюсь непосредственно с клиентом. И я описываю, как на меня как на разработчика это влияет. Замечательно влияет. Да. клиенты бывают разные, но в любом случае общение с ними очень влияет на процесс разработки. А вы мне — «должен, должен»…
2. Что зачит «должен — не должен»? Я говорю о своём опыте: у нас разработчики общаюсь непосредственно с клиентом. И я описываю, как на меня как на разработчика это влияет. Замечательно влияет. Да. клиенты бывают разные, но в любом случае общение с ними очень влияет на процесс разработки. А вы мне — «должен, должен»…
Если у вас это работает и работает «хорошо» — всё хорошо)
В моём мире, опытные разработчики и люди умные в академическом смысле часто бывают склонны к интеллектуальному иллитизму. Проще говоря активно придерживаются мнения, что «я умный (что в общем-то верно если говорить CS и околоCSных вещах), а эта „девочка“ — »манагерша проекта" — представитель заказчика — мммм… «неумная»."
В такой ситуации — поведение «программиста» при общении с «заказчиком» становится — неконструктивным. «Программист» своей микромиимкой, жестами, и интонациями невербально выражает глубокое сожаление от того, что ему приходится общаться с этой бестолочью. Девушка-«манагер» — такое негативное поведение чувствует и (она ведь тоже самый обычный человек) — отвечает неконструктивным поведением: агрессией, требованиями в форме ультиматумов и прочей бескомпромиссностью. И всё — положительная обратная связь. Все проиграли.
Ну и субъективно — такое нарушение инкапсуляции приводит к тем же результатам, что и при проектировании классов.
В моём мире, опытные разработчики и люди умные в академическом смысле часто бывают склонны к интеллектуальному иллитизму. Проще говоря активно придерживаются мнения, что «я умный (что в общем-то верно если говорить CS и околоCSных вещах), а эта „девочка“ — »манагерша проекта" — представитель заказчика — мммм… «неумная»."
В такой ситуации — поведение «программиста» при общении с «заказчиком» становится — неконструктивным. «Программист» своей микромиимкой, жестами, и интонациями невербально выражает глубокое сожаление от того, что ему приходится общаться с этой бестолочью. Девушка-«манагер» — такое негативное поведение чувствует и (она ведь тоже самый обычный человек) — отвечает неконструктивным поведением: агрессией, требованиями в форме ультиматумов и прочей бескомпромиссностью. И всё — положительная обратная связь. Все проиграли.
Ну и субъективно — такое нарушение инкапсуляции приводит к тем же результатам, что и при проектировании классов.
ЭЛИТИЗМ. интеллектуалы, ага.
Ага. Ну хорошо, вы добавили к моему списку ещё один пункт. Аджайл не подходит заносчивым, считающим себя слишком умными в академическом смысле людям. Спасибо.
А какой процесс лучше подходит таким людям?
А какой процесс лучше подходит таким людям?
Пригласите меня в свой чудесный идеальный мир, а?
Таким людям подходит либо роль примадонны, когда все мирятся с их прихотями, потому что за час работы они делают больше, чем другие за неделю, либо роль отшельника, если академические знания не превращаются регулярно в практический результат. Если человек в самом деле настолько крут, что потянет роль примадонны, то место ему найдется в любой команде. Вопрос будет только в том, достаточно ли умны остальные участники проекта, чтобы использовать такую звезду на все 100% и не заморачиваться из-за его прихотей.
В то же время, уверен, что настоящих примадонн, которых имеет смысл лелеять, в нашем мире очень мало. Если программист себя ведет, как примадонна, то зачастую это связано с проблемами в управлении проектом.
В то же время, уверен, что настоящих примадонн, которых имеет смысл лелеять, в нашем мире очень мало. Если программист себя ведет, как примадонна, то зачастую это связано с проблемами в управлении проектом.
Не совсем так. Я говорил о том, что допускать представителя заказчика до плотной работы с разработчиками может давать плохие результаты. Инкапсуляция команды «внутри менеджера» всё же «безопасней».
Что же касается внутрикомандного взаимодействия таких «звезд», то:
если руководитель группы/проекта не занимается ерундой, а работает со своими людьми — то опять же можно мягко и постепенно донести до своих звезд 2 мысли:
1)Все могут ошибаться и звезда в том числе. И когда человек ведет себя как «задница» — ему становится очень сложно признать свои ошибки. Это вредит отношением в коллективе и авторитету звезды.
2)В команде у нас специалисты разного уровня. Да. Большинство из них не знает что такое монады. Но дело в том, что большая часть работы в любом проекте — скучная рутина. И эти «незнающие монад» люди делают значительную часть этой грязной работы, давая возможность звезде читать про свои драгоценные монады.
Впрочем — всё это в равной мере относится к любому виду процесса. Agile тут совсем не причём.
Что же касается внутрикомандного взаимодействия таких «звезд», то:
если руководитель группы/проекта не занимается ерундой, а работает со своими людьми — то опять же можно мягко и постепенно донести до своих звезд 2 мысли:
1)Все могут ошибаться и звезда в том числе. И когда человек ведет себя как «задница» — ему становится очень сложно признать свои ошибки. Это вредит отношением в коллективе и авторитету звезды.
2)В команде у нас специалисты разного уровня. Да. Большинство из них не знает что такое монады. Но дело в том, что большая часть работы в любом проекте — скучная рутина. И эти «незнающие монад» люди делают значительную часть этой грязной работы, давая возможность звезде читать про свои драгоценные монады.
Впрочем — всё это в равной мере относится к любому виду процесса. Agile тут совсем не причём.
Я бы сказал немного по другому. Аджайл не подходит людям, для которых по настоящему сложные и нетривиальные технические проблемы интереснее и важнее, чем следование укладка процесса в рамки и подгонка всего и вся под какие то общие практики.
Если вы решаете по настоящему сложные задачи, вы, скорее всего, собираетесь опираться на нетривиальных, умных неординарных людей. При этом, вы не учитываете, что такие люди часто не любят излишнего контроля над собой, и главенства менеджерского духа над технарским.
Аджайл не подходит людям, которые умеют контролировать себя сами и отвечать за свои поступки, вместо того, чтобы отдать свою личную свободу в обмен на избавление от излишней ответственности и рисков со стороны «команды».
По другому, проще сказать так. У меня ощущение, что в вашей интерпретации, команда выше, чем отдельный программист в ней. Команда решила, каковы должны быть его часы работы, команда решила то, се. При таком подходе вы применяете уравниловку, что часто будет раздражать некоторых людей. Я вот не хочу например, приходить каждое утро к 9 утра, чтобы слушать нудные разглагольствования скрам-мастер. Пусть он соберет от всех текущий статус, напишет мне и прочим письмо со статус-апдейтом, и все прочитают, когда и где им удобно.
Если вы решаете по настоящему сложные задачи, вы, скорее всего, собираетесь опираться на нетривиальных, умных неординарных людей. При этом, вы не учитываете, что такие люди часто не любят излишнего контроля над собой, и главенства менеджерского духа над технарским.
Аджайл не подходит людям, которые умеют контролировать себя сами и отвечать за свои поступки, вместо того, чтобы отдать свою личную свободу в обмен на избавление от излишней ответственности и рисков со стороны «команды».
По другому, проще сказать так. У меня ощущение, что в вашей интерпретации, команда выше, чем отдельный программист в ней. Команда решила, каковы должны быть его часы работы, команда решила то, се. При таком подходе вы применяете уравниловку, что часто будет раздражать некоторых людей. Я вот не хочу например, приходить каждое утро к 9 утра, чтобы слушать нудные разглагольствования скрам-мастер. Пусть он соберет от всех текущий статус, напишет мне и прочим письмо со статус-апдейтом, и все прочитают, когда и где им удобно.
В данном случае не нужно говорить «клиент» — такая подмена понятий приводит к искажению смысла (и нарушению инкапсуляции)). Если это происходит на практике, то неизбежно создаёт ситуацию когда «scrum не подходит». Вверять неподготовленному клиенту постановку продуктовых задач и взаимодействие с командой не только неразумно, это просто опасно.
В методологии scrum взаимодействие команды и невовлечённых представителей клиента (stakeholders, скажем) случается не часто и очень жестко регламентируется. Обычно команда взаимодействует с человеком, играющим конкретную роль — «Product Owner». PO это разумная прослойка между клиентом и разработчиками, которая конвертирует «хотелки» бизнеса, в требования, задачи и приоритеты, соответствующие продукту и понятные команде. Очевидно, что для этого нужно «быть в теме», и не всякая «манагерша проекта» способна играть роль PO.
Если строить аналогию, то PO как водитель автомобиля. Он должен разбираться в бизнесе примерно в той же мере в какой водитель — ориентироваться в городе. Он должен учитывать особенности продукта и команды в той же степени, в какой водитель учитывает особенности вверенного ему механизма. Т.е. с одной стороны — знать как из точки A попасть в точку Б, наиболее эффективным образом, не намотав лишние километры и не простояв лишние часы в пробках. С другой — не трогаться с места включив 5-тую передачу, не смотря на то, что она самая быстрая, планировать не только поездки, но и заправки, а так же время для мойки и тех.обслуживания.
В методологии scrum взаимодействие команды и невовлечённых представителей клиента (stakeholders, скажем) случается не часто и очень жестко регламентируется. Обычно команда взаимодействует с человеком, играющим конкретную роль — «Product Owner». PO это разумная прослойка между клиентом и разработчиками, которая конвертирует «хотелки» бизнеса, в требования, задачи и приоритеты, соответствующие продукту и понятные команде. Очевидно, что для этого нужно «быть в теме», и не всякая «манагерша проекта» способна играть роль PO.
Если строить аналогию, то PO как водитель автомобиля. Он должен разбираться в бизнесе примерно в той же мере в какой водитель — ориентироваться в городе. Он должен учитывать особенности продукта и команды в той же степени, в какой водитель учитывает особенности вверенного ему механизма. Т.е. с одной стороны — знать как из точки A попасть в точку Б, наиболее эффективным образом, не намотав лишние километры и не простояв лишние часы в пробках. С другой — не трогаться с места включив 5-тую передачу, не смотря на то, что она самая быстрая, планировать не только поездки, но и заправки, а так же время для мойки и тех.обслуживания.
Простите, не совсем понял с чем в моём утверждении Вы не согласны.
asolntsev написал, что у них в компании «разработчики общаюсь непосредственно с клиентом», на что я сказал, что такая организация может приводить к печальным последствиям.
Мне показалось, что вы в своём комментарии пишете о том же. Нет?
asolntsev написал, что у них в компании «разработчики общаюсь непосредственно с клиентом», на что я сказал, что такая организация может приводить к печальным последствиям.
Мне показалось, что вы в своём комментарии пишете о том же. Нет?
Если представитель заказчика достаточно компетентен в вопросах разработки, то ему можно доверить общение с разработчиками. Если представитель исполнителя достаточно компетентен в предметной области заказчика, то ему можно доверить общение с заказчиком. Если продолжить аналогию, то заказчик может арендовать автомобиль (команду разработчиков) и по сути самому управлять процессом, а может взять такси и лишь сообщать куда ему надо (да еще по дороге изменить решение, раз уже говорим об аджайл).
А к печальным последствиям может привести, когда заказчик хочет ехать, а исполнитель предоставляет шашечки. Или наоборот.
А к печальным последствиям может привести, когда заказчик хочет ехать, а исполнитель предоставляет шашечки. Или наоборот.
А какой «умный» руководитель поставил над опытными разработчиками девочку-манагершу? При любых раскладах менеджер должен иметь авторитет среди разработчиков, и это совершенно не зависит от методологии. При чем тут Аджайл? Разве при любом другом подходе такой диссонанс не приведет к плачевным результатам?
Там речь шла о «девочке-представителе» заказчика. В реальной жизни у заказчика часто может не найтись другого представителя.
Что же до того, о чём пишете Вы: «поставил над опытными разработчиками девочку-манагершу». Вы так удивляетесь, как будто никогда с таким не сталкивались в релаьной жизни)
При чём тут agile. Да вы правы — не причём. Мой комментарий относился к практике asolntsev который писал, что у них в компании «разработчики общаюсь непосредственно с клиентом»
Что же до того, о чём пишете Вы: «поставил над опытными разработчиками девочку-манагершу». Вы так удивляетесь, как будто никогда с таким не сталкивались в релаьной жизни)
При чём тут agile. Да вы правы — не причём. Мой комментарий относился к практике asolntsev который писал, что у них в компании «разработчики общаюсь непосредственно с клиентом»
Agile — это один из способов создать качественный продукт в сроки. Другое дело, что само желание работать качественно, должно прочно устояться в атмосфере компании. Иначе все сводиться к культу карго.
В какой-то момент я понял, что Agile — не утверждённый перечень советов, практик, методик и тп. Это — общий стиль, идея, направленность. Это всё равно что «ренессанс» — нет чётких критериев, есть общее мировоззрение. Аджайл гибок не только к разработке, он гибок в первую очередь к себе.
С командой мы прошли долгий путь от жёсткого следования «стандартам» до нынешней точки, когда у нас свой внутрикорпоративный аджайл, который всех устраивает и никому не мешает.
Надо пробовать и приспосабливать его под себя, не забывай о бест-практисес — и будет счастье :)
С командой мы прошли долгий путь от жёсткого следования «стандартам» до нынешней точки, когда у нас свой внутрикорпоративный аджайл, который всех устраивает и никому не мешает.
Надо пробовать и приспосабливать его под себя, не забывай о бест-практисес — и будет счастье :)
Хороший пример, как НЕ надо называть свою статью.
Из-за названия полезная статья легла на душу как скрытый PR.
Из-за названия полезная статья легла на душу как скрытый PR.
Мы работаем сейчас по agile. Вот как бы вообще не получается. Я даже боюсь назвать, то чем сейчас стало все.
Для полноценного использования гибких методологий нужны не только гибкие методики, но и гибкая и профессиональная команда и гибкая платформа. Вот тогда можно говорить о гибких разработках. А если проект построен на древней платформе или в команде одни консерваторы, то никакой аджаил ее не спасет.
ЗЫ: это адресовалось не именно вашей команде, вполне возможно у вас команда отличная, но не хватает чего-то еще.
ЗЫ: это адресовалось не именно вашей команде, вполне возможно у вас команда отличная, но не хватает чего-то еще.
Согласен с автором, что вероятность создать работающий продукт удовлетворяющий потребности заказчика, маловероятно, если разработчики этого не хотят. Ходить на работу где платят деньги, есть нормальный интернет и НАДО что-то делать, или когда к разработке есть интерес, хочется осваивать и использовать новые технологии, создавать работающие программы которыми пользуются люди, это разные вещи.
Профессиональность также очень важна, если разработчик не может проектировать и конструировать ПО, и не может контролировать его эволюцию, то никакие гибкие методики тут не помогут.
А трудность освоения TDD до уровня приносящего значительную пользу, это скорее косность нашего образа мышления, большинство из нас наверняка начинали с процедурного программирования или ООП, мы привыкли писать код, и лишь потом проверять его, и уж если что-то не работает, тогда лезть в отладчик.
Как рассказывал Кент Бек (по моему в книге о TDD) «я научил свою старшую дочку Бетани программировать, используя стиль TDD, и теперь она думает что только так и нужно писать программы».
Профессиональность также очень важна, если разработчик не может проектировать и конструировать ПО, и не может контролировать его эволюцию, то никакие гибкие методики тут не помогут.
А трудность освоения TDD до уровня приносящего значительную пользу, это скорее косность нашего образа мышления, большинство из нас наверняка начинали с процедурного программирования или ООП, мы привыкли писать код, и лишь потом проверять его, и уж если что-то не работает, тогда лезть в отладчик.
Как рассказывал Кент Бек (по моему в книге о TDD) «я научил свою старшую дочку Бетани программировать, используя стиль TDD, и теперь она думает что только так и нужно писать программы».
Насчёт «никакие гибкие методики тут не помогут» не согласен. Я делал работающий софт, пользуясь «процедурным подходом с отладчиком», причём я его проектировал. Видел недостатки (как потом узнал они называются «монлитность», «связанность» и т. п.), но тупо не видел способа их исправить, кроме как «всё переписать», то «сверху вниз», то «снизу вверх». Когда прочитал того же Бека и стал постепенно использовать TDD, то как-то типичные недостатки стали исчезать сами собой (не сразу, конечно), а, главное, исчезает желание «всё переписать» вместе с желанием «всё запроектировать» и «добиться максимальной универсальности и повторного использования». Переписывать приходится чаще, чтобы тесты оставались простыми, а вот проектировать почти не приходится, но главное не теряется контроль над эволюцией. Правда, параллельно с TDD осваивал и VCS и это тоже сыграло свою роль, но не столь значительную, оказалось хорошим дополнением, но не более — просто разные неработающие тесты (или их небольшие группы при «сильном» рефакторинге) находятся в разных ветках. Не могу сказать, что научился проектировать, скорее научился избегать проектирования.
аджайл предписывает ежедневные утренние собрания — стэндапы
аджайл предлагает Continuous Integration сервер
аджайл прописал парное программирование
Ну вот где здесь такое написано?
Вы совершенно правы, нигде. Это просто так называемые проповедники аджайла, которые по моим ощущениям, зачачстую умеют преподавать аджайл куда лучше, чем создавать качественные продукты, любят рассказывать своей интерпретации, и своих практиках аджайла, которые ОНИ применяют, как о чем-то общепринятом для всего аджайла. Их аджайл уже не, гм, agile
А что такое тогда аджайл? На вкуси цвет фломастеры разные. Аджайл говорит вообще всего об одной вещи — надо быть гибким к их меняющимся условиям разработки продукта, а уж как, дело ваше. А говорить, что мы аджайл или скрам или ХР только потому, что выполнил из списка все пункты, это, извините мен, полная глупость и как раз не аджайл.
Хорошая статья, спасибо. Из неё я узнал, что «agile» — это «аджайл», а не «агиле» :)
НЛО прилетело и опубликовало эту надпись здесь
Добавлю ещё, что Agile и другие «мягкие» системы управления подходят лишь в том случае, если все работники работают для «своей компании», а не просто в «том офисе, где деньги платят».
В статью под заголовком «Почему Agile вам не подходит» я бы написал пожалуй: Потому, что где-то в цепи управления у нас затесался упертый, бестактный, бескомпромиссность идиот. Процесс не может быть более «гибким», чем самый «негибкий» участник-руководитель этого процесса.
Вы ничего не путаете? Единственная причина — идиот в управлении? То есть для методологии, ставящей во главу угла командную работу, главной проблемой является внешняя по отношению к команде причина? Сильно сомневаюсь.
Идиот-руководитель может все испортить, тут не поспоришь. Но никакой умница-руководитель не сможет внедрить Аджайл, если среди программистов затесался такой же упертный идиот, или просто человек, которому ничего не надо.
Поэтому я бы расширил вывод на всех участников проекта: Процесс не может быть более «гибким», чем самый «негибкий» участник этого процесса, включая представителя заказчика.
Идиот-руководитель может все испортить, тут не поспоришь. Но никакой умница-руководитель не сможет внедрить Аджайл, если среди программистов затесался такой же упертный идиот, или просто человек, которому ничего не надо.
Поэтому я бы расширил вывод на всех участников проекта: Процесс не может быть более «гибким», чем самый «негибкий» участник этого процесса, включая представителя заказчика.
>Вы ничего не путаете?
Нет. Я ведь не писал, что это «единственная причина».
Из утверждения «полицейские берут взятки» не следует что «все полицейские берут взятки».
По поводу ситуации с командой. Я всё же придерживаюсь мнения, что проекты обычно не растут как дикий плющ и не появляются ниоткуда. И если руководитель действительно «умница» — то наверно уж он приложит усилия чтобы набрать в команду более подходящих людей. Или если ему достался проект после другого руководителя — либо найти общий язык либо мягко заменить источник гангрены. «Я вижу, что вы очень опытный разработчик. Вы хорошо работаете, и заслуживаете повышения. Но к сожалению — в нашем проекте вам некуда расти выше. И мы это понимаем. И понимаем, что вам возможно было бы интересней перейти в другой проект. Если вы решите искать новое место работы — мы готовы предоставить вам рекомендации в обмен, на помощь в поиске и/или подготовки замены для вас». Ну и всё в таком духе.
Нет. Я ведь не писал, что это «единственная причина».
Из утверждения «полицейские берут взятки» не следует что «все полицейские берут взятки».
По поводу ситуации с командой. Я всё же придерживаюсь мнения, что проекты обычно не растут как дикий плющ и не появляются ниоткуда. И если руководитель действительно «умница» — то наверно уж он приложит усилия чтобы набрать в команду более подходящих людей. Или если ему достался проект после другого руководителя — либо найти общий язык либо мягко заменить источник гангрены. «Я вижу, что вы очень опытный разработчик. Вы хорошо работаете, и заслуживаете повышения. Но к сожалению — в нашем проекте вам некуда расти выше. И мы это понимаем. И понимаем, что вам возможно было бы интересней перейти в другой проект. Если вы решите искать новое место работы — мы готовы предоставить вам рекомендации в обмен, на помощь в поиске и/или подготовки замены для вас». Ну и всё в таком духе.
Значит мы говорим об одном и том же. Только вы делаете упор на то, что руководитель в итоге должен решать проблему с сотрудниками, если она возникнет (то есть на следствие), а я на то, что все участники проекта являются потенциальными источниками проблемы (то есть на первопричину). У вас это прозвучало, как «главная проблема в руководстве» — вот это неправда, поэтому я и ответил, что не в нем только дело.
Статья очень хорошая — по полочкам раскладывает основные трудности внедрения Agile. Все они в том или ином виде относятся к мотивационным проблемам. Аджайл не может работать, когда человек слабо представляет что он делает на рабочем месте и куда ему дальше расти.
Аджайл в первую очередь ориентирован на команду, а не просто группу людей. Перечисленные примеры как раз про ситуацию, когда команды толком нет, когда каждый запирается в своем мирке и там существует. Главная иллюзия такого подхода в том, что человек думает, что это позволяет ему эффективнее расти профессионально (ведь он занимается не бюрократической ерундой, а полезными вещами). И дело не в том заботится человек о компании или нет. Ему достаточно заботиться о своем проекте и своем профессиональном росте, непосредственно связанным с успехом проекта. Если человек этой связи не чувствует (по своей вине или вине руководства), то команда распадается, человек запирается в своем мирке, и ни о каком Аджайле речи быть не может.
Аджайл в первую очередь ориентирован на команду, а не просто группу людей. Перечисленные примеры как раз про ситуацию, когда команды толком нет, когда каждый запирается в своем мирке и там существует. Главная иллюзия такого подхода в том, что человек думает, что это позволяет ему эффективнее расти профессионально (ведь он занимается не бюрократической ерундой, а полезными вещами). И дело не в том заботится человек о компании или нет. Ему достаточно заботиться о своем проекте и своем профессиональном росте, непосредственно связанным с успехом проекта. Если человек этой связи не чувствует (по своей вине или вине руководства), то команда распадается, человек запирается в своем мирке, и ни о каком Аджайле речи быть не может.
Вы ещё забыли о моменте, когда заказчику плевать на ваш ажэайл, он заплатил деньги, сказал что нужно и у него больше нет времени этим заниматься, так как и без этого работы хватает.
Я так понимаю, если у кого-то возникает хоть по одному пункту идея — «а ведь чувак чертовски прав», то ему, действительно, стоит пересмотреть подходит ли ОН аджайлу.
Я так понимаю, если у кого-то возникает хоть по одному пункту идея — «а ведь чувак чертовски прав», то ему, действительно, стоит пересмотреть подходит ли ОН аджайлу.
Как по мне в разделе «Аджайл — это дисциплина» во всех пунктах кроме первого можно вместо agile смело ставить XP.
НЛО прилетело и опубликовало эту надпись здесь
Наймите роботов и пусть колбасят код.
Спасибо автору за статью! Интересно, позновательно!
Из плюсов аджайла, думаю можно еще один написать-это интенсивный обмен опытом, получени новых знаний.
ИМХО: лучше, что бы другие прграммисты видели твой код, чем то восхощались, подсказывали, смеялись, чем ты сам себе будешь что то изобретать, а потом понять что это не то или, хуже, есть готовые библиотеки, наработки, «велосипеды»)
Из плюсов аджайла, думаю можно еще один написать-это интенсивный обмен опытом, получени новых знаний.
ИМХО: лучше, что бы другие прграммисты видели твой код, чем то восхощались, подсказывали, смеялись, чем ты сам себе будешь что то изобретать, а потом понять что это не то или, хуже, есть готовые библиотеки, наработки, «велосипеды»)
Как-то всё, написанное в статье, можно выразить такой строчкой: «Ваш комфорт для вас важнее комфорта клиента? Agile не для вас».
Всё верно.
Я рад, что сумел выразить свои мысли так ясно.
Если так посмотреть, любую книгу и любой фильм можно выразить одной фразой. Вопрос в том, кто какую фразу себе вынесет. Вы вынесли правильную, в отличие от большинства комментариев здесь.
Я рад, что сумел выразить свои мысли так ясно.
Если так посмотреть, любую книгу и любой фильм можно выразить одной фразой. Вопрос в том, кто какую фразу себе вынесет. Вы вынесли правильную, в отличие от большинства комментариев здесь.
Многим людям важен комфорт клиента, они ответственны и готовы, если надо, работать по ночам и выходным, чтобы доставить продукт в срок. Но при этом, они хотят комфорта для себя тоже. Они хотят нормальный кабинет, а не дебильный опен-спейс без перегородок, где невозможно сосредоточиться из-за шума и где постоянно мимо тебя кто-то ходит, они хотят благоутроить свое рабочее место, потому что для них это второй (а часто — первый) дом, они хотят чтобы — «мое рабочее место — моя крепость.». И это нормально.
Основные проблемы ортодоксальных Эджайлистов — это излишняя пафосность и злоупотребление базз-вордами, на мой вгляд. Да внедряйте себе по-тихоньку, только никому не рассказывайте…
Основная проблема многих и многих проповедников аджайла, из-за которых в целом очень разумный, прагматичный и могущий давать хорошие результаты подход многими воспринимается в штыки:
— Аджайл часто проповедуется людьми без достаточного опыта его внедрения в разных типах проектов, команд и компаний, и людьми, у которых частично из-за отсутствия опыта, частично из-за излишней категоричности мышления, есть склонность делить мир на белое и черное и преподносить свой взгляд на мир, как единственно правильный. Из-за чего, когда такой проповедник приходит к команде сильных технарей, они чувствуют его насквозь и воспринимают со скептисом.
Утрированно: «коуч», поднаторевший в аджайле в мелких веб-проектах на руби, приходит к команде enterprise-ников, ораклистов, и начинает им рассказывать про практики CI.
Они ему говорят, что у них есть CI сервер, и тесты на нем проходят скажем, за час, и признают что это их напрягает.
Коуч хватается за бока, утирает слезы, выступившие от смеха, и говорит, что тесты вместе с билдом должны проходить все за 5 минут, а у вас, ущербных, они проходят за час — а все потому, что аджайла у вас нет, ребята.
Один из программистов разумно замечает, что тесты, использующие базу, работают долго, а именно таких тестов у них очень много.
Коуч опять хватается за бока, и поясняет, что нужно использовать везде моки и писать UNIT-тесты, а к базе должны обращаться только приемочно-интеграционные тесты, которые должны быть отделены от билда и все такое.
Один из ораклистов, с проявляющимся раздражением, указывает, что у них три четверти логики написано на PL-SQL (для примера), вылизана для производительности и без реальной базы все тесты не будут иметь смысла. В ответ на это, Коуч, который до того, как стать проповедником, писал небольшие проекты на руби, указывает, что можно использовать embedded-дв, и писать тесты на них, в ответ на замечание ораклиста, что все эти хранимые процедуры используют специфичный для оракла синтаксис и переписать их на SQL Lite или что-то подобное — это отдельная нетривиальная задача.
Услышав от коуча, что писать SQL, непереносимый между базами данных, это плохо, и что привязка к опреленной БД — это кошмар-кошмар, ораклист приходит к выходу, что разговаривает с некомпетентным идиотом, который с настоящими БД в настоящих проектах не работал, но который лезет учить «как правильно», и на этом разговор заканчивается.
К чему это я? У команды определенно, есть проблема. Она специфична в контексте этой команды и определенного проекта.
Тренер по аджайлу, который хочет его внедрить в этой команде, должен все это учитывать, должен быть реалистом, должен поработать в индустрии над реальными проектами, стать циником и прагматиком, понимать какие практики конкретно для этой команды могут заработать, а какие не стоит даже и предлагать.
И только потом, идти проповедовать аджайл. Без риска нарваться на такие коментарии, как мои :))
— Аджайл часто проповедуется людьми без достаточного опыта его внедрения в разных типах проектов, команд и компаний, и людьми, у которых частично из-за отсутствия опыта, частично из-за излишней категоричности мышления, есть склонность делить мир на белое и черное и преподносить свой взгляд на мир, как единственно правильный. Из-за чего, когда такой проповедник приходит к команде сильных технарей, они чувствуют его насквозь и воспринимают со скептисом.
Утрированно: «коуч», поднаторевший в аджайле в мелких веб-проектах на руби, приходит к команде enterprise-ников, ораклистов, и начинает им рассказывать про практики CI.
Они ему говорят, что у них есть CI сервер, и тесты на нем проходят скажем, за час, и признают что это их напрягает.
Коуч хватается за бока, утирает слезы, выступившие от смеха, и говорит, что тесты вместе с билдом должны проходить все за 5 минут, а у вас, ущербных, они проходят за час — а все потому, что аджайла у вас нет, ребята.
Один из программистов разумно замечает, что тесты, использующие базу, работают долго, а именно таких тестов у них очень много.
Коуч опять хватается за бока, и поясняет, что нужно использовать везде моки и писать UNIT-тесты, а к базе должны обращаться только приемочно-интеграционные тесты, которые должны быть отделены от билда и все такое.
Один из ораклистов, с проявляющимся раздражением, указывает, что у них три четверти логики написано на PL-SQL (для примера), вылизана для производительности и без реальной базы все тесты не будут иметь смысла. В ответ на это, Коуч, который до того, как стать проповедником, писал небольшие проекты на руби, указывает, что можно использовать embedded-дв, и писать тесты на них, в ответ на замечание ораклиста, что все эти хранимые процедуры используют специфичный для оракла синтаксис и переписать их на SQL Lite или что-то подобное — это отдельная нетривиальная задача.
Услышав от коуча, что писать SQL, непереносимый между базами данных, это плохо, и что привязка к опреленной БД — это кошмар-кошмар, ораклист приходит к выходу, что разговаривает с некомпетентным идиотом, который с настоящими БД в настоящих проектах не работал, но который лезет учить «как правильно», и на этом разговор заканчивается.
К чему это я? У команды определенно, есть проблема. Она специфична в контексте этой команды и определенного проекта.
Тренер по аджайлу, который хочет его внедрить в этой команде, должен все это учитывать, должен быть реалистом, должен поработать в индустрии над реальными проектами, стать циником и прагматиком, понимать какие практики конкретно для этой команды могут заработать, а какие не стоит даже и предлагать.
И только потом, идти проповедовать аджайл. Без риска нарваться на такие коментарии, как мои :))
Правда, приятно порассуждать про плохих проповедников и хороших программистов? ЧСВ повышается семимильными шагами и разрядка хорошая. А учитывая огромное преимущество в количестве программистов над всеми остальными еще и рейтинг вверх лезет. Благодать!
А на самом деле вы занимаетесь обычным троллингом. Когда человек пытается разобраться в проблеме и делает выводы, с которомы практически невозможно спорить, потому что с такими примерами сталкиваются все и всегда, вы за неимением аргументов начинаете многословно рассказывать про проповедника-идиота. Это по сути классическое «сам дурак».
А на самом деле вы занимаетесь обычным троллингом. Когда человек пытается разобраться в проблеме и делает выводы, с которомы практически невозможно спорить, потому что с такими примерами сталкиваются все и всегда, вы за неимением аргументов начинаете многословно рассказывать про проповедника-идиота. Это по сути классическое «сам дурак».
Какой рейтинг, где вы его видите?
Моя история — это иллюстрация real world case, специально сделанная понятной. С моим основным пунктом вы будете спорить? Что проповедники аджайла, которые умеют красиво говорить но НЕ являются сильными и опытными техническими специалистами, часто не вызывают доверия у последних и подрывают веру в аджайл как методологию?
Моя история — это иллюстрация real world case, специально сделанная понятной. С моим основным пунктом вы будете спорить? Что проповедники аджайла, которые умеют красиво говорить но НЕ являются сильными и опытными техническими специалистами, часто не вызывают доверия у последних и подрывают веру в аджайл как методологию?
Да вот же он — посмотрите на ваши плюсики. Или вы с этим поспорить хотите?
С основным вашим основным пунктом спорить невозможно, как и с основным пунктом в посте. Поэтому в нем другого смысла кроме «сам дурак» и нет. Автор поста пытается выяснить почему именно так происходит, а вы рассказываете банальности о том, что некомпетентный человек все может испортить. При этом в вашем случае идиот — сторонник аджайла, а технические специалисты сплошь умницы. Вы ни разу не встречали идиота-программиста? Идиотами всегда были другие люди? Конечно встречали, так зачем этот пафос?
И еще по секрету: чтобы грамотно внедрить методологию не обязательно быть техническим специалистом, обязательно понимать суть, докапываться до источника проблем и уметь работать с людьми. Умный человек с этим справится и не будучи техническим специалистом. А вот сами рограммисты далеко е всегда обладают этими навыками.
С основным вашим основным пунктом спорить невозможно, как и с основным пунктом в посте. Поэтому в нем другого смысла кроме «сам дурак» и нет. Автор поста пытается выяснить почему именно так происходит, а вы рассказываете банальности о том, что некомпетентный человек все может испортить. При этом в вашем случае идиот — сторонник аджайла, а технические специалисты сплошь умницы. Вы ни разу не встречали идиота-программиста? Идиотами всегда были другие люди? Конечно встречали, так зачем этот пафос?
И еще по секрету: чтобы грамотно внедрить методологию не обязательно быть техническим специалистом, обязательно понимать суть, докапываться до источника проблем и уметь работать с людьми. Умный человек с этим справится и не будучи техническим специалистом. А вот сами рограммисты далеко е всегда обладают этими навыками.
Если вы смысла еще не видите, то дальше объяснять уже смысла особого нет. Скажем так. Я встречал идиотов-программистов. Дофига. А вот по настоящему полезных аджайл тренеров — нет.
Без всякого секрета скажу, если вы внедряете методологию (кстати, прожженые айтишники, по секрету, часто ненавидят само понятие «методология»), не обладая конкретными техническими знаниями в той области, где у проекта проблемы, то для технически мыслящих людей вы выглядите ну, примерно как для нормального человека выглядит впариватель, который приходит к вам домой, и предлагает купить супер мега утюг всего за 2999 рублей.
Что вы понимаете под «уметь работать с людьми»? Уметь красиво говорить, показывать слайды и улыбаться в камеру?
Без всякого секрета скажу, если вы внедряете методологию (кстати, прожженые айтишники, по секрету, часто ненавидят само понятие «методология»), не обладая конкретными техническими знаниями в той области, где у проекта проблемы, то для технически мыслящих людей вы выглядите ну, примерно как для нормального человека выглядит впариватель, который приходит к вам домой, и предлагает купить супер мега утюг всего за 2999 рублей.
Что вы понимаете под «уметь работать с людьми»? Уметь красиво говорить, показывать слайды и улыбаться в камеру?
Не все коучи одинаковы полезны) Миш, скольких коучей ты слушали на скольких аджайл тренингах ты был?
Спасибо, за потрясающий коммент. Очень сильно написано. :)
Спасибо за статью, хорошее утреннее настроение и возможность посмотреть на людей, которые боятся аджайла, потому что им придется работать больше чем обычно)
Ничего против Agile не имею, только за, т.к. упорядочивание процесса — это хорошо. Только вот статья написана в духе «Agile для самых маленьких. С иллюстрациями». Поэтому возникает много вопросов:
1. Agile требует накладных расходов. Например, 5-минутная встреча абсолютно бесполезна, если представляет собой чтение в слух с выражением задач из багтрекера. А любое обсуждение возникших трудностей превращает её в часовой разговор о делах наших скорбных. Всё это требует времени разработчика, за которое платит компания. В итоге это приводит к повышению стоимости разработки, что не есть хорошо, ведь мы заботимся о благе организации.
2. Предполагается, что в проекте идеальная ситуация: один проект, длительный срок, нет просроченных задач и т.д. А теперь представим реальную ситуацию, когда проектов несколько. Переключаться между ними тяжело, а значит обобщить все задачи будет трудно. Или, к примеру, прибегает менеджер с воплем «шеф, усё пропало». Недовольные клиенты штурмуют офис — взяли первый этаж и сбоями продвигаются к кухне. Как быть в этом случае?
3. Прозрачность кода — это хорошо. Но что если в проектной команде каждой твари по паре? Один верстальщик, один flash-разработчик, один js-разработчик, один специалист по базам данных и т.д. Кто и что будет проверять? Кто будет проводить код-ревью и т.д.?
1. Agile требует накладных расходов. Например, 5-минутная встреча абсолютно бесполезна, если представляет собой чтение в слух с выражением задач из багтрекера. А любое обсуждение возникших трудностей превращает её в часовой разговор о делах наших скорбных. Всё это требует времени разработчика, за которое платит компания. В итоге это приводит к повышению стоимости разработки, что не есть хорошо, ведь мы заботимся о благе организации.
2. Предполагается, что в проекте идеальная ситуация: один проект, длительный срок, нет просроченных задач и т.д. А теперь представим реальную ситуацию, когда проектов несколько. Переключаться между ними тяжело, а значит обобщить все задачи будет трудно. Или, к примеру, прибегает менеджер с воплем «шеф, усё пропало». Недовольные клиенты штурмуют офис — взяли первый этаж и сбоями продвигаются к кухне. Как быть в этом случае?
3. Прозрачность кода — это хорошо. Но что если в проектной команде каждой твари по паре? Один верстальщик, один flash-разработчик, один js-разработчик, один специалист по базам данных и т.д. Кто и что будет проверять? Кто будет проводить код-ревью и т.д.?
Есть некоторый опыт в agile, могу попробовать ответить.
>1
Во-первых постановки задач из багтрекера зачитывать не нужно, нужно рассказывать о том, как идут дела с выполнением задач. Насчет затяжных встреч. Разработчики далеко не 8 из 8 часов работают. Потратить на обсуждение задач 40 скорее полезно, чем вредно.
>2
Я так понимаю вы говорить о скраме, где команда берет обязательства на итерацию? Есть такое, но это проблема скрама, а на agile. У нас вот перешли на канбан, там с этим по-лучше.
>3
О парном программировании тут нельзя говорить, но перекрестное код-ревью делать можно. Еще часто говорят о кроссфункциональности. О полноценной взаимозаменяемости тут сложно говорить. Но предположим верстальщик заболел, а в проде нашли серьезный баг. Если кто-нибудь в команде не сможет его пофиксить, будет беда. Можно устраивать семинары, где каждый будет обучать каким-то азам своего дела всех остальных.
>1
Во-первых постановки задач из багтрекера зачитывать не нужно, нужно рассказывать о том, как идут дела с выполнением задач. Насчет затяжных встреч. Разработчики далеко не 8 из 8 часов работают. Потратить на обсуждение задач 40 скорее полезно, чем вредно.
>2
Я так понимаю вы говорить о скраме, где команда берет обязательства на итерацию? Есть такое, но это проблема скрама, а на agile. У нас вот перешли на канбан, там с этим по-лучше.
>3
О парном программировании тут нельзя говорить, но перекрестное код-ревью делать можно. Еще часто говорят о кроссфункциональности. О полноценной взаимозаменяемости тут сложно говорить. Но предположим верстальщик заболел, а в проде нашли серьезный баг. Если кто-нибудь в команде не сможет его пофиксить, будет беда. Можно устраивать семинары, где каждый будет обучать каким-то азам своего дела всех остальных.
Ещё до кучи можно добавить «любовь» разработчиков демонстрировать свои результаты по окончанию каждой итерации (из Scrum).
Да, да. Аджайл — это дисциплина (а, RUP видимо — вершина безалаберностью). Всегда казалось, что аджайл — это гибкость, свобода. Жертвуем строгостью процесса, ради более эффективной работы. Individuals and interactions over processes and tools и все такое.
Но, проповедники налегают. В общем, комментарии выше вскрывают проблемы в полной мере, почти нечего добавить.
Но, проповедники налегают. В общем, комментарии выше вскрывают проблемы в полной мере, почти нечего добавить.
А по-вашему, Аджайл — вершина безалаберности?
Да, аджайл — это гибкость и свобода в части планирования задач. Но чтобы обеспечить эту гибкость, нужна строгая дисциплина в части технической реализации. Комментарии выше раскрывают лишь ту проблему, что люди не понимают и не хотят понимать, что такое аджайл. Только ленивый не упомянул про проповедников аджайл. Они, конечно, существуют, но в данном случае разговор о них не к месту.
Да, аджайл — это гибкость и свобода в части планирования задач. Но чтобы обеспечить эту гибкость, нужна строгая дисциплина в части технической реализации. Комментарии выше раскрывают лишь ту проблему, что люди не понимают и не хотят понимать, что такое аджайл. Только ленивый не упомянул про проповедников аджайл. Они, конечно, существуют, но в данном случае разговор о них не к месту.
Я вам про другое. «Individuals and interactions over processes and tools» — манифест аджайла, ага. А потом тут говорят, что каждый член команды должен приходить к 9 утра потому что «команда так решила» (прям как будто — партия сказала «надо!», комсомол ответил — «есть!»), если только у него нет какой то веской причины и прочее.
Нормально, когда я могу позвонить коллеге/менеджеру/CTO и сказать — «я — сегодня приду около 12, ладно? Если что — звони.» И он не будет спрашивать а почему и по какой причине и что это за дела, потом что он знает, что на меня можно положиться, и если я не буду из-за этог что-то успевать, то нагоню потом вечером или на выходных. Вот это и есть — treating individuals..over processes…
Нормально, когда я могу позвонить коллеге/менеджеру/CTO и сказать — «я — сегодня приду около 12, ладно? Если что — звони.» И он не будет спрашивать а почему и по какой причине и что это за дела, потом что он знает, что на меня можно положиться, и если я не буду из-за этог что-то успевать, то нагоню потом вечером или на выходных. Вот это и есть — treating individuals..over processes…
Если б я была разработчиком не имеющем представления о том, что такое аджайл, то после прочтения данной статьи и ваших комментариев к ней, бежала бы от аджайла, как от чумы.
Такое ощениние, что вы очень далеко ушели от основных идей и принципов, и подменили отсутствие личной мотивации армейской дисциплиной.)))
При этом откуда-то взялись обязательные приходы в 9 утра, отсутствие личного пространства и прочая ересь.
Одной время мне довелось работать в команде, где первый работник приходил в 6 утра и уходил в 14.00. Остальные собирались, кто к 10, кто 11, а кто и вообще к 13.00. Просто потому что им это было удобно. И — сюрприз, сюрприз — никаких проблем ни у кого это не вызывало.
В другой команде митинги перенесли с вечера на обед. Просто потому что всем членам команды было, в принципе, все равно, когда их проводить, а мой рабочий день заканчивался в 13.00 — 13.30. Опять-таки, все живы и счастливы.
Пускать кого-то за свой рабочий стол? Два монитора и одна виртуалка отлично решают эту проблему — и вуаля, вот вам и парное программирование, и личный комфорт.
Вопрос в том, как подходить к процессу. Было бы желание, а решение — найдется.
Поэтому, я бы сказала, что все с точностью наоборот: из-за поблажек в плане формальной дисциплины аджайл не подойдет тем, у кого проблемы с мотивацией и саодисциплиной.
Такое ощениние, что вы очень далеко ушели от основных идей и принципов, и подменили отсутствие личной мотивации армейской дисциплиной.)))
При этом откуда-то взялись обязательные приходы в 9 утра, отсутствие личного пространства и прочая ересь.
Одной время мне довелось работать в команде, где первый работник приходил в 6 утра и уходил в 14.00. Остальные собирались, кто к 10, кто 11, а кто и вообще к 13.00. Просто потому что им это было удобно. И — сюрприз, сюрприз — никаких проблем ни у кого это не вызывало.
В другой команде митинги перенесли с вечера на обед. Просто потому что всем членам команды было, в принципе, все равно, когда их проводить, а мой рабочий день заканчивался в 13.00 — 13.30. Опять-таки, все живы и счастливы.
Пускать кого-то за свой рабочий стол? Два монитора и одна виртуалка отлично решают эту проблему — и вуаля, вот вам и парное программирование, и личный комфорт.
Вопрос в том, как подходить к процессу. Было бы желание, а решение — найдется.
Поэтому, я бы сказала, что все с точностью наоборот: из-за поблажек в плане формальной дисциплины аджайл не подойдет тем, у кого проблемы с мотивацией и саодисциплиной.
НЛО прилетело и опубликовало эту надпись здесь
Открою страшную тайну и вторую половину истины: комфорт — необходимое условие производительности.
Мозг — это аналоговая вычислительная машина; эффективность его использования прямо зависит от достигнутого отношения сигнал-шум — от того, «на сколько разрядов после точки» вы себя слышите.
Программист, постоянно готовый дать формальный отчет — это графический конвейер, отрабатывающий все команды синхронно. Да, некоторые так работают. Нет, это не самая лучшая инженерная практика.
Мозг — это аналоговая вычислительная машина; эффективность его использования прямо зависит от достигнутого отношения сигнал-шум — от того, «на сколько разрядов после точки» вы себя слышите.
Программист, постоянно готовый дать формальный отчет — это графический конвейер, отрабатывающий все команды синхронно. Да, некоторые так работают. Нет, это не самая лучшая инженерная практика.
Интересно, что во многих командах принимают церемониал agile (ежедневные планерки, куча разных видов совещаний, терминологию), но наотрез отказываются от сути: идентифицируйте клиента и как можно чаще показывайте ему систему, которой он может хоть как-то пользоваться.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Почему Agile вам не подходит