Начал чтение "Scrum и XP" Хенрика Книберга (читаю в переводе Agile Ukraine).
Только начал знакомиться, а уже стало интересно.
Такой вопрос: не становятся ли процесс разработки при использовании такой модели слишком человекозависимым? Контраргумент: всегда существует рабочий билд из последней итерации. Аргумент: все же упор на команду велик.
В то, что XP и грамотное ведение документации могут жить вместе я почти верю.
А еще интересно, как XP относится к проектам, на которых упор ставится на техподдержку, в условиях меняющихся техпроектов и перманентного добавления фич.
Быть может, повезет и приму участие в паре новых проектов, надо будет посмотреть, сравнить, поучаствовать.
Читаю дальше.
Это суть agile - все делает человек. Он меняет процессы по своему усмотрению и по уровню своего профессионализма и для своего удобства.
ОтветитьУдалитьПричем процессы у таких людей поставлены четко, и каждый в команде знает, что произойдет (надо сделать) за текущим шагом (или уровнем).
И это круто.
ХР очень хорошо относится к проектам, на которых упор ставится на техподдержку, в условиях меняющихся техпроектов и перманентного добавления фич. Но ХР - это епархия программистов. Это набор практик, а не процессов. Грубо говоря, мануальным тестировщикам, которые привыкли к стандартным методам тестирования, пришпилиться к подобным программистам будет очень сложно.
// всегда существует рабочий билд из последней итерации.
Это же не значит, что это всегда работоспособный, отличный, нужный клиенту билд...
"Это суть agile - все делает человек."
ОтветитьУдалитьХм. Одно из основных достоинств является серьезным недостатком. За все надо платить, резонно.
"ХР очень хорошо относится к проектам, на которых упор ставится на техподдержку, в условиях меняющихся техпроектов и перманентного добавления фич."
Я еще не дочитал, но разве пакет хотелок и претензий от клиентов из которых n надо сделать вчера серьезно не нагнет итерацию-другую-третью...?
"Но ХР - это епархия программистов. Это набор практик, а не процессов."
А разве не епархия группы разработки? Тестировщик не включаются в процесс? Аналитик? Техписатель?
Насчет билда точно.
-----
Хотелось бы прояснить. Я понимаю, что agile - инструмент. И не пытаюсь увериться в том, что он плохой или хороший. Но как всякий инструмент, он имеет границы применения. Собственно их и выясняю.
Надо так как.
// "ХР очень хорошо относится к проектам, на которых упор ставится на техподдержку, в условиях меняющихся техпроектов и перманентного добавления фич."
ОтветитьУдалить// Я еще не дочитал, но разве пакет хотелок и претензий от клиентов из которых n надо сделать вчера серьезно не нагнет итерацию-другую-третью...?
Не нагнет, если понимать, что такое TDD и что такое "автоматизация в agile"...
// "Но ХР - это епархия программистов. Это набор практик, а не процессов."
// А разве не епархия группы разработки? Тестировщик не включаются в процесс? Аналитик? Техписатель?
Рекомендую почитать источники, в которых рассказывается про основы работы в стиле agile (еще раз - это не большой процесс, это - стиль работы, подход, рабочие практики и навыки, которые могут применяться в любом БОЛЬШОМ процессе). Иначе мы можем дойти до "Пацаны! Всю страницу можно положить в одну большую таблицу, и дать ей какой захочешь bgcolor!", тогда как bgcolor можно приписать тэгу body, и вся страница будет закрашена нужным фоном...
Также надо понимать контекст, в котором возник agile, и условия, в которых он "рулит".
Особенно это касается пресловутой "документации". В Штатах ее бывает излишне много, и вместо софта на руках у клиента груда бумаг со спецификациями и исследованиями... В СНГ, где основной процесс - "как получится", документации иногда реально не хватает... Считать, что agile - это когда без документации - в корне неверно. Или у тебя Хаос, или у тебя все под контролем.
Это не лекарство от всех болезней, и при неумелом использовании agile может очень легко погубить как команду, так и компанию, которая рискнула...
// Я понимаю, что agile - инструмент. И не пытаюсь увериться в том, что он плохой или хороший. Но как всякий инструмент, он имеет границы применения. Собственно их и выясняю.
Инструмент - молоток.
Процесс - утром взять молоток в таком-то месте, использовать в таком-то режиме в такое-то время.
В итоге работы после молотка будет забито столько-то гвоздей в таких-то местах (аналитики заранее определяют, куда и что забивать).
В итоге работы молоток в определенном состоянии положить в определенное положение.
По итогам работы сдать табуретку.
Подход в стиле Agile подразумевает, что есть молоток, ты умеешь им пользоваться, ты взял его где надо и умеешь делать табуретки или их отдельные части.
Но если где-то что-то неудобно в процессе работы - ты это меняешь. В итоге все равно получится табуретка. Но никто не знает, что я могу вколотить гвозди быстрее или как-то умнее их держать в более доступном месте, что я умею сперва вколачивать в разрозненные части пару гвоздей, а затем сколачивать разрозненные части за счет этих уже вбитых гвоздей одним движением...
Или что я спец по табуреткам, но если соседнего специалиста по шкафам засосет под пилу, я стану на его место и тоже сколочу шкаф - просто потому, что он тоже додумался до того, как ускорить сборку шкафа, как быстро (очень быстро) проверять готовность шкафа или же быстро и без особых потерь его разобрать и пересобрать, если есть необходимость, и задачи неожиданно поменялись ("а тут вставьте зеркало и полку") как в принципе, так и в каких-то частностях.
У меня появилось ощущение, что я рассказываю о сексе на форуме для 12-тилетних товарищей или о пилотировании вертолета на форуме домохозяек, которые умеют водить автомобили :) Ничего личного, просто agile надо показать.
Будем смотреть, понимать, пробовать.
ОтветитьУдалитьХм.
Вот и мне тоже мама в детстве говорила: "Сынок, не увлекайся метафорами"
А ощущение правильное, верное ощущение, чего уж тут говорить. Ну, а нравится или нет мне формулировка - моя проблема, хех.
Почитаю, попробую.
Ишшо: http://testitquickly.com/2009/01/20/motivation-for-testing/
ОтветитьУдалитьПрограммистам не нужен надсмотрщик-проверяльщик, призрак которого где-то маячит, и скоро как придет, да как проверит всё и вся…
Им нужен помощник, равноценный им по уму-разуму чувак, который понимает, что, как и зачем они делают, и может подсказать, если где-то как-то слажали.
В работе agile-команды этот принцип проявляется со страшной силой.
Там тестирование, в общем, сосредоточено на TDD - постоянной проверке всех миллионов отдельных модулей после каждого изменения и перед каждой сборкой билда в автоматическом режиме.
В целом это может привести к тому (может, а не приводит), что на долю тестировщика остается прохождение основной функциональности и/или еще и всякие издевательства над софтом, не предусмотренные требованиями.
Работать в таком режиме без предварительной подготовки и хотя бы частичной к этому предрасположенности невозможно. Особенно тестировщику.
Если программисты все грамотно делают, то тестировщик начинает придумывать себе работу или же проверяет какие-то орфографические ошибки в текстах :)
Шутка.
В общем, нет "код заморожен, начинаем этап тестирования". И не нужно :) "А как же регрешн?" А не нужно, если скрипты ну уровне юнит-тестинга все делают за пять-шесть секунд, и находят проблемы быстрее и четче, нежели пять человек-тестировщиков...
Хуже нет ситуации, когда люди пытаются сделать agile, но пользуются старыми приемами или же старой организацией и распределением ролей. От agile резко остаются только какие-то приколы, ритуалы, ненужные скрипты, которыми никто уже не может пользоваться, и разрулить такую ситуацию без коренных изменений невозможно...
Можно сказать так: работать по принципам agile очень удобно и разумно, если ты программист, и отвечаешь сам за себя. Тогда в твоих руках неимоверная силища. Качество работы неизменно повышается (поначалу в TDD абсолютно все тормозят, зато потом начинается party; но если сдаться, то party не будет).
Дада, в целом так и представляю. Через пару тройку дней старт проекта, как раз небльшими командами.
ОтветитьУдалитьХочу серьезно повлиять на деятельность той группы,в которую могу быть включен.
Потому много вопросов.
В книге-то как раз остановился на главе о тестировании, утром перечитаю на свежую голову и буду смотреть, что нужно сделать в реалиях нашей конторы.
А насчет "код заморожен" - согласен, почти фантастика. Сегодня и для меня.
Какие еще вопросы не освещены?
ОтветитьУдалитьПока они разрешимы, так как знания чисто теоретические.
ОтветитьУдалитьТак скажем - есть видение вариантов реализации agile у нас.
Очень конкретные вопросы придут с практикой.
Ну и с утра тоже.
Спасибо за ответы, astenix.
>> "Это суть agile - все делает человек."
ОтветитьУдалить>> Хм. Одно из основных достоинств является серьезным недостатком. За все надо платить, резонно.
В книжке нет упора на самое главное - упор можно делать ТОЛЬКО на хороших людей, которым не страшно доверить судьбу своей задницы. Как только появляются сомнения в профессионализме и самодисциплине - спасение окажется только в бюрократии.
Вот этим и платишь, т.к. нужны мудрые и самоорганизованные ребята.
>> А еще интересно, как XP относится к проектам, на которых упор ставится на техподдержку, в условиях меняющихся техпроектов и перманентного добавления фич.
ОтветитьУдалитьТочно так же как и к проектам разработки с нуля. Если очень грубо, то после первой итерации "разработка с нуля" превращается в "техподдержку, в условиях меняющихся техпроектов и перманентного добавления фич" :)