Здравствуйте, rsn81, Вы писали:
R>Здравствуйте, Курилка, Вы писали:
R>В статье Проектирования больше нет? Фаулер приводит причины, по которым использование только части взаимосвязанных практик XP приводит к тому, что остальные не приносят ожидаемого эффекта. Фаулер, как кот Матроскин, утверждает, что критиканы XP просто не так колбасу на хлеб кладут.
Все было бы так, только есть один нюанс. При размере команды в два человека можно применять эволюционное проектирование — основной фактор состоит в том, что эти двое просто не успеют сделать настолько много кода и реализовать настолько много противоречивых требований, чтобы система начала расползаться — т.е. "сглаживание кривой" обеспечивается в основном не магическими практиками ХР, а небольшим размером команды.
В реальности, основные движущие факторы, определяющие "экспоненциальность кривой", и прводящие ХР проекты к провалу на практике, — следующие:
1) Разработка отвратительно масшабируется при росте команды. Если сроки и функциональность таковы, что в проекте надо задействовать 10 человек и более, то практика ХР приведет к катастрофе по причине издержек коммуникации внутри команды, и отсутствия людей, владеющих общей картиной. Контроль над разработкой будет утерян в самом начале. 10 — это я для верности взял, чтобы наверняка. А вообще проблемы начнутся при количестве людей больше двух, и станут заметны невооруженным глазом начиная с 5 человек.
2) Реальный жизненный цикл реального продукта только начинается созданием первой версии. Все сложности только начнутся с ее выходом — тут же выяснится, что оказывается продукт надо а) поддерживать, внося туда исправления дефектов и разнообразные докрутки, а также б) выпускать новые версии с серьезно улучшенной функциональностью и адаптировать их под постоянно меняющиеся требования, диктуемые бизнесом и рыночной ситуацией.
3) Кроме этого, выяснится, что оказыватеся среди программистов бывает текучка — приходят новые, а старые уходят. А еще бывает, что у работ бывает высокий приоритет, и новые люди по быстрому вкручивают что-то в код, не имея времени в нем тольком разобраться (и боже упаси, рефакторинг делать).
Полноценные и "дедовские" (классические) методологии рассчитаны на эффективную работу именно в этих, реальных условиях — большие организованные команды разнопрофильных профессионалов (потому что сроки поджимают и софт сложный, группа "два тракториста-универсала" такой сделать просто не успеет), реальные живые люди (которые могут быть, например, склонны к индивидуальной работе по складу характера), цикл поддержки и развития с трассировкой требований (вместо наколеночного хакания всякой херни на авось). Написание софта — это бизнес, и ошибки в разработке и управлении имеют цену. Подчас — очень высокую, они могут убить бизнес.
ИМХО, ХР — это игрушка для создания одноразовых поделок. Реальные проекты надо планировать, надо проектировать, и более того — считается хорошей практикой тратить больше времени на дизайн, и меньше на кодирование. Думать побольше, прыгать поменьше. Это элементарный здравый смысл, подкрепленный замерами метрик с реальных проектов. Это способ, к которому интуитивно приходит большинство опыных рахработчиков. Deadline ДеМарко читали? Вот и ДеМарко, светоч девелоперского здравого смысла посреди мрака безумия, считает так же. "Кодируйте в последний момент" — так быстрее.
Увлечение ХР — это что-то вроде увлечения НЛП. Человек выполняет набор эффектных и бесполезных фокусов, и чувствует при этом свою якобы причастность к психологии, и якобы появившийся контроль над собой и окружающими людьми. Впрочем, увлечение НЛП быстро проходит, как только человек попадает в действительно серьезную жизненную передрягу. Так же, думаю, и с agile. Нельзя полагаться на технику и формальные подходы, особенно если они вводят необоснованные постулаты, противоречат здравому смыслу, или используют собственную терминологию для всем известнх вещей (последнее — верный признак что ничего нового в предлагаемой штуке нет — автор так маскирует ошибки и общую бредовость, затрудняя сопоставление с классикой — это типичный прием "экстремальных учонах" в науке). Головой думать надо.
Здравствуйте, Gaperton, Вы писали:
G>Здравствуйте, rsn81, Вы писали:
G>>>С логикой что-то не так? R>>Теперь понятно. R>>Практически, спорить не буду, потому что не имею (кто знает, может тоько пока) опыта работы в таких огромных командах. R>>Теоретически... не согласен, потому что читаю труды людей, которых уважаю, которые вроде бы имеют такой опыт и говорят противоположные вам вещи.
G>>>При том, что работать большими командами все-таки необходимо, нравится это кому-то, или нет, а подход ХР противоречит основным принципам работы больших команд — он практически гарантирует провал на большой команде. R>>Аналогично: не знаю, но сомневаюсь.
G>В таком случае должно быть какое-то простое и понятное объяснение — каким образом и почему разработка у них хорошо масштабируется. Я на слово даже уважаемым людям не верю — без понимания сути и причин пользы от такой веры никакой нет. А раз так — зачем себе голову забивать религиозными по сути штуками. Бритва Оккама.
Объяснение у них, очевидно, такое.
1) regression-тестами все накрываем, тестами!
Действительно, при таком подходе у нас становится сложнее внести ошибку в софтину. Многие это понимают, и применяют автоматические тесты — ведь их применение соверешенно иррелевантно к процессу разработки и методологии, на самом деле. Только тесты — не панацея, количество тестов по мере увеличения покрытия растет экспоненциально. Обеспечить покрытие, при котором рефакторинг стал бы действительно безопасным, обеспечивая полную защиту от дурака — это начиная с некоторого момента слишком дорого обходится. Потому, мы применяли сочетание regression-тестирования с проверкой предусловий-постусловий и инвариантов в рантайме, а также специальные "тестовые режимы" при которых старый и новый код выполняются впараллель — так просто дешевле, это уменьшает требуемое тестовое покрытие.
При этом, тесты вас совершенно не гарантируют от внесения новых ошибок. Тесты ловят уже обнаруженные ошибки при повторном их появлении. Самые худшие и дорогие ошибки — ошибки дизайна и архитектурные. Лучшая гарантия от них — это предварительное проектирование. Тогда не будет появляться хрупкий код.
2) Есть способ делать рефакторинг так, чтобы он обходился дешево.
Описываю реальные, типовые ситуации рефакторинга в CQG, коду которого уже лет 17 и размером он в пару миллионов строк. Предваряя замечания — дай вам бог написать код, который не выкинут через 17 лет, и он будет актуален — в этом коде заложена великолепная архитектура и огромный запас "архитектурной прочности". Так вот, как врач говорю, пардон — как бывший руководитель группы разработки сервера. Рефакторинг представляет собой головную боль не тогда, когда надо механически класс на два побить, а когда вам сильносвязную подсистему с неизвестным или просто дико кривым дизайном надо привести к хорошо структурированной системе, которая была бы лишена целого класса известных проблем, плюс успешно, без потока дефектов, выдержала бы добавление известно новой функциональности. Причем, как правило, вы требования к системе в этом случае снимаете частично с описания проблем, частично проводя reverse engineering имеющегося кода. После reverse engineering вы будете долго думать, как вам изменить дизайн так, чтобы серия планируемых изменений прошла безболезненно, с одной стороны, и старая функциональность при этом легла хорошо — с другой (здесь нет никакого универсального метода "рефакторинга" — тут надо уметь прикладные кейсы в голове держать и представльять, как они на дизайн лягут). Возможна ситуация (в описываемом случае — почти наверняка), когда вы поменяете при этом границы подсистем и измените их интерфейсы (иначе новая функциональность может не лечь), вот тут ваши юнит-тесты написанные с таким трудом дружно и отвалятся. Всем скопом. И это типовая ситуацияпри развитии продукта — адаптации его к изменившимся требованиям. И рулить будет то, что я написал выше в пункте 1 — общесистемные regression tests, инварианты с условиями в коде, и "тестовые режимы" с включенным старым и новым кодом (так дешевле — не надо окружения под них готовить).
Так вот, у меня такое произойет в продукте которому 17 лет, а при agile подходе вы имеете неплохие шансы словить такое в течении первого-второго года разработки одного проекта. Или же, у вас неплохой шанс сильно раздуть базу кода на ровном месте — это уж я даю гарантию почти 100% для сложного проекта начиная с определенного объема. Суть в том, что не делая предварительного дизайна, вы пишете legacy code. Сразу. Right now. Да, он будет с тестами, но это still the same fuckin legacy code. А юнит-тесты вы по дороге потеряете, по сценарию описанному мной в п 2. Вот такой примерно будет сценарий провала проекта. Советую запомнить — когда ЭТО начнется — вспомните гапертона, он конечно не фаулер, но предупреждал .
Здравствуйте, Курилка, Вы писали:
К>Собственно наткнулся на статью, где автор выделяет следующие недостатки agile-подходов:
По-моему агил — это формализация реального положения дел во многих проектах. Кавардак одним словом. И этому кавардаку пытаются придать великий смысл, и заставить разработчиков вкалывать еще сильнее. Ответственность размытая, оттого может получится так, что наиболее ответственные будут на себе тянуть других. По-моему эта модель хорошо подойдет для студентов. Им прикольно потуситься, и они хорошо управляемые.
Здравствуйте, Курилка, Вы писали:
К>Здравствуйте, Gaperton, Вы писали:
G>>Полноценные и "дедовские" (классические) методологии рассчитаны на эффективную работу именно в этих, реальных условиях — большие организованные команды разнопрофильных профессионалов (потому что сроки поджимают и софт сложный, группа "два тракториста-универсала" такой сделать просто не успеет), реальные живые люди (которые могут быть, например, склонны к индивидуальной работе по складу характера), цикл поддержки и развития с трассировкой требований (вместо наколеночного хакания всякой херни на авось). Написание софта — это бизнес, и ошибки в разработке и управлении имеют цену. Подчас — очень высокую, они могут убить бизнес.
К>А можно хотяб пару ссылок откуда копать по поводу выделенного? А то как-то чёткого понимания нет, всплывают только мысли по поводу CMMI и RUP.
RUP — это очень хорошо. Это концентрированный здравый смысл. Мы у себя применяем жизненный цикл RUP — "контроллируемая итерация". В нем основной ахтунг — RUP это шаблон, который подлежит обязательной кастомизации.
CMMI — набор критериев зрелости процесса разработки, не сам процесс. Дает ответ на вопрос "что, в принципе, хорошо", но не дает ответа на вопрос "как надо".
Микрософтский MSF — весьма приятная штука, методика для одной маленькой рабочей группы. Там надо обратить внимание на распределение ролей — у них весьма неплохо роли проработанны.
А вообще — блин, какие ссылки — всегда есть требования, дизайн, кодирование, отладка. Однажды я спросил одного из директора R&D CQG, только что заступившего в должность, какой цикл разработки он собирается применять и вообще — какую методологию? Может быть, RUP? Или, все-таки, XP? Ян МакФэйден, который перед этим возглавлял отдел разработки крупнейшего американского банка (Wells Fargo, кажется), засмеялся, и сказал что-то вроде этого: I don't really care. It's always something like requirements, design, coding, and testing. Whoops, I'm sorry guys, I need to take some evening beer with Dmitry (директор московского офиса)? Have you ever told that it's very dangerous — to stand between me and beer? И довольно заржал в одну калитку, манера у него была такая. Короче, мы были в шоке, и решили что пропал дом. Фигассе, не волнует его, пнимаешь.
Далее — в течени полугода Ян МакФэйден быстро, четко, без истерик и лишних движений, комплексом мер эффективно решил проблемы с качеством клиента CQG — проблема тогда была, что темп появления дефектов превышал темп их исправления, и никто не знал, что делать. Теперь я понимаю, что более компетентного, эффективного, простого в общении, и вообще — классного директора R&D я в жизни не видел. Хардкорный профи. Впрочем, я их вообще не так много видел . Только в CQG — человек 5.
R>В статье Проектирования больше нет? Фаулер приводит причины, по которым использование только части взаимосвязанных практик XP приводит к тому, что остальные не приносят ожидаемого эффекта. Фаулер, как кот Матроскин, утверждает, что критиканы XP просто не так колбасу на хлеб кладут.
Такие утверждения сильно подрывают доверие, поскольку делают разумные, в принципе, вещи похожими на шарлатанские методики похудания и исцеления, которые тоже накладывают строгие и сложноисполнимые требования, и неуспех естественным образом сваливается на даже минимальные отступления от них.
Не используешь парное программирование — все, привет. XP не работает.
В статье Проектирования больше нет? Фаулер приводит причины, по которым использование только части взаимосвязанных практик XP приводит к тому, что остальные не приносят ожидаемого эффекта. Фаулер, как кот Матроскин, утверждает, что критиканы XP просто не так колбасу на хлеб кладут.
Основополагающие практики ХР
В методологии XP имеется много спорных моментов. Одним из ключевых таких моментов является то, что она базируется на эволюционном, а не предварительном проектировании. А как мы уже выяснили, использование эволюционного проектирования не может привести ни к чему хорошему из-за обилия сиюминутных проектировочных решений и энтропии программного продукта.
В основе этого утверждения лежит кривая стоимости изменений в программном продукте. Согласно этой кривой, по мере развития проекта стоимость внесения изменений экспоненциально возрастает. Как правило, в ней используются понятия "фазы развития проекта" (как говорится, "изменение, которое на стадии анализа стоит 1 доллар, после поставки системы будет стоить многие тысячи"). В этом есть некая доля иронии, поскольку в большинстве проектов процесс разработки вообще не определен, и там просто нет стадии анализа, а экспоненциальная зависимость остается в силе. Получается, что если экспоненциальная кривая верна, то эволюционное проектирование вообще нельзя использовать в работе. Отсюда же следует, что нельзя делать ошибки в предварительном проектировании — затраты на их исправление будут определяться все той же зависимостью.
В основе XP лежит предположение, что эту кривую можно сгладить до такой степени, чтобы можно было применять эволюционное проектирование. Такое сглаживание, с одной стороны, возникает при использовании методологии XP, а с другой, оно же в ней и используется. Это еще раз подчеркивает тесную взаимосвязь между практиками ХР: нельзя использовать те части методологии, которые предполагают существование сглаживания, не используя те практики, которые это сглаживание осуществляют. Именно это является основным предметом споров вокруг XP. Многие начинают критиковать использование, не разобравшись в том, как его нужно достигать с помощью осуществления. Зачастую тому виной собственный опыт критикующего, который упустил в разработках те практики, которые позволяют осуществлять другие. В результате, раз обжегшись, такие люди при упоминании об ХР и на воду дуют.
У практик, с помощью которых осуществляется сглаживание, есть множество составляющих. В основе всех их лежит Тестирование и Непрерывная интеграция. Именно надежность кода, которую обеспечивает тестирование, делает возможным все остальное в этой методологии. Непрерывная интеграция необходима для синхронной работы всех разработчиков, так чтобы любой человек мог вносить в систему свои изменения и не беспокоиться об интеграции с остальными членами команды. Взятые вместе, эти две практики могут оказывать существенное влияние на кривую стоимости изменений в программном продукте. Я получил еще одно подтверждение этому в компании "ThoughtWorks". Даже применение всего двух практик, тестирования и непрерывной интеграции, существенно сказалось на результатах. Можно даже усомниться, действительно ли нужно (как это принято считать в ХР) следовать всем практикам, чтобы получить заметный результат.
Подобный эффект имеет и рефакторинг. Те, кто делают рефакторинг в той строгой манере, что принята в ХР, отмечают значительное повышение его эффективности по сравнению с более бессистемной реструктуризацией. Именно это я и ощутил, когда Кент наконец-то научил меня, как правильно делать рефакторинг. В конце концов, это так меня впечатлило, что я даже написал об этом целую книгу.
Джим Хайсмит (Jim Highsmith) в своем великолепном изложении методологии XP использует аналогию с обычными весами. На одной чаше лежит предварительное проектирование, на другой — рефакторинг. В более традиционных подходах к разработке ПО перевешивает предварительное проектирование, так как предполагается, что передумать вы не можете. Если же стоимость изменений снизится, то часть проектирования можно делать и на более поздних стадиях работы, в виде рефакторинга. Это вовсе не означает отказа от предварительного проектирования. Однако теперь можно говорить о существовании баланса между двумя подходами к проектированию, из которых можно выбрать наиболее подходящий. Что касается меня, то иногда мне кажется, что до знакомства с рефакторингом я работал, как однорукий калека.
Все эти основополагающие практики (непрерывная интеграция, тестирование и рефакторинг) создают новую среду, в которой эволюционное проектирование выглядит вполне убедительно. Впрочем, мы еще не выяснили, где же у этих весов точка равновесия. Лично я уверен, что не смотря на поверхностное впечатление, методология ХР — это не просто тестирование, кодирование и рефакторинг. В ней найдется место и для предварительного проектирования. Частично оно производится еще до написания первой строчки кода, но большая его часть приходится на то время, которое предшествует реализации конкретной задачи в течение итерации. Впрочем, такая ситуация представляет собой новое соотношение сил между предварительным проектированием и рефакторингом.
Re[11]: почему. Иллюстрация к показателю maintainabi
Здравствуйте, Аноним, Вы писали:
А>Да, но ведь если так рассуждать, то разработчику никак не разыграть вариант с грязным исправлением и последующим рефакторингом. Либо он делает чистое решение и не успевает, либо делает затычку в срок, но теряет всякую надежду провести рефакторинг, т.к. нет дефекта — не о чем разговаривать.
Вовсе нет. Давай разберемся в деталях, почему именно так стоит делать.
1. Чем плох "грязный" код? Высокой ценой внесения даже простых правок, он "хрупок", его легко сломать.
2. Вот допустим, "грязный" код отлажен и работает. Его надо ни с того ни с сего брать и рефакторить? Нет, не надо — зачем лезть в работающий механизм. Это не принесет абсолютно value. Ноль.
3. А вот теперь допустим, что мы для реализации некоторой feature, которая приносит реальный value, должны внести в данную подсистему исправления. Вот здесь — мы применяем для реализации данной feature двухфазную процедуру. Первым делом — готовим наши подсистемы к добавлению новой функциональности, проведя рефакторинг, и цикл тестирования. Вторым этапом — добавляем фичу начисто.
4. Или предположим, что к нам падает примерно 5 дефектов, относящиеся к "грязному" коду. Тимлид принимает решение закрыть все пять одним рефакторингом, заодно — посоветовавшись с менеджером выбирает из wishlist список фич, которые есть хороший и удобный повод накатить после.
Вот и все. Рефакторинг всегда проводится как часть работ, приносящих value, и его необходимость рассматривается постоянно. Это решение уровня тимлида.
G>>Как менеджер говрю. Не надо ставить меня, менеджера, в положении выбора, когда у менеджера объективно недостаточно информации, чтобы принять решение. Это решение — уровня тимлида, только у него достаточно информации (еще один плюс к необходимости должности тимлида, которые полупрограммеры, полуменеджеры). Оно должно подниматься выше только при серьезных случаях. Обычно, в таких случаях уже поздно .
А>В такое положение не надо.
А>Наверное, у нас в головах крутятся разные сценарии, или разное понимание ролей. У меня такой:
А>День до релиза (до сборки, которая должна стать релизом). Найдена проблема, которая ломает какую-то feature. А>Тимлид приходит к менеджеру и на его языке кратко излагает проблему, impact, варианты, риски, оценку трудозатрат и т.д. А также свои мысли по решению. А>Менеджер, пропуская это всё через своё видение ситуации, может решить А>* Выпустить релиз с дефектом А> — возможно, выпустить отдельную заплатку вскоре А>* Отложить релиз А>* Отменить релиз А>* Убрать/спрятать функционал с дефектом А>* Вставить ту самую временную затычку. Запланировать рефакторинг/тестирование на следующую итерацию, пересмотреть scope. А>(наверняка найдутся ещё варианты)
А>Т.е. насколько у менеджера не хватает понимания технического контекста, настолько у тимлида может не хватать понимания внешних отношений с клиентами, обязательств, пространства для манёвров и т.д. А>Потому вместе они — сила, а по отдельности — 2 силы, но послабее =)
Я в такой ситуации четко поставил тимлиду цель, разъяснил приоритеты, объяснил ответственность, и предложил принять решение самому. Он объясняет мне схему принятия своего решения, почему оно будет таким, какие альтернативы он рассмотрел, и если мне это кажется разумным, я его утверждаю. Пусть учится.
А рефакторингов планировать заранее не надо. Это решение каждый раз принимается при реализации полезных работ, и привязано к ним. Так — правильно.
Здравствуйте, Курилка, Вы писали:
К>Собственно наткнулся на статью, где автор выделяет следующие недостатки agile-подходов:
Я бы выделил еще несколько недостатков:
1. Очень часто команды "прячут" свою лень за термином agile при разработке систем. Когда требуется минимум документации, команды вобще не производят никакой документации, аргументируя тем, что они работают по agile. Грубо говоря, разработчику ставится задача на спринт (в SCRUMе) на словах и когда приходит время Demo, многие недовольны результатами.
2. Многие интерпретируют фразу из Agile Manifesto "Individuals and interactions over processes and tools" таким образом, что процессы при разработке по agile совершенно не нужны. Слово "interactions" подразумевает взаимоотношения. Тяжело эффективно управлять взаимоотношениями без какой-либо структуры или процесса.
Кроме того, считаю, что использование agile методологии, при теперешней острой нехватке квалифицированных кадров стоит дороже, чем формализированный процесс разработки, так как agile требует полной ответсвенности каждого члена agile команды. Наличие квалифицированных и в то же время ответственных сотрудников требует "сильного" HR и "жирного" бюджета. В то время, как постановка процессов разработки и установка автоматизированной системы управления процессом может потребовать меньше средств.
Все, что я здесь наговорил, совершенно не означает, что я не поддерживаю agile. Сам использовал, использую и буду использовать agile, так как на данный момент эта методология является эффективным средством создания систем среднего масштаба с высоким уровнем качества.
Здравствуйте, dangler, Вы писали:
К>>3. Требования создаются минимально достаточными (легче отрефакторить решение, чем спроектировать всё детально заранее) D>Точно. А в чем минус?
минус — рефакторинг стоит дороже (намного! дороже), чем детально спроектированное решение. Это неоспоримый факт! Чем ближе к релизу и чем больше "rollback", тем дороже это стоит.
К>>4. Тестирование задейстовано в течение всего процесса разработки. D>Опять же: это позволяет добиться того, что разрабатываемый апликейшн уже с самого начала – работоспособен и может начать приносить заказчику прибыли (снижать издержки/риски) уже после первого спринта. Плюс найденные быги легче пофиксать в тот момент, когда ты их посадил, а не потом, через пару месяцев, вспоминать – что же ты тут такое понаписал? D>Так в чем минус?
минусов больших не вижу, небольшой недостаток — кпд QA от тестирования намного ниже из-за траты времени на верификацию и декларирование времменых багов и связанных с побочными эффектами рефакторинга (которые известны девелоперам, и с или без участия QA будут исправленны к релизу). Но этот недостаток стоит фирме денег и бесполезного использования человеко-ресурсов (как тестировщиков, так и более ценное время разработчиков).
К>>5. "Частые поставки" (Frequent delivery), которые могут быть достаточно накладными D>Частые поставки дают 2 огромных плюса: D>• Новый функционал у заказчика появляется не в конце разработки всего продукта (через год-два), а после каждого спринта. А так как этот новый функционал как раз тот, который наиболее нужен заказчику на данный момент, то заказчик сразу же после начала его использования начинает получать больше прибыли (снижает свои риски/уменьшает издержки)
использование "в продукции" в сравнении с тестированием бета/спринт итерации на тест серверах на вымышленных данных совсем разные вещи и уж точно не приносят никакой прибыли, а иногда и спринт версия с кучей багов создает отрицательное впечатление и нервозность для заказчика.
D>• Заказчик сразу же видит, где функционал не соответствует его ожиданиям и где его нужно изменить. И получает измененный функционал в конце следующего спринта. Опять-же: доволен пользователь (быстрая реакция на его запросы) => доволен руковолитель пользователя => довольны мы. Плюс Scrum-team видит, что продукт, который она разрабатывает – используется в жизни (чего не хватает при разработке больших проектов по системе waterfall), что только мотивирует команду и повышает ее мораль.
Пользователь может быть недоволен, подсчитывая допольнытельные денежные затраты на изменения, подсознательно и субьективно ощущая, что не все "идет по плану".
P.S. "используется в жизни.." — не используется. Когда дело доходит до дела — к релизу, заведению в продакшн, реальным данным и юзерам, только тогда начинается реальная работа над ошибками, патчи, потная тех-поддержка и нервно курящие тестировщики. Спринты и скрам — мертвому примочка.
К>>6. Судя по откликам, agile-подходы напряжённы (intense) по отношению к разработчикам (100% реализация фич за итерацию и неукоснительность итераций "накладывет отпечаток") D>100% реализация фич за итерацию – неправда. Некоторые фичи переезжают из спринта в спринт просто потому что они оказались длиннее чем сам спринт или просто мы их начали в конце спринта. В этом ничего нет страшного.
Даже осознавая что не все фичи можно "распихать по коробкам" — спринтам, и часть переходит в следущий, это все равно откладывает негативный отпечаток на чуствительных разработчиков
D>Если под 100% реализацией фич подразумевается наличие работающего билда в конце каждой итерации – то да. Это один из определяющих факторов успешности спринта. Но, почитав пункт 5 мы в реале видим, что команда не только от этого не расстраивается, но и мотивируется, видя, что ее продукт и новые фичи сразу же идут в продакшен. А intense – это больше вопрос правильных эстимейтов и отношений с заказчиком если что-то было плохо проэстимейчено.
За годы участия в разработке и внедрении, не при какой технологи НЕ ВИДЕЛ, ЧТОБЫ итерации (не говоря даже о сырых бета версиях), а при агиле еще и потенциально подверженных рефакторингу, ШЛИ СРАЗУ В ПРОДАКШН!!!
Здравствуйте, EM, Вы писали:
G>>Далее — в течени полугода Ян МакФэйден быстро, четко, без истерик и лишних движений, комплексом мер эффективно решил проблемы с качеством клиента CQG — проблема тогда была, что темп появления дефектов превышал темп их исправления, и никто не знал, что делать.
EM>Выделенное глубоко верно, но это и так все знают. EM>Более интересно, какими именно мерами он "эффективно решил проблемы с качеством клиента CQG" ?
Ввел и наладил работу...
1) ...схемы приоретизации дефектов и планирования релизов. Дефекты начали сортировать по принципу value-cost, для этого собирался специальный triage meeting. Его МакФэйден вел лично.
2) ...а также улучшения маршрутизации дефектов и простейшей схемы контроля качества. МакФейден ввел код-ревью — все чекины, в которых не прописана фамилия проверяющего, отклонялись. Проверяющий был всегда компетентен в тех модулях, к которым относились исправления(была собрана матрица компетенции, которая применялась при назначениях). Это снизило количество дефектов, которые вносились исправлениями других дефектов.
Вот и все. Умница МакФейден. Как-то тихо все через полгода все забыли о проблемах с дефектами, когда схема заработала.
Я не так давно повторил этот фокус на последнем месте работы. Комания никак не могла выпустить maintenance release в срок, и каждый раз это было дикое напряжение и аврал — по 4 месяца задержки были. И вдруг через несколько месяцев — о чудо . Как-то незаметно и без напряжения все вдруг с удивлением обнаружили, что очередной maintenance release к выпуску готов . Странно, никто задницу на британский флаг не разрывал. Одна проблема — как-то слишком быстро и незаметно как-то все получилось, и customer support не успел поставить предыдущий release всем клиентам
А всего-то надо было делать несколько простых вещей. 1) code freeze — не подбрасывать в релиз, который проходит системный тест исправлений новых дефектов, просто потому, что "он все равно сломался" 2) Исправлять дефекты каждую неделю, не забивая на них полный болт. Скажем, по одному дню в неделю выделить на них каждому программерут 3) Иметь четкую отсечку по времени по выпуску каждого релиза. 4) разделить "зоны ответственности" между программистами, чтобы равномерно размазать по нима нагрузку по maintenance 5) и аккуратно управлять приоритетами, постоянно имея в виду всю эту схему — чтобы в первую очередь исправлялись критичные для кастомеров дефекты.
И все. Эти простые правила не напряжны для всех, и воистину творят чудеса Пункт 6) про code review — чтобы снизить количество неверных исправлений, я не смог до конца претворить в жизнь как непреложное правило (для этого нужна была новая инфраструктура билдов-VCS-issue tracker), но зоны ответственности уже положительно повлиял и на количество неверных исправлений.
EM>Кстати, я за этим чудо продуктом трейдил еще 9 лет назад и до сих пор этот ужас не забыл.
Не такой уж и ужас. Впрочем, было бы любопытно узнать, что именно вам не нравится в этом продукте — я это с удовольствием передам своему бывшему коллеге, который сейчас директор свой собственной конторы, и делает конкурента CQG . Заодно, расскажу, что из этого мы исправили с 1999 до 2005 года .
R>Вы утрируете. Фаулер говорит о конкретных взаимосвязанных практиках, а вовсе не о догматичном следовании всем-всем R>диктуемым действиям (на самом деле даже наоборот — прочтите статью полностью).
Честно говоря, не буду. У меня нет озабоченности методологией. Методология может быть любой удобной для конкретного проекта исходя из его реалий; Единственное требование — что бы ее элементы были осознанны, и что бы на любое КАК у нас было понимание ЗАЧЕМ. В противном случае это будет поклонение самолётам, а вот оно точно не работает.
Здравствуйте, b_manvelyan, Вы писали:
_> а где можно узнать побольше о таких "тестовых режимах"? правильно ли я понимаю, что при включенном таком режиме одновременно может работать и старых код (до рефакторинга) некой подсистемы и новый код (полученный после рефакторинга). Можно об этом рассказать подробнее?
Это не является стандартной техникой, это часть креативного подхода к тестированию. В данном случае речь идет о regression tests (тесты, доказывающие что вы ничего в старой системе не изменили), которые делаются достаточно халявным образом — старый код не вырезается, а ставится под флаг компиляции, таким образом, что в тестовом режиме работает одновременно старый и новый код, сравнивается их вывод, и любое несовпадение пишется в лог. Так мы, например, делали в CQG, проверяя корректность построения временных рядов новой версии. Удобно — вы пользуетесь системой, а она сама пишет в лог о вероятных ошибках.
Также в тестовом режиме можно проверять инварианты и также писать об их невыполнении в лог. Мы так тоже делали. Удобно — стоит сервер месяцами, обрабатывает себе тихонько котировки, а ты раз в неделю ищешь баги в файле errors.log
Плюсы тестовых режимов — вам не нужно делать окружения для тестов — роль окружения играет сама ваша система. И делает она это великолепно.
Вообще — тестовые режимы делать не обязательно. Regression test можно организовать и исключительно сверкой логов. Скажем, вы логгируете промежуточные результаты в набор файлов с системы до модификаций. Получаете что-то вроде трейса выполнения программы. После чего — берете diff с логами новой версии, и объясняете различия (не все типы различий будут ошибками в новой версии).
Другой подход к regression-тестированию — сверка состояний. Вы пишете в лог состояние системы в контрольных точках, для старой и новой систем, и так же берете diff. Там мы, например, отлаживали модель процессора MIPS — сравнивали состояние памяти после выполнения тестовой программы, в качестве эталона брали состояние памяти обычной настольной машины.
Короче, если как следует подумать о тестировании, можно съэкономить массу времени при разаботке. Вот еще пример — как отлаживать конечные автоматы. Пишем в лог одну запись на переключение состояния. Лог имеет форму таблицы с разделителями-табуляциями. После чего даем системе поработать, подцепляем лог-файл как таблицу MS Access, и одним SQL-запросом строим из нее матрицу смежности конечного автомата, для сравнения со спецификацией. Удобно? А то . Я так сам делал.
Основной плюс всех перечисленных методов — вам эти unit-tests достаются вам как бы бесплатно, вы их автоматически из общесистемных получаете.
Здравствуйте, Gaperton, Вы писали:
G>Вот такой примерно будет сценарий провала проекта. Советую запомнить — когда ЭТО начнется — вспомните гапертона, он конечно не фаулер, но предупреждал .
Здравствуйте, Dirichlet, Вы писали:
D>Здравствуйте, Gaperton, Вы писали:
G>>При том, что работать большими командами все-таки необходимо, нравится это кому-то, или нет, а подход ХР противоречит основным принципам работы больших команд — он практически гарантирует провал на большой команде.
D>Вот не очень понимаю, что мешает побить большой проект на несколько команд, а потом в одной/нескольких/всех использовать XP?
Ну да. Что мешает просто все взять, и поделить, что они там как дети с этим Каутским. Понимаете — в этом основная проблема и состоит, что только на бумаге можно просто все взять, и поделить. Что я могу сказать — валяйте, попробуйте. Увидите, что будет.
D>Отдельный компонент большой системы — это, фактически, отдельный проект со своим заказчиком, требованиями, дизайном, пользователями, версиями, и т.д. Его можно разрабатывать как хочется, при условии, что взаимодействие с остальными командами налажено.
Ни разу не отдельный проект, он должен тестироваться в составе крупной системы, и сильно с ней связан. Его еще надо выделить из общей кучи, этот проект, сформулировать к нему требования, и наладить межгрупповое взаимодействие. Кто это все будет делать по вашему, интересно? Бог из машины, в лице всезнающего архитектора или менеджера? Само собой это должно произойти?
Re[7]: почему. Иллюстрация к показателю maintainability
G>Через несколько месяцев, на последнем этапе тестирования (угроза срыва релиза), тестеры нашли маленький, но жутко неприятный дефект. Класса feature failure. Я заглянул в код, и понял, что наше "грязное решение" содержит ошибку — оно целиком полагалось на побочные эффекты, и мы кое-что пропустили. Я это быстро заткнул, и отправил исправление. На протяжении последующих двух недель ко мне пришло еще 4 подобных дефекта по этому же коду. Я понял, что надо было сразу переписать, и зарядил одному из программеров его переписывание. Однако, когда я затыкал его в пятый раз, и на код ревью корректность работы кода была доказана формально, я не стал чекинить новый "чистый" код, оставив старый. Новый код был отложен. Понятно почему?
Это важно, и требует пояснения. Этот модуль, который был "грязный", и из него перли баги, был очень хорошо изолирован от остального кода, и я не ожидал в нем никаких правок в ближайшие несколько лет с вероятностью 99,9%. Мы закрыли дефекты в нем с высокой вероятностью быстро, подняв "хрупкость" этого кода и цену внесения изменений в него до невообразимых высот. Но штука в том, что в него не будет внесено изменений в ближайшие несколько лет! А за очередную багу в этом релизе тестеры с дельмом съедят, они были в бешенстве.
Таким образом, принятые нами меры на каждом отдельном этапе были оправданы. Ну, а на тот невероятный случай, если вдруг в него будет вносится правка (типа риск), мы запланировали его рефакторинг, и в загашник был отложен новый код, который менее "хрупок" (типа mitigation plan). Вот так в реальной жизни и живем.
И не надо мне говорить, что надо предварительное проектирование лучше делать . Сам знаю . Это, во-первых, ошибки молодости, на которых я учился, во-вторых, именно о важности предварительного проектирования я и говорю во всей этой теме . Так что, можно считать это еще одним аргументом против agile в понимании XP и scrum.
Здравствуйте, ironwit, Вы писали:
G>>наличием приоритетов по срочности работ (что приводит к "грязным решениям")
I>перечитывал старую тему, с целью вырости над собой и увидел оставленную фразу. не сможете более подробно её прокомментировать? что имели в виду когда писали одновременно приоритетность срочности и грязные решения? заранее спасибо.
Пример из реальной жизни №1. Приходит дефект, приоритета 1, северити feature failure (полная неработоспособность фичи). До релиза — день. Разбирательство показывает, что год назад неправильно исправили другой дефект, который породил два новых. Они были найдены, и их закрыл другой человек, у него это почти получилось, но в одном неочевидном, однако — распространенном сценарии, случается задница.
По хорошему, надо все безобразие откатывать, и исправлять правильно. Однако, времени нет, и мы серьезно рискуем сорвать релиз. Собрали консилиум. Приняв во внимание все факторы, решили хирургически хачить поверх, и доказать корректность поведения формально. Операция заняла примерно 3 часа, два человека (я и Дима Осовский) "накладывали швы", внимательно следя, что учтены все побочные эффекты. Баг закрыли.
Пример номер два.
Делали одну штуковину, при ее дизайне упусти один юзкейс. Вспомнили о нем тогда, когда все было написано, и проверено, и пришло время его добавлять. Он был такой неудобный, при внешней безобидности, что пришлось бы все выбрость, и переписать — он менял весь дизайн радикально, и ничего "порефакторить" просто не получится.
Приняли решение делать "грязно". Сделали.
Через несколько месяцев, на последнем этапе тестирования (угроза срыва релиза), тестеры нашли маленький, но жутко неприятный дефект. Класса feature failure. Я заглянул в код, и понял, что наше "грязное решение" содержит ошибку — оно целиком полагалось на побочные эффекты, и мы кое-что пропустили. Я это быстро заткнул, и отправил исправление. На протяжении последующих двух недель ко мне пришло еще 4 подобных дефекта по этому же коду. Я понял, что надо было сразу переписать, и зарядил одному из программеров его переписывание. Однако, когда я затыкал его в пятый раз, и на код ревью корректность работы кода была доказана формально, я не стал чекинить новый "чистый" код, оставив старый. Новый код был отложен. Понятно почему?
Здравствуйте, Gaperton, Вы писали:
G>Все было бы так, только есть один нюанс. При размере команды в два человека можно применять эволюционное проектирование — основной фактор состоит в том, что эти двое просто не успеют сделать настолько много кода и реализовать настолько много противоречивых требований, чтобы система начала расползаться — т.е. "сглаживание кривой" обеспечивается в основном не магическими практиками ХР, а небольшим размером команды.
Два утверждения:Небольшой размер команды обычно приводит к сглаженной кривой стоимости изменений.
Единственной причиной сглаженной кривой стоимости изменений является малый размер команды.Может с логикой у меня что-то не так, но из первого утверждения вовсе не выплывает второе.
G>В реальности, основные движущие факторы, определяющие "экспоненциальность кривой", и прводящие ХР проекты к провалу на практике, — следующие: G>1) Разработка отвратительно масшабируется при росте команды. Если сроки и функциональность таковы, что в проекте надо задействовать 10 человек и более, то практика ХР приведет к катастрофе по причине издержек коммуникации внутри команды, и отсутствия людей, владеющих общей картиной. Контроль над разработкой будет утерян в самом начале. 10 — это я для верности взял, чтобы наверняка. А вообще проблемы начнутся при количестве людей больше двух, и станут заметны невооруженным глазом начиная с 5 человек.
Да, есть такая проблема, Фредерик Брукс достаточно детально ее рассматривал в своем "Мифическом человеко-месяце или как создавать программные системы". Непонятно только, причем тут XP?
G>2) Реальный жизненный цикл реального продукта только начинается созданием первой версии. Все сложности только начнутся с ее выходом — тут же выяснится, что оказывается продукт надо а) поддерживать, внося туда исправления дефектов и разнообразные докрутки, а также б) выпускать новые версии с серьезно улучшенной функциональностью и адаптировать их под постоянно меняющиеся требования, диктуемые бизнесом и рыночной ситуацией.
Не понял, а собственно причем тут XP?В XP используют итерации в 2-3 недели, в связанной с XP методологии Scrum декларируются спринты до одного месяца. Правильно класть колбасу итераций на хлеб — это заниматься планированием (его вовсе никто не выкидывает в XP), только планирование оперирует более обозримыми масштабами — итерациями.
Итеративность разработки тесно связана (скажем, одно без другого — непонятно зачем) с ранним прототипированием: каждая итерация заканчивается демонстрацией результатов заказчику (в лучшем варианте — конечному пользователю). Это позволяет заказчику оценить, что было сделано из запланированного на прошедшую итерацию, а также выставить приоритеты на следующую итерацию — планирование замыкается на новую итерацию.В итоге планирование становится прозрачным и меньше зависит от посторонних факторов.
G>3) Кроме этого, выяснится, что оказыватеся среди программистов бывает текучка — приходят новые, а старые уходят. А еще бывает, что у работ бывает высокий приоритет, и новые люди по быстрому вкручивают что-то в код, не имея времени в нем тольком разобраться (и боже упаси, рефакторинг делать).
XP вроде бы всеми руками-ногами за пересмотр кода: XP != code and fix.
G>Полноценные и "дедовские" (классические) методологии рассчитаны на эффективную работу именно в этих, реальных условиях — большие организованные команды разнопрофильных профессионалов (потому что сроки поджимают и софт сложный, группа "два тракториста-универсала" такой сделать просто не успеет), реальные живые люди (которые могут быть, например, склонны к индивидуальной работе по складу характера), цикл поддержки и развития с трассировкой требований (вместо наколеночного хакания всякой херни на авось). Написание софта — это бизнес, и ошибки в разработке и управлении имеют цену. Подчас — очень высокую, они могут убить бизнес.
Ага-ага, но причем тут XP?
G>ИМХО, ХР — это игрушка для создания одноразовых поделок. Реальные проекты надо планировать, надо проектировать, и более того — считается хорошей практикой тратить больше времени на дизайн, и меньше на кодирование. Думать побольше, прыгать поменьше. Это элементарный здравый смысл, подкрепленный замерами метрик с реальных проектов. Это способ, к которому интуитивно приходит большинство опыных рахработчиков. Deadline ДеМарко читали? Вот и ДеМарко, светоч девелоперского здравого смысла посреди мрака безумия, считает так же. "Кодируйте в последний момент" — так быстрее.
Непонятно, почему вы решили, что:XP и планирование в контрах. XP просто предлагает сделать его:
прозрачным, то есть понятным всем участникам проекта: и исполнителям, и заказчикам;
эффективным: результаты планирования, а это как успехи, так и промахи, видны участникам периодически (в конце каждой итерации), что потенциально позволяет вносить соответствующие коррективы в момент, когда еще не слишком поздно (а не в конце проекта в виде компресса на лоб мертворожденного проекта, которому планировщики запланировали светлое будущее на лета, а то как он помер в один день и не заметили, пребывая в восторженных заоблачных размышлениях).
XP == code and fix.
G>Увлечение ХР — это что-то вроде увлечения НЛП. Человек выполняет набор эффектных и бесполезных фокусов, и чувствует при этом свою якобы причастность к психологии, и якобы появившийся контроль над собой и окружающими людьми. Впрочем, увлечение НЛП быстро проходит, как только человек попадает в действительно серьезную жизненную передрягу. Так же, думаю, и с agile. Нельзя полагаться на технику и формальные подходы, особенно если они вводят необоснованные постулаты, противоречат здравому смыслу, или используют собственную терминологию для всем известнх вещей (последнее — верный признак что ничего нового в предлагаемой штуке нет — автор так маскирует ошибки и общую бредовость, затрудняя сопоставление с классикой — это типичный прием "экстремальных учонах" в науке).
Эмоции.
G>Головой думать надо.
А вот с этим согласен на все сто. Если не думать головой, то даже XP не спасет.
PS Оговорюсь сразу (чтобы не записали в фанатика-идолопоклонника Кента Бека), что вовсе не считаю XP приемлемым для всех проектов, выше в теме писал об этом.
Здравствуйте, Gaperton, Вы писали:
G>При том, что работать большими командами все-таки необходимо, нравится это кому-то, или нет, а подход ХР противоречит основным принципам работы больших команд — он практически гарантирует провал на большой команде.
Вот не очень понимаю, что мешает побить большой проект на несколько команд, а потом в одной/нескольких/всех использовать XP?
Отдельный компонент большой системы — это, фактически, отдельный проект со своим заказчиком, требованиями, дизайном, пользователями, версиями, и т.д. Его можно разрабатывать как хочется, при условии, что взаимодействие с остальными командами налажено.
Re[9]: почему. Иллюстрация к показателю maintainability
Здравствуйте, Аноним, Вы писали:
А>Важно при этом также иметь вес и аргументы для того, чтобы в дальнейшем "пробивать" время не рефакторинг и тестирование "грязных" решений.
Видишь ли какая штука. По секрету говорю крамольную вещь — как бывший разработчик, а теперь как менеджер. Не надо иметь для этого ни веса, ни аргументов. Разработчик всегда имеет возможность сказать, что "время исправления дефекта займет много времени, он архитектурный". И все. Менеджер проверить не может никак. А вот как только ему дадут выбор — "могу быстро, могу медленно" — угадай результат.
Как менеджер говрю. Не надо ставить меня, менеджера, в положении выбора, когда у менеджера объективно недостаточно информации, чтобы принять решение. Это решение — уровня тимлида, только у него достаточно информации (еще один плюс к необходимости должности тимлида, которые полупрограммеры, полуменеджеры). Оно должно подниматься выше только при серьезных случаях. Обычно, в таких случаях уже поздно .
Здравствуйте, Ананий., Вы писали:
А>Здравствуйте, Курилка, Вы писали:
К>>Собственно наткнулся на статью, где автор выделяет следующие недостатки agile-подходов: А>По-моему агил — это формализация реального положения дел во многих проектах. Кавардак одним словом. И этому кавардаку пытаются придать великий смысл, и заставить разработчиков вкалывать еще сильнее. Ответственность размытая, оттого может получится так, что наиболее ответственные будут на себе тянуть других. По-моему эта модель хорошо подойдет для студентов. Им прикольно потуситься, и они хорошо управляемые.
Не совсем так. Посылка agile на самом деле очень проста. Иногда бывают такие проекты, в которых следование организованному циклу разработки, будь то RUP или ватерфол — сопряжено со сложностями, в силу того, что возможности по формулированию и выяснению требований сильно ограничены. То же самое имеет место быть в проектах, которые находятся на грани технологии. И те и другие, по сути своей, представляют собой в ГОСТ-овской терминологии скорее поисковые НИР, и требуют особых методов управления. А именно — трудозатраты особо не планируются — потому что мы не знаем заранее, что и как мы будем делать, вместо этого работа ведется итерациями с фиксированными заранее определенными сроками.
В таких проектах по мере продвижения вперед и наблюдения за результатом, мы получаем новые знания, которые сильно меняют ТЗ. Agile исходит из предпосылки отказа от попыток сбора требований и глубокого проектирования, заменяя это продвижением к конечному продукту через серию коротких прототипов с фиксированными датами выпуска, и постоянной корректировкой планов. То есть, agile борется с хаосом ускорением получения обратной связи, и ускорением первых коррекций. Для проектов заказной разработки с высокой неопределенностью, небольшим бюджетом и объемом работ такой подход в целом обходится дешевле, чем классика, его отрицательные стороны просто не успевают сработать. Для продуктовой разработки методом agile хорошо писать ГУЙ, у которого высокие требования к юзабилити.
Разумеется, agile имеет сильные ограничения по применимости, и не является заменой обычным методам. Я сочувствую тем организациям и менеджерам, которые применяют в своей практике ТОЛЬКО agile. Глупо строить всю методологию вокруг одного приема планирования из многих, на самом деле. Разводилово это.
Вот, примерно так звучит отзыв об agile опытного инженера, который делал коробочный продукт, а не только наколенные поделки для внутреннего использования и сайты на PHP, и вообще нюхал пороху в командной разработке. Сразу видно по суждениям. Правильно. Не дадим заscrew-upить разработку разными там fuck-up meetingами!
Re[8]: почему. Иллюстрация к показателю maintainability
Хороший пример, когда осознание рисков и последствий меняет представление о том, что есть хорошо и правильно.
Важно при этом также иметь вес и аргументы для того, чтобы в дальнейшем "пробивать" время не рефакторинг и тестирование "грязных" решений. Иначе есть шанс получить код, к которому непонятно с какой стороны подойти. Особенно если это продукт. Или продуктовая линейка. Бррр...
А ещё если кто-то поднимает вопрос о важности проектирования в начале итерации, то хвала ему и почёт.
А если за день до релиза на митинге по критическому багу, то щёлкнуть по носу и ближе к делу.
Здравствуйте, Курилка, Вы писали:
К>Собственно наткнулся на статью, где автор выделяет следующие недостатки agile-подходов: К>1. Необходима большая вовлечённость пользователя в процесс разработки
Если бы можно было всверлить с помощью самой мощной дрели DeWalt только одну мысль каждому начинающему консультанту в голову, то это было бы: клиенты не знают, что они хотят. Перестаньте ждать от клиентов, что они будут знать, чего они хотят. Этого никогда не случится. Смиритесь с этим.
Вместо этого, представьте, что вы всё равно что-то сделаете, и это должно понравиться клиентам, и будет это для них маленьким сюрпризом. ВЫ должны сделать иcследование. ВЫ должны придумать дизайн, который решает проблему клиента удобным для него способом.
Поставьте себя на их место. Представьте, что вы только что продали свою компанию Yahoo! за $100 000 000 и решили, что пора сделать ремонт в кухне. Поэтому вы нанимаете профессионального архитектора и объясняете, что «это должно быть круче, чем у моего друга Васи». Вы не имеете ни малейшего понятия, как это сделать. Вы не знаете, что вы хотите: комплект Bucalossi или плитку от Marazzi – это не входит в ваш словарный запас. Вы хотите, чтобы архитектор сделал что-то хорошее, и именно поэтому вы его наняли.
Адепты Экстремального Программирования говорят, что решение – позвать к себе клиента и включить его в каждый шаг процесса разработки дизайна, сделать его членом команды разработчиков. По-моему, это слишком «экстремально». Это как если бы мой архитектор показывал мне, как они разрабатывают дизайн кухни, и просил ответной реакции по каждой мелочи. Это надоедает: если бы я хотел стать архитектором, то я бы учился на архитектора.
Другое дело — что есть множество проектов, которые не по agile вообще не могут быть решены, вот и приходится мирится с таким недостатком.
К>2. Требования меняются и развиваются (не подходит, как минимум, для "fixed price" проектов)
Не неподходит, а сложнее. Просто нужно уметь заложить не-вполне-понятно-что в стоимость. Например, оценить за сколько Вы готовы сделать то, что видется только вначале заказчику и умножить на 10, 100 или 1000.
Да и сдался этот fixed price что ли? T&M для agile — нормально.
К>3. Требования создаются минимально достаточными (легче отрефакторить решение, чем спроектировать всё детально заранее)
Это вовсе не обязательно для agile в общем случае.
К>4. Тестирование задейстовано в течение всего процесса разработки.
Да, дорого.
К>5. "Частые поставки" (Frequent delivery), которые могут быть достаточно накладными
Это зависит много от чего... и не сильно актуально, IMHO. Обычно в agile решается один раз.
К>6. Судя по откликам, agile-подходы напряжённы (intense) по отношению к разработчикам (100% реализация фич за итерацию и неукоснительность итераций "накладывет отпечаток")
Да, есть такое, но это скорее по причине плохих менеджеров. Для agile квалификация менеджера должна быть очень высокой, чтобы не потерять управляемость.
Здравствуйте, Курилка, Вы писали:
К>Собственно наткнулся на статью, где автор выделяет следующие недостатки agile-подходов: К>1. Необходима большая вовлечённость пользователя в процесс разработки К>2. Требования меняются и развиваются (не подходит, как минимум, для "fixed price" проектов) К>3. Требования создаются минимально достаточными (легче отрефакторить решение, чем спроектировать всё детально заранее) К>4. Тестирование задейстовано в течение всего процесса разработки. К>5. "Частые поставки" (Frequent delivery), которые могут быть достаточно накладными К>6. Судя по откликам, agile-подходы напряжённы (intense) по отношению к разработчикам (100% реализация фич за итерацию и неукоснительность итераций "накладывет отпечаток")
Согласен с пунктом 2, agile действительно не подходит для fixed price. По остальныем пунктам не видно в чем же собственно недостатки.
Здравствуйте, Курилка, Вы писали:
К>Здравствуйте, Андрей Коростелев, Вы писали:
АК>>Согласен с пунктом 2, agile действительно не подходит для fixed price. По остальныем пунктам не видно в чем же собственно недостатки.
К>И из статьи не видно?
Честно говоря, я не нашел в этой статье убедительных доводов.
Частое дерганье пользователей? А сушествуют ли пользователь, который ясно и четко знает что ему нужно и что никогда не меняет своего мнения?
С самого начала нужно тратиться на тестеров? Юнит-тестирование — дело разработчиков, а не тестеров.
Отсутствие всеобъемлющей документации мешает влиться новичкам? Новички получают только то, что нужно и не стеснены рамками существуещего дизайна.
Требуется более интенсивная коммуникации между разрабочиками? Решается небольшими размерами групп.
Здравствуйте, Курилка, Вы писали:
К>Здравствуйте, Андрей Коростелев, Вы писали:
АК>>С самого начала нужно тратиться на тестеров? Юнит-тестирование — дело разработчиков, а не тестеров. К>Довольно странное заявление, модульное тестирование, хоть и важная часть тестирования, но не единственная. Интеграционное и приёмочное тестирование у вас совсем не используется?
У моменту интеграционного, а тем более приёмочного тестирования, agile процесс уже должен произвести некотороое количество докуменации, достаточное для тестирования модулей как blackbox-ов. Таким обазом, процесс интеграционного и приёмочного тестирование не должны различаться для agile и для не-agile методик.
Расширение кругозора человека приводит к тому, что у него появляется на вооружении больше КАК, а если человек разумный, то на каждом КАК его разум делает пометку ЗАЧЕМ.
PS И еще раз, только не нужно клеймить меня идолопоклонением.
Здравствуйте, VGn, Вы писали:
G>>>ИМХО, ХР — это игрушка для создания одноразовых поделок.
AE>>Нет. Для agile есть одна полноценная ниша в больших проектах: макетно-исследовательский этап.
VGn>Наверное, ты всё-таки путаешь agile и XP. VGn>XP это agile. А agile — это не только XP. VGn>Так что к гибкой методологии вообще критика Гапертона, я так понимаю, не относилась.
Гапертон несколько эмоционально обобщает.
И я позволил себе сохранить это обобщение.
P.S.
И вообще говоря, для его подхода есть основания.
Поскольку я практически не встречал случая, когда фирмы умели бы пользоваться полнофункциональными макетами.
Hello, !
You wrote on Wed, 05 Sep 2007 07:16:54 GMT:
К> Собственно наткнулся на К> [url=http://kw-agiledevelopment.blogspot.com/2007/09/disadvantages-of- К> agile-software.html]статью[/url], где автор выделяет следующие К> недостатки agile-подходов: К> 1. Необходима большая вовлечённость пользователя в процесс разработки К> 2. Требования меняются и развиваются (не подходит, как минимум, для К> "fixed price" проектов) К> 3. Требования создаются минимально достаточными (легче отрефакторить К> решение, чем спроектировать всё детально заранее) К> 4. Тестирование задейстовано в течение всего процесса разработки. К> 5. "Частые поставки" (Frequent delivery), которые могут быть К> достаточно накладными К> 6. Судя по откликам, agile-подходы напряжённы (intense) по отношению К> к разработчикам (100% реализация фич за итерацию и неукоснительность К> итераций "накладывет отпечаток")
Самое главное в статье — не подказано, для кого это недостатки
ЗЫ По мне — так одни достоинста
With best regards, Yury Kopyl. E-mail: hrg@yandex.ru
Думаю нужно добавить ещё парочку (частично применимы и к XP).
1. Высокие требования к квалификации разработчиков.
2. Зачастую низка заменяемость кадров на проекте, так как используется минимальный объем документации по проекту и часто отсутствует общее видение проекта в целом (нет четкой формализации критериев качества для данного проекта, все фактически опирается на квалификацию разработчиков).
Плюсы я думаю всем и так понятны
Здравствуйте, mr_kern, Вы писали: _>Здравствуйте, Курилка, Вы писали:
[skipped]
К>>6. Судя по откликам, agile-подходы напряжённы (intense) по отношению к разработчикам (100% реализация фич за итерацию и неукоснительность итераций "накладывет отпечаток") _>и тут тоже ощутимо...
Поясните плз этот пункт...Что-то не понял в чём тут проблема(что сложно)? Нельзя разве запланировать фичу на 2 итерации и интегрировать в проект уже ближе к концу второй итерации?
А "неукоснительность итераций" — стоит понимать как "надо постоянно работать"?
Мы были здесь. Но пора идти дальше. (с) Дуглас Коупленд, Рабы "Микрософт"
Основной недостаток в том, что фокусируемся на "что сделать", а не "как сделать". Идет планирование и анализ отт "user story", т.е. некой неформализованной сущьности. Как результат получается делитанское планирование, где главное сделать "что хочет заказчик" без должного внимания техническим деталям, которых заказчик даже и не знает. Понятно, что заказчик-пользователь внятно не может понять и представить "начинку" сложно системы. Все ограничивается "рожей": диалоги, орнаменты и пр.
Собственно наткнулся на статью, где автор выделяет следующие недостатки agile-подходов:
1. Необходима большая вовлечённость пользователя в процесс разработки
2. Требования меняются и развиваются (не подходит, как минимум, для "fixed price" проектов)
3. Требования создаются минимально достаточными (легче отрефакторить решение, чем спроектировать всё детально заранее)
4. Тестирование задейстовано в течение всего процесса разработки.
5. "Частые поставки" (Frequent delivery), которые могут быть достаточно накладными
6. Судя по откликам, agile-подходы напряжённы (intense) по отношению к разработчикам (100% реализация фич за итерацию и неукоснительность итераций "накладывет отпечаток")
Здравствуйте, Курилка, Вы писали:
К>Собственно наткнулся на статью, где автор выделяет следующие недостатки agile-подходов: К>1. Необходима большая вовлечённость пользователя в процесс разработки
Для разработчиков IMHO это как раз то, что нужно — что бы не гадать, как хочет заказчик. Это недостаток только для ленивого или вредного заказчика, который хочет что бы сделали проект который ему нужен, но без его активного участия К>2. Требования меняются и развиваются (не подходит, как минимум, для "fixed price" проектов)
Обычно новые требования начинаются когда заказчик видит уже хоть что-то. А agile прекрасно применим и для "fixed price" проектов К>3. Требования создаются минимально достаточными (легче отрефакторить решение, чем спроектировать всё детально заранее)
Чего-то я непонимаю где здесь недостаток? К>4. Тестирование задейстовано в течение всего процесса разработки.
То же самое... К>5. "Частые поставки" (Frequent delivery), которые могут быть достаточно накладными
да, тут есть немного... К>6. Судя по откликам, agile-подходы напряжённы (intense) по отношению к разработчикам (100% реализация фич за итерацию и неукоснительность итераций "накладывет отпечаток")
и тут тоже ощутимо...
Здравствуйте, mr_kern, Вы писали:
_>Здравствуйте, Курилка, Вы писали: К>>1. Необходима большая вовлечённость пользователя в процесс разработки _>Для разработчиков IMHO это как раз то, что нужно — что бы не гадать, как хочет заказчик. Это недостаток только для ленивого или вредного заказчика, который хочет что бы сделали проект который ему нужен, но без его активного участия
Вот тут-то весь и фикус — часто играет роль мысль "заказчик всегда прав". Всё что он хочет — дать тебе задачу, заплатить и получить готовый результат решающий проблему (а лучше любые проблемы ), он вероятно будет не готов выделять своих людей и отдавать их разработчикам вместо того чтоб "делать бизнес" (т.е. терять реальные деньги).
К>>2. Требования меняются и развиваются (не подходит, как минимум, для "fixed price" проектов) _>Обычно новые требования начинаются когда заказчик видит уже хоть что-то. А agile прекрасно применим и для "fixed price" проектов
А какой же будет agile, если ТЗ уже есть и сроки прописаны? К>>3. Требования создаются минимально достаточными (легче отрефакторить решение, чем спроектировать всё детально заранее) _>Чего-то я непонимаю где здесь недостаток?
Не встречал клиентов для которых нужны талмуды документации в которых было бы всё описано "от и до"? К>>4. Тестирование задейстовано в течение всего процесса разработки. _>То же самое...
Заметно повышает стоимость проекта (на время тестеров), хотя снижает риски.
Здравствуйте, Андрей Коростелев, Вы писали:
АК>Согласен с пунктом 2, agile действительно не подходит для fixed price. По остальныем пунктам не видно в чем же собственно недостатки.
Здравствуйте, Андрей Коростелев, Вы писали:
АК>Частое дерганье пользователей? А сушествуют ли пользователь, который ясно и четко знает что ему нужно и что никогда не меняет своего мнения?
Ну тут имеем противодействие заказчика. Просто всёж он тратит деньги за продукт и если вы его не убедите, что ему нужно отдать часть своих специалистов для процесса разработки, то он просто не заключит с вами контракт или же agile получится как минимум фиговый. АК>С самого начала нужно тратиться на тестеров? Юнит-тестирование — дело разработчиков, а не тестеров.
Довольно странное заявление, модульное тестирование, хоть и важная часть тестирования, но не единственная. Интеграционное и приёмочное тестирование у вас совсем не используется? АК>Отсутствие всеобъемлющей документации мешает влиться новичкам? Новички получают только то, что нужно и не стеснены рамками существуещего дизайна. АК>Требуется более интенсивная коммуникации между разрабочиками? Решается небольшими размерами групп.
Там же отмечено — есть тестеры (скажем на приёмочном тестировании), как ты решишь проблему взаимодействия их с разработчиками при помощи небольшого размера групп?
Здравствуйте, Gaperton, Вы писали:
G>Полноценные и "дедовские" (классические) методологии рассчитаны на эффективную работу именно в этих, реальных условиях — большие организованные команды разнопрофильных профессионалов (потому что сроки поджимают и софт сложный, группа "два тракториста-универсала" такой сделать просто не успеет), реальные живые люди (которые могут быть, например, склонны к индивидуальной работе по складу характера), цикл поддержки и развития с трассировкой требований (вместо наколеночного хакания всякой херни на авось). Написание софта — это бизнес, и ошибки в разработке и управлении имеют цену. Подчас — очень высокую, они могут убить бизнес.
А можно хотяб пару ссылок откуда копать по поводу выделенного? А то как-то чёткого понимания нет, всплывают только мысли по поводу CMMI и RUP.
Вы писали:
G>ИМХО, ХР — это игрушка для создания одноразовых поделок.
Нет. Для agile есть одна полноценная ниша в больших проектах: макетно-исследовательский этап.
Но в этом случае действительно не более 2-3 человек и ограничение по времени.
А потом, по результатам agile-проекта зачудительно пишется хорошая постановочная документация для "дедовских способов".
Здравствуйте, rsn81, Вы писали:
R>Здравствуйте, Gaperton, Вы писали:
G>>Все было бы так, только есть один нюанс. При размере команды в два человека можно применять эволюционное проектирование — основной фактор состоит в том, что эти двое просто не успеют сделать настолько много кода и реализовать настолько много противоречивых требований, чтобы система начала расползаться — т.е. "сглаживание кривой" обеспечивается в основном не магическими практиками ХР, а небольшим размером команды. R>Два утверждения:Небольшой размер команды обычно приводит к сглаженной кривой стоимости изменений. R>Единственной причиной сглаженной кривой стоимости изменений является малый размер команды.Может с логикой у меня что-то не так, но из первого утверждения вовсе не выплывает второе.
Я поясню свою мысль. Второе утверждение на самом деле звучит по другому: основной причиной несглаженной кривой являются проблемы взаимодействится при большой команде + особенности поддержки и развития продукта + большая сложность софта, такая, что в голове одного разработчика она не укладывается, обусловленная объемом и возрастом исходников, большим объемом противоречивых требований, изменением этих требований во времени, наличием приоритетов по срочности работ (что приводит к "грязным решениям"), ротацией кадров (происходит постоянная утеря компетенции). Друг из друга они напрямую не следуют, но они связанны. Малая команда во-первых малая, и не имеет проблем взаимодействия, а во-вторых — просто не сможет создать достаточно большой и сложный софт, чтобы появились проблемы с его сложностью. Посему, определяющей причиной, основной, но не единственной, таки является малый рамер команды.
С логикой что-то не так?
G>>В реальности, основные движущие факторы, определяющие "экспоненциальность кривой", и прводящие ХР проекты к провалу на практике, — следующие: G>>1) Разработка отвратительно масшабируется при росте команды. Если сроки и функциональность таковы, что в проекте надо задействовать 10 человек и более, то практика ХР приведет к катастрофе по причине издержек коммуникации внутри команды, и отсутствия людей, владеющих общей картиной. Контроль над разработкой будет утерян в самом начале. 10 — это я для верности взял, чтобы наверняка. А вообще проблемы начнутся при количестве людей больше двух, и станут заметны невооруженным глазом начиная с 5 человек. R>Да, есть такая проблема, Фредерик Брукс достаточно детально ее рассматривал в своем "Мифическом человеко-месяце или как создавать программные системы". Непонятно только, причем тут XP?
При том, что работать большими командами все-таки необходимо, нравится это кому-то, или нет, а подход ХР противоречит основным принципам работы больших команд — он практически гарантирует провал на большой команде.
G>>3) Кроме этого, выяснится, что оказыватеся среди программистов бывает текучка — приходят новые, а старые уходят. А еще бывает, что у работ бывает высокий приоритет, и новые люди по быстрому вкручивают что-то в код, не имея времени в нем тольком разобраться (и боже упаси, рефакторинг делать). R>XP вроде бы всеми руками-ногами за пересмотр кода: XP != code and fix.
Вопрос — чему равно-равно ХР, и чем оно отличается от "обычной разработки"? Прототипирование на стадии "эскизного проекта" (вы писали там выше, что оно с прототипированием связано) прописано еще в древних ГОСТ-ах аж семидесятых годов. Практика review разработана Фаганом тоже в 70-х. Где
G>>Полноценные и "дедовские" (классические) методологии рассчитаны на эффективную работу именно в этих, реальных условиях — большие организованные команды разнопрофильных профессионалов (потому что сроки поджимают и софт сложный, группа "два тракториста-универсала" такой сделать просто не успеет), реальные живые люди (которые могут быть, например, склонны к индивидуальной работе по складу характера), цикл поддержки и развития с трассировкой требований (вместо наколеночного хакания всякой херни на авось). Написание софта — это бизнес, и ошибки в разработке и управлении имеют цену. Подчас — очень высокую, они могут убить бизнес. R>Ага-ага, но причем тут XP?
По моему, я объяснил.
G>>ИМХО, ХР — это игрушка для создания одноразовых поделок. Реальные проекты надо планировать, надо проектировать, и более того — считается хорошей практикой тратить больше времени на дизайн, и меньше на кодирование. Думать побольше, прыгать поменьше. Это элементарный здравый смысл, подкрепленный замерами метрик с реальных проектов. Это способ, к которому интуитивно приходит большинство опыных рахработчиков. Deadline ДеМарко читали? Вот и ДеМарко, светоч девелоперского здравого смысла посреди мрака безумия, считает так же. "Кодируйте в последний момент" — так быстрее. R>Непонятно, почему вы решили, что:XP и планирование в контрах. XP просто предлагает сделать его:
прозрачным, то есть понятным всем участникам проекта: и исполнителям, и заказчикам;
R>эффективным: результаты планирования, а это как успехи, так и промахи, видны участникам периодически (в конце каждой итерации), что потенциально позволяет вносить соответствующие коррективы в момент, когда еще не слишком поздно (а не в конце проекта в виде компресса на лоб мертворожденного проекта, которому планировщики запланировали светлое будущее на лета, а то как он помер в один день и не заметили, пребывая в восторженных заоблачных размышлениях).R>XP == code and fix.
А что, XP разве не предполагает продвижение к результату через чередующиеся сессии кодирования и рефакторинга (т.е. через серию причесанных прототипов)? Не так? Поправьте меня И вы спрашиваете меня, почем я решил, что XP == code and fix? А что — разве в ХР изобрели какой-то новый способ программировать? Без традиционных стадий дизайна, но при этом и без кодирования с отладкой? Who the fuckin guy XP is тогда?
Здравствуйте, dmz, Вы писали:
dmz>Такие утверждения сильно подрывают доверие, поскольку делают разумные, в принципе, вещи похожими на шарлатанские методики похудания и исцеления, которые тоже накладывают строгие и сложноисполнимые требования, и неуспех естественным образом сваливается на даже минимальные отступления от них.
Утверждения — да, согласен, но аргументация — вовсе не обязательно. К примеру, по ссылке выше Фаулер аргументирует, а в процитированном абзаце непосредственно выше вы всего лишь утверждаете.
dmz>Не используешь парное программирование — все, привет. XP не работает.
Вы утрируете. Фаулер говорит о конкретных взаимосвязанных практиках, а вовсе не о догматичном следовании всем-всем диктуемым действиям (на самом деле даже наоборот — прочтите статью полностью).
Здравствуйте, Gaperton, Вы писали:
G>С логикой что-то не так?
Теперь понятно. Практически, спорить не буду, потому что не имею (кто знает, может тоько пока) опыта работы в таких огромных командах.
Теоретически... не согласен, потому что читаю труды людей, которых уважаю, которые вроде бы имеют такой опыт и говорят противоположные вам вещи.
G>При том, что работать большими командами все-таки необходимо, нравится это кому-то, или нет, а подход ХР противоречит основным принципам работы больших команд — он практически гарантирует провал на большой команде.
Аналогично: не знаю, но сомневаюсь.
G>Вопрос — чему равно-равно ХР, и чем оно отличается от "обычной разработки"? Прототипирование на стадии "эскизного проекта" (вы писали там выше, что оно с прототипированием связано) прописано еще в древних ГОСТ-ах аж семидесятых годов. Практика review разработана Фаганом тоже в 70-х. Где
А здесь не согласен: вы пропустили основной акцент, уцепившись за частность в стиле "в XP нет ничего принципиально нового". Почему вы пропустили главное: прототипирование в XP/Scrum не догма в виде автономно летающего в вакууме сферического коня, а именно фактор повышения эффективности планирования по сравнению с водопадом? Ведь самое важное в любом agile: иной, нежели стандартный, подход к планированию.
G>А что, XP разве не предполагает продвижение к результату через чередующиеся сессии кодирования и рефакторинга (т.е. через серию причесанных прототипов)? Не так? Поправьте меня И вы спрашиваете меня, почем я решил, что XP == code and fix? А что — разве в ХР изобрели какой-то новый способ программировать? Без традиционных стадий дизайна, но при этом и без кодирования с отладкой? Who the fuckin guy XP is тогда?
Разницу между XP и code and fix Фаулер описывает в статье, ссылку на которую давал выше. В его аргументации нашел параллели с обстоятельствами своей работы, потому считаю его позицию отчасти своей, но, честно говоря, начинаю чувствовать себя попкой-дураком, приводя краткое содержание его мыслей; думаю, лучше прочитать первоисточник.
R>Расширение кругозора человека приводит к тому, что у него появляется на вооружении больше КАК, а если человек разумный, то на каждом КАК его разум делает пометку ЗАЧЕМ.
Убедили. Просмотрел. Только оказалось, что это не статья, а что-то типа записи в блоге, набор тривиальных соображений, очередные "10 причин по которым нельзя курить", короче. Что обсуждать-то?
Большинство этих соображений высказывались, когда XP только входило в моду, потому как самоочевидны, т.е. лет восемь как не новость.
Здравствуйте, rsn81, Вы писали:
G>>С логикой что-то не так? R>Теперь понятно. R>Практически, спорить не буду, потому что не имею (кто знает, может тоько пока) опыта работы в таких огромных командах. R>Теоретически... не согласен, потому что читаю труды людей, которых уважаю, которые вроде бы имеют такой опыт и говорят противоположные вам вещи.
G>>При том, что работать большими командами все-таки необходимо, нравится это кому-то, или нет, а подход ХР противоречит основным принципам работы больших команд — он практически гарантирует провал на большой команде. R>Аналогично: не знаю, но сомневаюсь.
В таком случае должно быть какое-то простое и понятное объяснение — каким образом и почему разработка у них хорошо масштабируется. Я на слово даже уважаемым людям не верю — без понимания сути и причин пользы от такой веры никакой нет. А раз так — зачем себе голову забивать религиозными по сути штуками. Бритва Оккама.
G>>Вопрос — чему равно-равно ХР, и чем оно отличается от "обычной разработки"? Прототипирование на стадии "эскизного проекта" (вы писали там выше, что оно с прототипированием связано) прописано еще в древних ГОСТ-ах аж семидесятых годов. Практика review разработана Фаганом тоже в 70-х. Где R>А здесь не согласен: вы пропустили основной акцент, уцепившись за частность в стиле "в XP нет ничего принципиально нового". Почему вы пропустили главное: прототипирование в XP/Scrum не догма в виде автономно летающего в вакууме сферического коня, а именно фактор повышения эффективности планирования по сравнению с водопадом? Ведь самое важное в любом agile: иной, нежели стандартный, подход к планированию.
Прототипирование всегда повышает точность планирования, которая напрямую связана с представлением о структуре и сложности разрабатываемой штуки. Именно с этой целью прототипирование наиболее рискованных/критичных вещей и проводят — это common egineering sense. В ГОСТ на этапе "разработка эскизного проекта" предисывается проводить прототипирование непонятных и сложных штук. Других целей и причин прототипирования не существует, вне контекста agile или не agile. Если вам понятно, как будет устроена ваша штука, и точность плана и оценок вас устраивает, то разработка прототипа это просто выкинутые на ветер ресурсы. Дешевле как следует подумать, и сделать сразу начисто, чем по частям с постоянным допиливанием — в последнем случае вы серьезно рискуете словить очень крупные проблемы ближе к концу проекта.
G>>А что, XP разве не предполагает продвижение к результату через чередующиеся сессии кодирования и рефакторинга (т.е. через серию причесанных прототипов)? Не так? Поправьте меня И вы спрашиваете меня, почем я решил, что XP == code and fix? А что — разве в ХР изобрели какой-то новый способ программировать? Без традиционных стадий дизайна, но при этом и без кодирования с отладкой? Who the fuckin guy XP is тогда? R>Разницу между XP и code and fix Фаулер описывает в статье, ссылку на которую давал выше. В его аргументации нашел параллели с обстоятельствами своей работы, потому считаю его позицию отчасти своей, но, честно говоря, начинаю чувствовать себя попкой-дураком, приводя краткое содержание его мыслей; думаю, лучше прочитать первоисточник.
Вы разве не в курсе, что все понимают одни и те же статьи/книги по разному? Меня интересовала краткая и емкая характеристика-определение в один абзац — ваше мнение. Ведь вы мне возражаете — не Фаулер?
Gaperton wrote: > 1) Разработка отвратительно масшабируется при росте команды. Если сроки > и функциональность таковы, что в проекте надо задействовать 10 человек и > более, то практика ХР приведет к катастрофе по причине издержек > коммуникации внутри команды, и отсутствия людей, владеющих общей > картиной. Контроль над разработкой будет утерян в самом начале. 10 — это > я для верности взял, чтобы наверняка. А вообще проблемы начнутся при > количестве людей больше двух, и станут заметны невооруженным глазом > начиная с 5 человек.
[skip]
Согласен, в общем-то. Еще XP неплохо работает для небольших команд,
делающих конкретные модули большой системы (которая управляется по
классическим методологиям). Хотя это, скорее, просто частный случай
"небольшого продукта".
К>>>4. Тестирование задейстовано в течение всего процесса разработки. _>>То же самое... К>Заметно повышает стоимость проекта (на время тестеров), хотя снижает риски.
Если тестирование автоматизировано, то объём должен быть тот же или меньше.
Если обезьянки с клавиатурами — тогда судьба такая.
G>>ИМХО, ХР — это игрушка для создания одноразовых поделок.
AE>Нет. Для agile есть одна полноценная ниша в больших проектах: макетно-исследовательский этап.
Наверное, ты всё-таки путаешь agile и XP.
XP это agile. А agile — это не только XP.
Так что к гибкой методологии вообще критика Гапертона, я так понимаю, не относилась.
(Если не считать намёк на то, что ярлыки на самом деле значат меньше, чем многие думают)
G>Так вот, у меня такое произойет в продукте которому 17 лет, а при agile подходе вы имеете неплохие шансы словить такое в течении первого-второго года разработки одного проекта. Или же, у вас неплохой шанс сильно раздуть базу кода на ровном месте — это уж я даю гарантию почти 100% для сложного проекта начиная с определенного объема. Суть в том, что не делая предварительного дизайна, вы пишете legacy code. Сразу. Right now. Да, он будет с тестами, но это still the same fuckin legacy code. А юнит-тесты вы по дороге потеряете, по сценарию описанному мной в п 2. Вот такой примерно будет сценарий провала проекта. Советую запомнить — когда ЭТО начнется — вспомните гапертона, он конечно не фаулер, но предупреждал .
В этом отношении RUP должен, я думаю, быть поприятнее: в том смысле что гибкость проекта подбирается в зависимости от различных факторов. Без крайностей водопад/ХР.
Хотя в некоторых случаях и то и то приемлемо.
Смущает только его дороговизна.
Так что думаю лучше придерживаться некоторых идей RUP без внедрения RUP как такового.
Что в принципе советует Крачтен.
АК>У моменту интеграционного, а тем более приёмочного тестирования, agile процесс уже должен произвести некотороое количество докуменации, достаточное для тестирования модулей как blackbox-ов. Таким обазом, процесс интеграционного и приёмочного тестирование не должны различаться для agile и для не-agile методик.
А когда, интересно, в Agile наступает момент интеграционного тестирования?
Здравствуйте, VGn, Вы писали:
VGn>В этом отношении RUP должен, я думаю, быть поприятнее: в том смысле что гибкость проекта подбирается в зависимости от различных факторов. Без крайностей водопад/ХР. VGn>Хотя в некоторых случаях и то и то приемлемо. VGn>Смущает только его дороговизна.
Дороговизна RUP?! Это, извините за занудство, вы о чем, о дороговизне внедрения, что ли? Или о дороговизне отдельных людей на ролях?
Насчёт XP и Agile согласен во многом ... Считаю правда что лучшее оттуда стоит заимствовать при необходимости.
P.S.:
Насчёт NLP не согласен . Вы Бендлера и Гриндлера читали? . Можем продолжить обсуждение в отдельной ветке.
Здравствуйте, Gaperton, Вы писали:
G>2) Есть способ делать рефакторинг так, чтобы он обходился дешево. G>Описываю реальные, типовые ситуации рефакторинга в CQG, коду которого уже лет 17 и размером он в пару миллионов строк. Предваряя замечания — дай вам бог написать код, который не выкинут через 17 лет, и он будет актуален — в этом коде заложена великолепная архитектура и огромный запас "архитектурной прочности". Так вот, как врач говорю, пардон — как бывший руководитель группы разработки сервера. Рефакторинг представляет собой головную боль не тогда, когда надо механически класс на два побить, а когда вам сильносвязную подсистему с неизвестным или просто дико кривым дизайном надо привести к хорошо структурированной системе, которая была бы лишена целого класса известных проблем, плюс успешно, без потока дефектов, выдержала бы добавление известно новой функциональности. Причем, как правило, вы требования к системе в этом случае снимаете частично с описания проблем, частично проводя reverse engineering имеющегося кода. После reverse engineering вы будете долго думать, как вам изменить дизайн так, чтобы серия планируемых изменений прошла безболезненно, с одной стороны, и старая функциональность при этом легла хорошо — с другой (здесь нет никакого универсального метода "рефакторинга" — тут надо уметь прикладные кейсы в голове держать и представльять, как они на дизайн лягут). Возможна ситуация (в описываемом случае — почти наверняка), когда вы поменяете при этом границы подсистем и измените их интерфейсы (иначе новая функциональность может не лечь), вот тут ваши юнит-тесты написанные с таким трудом дружно и отвалятся. Всем скопом. И это типовая ситуацияпри развитии продукта — адаптации его к изменившимся требованиям. И рулить будет то, что я написал выше в пункте 1 — общесистемные regression tests, инварианты с условиями в коде, и "тестовые режимы" с включенным старым и новым кодом (так дешевле — не надо окружения под них готовить).
а где можно узнать побольше о таких "тестовых режимах"? правильно ли я понимаю, что при включенном таком режиме одновременно может работать и старых код (до рефакторинга) некой подсистемы и новый код (полученный после рефакторинга). Можно об этом рассказать подробнее?
Здравствуйте, Курилка, Вы писали:
К>Собственно наткнулся на статью, где автор выделяет следующие недостатки agile-подходов: К>1. Необходима большая вовлечённость пользователя в процесс разработки
Пользователь = человек со стороны заказчика, или так называемый Product Owner. Действительно, требуется его сильная вовлеченность в процесс разработки. Но именно благодаря этой вовлеченности нам и удается создать продукт, который больше всего подходит заказчику. К>2. Требования меняются и развиваются (не подходит, как минимум, для "fixed price" проектов)
Exigen сейчас разрабатывает технологию по продаже Agile-проектов как fixed-price. В мире нет ничего невозможного К>3. Требования создаются минимально достаточными (легче отрефакторить решение, чем спроектировать всё детально заранее)
Точно. А в чем минус? К>4. Тестирование задейстовано в течение всего процесса разработки.
Опять же: это позволяет добиться того, что разрабатываемый апликейшн уже с самого начала – работоспособен и может начать приносить заказчику прибыли (снижать издержки/риски) уже после первого спринта. Плюс найденные быги легче пофиксать в тот момент, когда ты их посадил, а не потом, через пару месяцев, вспоминать – что же ты тут такое понаписал?
Так в чем минус? К>5. "Частые поставки" (Frequent delivery), которые могут быть достаточно накладными
Частые поставки дают 2 огромных плюса:
• Новый функционал у заказчика появляется не в конце разработки всего продукта (через год-два), а после каждого спринта. А так как этот новый функционал как раз тот, который наиболее нужен заказчику на данный момент, то заказчик сразу же после начала его использования начинает получать больше прибыли (снижает свои риски/уменьшает издержки)
• Заказчик сразу же видит, где функционал не соответствует его ожиданиям и где его нужно изменить. И получает измененный функционал в конце следующего спринта. Опять-же: доволен пользователь (быстрая реакция на его запросы) => доволен руковолитель пользователя => довольны мы. Плюс Scrum-team видит, что продукт, который она разрабатывает – используется в жизни (чего не хватает при разработке больших проектов по системе waterfall), что только мотивирует команду и повышает ее мораль. К>6. Судя по откликам, agile-подходы напряжённы (intense) по отношению к разработчикам (100% реализация фич за итерацию и неукоснительность итераций "накладывет отпечаток")
100% реализация фич за итерацию – неправда. Некоторые фичи переезжают из спринта в спринт просто потому что они оказались длиннее чем сам спринт или просто мы их начали в конце спринта. В этом ничего нет страшного.
Если под 100% реализацией фич подразумевается наличие работающего билда в конце каждой итерации – то да. Это один из определяющих факторов успешности спринта. Но, почитав пункт 5 мы в реале видим, что команда не только от этого не расстраивается, но и мотивируется, видя, что ее продукт и новые фичи сразу же идут в продакшен. А intense – это больше вопрос правильных эстимейтов и отношений с заказчиком если что-то было плохо проэстимейчено.
SD>минус — рефакторинг стоит дороже (намного! дороже), чем детально спроектированное решение. Это неоспоримый факт! Чем ближе к релизу и чем больше "rollback", тем дороже это стоит.
Согласен про рефакторинги. Тут как раз идет сравнение времени, которое тратиться на разработку детального SRS а потом архитектуры со временем, которое мы может потратим (а может и нет) на последующие рефакторинги. Причем TDD во многом удешевит стоимость рефакторингов и последующего перетестирования.
SD>минусов больших не вижу, небольшой недостаток — кпд QA от тестирования намного ниже из-за траты времени на верификацию и декларирование времменых багов и связанных с побочными эффектами рефакторинга (которые известны девелоперам, и с или без участия QA будут исправленны к релизу). Но этот недостаток стоит фирме денег и бесполезного использования человеко-ресурсов (как тестировщиков, так и более ценное время разработчиков).
Это что за баги такие, которые «известны девелоперам», но еще не пофиксаны?
Фикс багов, как я писал выше, идет быстрее за счет быстрого реагирования. Плюс тесное общение людей внутри команды позволяет фиксать багги не регистрируя их в баг-треккинг системе, что еще больше снижает время их фикса.
SD>использование "в продукции" в сравнении с тестированием бета/спринт итерации на тест серверах на вымышленных данных совсем разные вещи и уж точно не приносят никакой прибыли, а иногда и спринт версия с кучей багов создает отрицательное впечатление и нервозность для заказчика.
Все зависит от уровня команды по умению эстимейтить и от умения скрам-мастера объяснить заказчику откуда баги и что с ними будет сделано в ближайшее время . А если команда умеет правильно эстимейтить – то билды после каждой итерации выглядят очень симпатично, и заказчик от этого только становится более счастливым. Это я говорю исключительно на примере моего текущего проекта: у нас бежит уже 12ый спринт, и команда вышла на такой уровень, что без всякого аврала в конце спринта мы показываем заказчику полностью работающую ф-ть, которую мы и планировали в начале спринта. Очень приятно.
SD>Пользователь может быть недоволен, подсчитывая допольнытельные денежные затраты на изменения, подсознательно и субьективно ощущая, что не все "идет по плану". SD>P.S. "используется в жизни.." — не используется. Когда дело доходит до дела — к релизу, заведению в продакшн, реальным данным и юзерам, только тогда начинается реальная работа над ошибками, патчи, потная тех-поддержка и нервно курящие тестировщики. Спринты и скрам — мертвому примочка.
Вид оплаты Time & Material всегда для заказчиков был менее интересен, чем Fixed Price. Поэтому наша компания сейчас разрабатывает подход, при котором мы сможем продавать Scrum-разработку за Fixed Price.
А по второму пункту – вот у нас сейчас пойдет в продакшен функциональность, которая была разработана за последние 4 спринта (2 месяца). Причем с этой функциональностью знаком уже и конечные пользователи за счет того, что мы ее им презентовали уже 3 раза (в конце каждого спринта). И не ожидается никакого «потная тех-поддержка и нервно курящие тестировщики».
Все зависит от того насколько правильно поставлен процесс
SD>Даже осознавая что не все фичи можно "распихать по коробкам" — спринтам, и часть переходит в следущий, это все равно откладывает негативный отпечаток на чуствительных разработчиков
Такого фид-бека не получал ни от одного из участников своих скрам-проектов… Может у меня просто не было чувствительных разработчиков?
SD>За годы участия в разработке и внедрении, не при какой технологи НЕ ВИДЕЛ, ЧТОБЫ итерации (не говоря даже о сырых бета версиях), а при агиле еще и потенциально подверженных рефакторингу, ШЛИ СРАЗУ В ПРОДАКШН!!!
Да, после каждого спринта в продакшен выходят очень редкие продукты (в конце спринта должен быть “Potentially shippable” билд, а вовсе необязательно продакшен), но все-равно продакшен случается намного чаще, чем при Waterfall и других моделях/методологиях разработки.
SD>минус — рефакторинг стоит дороже (намного! дороже), чем детально спроектированное решение. Это неоспоримый факт! Чем ближе к релизу и чем больше "rollback", тем дороже это стоит.
В теории мега-верно. Не придерёшься. В теории.
На практике фиксация проекта — риск. Дорогой риск.
Рефакторинги дороже, только когда применяются излишне плотно. Иначе — выигрыш из-за отсутствия тяжеловесных перестраховочных конструкций (если Вы фиксируете проект, его утяжеление — это чисто инстинктивный способ разработчика предупредить возможный риск изменений).
Здравствуйте, dangler, Вы писали:
D>Согласен про рефакторинги. Тут как раз идет сравнение времени, которое тратиться на разработку детального SRS а потом архитектуры со временем, которое мы может потратим (а может и нет) на последующие рефакторинги. Причем TDD во многом удешевит стоимость рефакторингов и последующего перетестирования.
Возможно, ..но в классике юниттесты никто не запрещает.
D>Это что за баги такие, которые «известны девелоперам», но еще не пофиксаны?
не буду углубляться в детали различных недоделок которые имеют место в незаконнченном продукте. Коротко пример: Новый функционал затрагивает рефакторинг старого кода, в котором временно ставятся "заглушки" (известные девелоперам ). Тут заканчивается спринт и тестировщики начинают писать баг репорты если заглушка оказыватся в поле их тестов по данному спринту. Что тут удивительного?
D>Все зависит от уровня команды по умению эстимейтить и от умения скрам-мастера объяснить заказчику откуда баги и что с ними будет сделано в ближайшее время . А если команда умеет правильно эстимейтить – то билды после каждой итерации выглядят очень симпатично, и заказчик от этого только становится более счастливым. Это я говорю исключительно на примере моего текущего проекта: у нас бежит уже 12ый спринт, и команда вышла на такой уровень, что без всякого аврала в конце спринта мы показываем заказчику полностью работающую ф-ть, которую мы и планировали в начале спринта. Очень приятно.
Похоже что у вас сферическая команда в вакууме
D>А по второму пункту – вот у нас сейчас пойдет в продакшен функциональность, которая была разработана за последние 4 спринта (2 месяца). Причем с этой функциональностью знаком уже и конечные пользователи за счет того, что мы ее им презентовали уже 3 раза (в конце каждого спринта). И не ожидается никакого «потная тех-поддержка и нервно курящие тестировщики».
D>Все зависит от того насколько правильно поставлен процесс
D>Да, после каждого спринта в продакшен выходят очень редкие продукты (в конце спринта должен быть “Potentially shippable” билд, а вовсе необязательно продакшен), но все-равно продакшен случается намного чаще, чем при Waterfall и других моделях/методологиях разработки.
Повторяю — показать из далека или отдать на реальное пользование — разные вещи.
И вообще, наверное мы говорим о разных вещах. Я о коробочном продукте для больших контор, которые физически не могут (и если и могут то им там по правилам не положено) делать апдейты в продакшн чаще чем раз в полгода, а после оффициального релиза продукт еще и тестируется в течении пары месяцев самыми консервативными заказчиками.
Здравствуйте, shrecher, Вы писали:
S>Здравствуйте, Курилка, Вы писали:
S>Основной недостаток в том, что фокусируемся на "что сделать", а не "как сделать". Идет планирование и анализ отт "user story", т.е. некой неформализованной сущьности. Как результат получается делитанское планирование, где главное сделать "что хочет заказчик" без должного внимания техническим деталям, которых заказчик даже и не знает. Понятно, что заказчик-пользователь внятно не может понять и представить "начинку" сложно системы. Все ограничивается "рожей": диалоги, орнаменты и пр.
S>>Основной недостаток в том, что фокусируемся на "что сделать", а не "как сделать". Идет планирование и анализ отт "user story", т.е. некой неформализованной сущьности. Как результат получается делитанское планирование, где главное сделать "что хочет заказчик" без должного внимания техническим деталям, которых заказчик даже и не знает. Понятно, что заказчик-пользователь внятно не может понять и представить "начинку" сложно системы. Все ограничивается "рожей": диалоги, орнаменты и пр.
G>Все правильно. Обратите внимание, что FDD лишен этого недостатка. Там — нет планирования от user story. G>http://en.wikipedia.org/wiki/Feature_Driven_Development#Develop_Overall_Model
Вот в общем и разобрались .
Подход новых процессов — не от кодирования и делания программы, а от управления требованиями и рисками.
Старые методологии (в том числе и MSF) конечно тоже решают эти вопросы, но не ставят их во главу угла. Для них главное — код. План по валу.
Вы считаете недостатком то, что апологеты новых процессов считают их основным достоинством.
При этом технические вопросы на самом деле никуда не исчезают и не задвигаются. Просто перестают быть приоритетом отчасти потому, что они являются более низкоуровневыми что ли относительно всего процесса и просто подразумеваются, не теряя при этом своей фактической значимости.
В этом отношении FDD — имхо просто кадавр какой-то
VGn>При этом технические вопросы на самом деле никуда не исчезают и не задвигаются. Просто перестают быть приоритетом отчасти потому, что они являются более низкоуровневыми что ли относительно всего процесса и просто подразумеваются, не теряя при этом своей фактической значимости.
Если что-то перестает быть приоритетом, то это и значит, что это задвигается. По крайней мере, я так это понимаю =)
Вообще, мне кажется, что многое зависит от области приложения усилий — одно дело, штамповать N-й по счету веб-сайт, когда действительно надо собрать требования и просто перенести их в готовый фреймворк, и совсем другое дело, когда пишется коробочный продукт, где надо приложить массу усилий, чтобы обогнать конкурентов и технические вопросы играют большую роль.
S>Основной недостаток в том, что фокусируемся на "что сделать", а не "как сделать". Идет планирование и анализ отт "user story", т.е. некой неформализованной сущьности. Как результат получается делитанское планирование, где главное сделать "что хочет заказчик" без должного внимания техническим деталям, которых заказчик даже и не знает.
Это ваше решение. Хотите — делаете "на тяп-ляп", лишь бы заказчику понравилось.
А можно делать по-человечески, оставаясь в рамках agile. Да и черт с ними, с этими рамками, в конце концов!
К примеру, у нас в итерации вполне могут встречаться такие задачи как "спроектировать нечто" или "исследовать возможность применения нечта" или "попробовать на маленьком кусочке применить нечто в объеме достаточном для того, чтобы можно было на следующей итерации оценить трудоемкость применения этого нечта в полный рост".
Ну и попробуй докажи мне, что это не agile Не будьте догматиками!
COF>Если что-то перестает быть приоритетом, то это и значит, что это задвигается. По крайней мере, я так это понимаю =)
Прочти ещё раз. Каким боком сущности на разных уровнях можно рассматривать конкурентно?
COF>Вообще, мне кажется, что многое зависит от области приложения усилий — одно дело, штамповать N-й по счету веб-сайт, когда действительно надо собрать требования и просто перенести их в готовый фреймворк, и совсем другое дело, когда пишется коробочный продукт, где надо приложить массу усилий, чтобы обогнать конкурентов и технические вопросы играют большую роль.
Ты меня не понял. Технические вопросы всегда играют роль. Только заказчик почти никогда не покупает технические вопросы и конкуренты редко конкурируют именно по техническим вопросам.
Здравствуйте, Gaperton, Вы писали:
G>А вообще — блин, какие ссылки — всегда есть требования, дизайн, кодирование, отладка. Однажды я спросил одного из директора R&D CQG, только что заступившего в должность, какой цикл разработки он собирается применять и вообще — какую методологию? Может быть, RUP? Или, все-таки, XP? Ян МакФэйден, который перед этим возглавлял отдел разработки крупнейшего американского банка (Wells Fargo, кажется), засмеялся, и сказал что-то вроде этого: I don't really care. It's always something like requirements, design, coding, and testing.
Right
G>Далее — в течени полугода Ян МакФэйден быстро, четко, без истерик и лишних движений, комплексом мер эффективно решил проблемы с качеством клиента CQG — проблема тогда была, что темп появления дефектов превышал темп их исправления, и никто не знал, что делать.
Выделенное глубоко верно, но это и так все знают.
Более интересно, какими именно мерами он "эффективно решил проблемы с качеством клиента CQG" ?
Кстати, я за этим чудо продуктом трейдил еще 9 лет назад и до сих пор этот ужас не забыл.
Опыт — это такая вещь, которая появляется сразу после того, как была нужна...
Здравствуйте, Gaperton, Вы писали:
G>наличием приоритетов по срочности работ (что приводит к "грязным решениям")
перечитывал старую тему, с целью вырости над собой и увидел оставленную фразу. не сможете более подробно её прокомментировать? что имели в виду когда писали одновременно приоритетность срочности и грязные решения? заранее спасибо.
Курилка пишет:
> 1. Необходима большая вовлечённость пользователя в процесс разработки
да, ублюдкам, которые "хочу что-то, сам толком не знаю что" это не
подходит
> 2. Требования меняются и развиваются (не подходит, как минимум, для > "fixed price" проектов)
как компромисс — рассматривать fixed price на итерацию, естественно
после согласования входящих в нее фич и договоренности ничего не менять
до выпуска версии.
> 3. Требования создаются минимально достаточными (легче отрефакторить > решение, чем спроектировать всё детально заранее)
предполагается что люди "в теме" и понимают о чем идет речь. А вот если
просят сделать блог, а потом оказывается что хотели вики с функцией
комментирования — придется брать кастомера за жабры и допрашивать вплоть
до расположения кнопочек.
> 4. Тестирование задейстовано в течение всего процесса разработки.
дык это даже плюс, имхо
> 5. "Частые поставки" (Frequent delivery), которые могут быть достаточно > накладными
если проблема в ресурсоемкости самого процесса передачи версии — надо
подумать как это можно автоматизировать. На одном из моих проектов
installation manual с 2х страниц (которые программер на стороне
заказчика с 1го раза никак не мог осилить, хоть и написано было
предельно просто ) мигрировал до одного install.sh, который все
делает сам.
> 6. Судя по откликам, agile-подходы напряжённы (intense) по отношению к > разработчикам (100% реализация фич за итерацию и неукоснительность > итераций "накладывет отпечаток")
бодрый тонус и рабочий темп не есть плохо. гораздо напряженнее
доделывать недостающие 99% в ночь перед дедлайном
Re[10]: Re[10]: почему. Иллюстрация к показателю maintainabi
От:
Аноним
Дата:
23.09.08 23:51
Оценка:
А>>Важно при этом также иметь вес и аргументы для того, чтобы в дальнейшем "пробивать" время не рефакторинг и тестирование "грязных" решений.
G>Видишь ли какая штука. По секрету говорю крамольную вещь — как бывший разработчик, а теперь как менеджер. Не надо иметь для этого ни веса, ни аргументов. Разработчик всегда имеет возможность сказать, что "время исправления дефекта займет много времени, он архитектурный". И все. Менеджер проверить не может никак. А вот как только ему дадут выбор — "могу быстро, могу медленно" — угадай результат.
Да, но ведь если так рассуждать, то разработчику никак не разыграть вариант с грязным исправлением и последующим рефакторингом. Либо он делает чистое решение и не успевает, либо делает затычку в срок, но теряет всякую надежду провести рефакторинг, т.к. нет дефекта — не о чем разговаривать.
Конечно, формулировать вопрос через "быстро или медленно" было бы не очень умно.
И согласен с тем, что правильно сформулированный вопрос не должен обременять начальство возможностью выбора =).
Но вообще, работая недалеко от позиции тимлида я верю, что регулярное общение и обсуждения с грамотным менеджером ну просто очень полезны. Приводит к тому, что у обоих складывается схожее видение проблем и реакция на них.
G>Как менеджер говрю. Не надо ставить меня, менеджера, в положении выбора, когда у менеджера объективно недостаточно информации, чтобы принять решение. Это решение — уровня тимлида, только у него достаточно информации (еще один плюс к необходимости должности тимлида, которые полупрограммеры, полуменеджеры). Оно должно подниматься выше только при серьезных случаях. Обычно, в таких случаях уже поздно .
В такое положение не надо.
Наверное, у нас в головах крутятся разные сценарии, или разное понимание ролей. У меня такой:
День до релиза (до сборки, которая должна стать релизом). Найдена проблема, которая ломает какую-то feature.
Тимлид приходит к менеджеру и на его языке кратко излагает проблему, impact, варианты, риски, оценку трудозатрат и т.д. А также свои мысли по решению.
Менеджер, пропуская это всё через своё видение ситуации, может решить
* Выпустить релиз с дефектом
— возможно, выпустить отдельную заплатку вскоре
* Отложить релиз
* Отменить релиз
* Убрать/спрятать функционал с дефектом
* Вставить ту самую временную затычку. Запланировать рефакторинг/тестирование на следующую итерацию, пересмотреть scope.
(наверняка найдутся ещё варианты)
Т.е. насколько у менеджера не хватает понимания технического контекста, настолько у тимлида может не хватать понимания внешних отношений с клиентами, обязательств, пространства для манёвров и т.д.
Потому вместе они — сила, а по отдельности — 2 силы, но послабее =)
Re[12]: почему. Иллюстрация к показателю maintainabi
От:
Аноним
Дата:
24.09.08 20:56
Оценка:
Странно, а от куда может браться грязный код при адекватном менеджменте?
G> Рефакторинг всегда проводится как часть работ, приносящих value, и его необходимость рассматривается постоянно. Это решение уровня тимлида.
А что ты подразумеваешь под рефакторингом?
Re[13]: почему. Иллюстрация к показателю maintainabi
Здравствуйте, Аноним, Вы писали:
А>Странно, а от куда может браться грязный код при адекватном менеджменте?
Объяснил выше, в том числе и с конкретными примерами.
G>> Рефакторинг всегда проводится как часть работ, приносящих value, и его необходимость рассматривается постоянно. Это решение уровня тимлида.
А>А что ты подразумеваешь под рефакторингом?
Gaperton пишет:
> А рефакторингов планировать заранее не надо. Это решение каждый раз > принимается при реализации полезных работ, и привязано к ним. Так — > правильно.
+1
Если конечно проект не в ж**е и рефакторинг не грозит затянуться на пару
месяцев
Re[12]: почему. Иллюстрация к показателю maintainabi
От:
Аноним
Дата:
27.09.08 00:36
Оценка:
G>Я в такой ситуации четко поставил тимлиду цель, разъяснил приоритеты, объяснил ответственность, и предложил принять решение самому. Он объясняет мне схему принятия своего решения, почему оно будет таким, какие альтернативы он рассмотрел, и если мне это кажется разумным, я его утверждаю. Пусть учится.
Вот, в целом такой подход мне тоже кажется разумным. Детали могут меняться в зависимости от понимания ролей в конкретной организации, но это детали.
G>А рефакторингов планировать заранее не надо. Это решение каждый раз принимается при реализации полезных работ, и привязано к ним. Так — правильно.
Для описанного (в предыдущем посте) примера это имеет смысл. Границы рефакторинга, его стоимость и риск не меняются со временем.
Если же проблема такова, что она гарантированно "всплывёт" позже, и задержка рефакторинга приводит к его удорожанию (новый код попадает под рефакторинг; тестирование после оного необходимо проводить заново), то не стоит откладывать.
Если обстоятельства позволяют сделать его сразу, лучше сделать сразу. Если же нет — запланировать наряду с другими задачами.
.
И вы спрашиваете меня, почем я решил, что XP == code and fix? 
