Pull to refresh

Comments 48

Результатом этого мазафака-программинга, без того, что перечисленно вначале, будет огромное количество никому не нужного кода. То есть полный фейл. К сожалению.
Результатом всяких «методик разработки» есть красивые графики которые можно показать начальству. И многократное замедление процесса разработки. Как будто тикеты когда-то увеличивали полезность кода. Или, как будто, скрам мастер вдруг сделает что код не бесполезен. Три раза «ха».
Тикеты — это формальные указатели на задачи, которые требуется решить. Что вы собрались писать, не имея представления о задачах и приоритетах? Тикеты — это инструмент структурированного (эффективного) общения в команде. Как вы собираетесь синхронизировать свою работу с остальными, не имея удобных сущностей для привязки? Тикеты — это удобный инструмент внутрикомандного планирования, причем тут вообще начальство? По большому счету, абсолютно пофигу как вы называете свою методологию, но совсем без нее вы получите только несъедобную кашу: в головах, в коде, в общем результате. Проходили такое. Ха.
Ваши утверждения о «эффективности» голословны. Более того, я считаю что они еще беспочвенны и неправильны.
Ну конечно. У меня ведь нет совершенно никакого собственного опыта управления и участия в разработке, вам ведь лучше знать. Ок. =)
Позвольте не согласиться. Методологии устанавливают правила игры, которых должна придерживаться команда проекта чтобы не «влазить в чужие тапки», по возможности избегать конфликтов и понимать «где мы сейчас находимся и что нам осталось». И по-сути тут всего два больших подхода:
  • «пытаемся представить систему целиком в деталях» = waterfall, RUP/OpenUP etc
  • «понимаем что всё систему представить пока не можем, начинаем с чего попроще» = всё гибкое и «быстрое» (хотя «быстрость» не гарантирует что полноценный продукт появится раньше, чем его бы делали по водопаду)

Весь современный уход в «гибкость» вызван высокой конкурентностью рынка ИТ-продуктов. Пока одни думают «как сделать сразу всё правильно» — другие уже выпустили «хоть что-то» и забили место в своём сегменте.
При этом «гибкость» часто приносит в жертву правильное планирование архитектуры. А 2-3 этапа рефакторинга между версией 1 (вышли в паблик) и 2 (вот теперь у нас все фичи и монетизация) таки растягивают и сроки и бюджеты. Что и вызывает необходимость в экспертах по «экстремальному программированию»
Да, я согласен. Методологии это компенсация если в команде поломано общение. Я и не спорю. Но не надо рассказывать про «эффективность» и прочую ахинею. Любая формализация идет в убыток производительности. Если у вас не хорошо слаженна работа в команде, то безусловно, можно выбрать процесс и следовать ему.
P.S.
Я, кстате, так и не понял с чем Вы не согласны.
Мне не понравилось утверждение, что «Результатом всяких «методик разработки» есть красивые графики которые можно показать начальству»

«Методики разработки» нужно грамотно подбирать под конкретную команду и особенности проекта. И тогда эффективность — речь об эффективности работы команды — будет расти.
Т.е. эффективность является скорее метрикой работы команды. А знание методик и умение грамотно их применять в конкретных случаях — её повышает
Ну, а что еще? Любая бюрократия идет в убыток максимальной возможной производительности.
Знание методик и умение их применять может только уменьшить убыток от бюрократии которую они тащат. Если ваша команда не может без бюрократии — пожалуйста. Суйте свои оверхеды методик.
Речь не о бюрократии, а об организации процесса постановки задач. Можно полчаса обсуждать задачу с начальником/заказчиком в то время, когда удобно им, а можно за 2 минуты прочитать общую постановку задачи в таск-трекере, потратить 2 минуты на написание коммента с уточняющими вопросами, и через час потратить еще 2 минуты на чтение ответа. В остальное время можно заниматься другой работой или пинать балду своими делами (в зависимости от ситуации).
Мне кажется, вы просто переносите свой негативный опыт в конкретной ситуации на все методологии организации процесса разработки.
И я не спорю что я выражаю отвращение и собственный негативный опыт внедрений эджайла консультантами которыми было интересно получить деньги а не достичь результата. И я далеко не один такой.
Ни одного позитивного опыта внедрения процесса я не видел. Было плохо или стало еще хуже, или было хорошо и осталось хорошо, но с красивыми графиками для начальства.

