Трудно вычислить насколько я осознаю суть и назначение методологий. Это всё субъективно. Программные проекты я веду более 20 лет. Сказать что всё было успешно, и что я всё правильно осознаю? Не уверен. Не всё успешно. Но многое. Полагаю, что, что-то видимо я уже осознаю. :-)
Статья носит общеобразовательный характер. Повод для дискуссии. Осмысление вроде бы тривиальных вещей. Я не считаю что я во всём прав. Но какие-то знания определённо есть. В конце концов. я не навязываю свой опыт. Каждый вправе пользоваться любой, удобной ему информацией.
Я видимо закончу сегодня чуть детальнее про непосредственно Скрам. Мне не хотелось описывать технологические моменты до пояснения принципов. Будет просто неясно, зачем придуманы те или иные ухищрения.
Цель — перевести обсуждение Скрам в критическую плоскость. Не потому, что он плох, а ради понимания того, что и где он навязывает, когда даёт свободу и какие важные вещи действительно остаются на откуп разработчикам или просто остаются за кадром. Что бы применять его грамотно и точно, не сводя возможную неудачу проекта к недостаткам методологии.
Концепция тестов в XP чуть шире. Что бы просто найти баги, достаточно один раз всё аккуратно проверить и поправить. В XP же предполагается, что вы и код будете итеративно менять (проводить рефакторинг), что бы он был вылизан и удобен для последующего сопровождения.
Меняя код, всегда есть риск внести ошибку. Посему, помимо поиска ошибок, программыне тесты (юнит-тесты) нужны для быстрой механической проверки уже работающих кусков кода после рефакторинга.
Я в общем три планировал. Похоже, что я измеряю информацию не количеством топиков. Но с другой стороны, вроде как и читать насильно я никого не заставляю. Тем более я никого не заставляю оскорблять других. Дело в том, что на написание заметки я трачу исключительно и только своё собственное время. :-)
В принципе моей целью не было скопипастить чужие статьи. Цель несколько иная. Пояснив кратко принципы XP и Скрама, попытаться, к третьей части вынести дискуссию в критическую плоскость. Мне показалось нелогичным давать ссылку на чужую статью и затем критиковать. Я решил, что будет уместнее вначале изложить основы своими словами.
Автор имеет некоторый опыт управления проектами. :-)
Также, автор не имеет ничего против водопада. Также как и Рупа и прочих. Автор также полагает, что XP подходы были достаточно революционны в свое время и заметно отличались от других. С проблемами управления автор сталкивался часто. Читателей он уважает. Иначе не стал бы писать.
Тормозят они как-то. Мелкими шажками двигаются. Очевидно же, что открывашка для пива уже давно должна быть конструктивной частью корпуса компа. Как USB разъём и выход на наушники. Что бы всякий пользователь, в любом состоянии, твёрдо знал, что подойдя к любому корпусу он легко и быстро обнаружит соответствующий выступ или отверстие, используя которые он мгновенно сможет произвести необходимую операцию, не нанеся при этом никаких повреждений корпусу и спрятанным в нём устройствам.
Ото эти надуманные консервативные шаги с флешками… А вдруг она потеряется и что тогда?
Грустно конечно, но вряд ли имеет смысл говорить о пользе калибровки монитора на TN матрице.
Когда речь идёт о калибровке цвета, предполагается что это всё таки S-IPS матрица. PVA хоть и лучше чем TN, но о полноценной работе с цветом там также речь не идёт. А у TN просто диапазона не хватит на вменяемую калибровку. Посему если предполагается работа с цветом, то пусть и не супер-пупер дорогой Эйза и иже с ними, но таки S-IPS монитор. Их не так и много. Как правило это NEC в районе штуки. Возможно вам имеет смысл сакцентироваться на корректировке профилей. Если вы работаете скажем с фотошопом. То есть это некая программная подстройка цвета с учётом типа принтера (и бумаги принтера).
Очень толковых советов не дам. Ибо я любитель, но фотографией балуюсь. Сам выбрал Apple Cinema Display. Печатаю для себя и друзей на Epson Stylus R220.
Не хотелось бы показаться занудливым, но чуть резанула глаз вот эта фраза:… в моду вошла трехуровневая парадигма программирования: сервер баз данных, сервер приложения и тонкий клиент…
Наверное всё таки не парадигма программирования, а трёх-уровневая архитектура клиент-сервер.
Согласен с Вами. На мой взгляд также поощрять нужно не самые рейтинговые топики, а те, которые хороши, являются собственными и при этом, мягко сдвигают ресурс в нужном информационном направлении. Если я правильно понимаю, всё таки техническом. А не новостно-прикольном.
Scrum, это Agile методология управления проектами, в основу которой положены принципы и подходы XP. Включая основной. Если это не оттенить, то говорить о Scrum сложно. Что бы не сказать — бесполезно.
Когда речь заходит о некоем наборе принципов, которые лягут в основу методологий, то вначале важно уловить именно ключевую суть, а не перчислить все сопутствующие признаки. Ключевая суть XP именно в том, что бы завязать проект в спираль, на каждом витке которой вы имеете работающую систему. И, тем самым, имеете что-то, отчего сразу можете отталкиваться в вашей коммуникации с заказчиком.
XP кстати, имеет и ещё одну жёстокую особенность, которая часто остаётся в тени. А именно — что бы построить проект таким образом, вам нужно крайне хорошо владеть принципами проектирования. Ибо никаким рефакторингом вы не заполируете тот факт, что, к примеру, на ранних этапах проектирования вы допустили серъёзные изъяны в декомпозиции системы.
Когда речь заходит о некоем наборе принципов, которые лягут в основу методологий, то вначале важно уловить именно ключевую суть, а не перчислить все сопутствующие признаки. Ключевая суть XP именно в том, что бы завязать проект в спираль, на каждом витке которой вы имеете работающую систему. И, тем самым, имеете что-то, отчего сразу можете отталкиваться в вашей коммуникации с заказчиком.
XP кстати, имеет и ещё одну жёстокую особенность, которая часто остаётся в тени. А именно — что бы построить проект таким образом, вам нужно крайне хорошо владеть принципами проектирования. Ибо никаким рефакторингом вы не заполируете тот факт, что, к примеру, на ранних этапах проектирования вы допустили серъёзные изъяны в декомпозиции системы.
Нагативного оттенка нет. Я считаю, что именно на XP подходы в наше время и должны опираться методологии управления проектами. Обязательно ли это должна быть методология Scrum, это уже другой вопрос.
Насчёт документации. Вы абсолютно правы. Я также нигде не встречал, что некая методология вслух постулирует позицию вида — не пишите документацию. Конечно же нет. Но, если методология явно не настаивает на том, какие документы и где должны порождаться в процессе ведения проекта, то тем самым она оставляет это на откуп разработчика или руководителя проекта. И у них соблазн велик. Многие искренне полагают, что Скрам им развязал руки и терь можно только говорить и ничего не писать. Типа мы и раньше так делали, а тут и научная база подоспела. Это действительно заблуждение.
К примеру, если взять RUP, то там внятно перечислено достаточно много так называемых артефактов, которые должны (желательны) порождаться на каждой стадии проекта. Артефакт, это, грубо говоря, некий, как правило бумажный, выхлоп после прохождения стадии создания проекта. Называется он таким словом потому, что быть он может разным. Это и текст, и UML-диаграмма, и просто сведёные в таблицу кейсы, и… RUP использует UML и тщательно прописывает какого рода UML диаграммы вам желательно сделать в том или ином случае.
По поводу качества кода. Тут опять же — ни одна здравомыслящая методология не предлагает писать грязный код или код не в соответствии с принятыми в компании стандартами. Ни в коем разе.
Но, XP прямо и честно говорит — и в коде не старайтесь всё учесть сразу. Не тратьте на первых этапах свое время на то, что бы придумать максимально точное название. Не тратьте время на то, что бы сразу и окончательно решить будет эта переменная локальной или членом класса. Не тратьте сразу время на то, что бы окончательно решить что будет отдельным методом класса и какая у него область видимости. Не потому, что это не важно, а потому, что вы пока этого окончательно не знаете. Признайте факт того, что с высокой вероятностью это может измениться и сейчас сделайте так как вам удобнее. Затем, когда некая часть кода устоится (или просто появится больше определённости), вы обязательно зарефакте эту часть, что бы окончательный код был действительно хорош и удобен. Вот где-то так примерно.
Хотя меня слегка удивило, что хабравцы стали вслух принижать значение денежной мотивации. Прям гордость за них взяла. Нам хлеба не надо — работу давай! Думаю, что и тут работает таже поправка. :-)
Возможно. Но, я очень давно в IT. Исходя из моего опыта управления людьми, ситуация несколкьо сложнее. Да, только 15% людей объективно оценивают свои возможности. Или даже целых 10% :-)
Но ещё 50% полагают, что они свои возможности также оценивают объективно. Просто обстоятельства мешают им самореализоваться. И они в это верят также искренне как и первые 15%. И с этим всегда нужно считаться. Ибо люди эти часто вполне толковые. Пусть даже они и переоценивают свои возможности.
Ну если этот страх так страшен, а сам факт его присутствия воспринимается как чисто фашизм и выше чем желание обеспечить своей семье лучший уровень жизни, то добро пожаловать в безработные, сесть на пособие и впредь ничего в жизни не боятся.
Статья носит общеобразовательный характер. Повод для дискуссии. Осмысление вроде бы тривиальных вещей. Я не считаю что я во всём прав. Но какие-то знания определённо есть. В конце концов. я не навязываю свой опыт. Каждый вправе пользоваться любой, удобной ему информацией.
habrahabr.ru/blogs/pm/39534/
Налетаем, критикуем, пинаем ногами. Скрам, значит скрам.
Но вежливо. Что бы, бля, не поранить мою тонкую душевную организацию!
Меняя код, всегда есть риск внести ошибку. Посему, помимо поиска ошибок, программыне тесты (юнит-тесты) нужны для быстрой механической проверки уже работающих кусков кода после рефакторинга.
Также, автор не имеет ничего против водопада. Также как и Рупа и прочих. Автор также полагает, что XP подходы были достаточно революционны в свое время и заметно отличались от других. С проблемами управления автор сталкивался часто. Читателей он уважает. Иначе не стал бы писать.
Ото эти надуманные консервативные шаги с флешками… А вдруг она потеряется и что тогда?
Когда речь идёт о калибровке цвета, предполагается что это всё таки S-IPS матрица. PVA хоть и лучше чем TN, но о полноценной работе с цветом там также речь не идёт. А у TN просто диапазона не хватит на вменяемую калибровку. Посему если предполагается работа с цветом, то пусть и не супер-пупер дорогой Эйза и иже с ними, но таки S-IPS монитор. Их не так и много. Как правило это NEC в районе штуки. Возможно вам имеет смысл сакцентироваться на корректировке профилей. Если вы работаете скажем с фотошопом. То есть это некая программная подстройка цвета с учётом типа принтера (и бумаги принтера).
Очень толковых советов не дам. Ибо я любитель, но фотографией балуюсь. Сам выбрал Apple Cinema Display. Печатаю для себя и друзей на Epson Stylus R220.
Наверное всё таки не парадигма программирования, а трёх-уровневая архитектура клиент-сервер.
Когда речь заходит о некоем наборе принципов, которые лягут в основу методологий, то вначале важно уловить именно ключевую суть, а не перчислить все сопутствующие признаки. Ключевая суть XP именно в том, что бы завязать проект в спираль, на каждом витке которой вы имеете работающую систему. И, тем самым, имеете что-то, отчего сразу можете отталкиваться в вашей коммуникации с заказчиком.
XP кстати, имеет и ещё одну жёстокую особенность, которая часто остаётся в тени. А именно — что бы построить проект таким образом, вам нужно крайне хорошо владеть принципами проектирования. Ибо никаким рефакторингом вы не заполируете тот факт, что, к примеру, на ранних этапах проектирования вы допустили серъёзные изъяны в декомпозиции системы.
XP кстати, имеет и ещё одну жёстокую особенность, которая часто остаётся в тени. А именно — что бы построить проект таким образом, вам нужно крайне хорошо владеть принципами проектирования. Ибо никаким рефакторингом вы не заполируете тот факт, что, к примеру, на ранних этапах проектирования вы допустили серъёзные изъяны в декомпозиции системы.
Насчёт документации. Вы абсолютно правы. Я также нигде не встречал, что некая методология вслух постулирует позицию вида — не пишите документацию. Конечно же нет. Но, если методология явно не настаивает на том, какие документы и где должны порождаться в процессе ведения проекта, то тем самым она оставляет это на откуп разработчика или руководителя проекта. И у них соблазн велик. Многие искренне полагают, что Скрам им развязал руки и терь можно только говорить и ничего не писать. Типа мы и раньше так делали, а тут и научная база подоспела. Это действительно заблуждение.
К примеру, если взять RUP, то там внятно перечислено достаточно много так называемых артефактов, которые должны (желательны) порождаться на каждой стадии проекта. Артефакт, это, грубо говоря, некий, как правило бумажный, выхлоп после прохождения стадии создания проекта. Называется он таким словом потому, что быть он может разным. Это и текст, и UML-диаграмма, и просто сведёные в таблицу кейсы, и… RUP использует UML и тщательно прописывает какого рода UML диаграммы вам желательно сделать в том или ином случае.
По поводу качества кода. Тут опять же — ни одна здравомыслящая методология не предлагает писать грязный код или код не в соответствии с принятыми в компании стандартами. Ни в коем разе.
Но, XP прямо и честно говорит — и в коде не старайтесь всё учесть сразу. Не тратьте на первых этапах свое время на то, что бы придумать максимально точное название. Не тратьте время на то, что бы сразу и окончательно решить будет эта переменная локальной или членом класса. Не тратьте сразу время на то, что бы окончательно решить что будет отдельным методом класса и какая у него область видимости. Не потому, что это не важно, а потому, что вы пока этого окончательно не знаете. Признайте факт того, что с высокой вероятностью это может измениться и сейчас сделайте так как вам удобнее. Затем, когда некая часть кода устоится (или просто появится больше определённости), вы обязательно зарефакте эту часть, что бы окончательный код был действительно хорош и удобен. Вот где-то так примерно.
Хотя меня слегка удивило, что хабравцы стали вслух принижать значение денежной мотивации. Прям гордость за них взяла. Нам хлеба не надо — работу давай! Думаю, что и тут работает таже поправка. :-)
Но ещё 50% полагают, что они свои возможности также оценивают объективно. Просто обстоятельства мешают им самореализоваться. И они в это верят также искренне как и первые 15%. И с этим всегда нужно считаться. Ибо люди эти часто вполне толковые. Пусть даже они и переоценивают свои возможности.