Comments 62
«Мы даже садимся рядом, чтобы другой чел не читал хабр в то время когда я кодирую»
Наконец-то честно сказали, зачем нужно парное кодирование
Наконец-то честно сказали, зачем нужно парное кодирование
Статья о Scrum а описывается в основном Extreme Programming, где раскрытие темы статьи? я так и не понял что такое Scrum, почему он панацея и где он полезен :(
Пиво закончилось =P
а он статью пишет тоже по scrum'у
Scrum, это Agile методология управления проектами, в основу которой положены принципы и подходы XP. Включая основной. Если это не оттенить, то говорить о Scrum сложно. Что бы не сказать — бесполезно.
Да какая разница, не принципиально, статья то хорошая =) Все бы так писали. Да и как указал автор нужно быть последовательным.
Радует меня такие статьи, статьи — в которых, с долей юмора, сам автор, описывает проблемную тему. Не копипаст выдержек из разных источников, а именно рассказ. В общем Спасибо, и шоу маст гоу он =)
Радует меня такие статьи, статьи — в которых, с долей юмора, сам автор, описывает проблемную тему. Не копипаст выдержек из разных источников, а именно рассказ. В общем Спасибо, и шоу маст гоу он =)
Во первых не пойму для кого эта статья — для пм-ов или членов команды?
Комментарии:
качество кода и скрам — никак не связаны. точно так же налажать можно и в водопаде, и в итерациях, и в спринте. зря вы это смешали.
отсутствие документации — тоже не верно. мои проекты документируются. спецификации — нет, но она и не нужна, поскольку все и так уже описано в product requirements.
основной принцип скрама не в том, что — сначала сделаем, а потом посмотрим. а в том, что делается понемногу, минимальными итерациями — неделя-две. это значит что через неделю заказчик получает оттестированный продукт, в которой есть по крайней мере одна имплементированная фича и CR. Таким образом минимизируется изменения в работающих компонентах. Но команда тем не менее отвечает за качество и полноту кода.
Я понимаю, что можно привести пример когда скрам или водопад заваливает проект. Тем не менее скрам интересен своей динамичностью, люди не сидят в одном и том же месте (коде) неделями, а могут оперативно меняться. Это кстати, одна из причин pair programming. Есть несколько основных принципов в agile (которые, например, можно узнать из книжки Бека): common ownership, pair programming, shared knowledge.
Как человек, поработавший со всем, чем можно могу сказать, что скрам «веселее», дает больше шансов проявиться, проекты как правило небольшие и не дают засиживаться. Но и выкладываться конечно в скрам-проекте на 100% придется. Так что любителям полазать в контакте не советую.
Комментарии:
качество кода и скрам — никак не связаны. точно так же налажать можно и в водопаде, и в итерациях, и в спринте. зря вы это смешали.
отсутствие документации — тоже не верно. мои проекты документируются. спецификации — нет, но она и не нужна, поскольку все и так уже описано в product requirements.
основной принцип скрама не в том, что — сначала сделаем, а потом посмотрим. а в том, что делается понемногу, минимальными итерациями — неделя-две. это значит что через неделю заказчик получает оттестированный продукт, в которой есть по крайней мере одна имплементированная фича и CR. Таким образом минимизируется изменения в работающих компонентах. Но команда тем не менее отвечает за качество и полноту кода.
Я понимаю, что можно привести пример когда скрам или водопад заваливает проект. Тем не менее скрам интересен своей динамичностью, люди не сидят в одном и том же месте (коде) неделями, а могут оперативно меняться. Это кстати, одна из причин pair programming. Есть несколько основных принципов в agile (которые, например, можно узнать из книжки Бека): common ownership, pair programming, shared knowledge.
Как человек, поработавший со всем, чем можно могу сказать, что скрам «веселее», дает больше шансов проявиться, проекты как правило небольшие и не дают засиживаться. Но и выкладываться конечно в скрам-проекте на 100% придется. Так что любителям полазать в контакте не советую.
Перенёс текст сюда снизу.
Когда речь заходит о некоем наборе принципов, которые лягут в основу методологий, то вначале важно уловить именно ключевую суть, а не перчислить все сопутствующие признаки. Ключевая суть XP именно в том, что бы завязать проект в спираль, на каждом витке которой вы имеете работающую систему. И, тем самым, имеете что-то, отчего сразу можете отталкиваться в вашей коммуникации с заказчиком.
XP кстати, имеет и ещё одну жёстокую особенность, которая часто остаётся в тени. А именно — что бы построить проект таким образом, вам нужно крайне хорошо владеть принципами проектирования. Ибо никаким рефакторингом вы не заполируете тот факт, что, к примеру, на ранних этапах проектирования вы допустили серъёзные изъяны в декомпозиции системы.
Когда речь заходит о некоем наборе принципов, которые лягут в основу методологий, то вначале важно уловить именно ключевую суть, а не перчислить все сопутствующие признаки. Ключевая суть XP именно в том, что бы завязать проект в спираль, на каждом витке которой вы имеете работающую систему. И, тем самым, имеете что-то, отчего сразу можете отталкиваться в вашей коммуникации с заказчиком.
XP кстати, имеет и ещё одну жёстокую особенность, которая часто остаётся в тени. А именно — что бы построить проект таким образом, вам нужно крайне хорошо владеть принципами проектирования. Ибо никаким рефакторингом вы не заполируете тот факт, что, к примеру, на ранних этапах проектирования вы допустили серъёзные изъяны в декомпозиции системы.
Пара комментариев:
>> Почему? Ну, наверное, потому что скрам крайне неформальный подход к разработке, предполагающий минимум документирования и много общения. Вы часто видели
>> разработчиков, которым нравится писать отдельную документацию на свой собственный код? Я – редко.
Это общее заблуждение всех, кто про SCRUM и XP только читал. В книгах написано не «документации быть не должно», а «не надо создавать ЛИШНЕЙ документации». То есть, если заказчику и коменде не нужна полная UML схема проекта, то не надо ее делать. Если небольшой документации в wiki по каждому модулю достаточно — отлично, не надо писать целую книгу про программу. Не нужно заводить специальную должность, который будет писать документацию, если она не нужна.
>> — Мы не паримся с тщательным названием переменных и методов кода. Мы выгоняем код быстро. Мы даже садимся рядом, чтобы другой чел не читал хабр в то время
>>когда я кодирую
Про «не паримся с названием» — это вообще неправда и обман. В гибких технологиях качество кода — одна из важнейших составляющих успеха. У всех есть coding standards, code review и т.п. Парное программирование вообще позволяет забыть про страшный код, т.к. второй именно за этим и следит. Ну, также и чтобы на хабр не лезть — да. Это, кстати, производительность иногда в разы повышает :)
Но в целом про XP верно написано, если убрать негативный оттенок из текста :)
Смысл — Подцепить заказчика на крючок и держать его там до конца. Но это обоюдовыгодный крючок.
>> Почему? Ну, наверное, потому что скрам крайне неформальный подход к разработке, предполагающий минимум документирования и много общения. Вы часто видели
>> разработчиков, которым нравится писать отдельную документацию на свой собственный код? Я – редко.
Это общее заблуждение всех, кто про SCRUM и XP только читал. В книгах написано не «документации быть не должно», а «не надо создавать ЛИШНЕЙ документации». То есть, если заказчику и коменде не нужна полная UML схема проекта, то не надо ее делать. Если небольшой документации в wiki по каждому модулю достаточно — отлично, не надо писать целую книгу про программу. Не нужно заводить специальную должность, который будет писать документацию, если она не нужна.
>> — Мы не паримся с тщательным названием переменных и методов кода. Мы выгоняем код быстро. Мы даже садимся рядом, чтобы другой чел не читал хабр в то время
>>когда я кодирую
Про «не паримся с названием» — это вообще неправда и обман. В гибких технологиях качество кода — одна из важнейших составляющих успеха. У всех есть coding standards, code review и т.п. Парное программирование вообще позволяет забыть про страшный код, т.к. второй именно за этим и следит. Ну, также и чтобы на хабр не лезть — да. Это, кстати, производительность иногда в разы повышает :)
Но в целом про XP верно написано, если убрать негативный оттенок из текста :)
Смысл — Подцепить заказчика на крючок и держать его там до конца. Но это обоюдовыгодный крючок.
Нагативного оттенка нет. Я считаю, что именно на XP подходы в наше время и должны опираться методологии управления проектами. Обязательно ли это должна быть методология Scrum, это уже другой вопрос.
Насчёт документации. Вы абсолютно правы. Я также нигде не встречал, что некая методология вслух постулирует позицию вида — не пишите документацию. Конечно же нет. Но, если методология явно не настаивает на том, какие документы и где должны порождаться в процессе ведения проекта, то тем самым она оставляет это на откуп разработчика или руководителя проекта. И у них соблазн велик. Многие искренне полагают, что Скрам им развязал руки и терь можно только говорить и ничего не писать. Типа мы и раньше так делали, а тут и научная база подоспела. Это действительно заблуждение.
К примеру, если взять RUP, то там внятно перечислено достаточно много так называемых артефактов, которые должны (желательны) порождаться на каждой стадии проекта. Артефакт, это, грубо говоря, некий, как правило бумажный, выхлоп после прохождения стадии создания проекта. Называется он таким словом потому, что быть он может разным. Это и текст, и UML-диаграмма, и просто сведёные в таблицу кейсы, и… RUP использует UML и тщательно прописывает какого рода UML диаграммы вам желательно сделать в том или ином случае.
По поводу качества кода. Тут опять же — ни одна здравомыслящая методология не предлагает писать грязный код или код не в соответствии с принятыми в компании стандартами. Ни в коем разе.
Но, XP прямо и честно говорит — и в коде не старайтесь всё учесть сразу. Не тратьте на первых этапах свое время на то, что бы придумать максимально точное название. Не тратьте время на то, что бы сразу и окончательно решить будет эта переменная локальной или членом класса. Не тратьте сразу время на то, что бы окончательно решить что будет отдельным методом класса и какая у него область видимости. Не потому, что это не важно, а потому, что вы пока этого окончательно не знаете. Признайте факт того, что с высокой вероятностью это может измениться и сейчас сделайте так как вам удобнее. Затем, когда некая часть кода устоится (или просто появится больше определённости), вы обязательно зарефакте эту часть, что бы окончательный код был действительно хорош и удобен. Вот где-то так примерно.
Насчёт документации. Вы абсолютно правы. Я также нигде не встречал, что некая методология вслух постулирует позицию вида — не пишите документацию. Конечно же нет. Но, если методология явно не настаивает на том, какие документы и где должны порождаться в процессе ведения проекта, то тем самым она оставляет это на откуп разработчика или руководителя проекта. И у них соблазн велик. Многие искренне полагают, что Скрам им развязал руки и терь можно только говорить и ничего не писать. Типа мы и раньше так делали, а тут и научная база подоспела. Это действительно заблуждение.
К примеру, если взять RUP, то там внятно перечислено достаточно много так называемых артефактов, которые должны (желательны) порождаться на каждой стадии проекта. Артефакт, это, грубо говоря, некий, как правило бумажный, выхлоп после прохождения стадии создания проекта. Называется он таким словом потому, что быть он может разным. Это и текст, и UML-диаграмма, и просто сведёные в таблицу кейсы, и… RUP использует UML и тщательно прописывает какого рода UML диаграммы вам желательно сделать в том или ином случае.
По поводу качества кода. Тут опять же — ни одна здравомыслящая методология не предлагает писать грязный код или код не в соответствии с принятыми в компании стандартами. Ни в коем разе.
Но, XP прямо и честно говорит — и в коде не старайтесь всё учесть сразу. Не тратьте на первых этапах свое время на то, что бы придумать максимально точное название. Не тратьте время на то, что бы сразу и окончательно решить будет эта переменная локальной или членом класса. Не тратьте сразу время на то, что бы окончательно решить что будет отдельным методом класса и какая у него область видимости. Не потому, что это не важно, а потому, что вы пока этого окончательно не знаете. Признайте факт того, что с высокой вероятностью это может измениться и сейчас сделайте так как вам удобнее. Затем, когда некая часть кода устоится (или просто появится больше определённости), вы обязательно зарефакте эту часть, что бы окончательный код был действительно хорош и удобен. Вот где-то так примерно.
Когда речь заходит о некоем наборе принципов, которые лягут в основу методологий, то вначале важно уловить именно ключевую суть, а не перчислить все сопутствующие признаки. Ключевая суть XP именно в том, что бы завязать проект в спираль, на каждом витке которой вы имеете работающую систему. И, тем самым, имеете что-то, отчего сразу можете отталкиваться в вашей коммуникации с заказчиком.
XP кстати, имеет и ещё одну жёстокую особенность, которая часто остаётся в тени. А именно — что бы построить проект таким образом, вам нужно крайне хорошо владеть принципами проектирования. Ибо никаким рефакторингом вы не заполируете тот факт, что, к примеру, на ранних этапах проектирования вы допустили серъёзные изъяны в декомпозиции системы.
XP кстати, имеет и ещё одну жёстокую особенность, которая часто остаётся в тени. А именно — что бы построить проект таким образом, вам нужно крайне хорошо владеть принципами проектирования. Ибо никаким рефакторингом вы не заполируете тот факт, что, к примеру, на ранних этапах проектирования вы допустили серъёзные изъяны в декомпозиции системы.
Все используем, но по поводу тестов: для многих функций мы не пишем тесты только потому, что написание теста занимает столько времени, за сколько можно написать еще пару-тройку функций :)
В основном, если пишем тесты, то для, скажем так, «вычислительных функций», в которых зашит некий алгоритм с достаточно сложной логикой.
Т.е. если функция выбирает данные с базы и возвращает некий объект, то для такой функции тесты, по-моему, излишни.
Хотя, с точки зрения TDD это, может и неверно, но все-таки надо применять гибкий подход: иногда писать тесты, а иногда и нет :)
В основном, если пишем тесты, то для, скажем так, «вычислительных функций», в которых зашит некий алгоритм с достаточно сложной логикой.
Т.е. если функция выбирает данные с базы и возвращает некий объект, то для такой функции тесты, по-моему, излишни.
Хотя, с точки зрения TDD это, может и неверно, но все-таки надо применять гибкий подход: иногда писать тесты, а иногда и нет :)
Тесты не только для того, чтобы проверить расчеты. Они, в частности, для того, чтобы держать всю систему в согласованном состоянии и быть уверенным, что разные блоки системы нормально стыкуются друг с другом и ничего «друг у друга не ломают». Это принципы постоянной интеграции (CI) — в маленьком проекте это может быть не так критично, но для продуктов, поддерживаемых и дорабатываемых (и расширяемых) в течение длительного времени — это просто панацея от большинства багов (в особенности, функциональных и интеграционных).
Да, сама концепция «запустил набор тестов-получил ответ, где баги» мне нравится.
Во многих случаях действительно получалось, что изменение в одной части системы нарушало что-то в другой,
но становилось это видно только тогда, тогда добираешься до проверки той другой части.
Вот только подскажите, как бы ее начать применять и не забить на полпути? :)
Еще одна проблема, которая возникает при внедрении TDD — непонятность с объемом:
если есть 25 объектов, и у каждого по 6-7 функций, то выходит, что нужно минимум 150 тестов, не учитывая
комплексных, которые работают с несколькими объектами или функциями.
Как быть?
Или где об этом почитать :)? (не теорию, а именно практические аспекты применения)
Во многих случаях действительно получалось, что изменение в одной части системы нарушало что-то в другой,
но становилось это видно только тогда, тогда добираешься до проверки той другой части.
Вот только подскажите, как бы ее начать применять и не забить на полпути? :)
Еще одна проблема, которая возникает при внедрении TDD — непонятность с объемом:
если есть 25 объектов, и у каждого по 6-7 функций, то выходит, что нужно минимум 150 тестов, не учитывая
комплексных, которые работают с несколькими объектами или функциями.
Как быть?
Или где об этом почитать :)? (не теорию, а именно практические аспекты применения)
Да, совершенно верно. Придется писать эти, грубо говоря, 150 тестов. Более того, тесты могут быть достаточно сложными (если используется подход mocking-а объектов и тестирование поведений — один из двух стилей TDD). Но это с лихвой (в частности, у нас) окупается отсутствием длительного времяпрепровождения в дебаггере и в простоте дальнейшей поддержки и беспрепятственным развитием нового функционала.
CI — внедряется совсем не сложно. Не буду описывать здесь всю концепцию, однако в целом процесс выглядит так:
— Задачи делятся на очень атомарные (то есть, программист не должен выполнять одну задачу, скажем, неделю, максимум — день);
— Все всегда хранится в репозитории контроля версий;
— Кусок кода (рабочая копия), полностью покрытый тестами и работающий помещается в репозиторий;
— Параллельно, при загрузке, может возникнуть необходимость соединения кусков файла когда разные разработчики работали с одним и тем же файлом);
— На сервере стоит CI-сервер (мы используем CruiseControl.NET), который автоматически после помещения разработчиком его куска кода, с помощью NAnt собирает общий билд решения и запускает необходимые тесты на выполнение (также запускается NCover для проверки уровня покрытия кода тестами и несколько других полезных и не очень утилит);
— Если все тесты, запущенные CI-сервером выполняются, значит интеграция прошла успешно.
— Если часть тестов не выполнилась — разработчик, запустивший свой код в репозиторий последним, устраняет ошибки, переписывая часть кода (причем, не только своего!), чтобы все тесты всего решения выполнялись;
В итоге получаем, что решение в репозитории всегда работающее, а ошибки не живут, в общем случае, больше суток. Причем, это не зависит от размера проекта. В итоге, мы не проводим перед релизом (или после его предполагаемой даты :), интеграцию, в течение трех недель вылавливая ошибки и пытаясь понять «кто и где напортачил».
Более подробно и детально процесс описан в статье Мартина Фаулера Continuous Integration.
CI — внедряется совсем не сложно. Не буду описывать здесь всю концепцию, однако в целом процесс выглядит так:
— Задачи делятся на очень атомарные (то есть, программист не должен выполнять одну задачу, скажем, неделю, максимум — день);
— Все всегда хранится в репозитории контроля версий;
— Кусок кода (рабочая копия), полностью покрытый тестами и работающий помещается в репозиторий;
— Параллельно, при загрузке, может возникнуть необходимость соединения кусков файла когда разные разработчики работали с одним и тем же файлом);
— На сервере стоит CI-сервер (мы используем CruiseControl.NET), который автоматически после помещения разработчиком его куска кода, с помощью NAnt собирает общий билд решения и запускает необходимые тесты на выполнение (также запускается NCover для проверки уровня покрытия кода тестами и несколько других полезных и не очень утилит);
— Если все тесты, запущенные CI-сервером выполняются, значит интеграция прошла успешно.
— Если часть тестов не выполнилась — разработчик, запустивший свой код в репозиторий последним, устраняет ошибки, переписывая часть кода (причем, не только своего!), чтобы все тесты всего решения выполнялись;
В итоге получаем, что решение в репозитории всегда работающее, а ошибки не живут, в общем случае, больше суток. Причем, это не зависит от размера проекта. В итоге, мы не проводим перед релизом (или после его предполагаемой даты :), интеграцию, в течение трех недель вылавливая ошибки и пытаясь понять «кто и где напортачил».
Более подробно и детально процесс описан в статье Мартина Фаулера Continuous Integration.
Кстати, при использовании CI, то, что разработчики правят код друг друга приводит к реализации другой хорошей практике Agile — коллективное владение кодом. При грамотном использовании ротации и рецензировании кода, каждый сотрудник в проекте, помимо понимания всех частей системы, становится также в значительной степени заменяемым — нет страха того, что если он заболеет/уйдет/уедет в отпуск, некому будет поддерживать и развивать код, написанный им.
Концепция тестов в XP чуть шире. Что бы просто найти баги, достаточно один раз всё аккуратно проверить и поправить. В XP же предполагается, что вы и код будете итеративно менять (проводить рефакторинг), что бы он был вылизан и удобен для последующего сопровождения.
Меняя код, всегда есть риск внести ошибку. Посему, помимо поиска ошибок, программыне тесты (юнит-тесты) нужны для быстрой механической проверки уже работающих кусков кода после рефакторинга.
Меняя код, всегда есть риск внести ошибку. Посему, помимо поиска ошибок, программыне тесты (юнит-тесты) нужны для быстрой механической проверки уже работающих кусков кода после рефакторинга.
Здесь стоит провести небольшую грань между Scrum и XP. Сами создатели Скрама говорят, что это больше «организационная» (то есть, о том, как организовать сам проект) методология, и никак не противоречит использованию «инженерных» (то есть, как организовать работу над реализацией проекта, включая технические аспекты) методологий вроде XP.
Объединяет же их то, что они обе «agile» — то есть это адаптивный подход, связанный с реальностью — для сложной системы никогда не известно заранее, что должно получиться и лучше не «гадать на кофейной гуще», а разрабатывать постепенно то, что уже известно.
Инженерные практики типа TDD здесь просто в помощь и адресованы для решения вполне конкретных проблем.
Сами используем и XP и Scrum, чему несказанно рады. Люди уже просто не представляют как можно работать без таких техник, как Test-Driven Development, CI (Continuous Integration) и других — ведь это в разы повышает качество и предсказуемость кода, чем сильно упрощает жизнь.
Вообще, прийти к Alige заставляет понимание того, что процесс разработки должен быть как-то адаптирован к постоянным запросам на изменение от заказчиков, а классический процесс не адаптирован к этому.
Объединяет же их то, что они обе «agile» — то есть это адаптивный подход, связанный с реальностью — для сложной системы никогда не известно заранее, что должно получиться и лучше не «гадать на кофейной гуще», а разрабатывать постепенно то, что уже известно.
Инженерные практики типа TDD здесь просто в помощь и адресованы для решения вполне конкретных проблем.
Сами используем и XP и Scrum, чему несказанно рады. Люди уже просто не представляют как можно работать без таких техник, как Test-Driven Development, CI (Continuous Integration) и других — ведь это в разы повышает качество и предсказуемость кода, чем сильно упрощает жизнь.
Вообще, прийти к Alige заставляет понимание того, что процесс разработки должен быть как-то адаптирован к постоянным запросам на изменение от заказчиков, а классический процесс не адаптирован к этому.
Scrum подразумевает работу в команде, а это немного отличается от парного программирования тем, что 2 человека не тыкают по очереди по одной клавиатуре, а они садятся и обсуждают каким образом модули, которые они будут реализовывать будут соединены воедино, и смысл в том что именно это обсуждение заменяет документацию (уменьшает ее объем и время потраченное на нее).
Никакая методика не является панацеей, если методика позиционирует себя как панацея — это повод лишний раз ее внимательно проверить на адекватность ситуации, к которой ее предлагается приложить. Панацеей является только желание думать и выбирать методику или набор методик, которые подходят к конкретной ситуации.
Я бы вынес описание сабжа ДО хабраката. Это позволит человеку понять о чем идет речь, не открывая страницу — простое правило хорошего тона.
невероятная профанация — такое ощущение, что автор далек от управления проектами. Это, наверное, плохо и, возможно, невежливо, но копаться в тексте и расписывать каждое некорректное место не буду — не стоит того. Просто, наткнувшись на фразу «Лет десять назад самые мудрые из нас, набрались смелости и приняли другое решение, и постулировали иные принципы.» — типа, водопад, это плохо, а итеративная/спиральная разработка лучше? Очевидно же, что для разных проектов подходят разные методологии. И есть, и долго еще будет большое количество проектов, для которых подходит только «водопад», пусть даже с большими затратами. После пары таких высказываний и откровенно небрежных выводов нет желания что-либо пытаться улучшить в этой статье. Соответственно, такие высказывания заставляют задуматься: то ли Автор так не уважает читателей, что позволяет себе писать откровенную ерунду, то ли он сам в этом слабо разбирается.
поэтому вопрос, который с первых строк возник — для чего Автор написал эту статью? он столкнулся с соответствующей проблемой и решил обсудить ее? или что-то для себя понял и решил просветить начинающих? другой вариант? поэтому и интересно, какое отношение сам Автор имеет к УП? (несмотря на первый «негативный» абзац, это не попытка перехода на личности — вопрос возник сразу же, при прочтении вступления — всегда лучше воспринимаю статью, если понимаю мотивацию автора, или хотя бы то, что он за нее выдает).
поэтому вопрос, который с первых строк возник — для чего Автор написал эту статью? он столкнулся с соответствующей проблемой и решил обсудить ее? или что-то для себя понял и решил просветить начинающих? другой вариант? поэтому и интересно, какое отношение сам Автор имеет к УП? (несмотря на первый «негативный» абзац, это не попытка перехода на личности — вопрос возник сразу же, при прочтении вступления — всегда лучше воспринимаю статью, если понимаю мотивацию автора, или хотя бы то, что он за нее выдает).
Автор имеет некоторый опыт управления проектами. :-)
Также, автор не имеет ничего против водопада. Также как и Рупа и прочих. Автор также полагает, что XP подходы были достаточно революционны в свое время и заметно отличались от других. С проблемами управления автор сталкивался часто. Читателей он уважает. Иначе не стал бы писать.
Также, автор не имеет ничего против водопада. Также как и Рупа и прочих. Автор также полагает, что XP подходы были достаточно революционны в свое время и заметно отличались от других. С проблемами управления автор сталкивался часто. Читателей он уважает. Иначе не стал бы писать.
Спасибо.
Собственно, остается вопрос: цель этой статьи? И, конечно, когда будет раскрыта собственно тема статьи? Пока что есть только некое описание трех методологий, но тема выбора не затронута
Собственно, остается вопрос: цель этой статьи? И, конечно, когда будет раскрыта собственно тема статьи? Пока что есть только некое описание трех методологий, но тема выбора не затронута
Цель — перевести обсуждение Скрам в критическую плоскость. Не потому, что он плох, а ради понимания того, что и где он навязывает, когда даёт свободу и какие важные вещи действительно остаются на откуп разработчикам или просто остаются за кадром. Что бы применять его грамотно и точно, не сводя возможную неудачу проекта к недостаткам методологии.
хорошая цель)
довольно интересный вопрос, хоть и выводящий за пределы привычной сфре скрама — в каких непрограммистских/неайтишных проектах его можно применять. Я на такой вопрос не могу ответить с достаточной долей уверенности.
если брать айти — интересно рассмотреть проекты с «внутренним» заказчиком. например, в проектах разработки и внедрения внутрикорпоративного продукта. Как правило, такие проекты затрагивают не одно подразделение, соответственно, много руководителей так или иначе участвует в проекте или пытается на него влиять. Тут, по моему мнению и опыту, скрам позволяет максимально защитить и команду проекта, и сам проект от множества векторов влияния, продиктованных, к тому же, самыми разнообразными причинами. Но для этого (опять же по опыту), очень сплоченно должны действовать куратор и руководитель проекта (т.е. Product Owner и Scrum Master) — им вместе придется стандартные совещания начальства стараться сделать максимально продуктивными для ведения баклога проекта, и вместе же придется отстаивать такие вещи, как неприкосновенность плана текущего спринта. Кроме того, могут быть проблемы, если участники команды структурно находятся в разных подразделениях — соответственно, над ними, кроме руководителя проекта, есть еще линейные руководители, опять же имеющие свою точку зрения на проект, не всегда совпадающую с утвержденным баклогом (такая ситуация может быть в айтишных фирмах). Другие интересные варианты проектов с «внутренним» заказчиком — разработка принципиально нового продукта/разработка продукта, уже имеющего аналоги, в т.ч. новой версии существующего продукта. Отличаются, по моему, в первую очередь агрессивностью внешней среды — во втором случае добавляются такие факторы давления, как ожидания/претензии существующих пользователей, учет проекта в планах продаж, соответственно, различные публичные обещания руководства, маркетологов и т.п. Первый случай — это, фактически, стартап, т.е. проект, не встраивающийся в существующий рынок, а пытающийся этот рынок изменить/перевернуть/создать новый, и не имеющий описанной «наследственности» — существующих пользователей и т.п. Несмотря на то, что проекты а ля стартапы имеют тенденцию сильно меняться в ходе своего развития, все-таки постоянного сильного давления на них нет. К проектам первого типа скрам, по-моему, вообще очень хорошо подходит — позволяет двигаться даже без четкой дорожной карты. К проектам второго, в принципе, не хуже — опять же, внешняя среда очень изменчива.
проекты с внутренним заказчиком интересны прежде всего потому, что они заведомо рассчитаны на «продолжение» — после формального запуска проекта так или иначе его нужно продолжать разрабатывать, и, обычно, силами той же команды. То есть у них заведомо есть установка — сделать успешный продукт. В то время как в проектах «для дяди» основная цель — сделать продукт, которым будет доволен заказчик (успешно сдать продукт). А некоторая разница между этими целями есть)
Важный момент: под разработчиками Вы понимаете программистов/проектировщиков/архитекторов или всех членов команды? потому что говорить, что скрам отдает на откуп программистам какую-либо задачу, обычно не свойственную им, например, аналитику, — неверно в принципе: скрам позволяет команде самой задавать распределение задач, но происходит это в соответствии в том числе с компетенцией. И даже если, скажем, программист занимается аналитикой — это не потому, что скрам ему ее на откуп отдал, а потому, что программист в данном спринте играет еще и роль аналитика, т.к. команда нашла его достаточно компетентным. Т.е. все равно аналитикой занимается аналитик.
Возвращаясь к статье: обсуждать методологию адекватно могут только те, кто, вне зависимости от специализации, достаточно опытен, чтобы вообще осознавать суть и назначение методологий. Обсуждать же пригодность методологии к тем или иным видам проектов, по-моему, вообще могут только люди, опытные в УП — менеджеры проектов да ведущие разработчики. А для таких людей статья, в принципе, ничего полезного не несет — возможно, хватило бы просто вопроса? Все равно в статье вопрос не задан более развернуто, чем в названии ))
довольно интересный вопрос, хоть и выводящий за пределы привычной сфре скрама — в каких непрограммистских/неайтишных проектах его можно применять. Я на такой вопрос не могу ответить с достаточной долей уверенности.
если брать айти — интересно рассмотреть проекты с «внутренним» заказчиком. например, в проектах разработки и внедрения внутрикорпоративного продукта. Как правило, такие проекты затрагивают не одно подразделение, соответственно, много руководителей так или иначе участвует в проекте или пытается на него влиять. Тут, по моему мнению и опыту, скрам позволяет максимально защитить и команду проекта, и сам проект от множества векторов влияния, продиктованных, к тому же, самыми разнообразными причинами. Но для этого (опять же по опыту), очень сплоченно должны действовать куратор и руководитель проекта (т.е. Product Owner и Scrum Master) — им вместе придется стандартные совещания начальства стараться сделать максимально продуктивными для ведения баклога проекта, и вместе же придется отстаивать такие вещи, как неприкосновенность плана текущего спринта. Кроме того, могут быть проблемы, если участники команды структурно находятся в разных подразделениях — соответственно, над ними, кроме руководителя проекта, есть еще линейные руководители, опять же имеющие свою точку зрения на проект, не всегда совпадающую с утвержденным баклогом (такая ситуация может быть в айтишных фирмах). Другие интересные варианты проектов с «внутренним» заказчиком — разработка принципиально нового продукта/разработка продукта, уже имеющего аналоги, в т.ч. новой версии существующего продукта. Отличаются, по моему, в первую очередь агрессивностью внешней среды — во втором случае добавляются такие факторы давления, как ожидания/претензии существующих пользователей, учет проекта в планах продаж, соответственно, различные публичные обещания руководства, маркетологов и т.п. Первый случай — это, фактически, стартап, т.е. проект, не встраивающийся в существующий рынок, а пытающийся этот рынок изменить/перевернуть/создать новый, и не имеющий описанной «наследственности» — существующих пользователей и т.п. Несмотря на то, что проекты а ля стартапы имеют тенденцию сильно меняться в ходе своего развития, все-таки постоянного сильного давления на них нет. К проектам первого типа скрам, по-моему, вообще очень хорошо подходит — позволяет двигаться даже без четкой дорожной карты. К проектам второго, в принципе, не хуже — опять же, внешняя среда очень изменчива.
проекты с внутренним заказчиком интересны прежде всего потому, что они заведомо рассчитаны на «продолжение» — после формального запуска проекта так или иначе его нужно продолжать разрабатывать, и, обычно, силами той же команды. То есть у них заведомо есть установка — сделать успешный продукт. В то время как в проектах «для дяди» основная цель — сделать продукт, которым будет доволен заказчик (успешно сдать продукт). А некоторая разница между этими целями есть)
Важный момент: под разработчиками Вы понимаете программистов/проектировщиков/архитекторов или всех членов команды? потому что говорить, что скрам отдает на откуп программистам какую-либо задачу, обычно не свойственную им, например, аналитику, — неверно в принципе: скрам позволяет команде самой задавать распределение задач, но происходит это в соответствии в том числе с компетенцией. И даже если, скажем, программист занимается аналитикой — это не потому, что скрам ему ее на откуп отдал, а потому, что программист в данном спринте играет еще и роль аналитика, т.к. команда нашла его достаточно компетентным. Т.е. все равно аналитикой занимается аналитик.
Возвращаясь к статье: обсуждать методологию адекватно могут только те, кто, вне зависимости от специализации, достаточно опытен, чтобы вообще осознавать суть и назначение методологий. Обсуждать же пригодность методологии к тем или иным видам проектов, по-моему, вообще могут только люди, опытные в УП — менеджеры проектов да ведущие разработчики. А для таких людей статья, в принципе, ничего полезного не несет — возможно, хватило бы просто вопроса? Все равно в статье вопрос не задан более развернуто, чем в названии ))
Трудно вычислить насколько я осознаю суть и назначение методологий. Это всё субъективно. Программные проекты я веду более 20 лет. Сказать что всё было успешно, и что я всё правильно осознаю? Не уверен. Не всё успешно. Но многое. Полагаю, что, что-то видимо я уже осознаю. :-)
Статья носит общеобразовательный характер. Повод для дискуссии. Осмысление вроде бы тривиальных вещей. Я не считаю что я во всём прав. Но какие-то знания определённо есть. В конце концов. я не навязываю свой опыт. Каждый вправе пользоваться любой, удобной ему информацией.
Статья носит общеобразовательный характер. Повод для дискуссии. Осмысление вроде бы тривиальных вещей. Я не считаю что я во всём прав. Но какие-то знания определённо есть. В конце концов. я не навязываю свой опыт. Каждый вправе пользоваться любой, удобной ему информацией.
>Т.е. все равно аналитикой занимается аналитик.
Время для дискуссий наверно уже вышло, и все же замечу, что при переходе на SCRUM или иной вид кроссфункциональной организации часто возникает проблема, куда девать выделенных аналитиков.
Товарищ делал интересный доклад на эту тему: «Аналитик в Agile: Архаизм или необходимость?», возможно заинтересует.
Время для дискуссий наверно уже вышло, и все же замечу, что при переходе на SCRUM или иной вид кроссфункциональной организации часто возникает проблема, куда девать выделенных аналитиков.
Товарищ делал интересный доклад на эту тему: «Аналитик в Agile: Архаизм или необходимость?», возможно заинтересует.
да хорошая статья для новичков. я вот только вхожу в курс дела. и обычно делаю это по принципу от общего к частному. поэтому статья мне дает некоторые представления вообще что за скрум xp и с чем их едят.
по моему, сложные вещи описать простым понятным языком много стоит. плюс, читая коммены, например, ваш, начинаешь глубже вникать в детали.
по моему, сложные вещи описать простым понятным языком много стоит. плюс, читая коммены, например, ваш, начинаешь глубже вникать в детали.
Ничего себе привет из прошлого) — это я про ответ на 4-летний коммент.
Если новичок, советую для начала почитать что-нибудь про принципы организации бизнес-процессов в целом, например, «Дао Toyota» — все программистские «новые методологии» — по сути, адаптация опыта других сфер в сочетании со здравым смыслом к отрасли разработки ПО, поскольку базовые законы везде одинаковы.
Если новичок, советую для начала почитать что-нибудь про принципы организации бизнес-процессов в целом, например, «Дао Toyota» — все программистские «новые методологии» — по сути, адаптация опыта других сфер в сочетании со здравым смыслом к отрасли разработки ПО, поскольку базовые законы везде одинаковы.
извиняюсь за многа букав)
подумал, пока писал предыдущий пост: имеет больше смысла отталкиваться от типа создаваемого продукта, как, например, это делает Джоэл — www.joelonsoftware.com/articles/FiveWorlds.html. Возможно, кто-то не согласится с классификацией. Но даже по ней видно, что проекты из первого и второго миров как раз подходят под Agile в целом — изменчивая внешняя среда, возможно, отсутствие полной дорожной карты проекта.
Вообще, гораздо проще понять, куда подходит/не подходит Agile, чем сформулировать критерии выбора внутри Agile, не опускаясь в личные предпочтения. Хотя, если XP брать как жестко заданный набор практик, можно понять, где его нельзя использовать) Скрам же все-таки проще, менее детализирован — в этом его «прелесть»
подумал, пока писал предыдущий пост: имеет больше смысла отталкиваться от типа создаваемого продукта, как, например, это делает Джоэл — www.joelonsoftware.com/articles/FiveWorlds.html. Возможно, кто-то не согласится с классификацией. Но даже по ней видно, что проекты из первого и второго миров как раз подходят под Agile в целом — изменчивая внешняя среда, возможно, отсутствие полной дорожной карты проекта.
Вообще, гораздо проще понять, куда подходит/не подходит Agile, чем сформулировать критерии выбора внутри Agile, не опускаясь в личные предпочтения. Хотя, если XP брать как жестко заданный набор практик, можно понять, где его нельзя использовать) Скрам же все-таки проще, менее детализирован — в этом его «прелесть»
вербальная диарея… тот случай, когда копипаст предпочтительнее авторской статьи
www.osp.ru/os/2007/04/4220063/
www.citforum.ru/SE/project/scrum/
classicpm.wordpress.com/2006/09/14/scrum-part-1/
www.osp.ru/os/2007/04/4220063/
www.citforum.ru/SE/project/scrum/
classicpm.wordpress.com/2006/09/14/scrum-part-1/
В принципе моей целью не было скопипастить чужие статьи. Цель несколько иная. Пояснив кратко принципы XP и Скрама, попытаться, к третьей части вынести дискуссию в критическую плоскость. Мне показалось нелогичным давать ссылку на чужую статью и затем критиковать. Я решил, что будет уместнее вначале изложить основы своими словами.
Два топика — это не кратко.
Я в общем три планировал. Похоже, что я измеряю информацию не количеством топиков. Но с другой стороны, вроде как и читать насильно я никого не заставляю. Тем более я никого не заставляю оскорблять других. Дело в том, что на написание заметки я трачу исключительно и только своё собственное время. :-)
Не понимаю чего вы прицепились. Лично мне, немного знакомому с методологией, подобное не-академическое изложение понравилось — а это важно потому что читать сухие тексты по управлению проектами не каждый разработчик осилит :)
Да я вообще-то тоже малознаком с методологией. Именно поэтому я и обрадовался заголовку — хотел узнать больше. А что прочитал? Ноль по сути. И много красивых оборотов.
Я видимо закончу сегодня чуть детальнее про непосредственно Скрам. Мне не хотелось описывать технологические моменты до пояснения принципов. Будет просто неясно, зачем придуманы те или иные ухищрения.
Может стоит задуматься над «красивыми оборотами»: где их можно применить, как их можно применить для своего проекта; а не ожидать что все разжуют и покажут как надо делать? ;)
Имхо, информация именно в таком неформальном виде наимолее «усваяемая».
Имхо, информация именно в таком неформальном виде наимолее «усваяемая».
Кстати не встречал еще здесь упоминания про ПО для автоматизации процесса Scrum-разработки. Я лично знаком со ScrumWorks. Есть фришная версия. Подробности здесь: danube.com/scrumworks/basic
Так читайте комментарии. Весьма интересная дискуссия… ТС, думаю, не будет против мысли, что обсуждение дает бОльшую пользу, нежели статья? :)
UFO just landed and posted this here
Панацея ли Scrum?
Панацеи нет
Панацеи нет
То, что Вы описали очень напоминает принцип «Quick and Dirty».
Работаю в проекте управляемом SCRUM уже 10 месяцев и статьи по нему читал, но пока конкретно о нём не писалось — подожду до следующей статьи с коментариями.
А у бывалых SCRUM-щиков и SCRUM-мастеров хотел спросить следующее.
Совместим ли SCRUM со свободным графиком работы? Возьмем книжную длительность спринта в 30 дней( 27 полных дня +3 дня на риски). Реально ли огранизовать работу в офисе для небольшой команды со свободным графиком и какие принципы могут помочь, для эффективной работы? Как производить планирование в этом случае? Или для такой динамичной технологии управления свободный график губителен?
Работаю в проекте управляемом SCRUM уже 10 месяцев и статьи по нему читал, но пока конкретно о нём не писалось — подожду до следующей статьи с коментариями.
А у бывалых SCRUM-щиков и SCRUM-мастеров хотел спросить следующее.
Совместим ли SCRUM со свободным графиком работы? Возьмем книжную длительность спринта в 30 дней( 27 полных дня +3 дня на риски). Реально ли огранизовать работу в офисе для небольшой команды со свободным графиком и какие принципы могут помочь, для эффективной работы? Как производить планирование в этом случае? Или для такой динамичной технологии управления свободный график губителен?
Скрам + нагруженный проект = коллапс
А, так вот почему Хабр периодически nginx 500 выдаёт! Всё дело в волшебном Скраме!
Смех смехом, товарищи, но любым кодом кроме 200 и 301 ресурс очень сильно обязан этому самому скраму. К сожалению, у меня на хватает времени и идей, как этому лучше противостоять.
Если говорить о «внутреннем заказчике» то если взять зачаточный проект с сомнительным будущим, где квалификация и техническое руководство не играют роли, когда надо в длинный срок что-то хоть как-то сделать, а работать ой как не хочется, то скрам здесь очень кстати.
Скраму не место там где работают опытные, ответственные люди, вот моё мнение. Не место ему и там где случаются стрессовые ситуации. А рефакторинг в смысле скрама это такая несбыточная сказка или же попросту двойной труд.
Если говорить о «внутреннем заказчике» то если взять зачаточный проект с сомнительным будущим, где квалификация и техническое руководство не играют роли, когда надо в длинный срок что-то хоть как-то сделать, а работать ой как не хочется, то скрам здесь очень кстати.
Скраму не место там где работают опытные, ответственные люди, вот моё мнение. Не место ему и там где случаются стрессовые ситуации. А рефакторинг в смысле скрама это такая несбыточная сказка или же попросту двойной труд.
Тут, парни, появилась вторая часть:
habrahabr.ru/blogs/pm/39534/
Налетаем, критикуем, пинаем ногами. Скрам, значит скрам.
Но вежливо. Что бы, бля, не поранить мою тонкую душевную организацию!
habrahabr.ru/blogs/pm/39534/
Налетаем, критикуем, пинаем ногами. Скрам, значит скрам.
Но вежливо. Что бы, бля, не поранить мою тонкую душевную организацию!
А если не получается так часто встречаться с заказчиком? отправить письмом? а кто сказал что он там в течении дня ответить? названивать и просить посмотреть проект? потом скзать свой отзыв? опять же не всегда так может получиться.
и вот прос заклушки, заменяемые потом реальным кодом не очень понтяно.
и вот прос заклушки, заменяемые потом реальным кодом не очень понтяно.
А не страдает ли при таком подходе качество кода и не получается ли продукт, попросту говоря, тормозным (и глючным)?
Поправьте пожалуйста теги. У Вас три тега слились в один.
В общем-то, комментарии интересней, чем сама статья.
Вот и ответ на все вопросы о полезности поста.
Вот и ответ на все вопросы о полезности поста.
Sign up to leave a comment.
Панацея ли Scrum? Давайте рассуждать вместе, где он нам полезен