О тикетах у меня очень другое мнение. Я считаю что лучше поговорить пол часа с заказчиком, понять что нужно сделать, и сделать это, чем писать комменты, и пинать балду остальное время, а потом переделывать фичу в следующем спринте потому что не так что-то поняли в переписке.
У тикетоной модели есть бонусы — это формальная методология, у которой работники это шестеренки в системе. Их можно легко заменять. Уволился человек, ничего страшного, раскидали его тикеты, и дальше идет машина.
Хмм, а потом вы заболеете, умрете, уйдете в другой проект… то что вы «наговорили» с заказчиком уйдет вместе с вами… А оставшиеся, через полтора месяца, будут ломать голову, как должен был работать вот именно тот кусок кода, который вы тогда написали, и работает ли он правильно сейчас… В конечном итоге — переписанный за вами функционал, который возможно и правильно работал и его потом еще раз перепишут, протестируют, интегрируют… потратят 100500 часов, вместо одного-двух часов «бюрократии»… В конечном итоге методология — инструмент не только разработки, но и общения и сохранения знаний о проекте. При нормальных или близких к нормальным условиях.
А при чем здесь «эффективность»?
Эффективность — отношение затрат к полученному результату. В случае с разработкой ПО — получение максимально ожидаемого и предсказуемого результат с наименьшими затратами — высокая эффективность. В случае, который я привел, как пример, «без бюрократии» затраты во много раз превысят затраты «с бюрократией», соответственно эффективность процесса будет ниже в разы. Но про эффективность как таковую я не писал, я просто привел пример, почему методологии/методики/принципы и т.п. стоит применять и подчиняться правилам. Когда все идет как должно идти пользу методологии вы не увидите, она будет казаться вам чем то лишним и ненужным, а вот когда случится какая-нибудь *опа… Снизить риски и потери как компании так и сотрудников (в том числе и имиджевые) может только грамотно настроенная и соблюдаемая методология производства… А *опа случится обязательно рано или поздно… «Просто писать код» — это круто, но не надо тогда удивляться, когда однажды вместо зп получите кукиш, просто потому что сочетание различных обстоятельств привело к тому, что контора не получила доход, а вы (или ваше начальство и коллеги) никак не поучаствовали в том, чтобы хотя бы часть из этих обстоятельств отработать хотя бы методологией…
Вы конкретно путаете бюрократию (причем именно негативную ее часть) и организацию дела.

Вы считаете, что ничего не нужно для того, чтобы производить продукт. Но кто-то должен платить налоги, получать переводы, чтобы вы могли получить за продукт зп. Если вы не получите ЗП, вы не будете разрабатывать, следовательно производительность упадет.

То, что вам не понравилось, как в какой-то отдельно взятой конторе менеджер бегает за красивыми словами, а не за организацией труда, никак не умаляет плюсы и agile и waterwall, грамотно реализованными.
Я считаю что нужно писать код. Все остальное не стоящая внимания фигня придуманная бездельниками.
В больших компаниях такое не работает, но и большие компании я считаю болотом на 80% заселенными бездельниками.
Те кто не бездельники обязаны тратить время на бюрократия. Кстате, бюрократия это по определению следование процессу.
И это пипец какое распространенное и дорогое заблуждение. Не нужно писать код. Нужно решать проблемы. Если ты написал 100к строк охренительного кода, но этот код никаких проблем не решает, ты выкинул N времени своей жизни в трубу, потому что лучше-то от твоего кода никому не стало, только энтропия увеличилась. И не полезет никто никогда в твой код, потому что он никому не нужен. Собственно, всем вообще наплевать, есть твой код или нет. У всех проблем по горло, а тут какой-то код, который вообще хрен знает, для кого.

И вот ровно затем, чтобы все четко понимали, чью проблему, какую проблему, как и в какие сроки они пытаются решить, нужна организация производственного процесса, то есть — бюрократия. Работающая. Эффективная. Решающая проблемы. Делающая мир лучше. Бюрократия. Добро пожаловать.
Смешались в кучу кони, люди модели и методологии.

Waterfall, V, Инкременты, эволюция прототипов, спираль — модели. Модели нужны чтобы предсказывать будущее поведение систем.
Scrum, Kanban, RUP, CMM, MSF, XP и даже TDD — методологии, то есть набор артефактов и ритуалов. Методологии нужны чтобы система работала (и вообще существовала как система), а еще нужны чтобы продавать софт, консалтинг, книги и прочий инфобизнес.
Agile это не модель и не методология, это набор принципов на основе которых можно построить множество моделей и методологий.
+1.
Например Scrum и SAFe — совершенно разные методологии, которые поддерживают принципы Agile и реализуют итеративную модель жизненного цикла.
Справедливости ради, нужно отметить, что в данной статье клёвые картинки :)
Согласен, но мне кажется это единственная ценность статьи.
Примерно так, кроме CMM и CMMI. Это не практики, а общие методологии, в которых вообще нет указания на то, как что-то делать. Там уровни, на каждом из которых рассказывается, какая составляющая управления должна быть. А как её реализовывать — это уже даётся на откуп группе, ответственной за процессы. Т.е., прочие методологии могут быть решением к достижению целей из CMM.
По вашему получается, что тщательное тестирование происходит только в V-Model, а спиральная модель — то же самое что итеративная, только зачем то выделено 4 этапа.
На мой взгляд главная особенность V-Model — связь этапов анализа и проектирования с этапом тестирования. Пример: пока аналитик уточняет требования, тестировщики продумывают высокоуровненвые методы и подходы к тестированию, пока архитектор проектирует систему, тестировщики продумывают тест-планы, пока архитекторы проектируют компоненты системы, тестировщики создают тест-кейсы, инструменты, инструкции и т.п. Т.е. к тому времени пока мы подойдём к реализации уже есть куча документации, не только по требованиям и архитектуре, но и по тщательно продуманному тестированию.
Важная особенность спиральной модели — на этапе анализа риска мы создаём концепты, прототипы и модели чтобы попробовать оценить и разрешить риск до того, как приступим к реализации
Мне кажется (после чтения многочисленных источников в интернете) что V-Model вообще не модель разработки ПО, а просто демонстрация связи этапов разработки с этапами тестирования. То есть, она должна выполнятся при любой модели разработки если мы хотим организованный процесс тестирования. Есть в нашей модели этап утверждения требований, значит по его завершению должны быть готовы приемо-сдаточные тесты. Если по нашей модели мы возвращаемся в какой то момент и пересматриваем/дополняем требования, значит и соответствующие тесты пересматриваются/дополняются.
Скажите пожалуйста, что такое «большой проект», сколько это человеколет разработки? У вас это написано как критерий, а определения нету.
Просто удивительно, как мнеджеры любят изобретать велосипеды, читать модные книжки по управлению проектами, ходить на треннинги, получать сертификаты, обязательно певать в сторону водопадной модели, но при этом умудряются так и не прочитать десять страничек о ройсовских водопадах.
Причина плевков в сторону не-ройсовских водопадов это то, что именная такая модель часто приводит к провалу крупных проектов. Ройсовские водопады, с их возможностью возврата на предыдущий этап, на мой взгляд, всё равно хуже итеративной модели. Не стоит забывать, что в то время, когда Ройс написал свою статью, процесс разработки был совершенно иным. Отлаживали в уме и на листочке, писали на перфокартах, относили их в компьютерный центр, ждали неделю когда протестируют, а потом исправляли ошибки. Понятно что в то время итеративный подход был неприменим, не говоря уж о TDD, непрерывной интеграции и т.п.
Как-то не очевидны отличия между этими моделями.
Вот давайте на примере, по простому:
Если мы имеем
1. Есть новый кусок требований у заказчика:
2. Аналитики проанализировали, написали какое-то ТЗ на разработку
3. Разработчики разработали
4. Тестировщики оттестировали
5. Выкатили в прод, заказчик посмотрел и появились новые требования
— и дальше Go To 1

Это вот какая модель разработки??? Водопад или итерационная? Или спиральная. Я как-то теряюсь.

И как она будет выглядить во всех 7 разных вариантах.

p.s. Реально хочется разобраться, без наезда!
субъективно:)
  1. каскадная: требования не меняются в процессе разработки
  2. V-Model: задачи разбиваются на подзадачи, для каждой задачи создается задача проверки
  3. инкрементная: имплементят фичи одну за другой, пока их становится слишком много
  4. RAD: рисование UML и прочих диаграмм, генерация кода по ним, SQL в визуальном редакторе, рисование формочек в конструкторе и т.д.
  5. agile: ежедневные митинги, где можно похвастаться достижениями и пожаловаться на проблемы
  6. итеративная: быстро делают протототип, потом долго отлавливают баги, отвлекаясь на изменяющиеся требования заказчика
  7. спиральная: в колесо цикла разработки вставляется палка в виде анализа рисков

модели разработки

инкрементальная и итеративная стратегии
Алистеру Кокбернц (Alistair Cockburn):
  • Инкрементальная разработка — это поэтапная и следующая временным графикам стратегия, в которой разные части системы разрабатываются в разное время и разными темпами, и если одна часть готова, тогда ее интегрируют в систему. Альтернативной стратегией было бы решение кодировать все части системы, а затем интегрировать весь код сразу.
  • Итеративная разработка — это так называемая стратегия изменений, где предусматриваются переделка и исправление существующих компонентов системы. Альтернативная стратегия заключалась бы в планировании деятельности таким образом, чтобы всё делалось бы с первой попытки.

отсюда
каскадная модель
V-Model
итеративная модель
спиральная модель
методология RAD
agile-методы
3. Внутри каждой фичи они разрабатываются водопадно?? или как?
4. Вообще не понял. А в любой другой модели нельзя рисовать uml и генерить код визуально, так чтоли?
5. Хм… вом мы как бы инкрементально по фичам работаем и каждый день митинги проводим — это аджайл или нет?
3. в оптимистическом варианте
4. можно(например, в рамках спиральной модели), это же методология(способ)
посмотрите на картинку
image
в цикле нет явного планирования, тестирования
субъективно:
  • заказчик смотрит на программу и говорит:
  • «у пользователя может быть два телефона»
  • «а что если кнопочка будет желтая»
  • добавляете поле, соответсвующее поведение
  • меняете цвет
  • показываете заказчику
а модель — это скорее точка зрения, ви́дение процесса разработки
Так, в рамках спирального подхода:
виток спирали соответствует созданию фрагмента или версии программного обеспечения
на каждом витке спирали могут применяться разные модели процесса разработки ПО
5. если вы следуете принципам agile-манифеста, то это agile, независимо, от того, что вы помимо этого делаете или используете

пока вы работаете по agile, ваш менеджер работает по спиральной модели :)
хотя у вас, скорее всего итеративная модель(явно выделен Цикл Деминга)
Что заставляет аглийские слова Validation и Verification писать русскими буквами?
То же самое, что заставляет писать Incrementation и Iteration русскими буквами. То ли профессиональная деформация, то ли компьютерный сленг.
Валидация и верификация — это корректные русскоязычные термины, которые в таком виде присутствуют в том числе в госстандартах. Не очень красиво, конечно, но это факт.
А в опросе не хватает пункта «мы врём заказчику, начальству, друг другу и сами себе, что используем Agile, а на самом деле у нас хаос».
Какие методологии используете вы?

Такую:
Где вы были, когда мы ломали голову над заглавной картинкой-)
В чем принципиальное различие между перечисленными в статье итерационными моделями?

Глядя на процессы с точки зрения заказчика, если я заказываю «Мону Лизу» — мне все равно, будет она писаться итерациями с прорисовкой деталей поверх общего эскиза, или же итерациями с прорисовкой отдельных областей.

Главное, чтобы это была «Мона Лиза», в срок и в рамках бюджета.
Как раз таки я очень понимаю разницу с т.з заказчика. В итеративной модели быстро можно увидеть всю картину (недоделанную, нетестированную, с багами, но всю!) Это очень, скажем так — воодушевляет заказчика (на самом деле). А когда частями — некоторые части не увидеть совем до последнего дедалйна — и если эта часть внезапно совсем не то что надо — может быть поздно!
Это вы так говорите не подумав. Это частный случай. Если бы с ПО всё всегда было именно так, никому не нужно было бы ничего кроме водопада и монолитной поставки.
В реальной жизни часто заказчик ещё никогда не видел Мону Лизу, и не уверен в том, какая она должна быть. И бюджет он хочет сэкономить, поэтому сразу заплатить за проработку всех вариантов — невыгодно (и по времени тоже недопустимо).
Поэтому в системе с водопадом ты рисуешь Мона Лизу, приносишь её, заказчик смотрит, думает, и говорит что надо было бы крупнее в два раза и ещё нужен младенец. Ты идёшь и рисуешь Мадонну в скалах, снова с нуля, и снова начистоту. Это дорогой средневековый метод.

Потому и придумали всякие методы, чтобы всякие уточнения требований поступали как можно раньше, и возвращали тебя назад как можно быстрее, пока ещё не потеряны деньги и время. Все различия методологий крутятся вокруг этого вопроса, всё остальное — чепуха. В крайнем случае, в большинстве agile-методик заказчик просто включается в команду и участвует в работе, непрерывно корректируя требования. Да, бюджет становится неизвестным, но подразумевается, что традиционным способом всё равно вышло бы дороже и более непредсказуемо. Здесь надо вдумчиво выбирать. Нет одного лучшего способа.
Требования значит при Agile постоянно меняются, а зарплата почему-то нет)
Дочитал до Agile и с сожалением понял, что читаю дикую чушь( Как минимум параграф про Agile начинается с полного непонимания самой терминологии
Спасибо большое за статью. Но действительно статье есть куда совершенствоваться.
Я так понимаю она во многом основывается вот на этом источнике? Жаль что не весь объем текста и картинок использован в вашей статье.

Ну и у вас и там, как мне кажется, про итеративную модель допущено искажение:
When to use iterative model:
Requirements of the complete system are clearly defined and understood.


которое не стыкуется с:

An iterative life cycle model does not attempt to start with a full specification of requirements.

Вроде и методологий куча. Но ощущение, будто чего-то не хватает, будто это какой-то односторонний взгляд на проблематику разработки.

Sign up to leave a comment.