MSF Agile vs Scrum
MSF Пиши код блеать!
Агил — это ширма для непрофессионализма.
Самый правильный подход следующий: создание прототипа приложения (например, в виде красивых веб-формочек) и согласование проекта с заказчиком по деньгам и срокам, а также детальная разработка архитектуры приложения аналитиками и опытными разработчиками "на бумаге" в виде тз, затем, на последнем этапе, кодирование и сдача проекта. Все.
Самый правильный подход следующий: создание прототипа приложения (например, в виде красивых веб-формочек) и согласование проекта с заказчиком по деньгам и срокам, а также детальная разработка архитектуры приложения аналитиками и опытными разработчиками "на бумаге" в виде тз, затем, на последнем этапе, кодирование и сдача проекта. Все.
И какой процент проектов сделанных по такому подходу оказался успешным? Желательно с отсылкой к мировой практике.
Проекты, в которых участвовал, были сделаны по такой методологии и оказались весьма успешными.
В частности, последний мой проект для российского филиала одной очень известной и крупной американской компании. Сейчас они к нам пришли еще за одним приложением, видимо им понравилось высокое качество исполнения первого при относительно низких денежных затратах
P.S. Важное конкурентное преимущество такой методологии по сравнению с Агилом — это экономия денег на написании кода, который потом выкидывается. Легче исправить строчку в тексте тз, чем выкинуть модуль из 10 тыс. строк программного кода. Нужно отметить также, что продуманная заранее архитектура приложения, когда она разрабатывается до написания кода, делает весь проект максимально прозрачным, исключаются потенциальные ошибки и множество сложностей, которые связаны с интеграцией, экономится время программистов, а значит минимизируются денежные затраты при максимизации качества программного продукта.
В частности, последний мой проект для российского филиала одной очень известной и крупной американской компании. Сейчас они к нам пришли еще за одним приложением, видимо им понравилось высокое качество исполнения первого при относительно низких денежных затратах
P.S. Важное конкурентное преимущество такой методологии по сравнению с Агилом — это экономия денег на написании кода, который потом выкидывается. Легче исправить строчку в тексте тз, чем выкинуть модуль из 10 тыс. строк программного кода. Нужно отметить также, что продуманная заранее архитектура приложения, когда она разрабатывается до написания кода, делает весь проект максимально прозрачным, исключаются потенциальные ошибки и множество сложностей, которые связаны с интеграцией, экономится время программистов, а значит минимизируются денежные затраты при максимизации качества программного продукта.
Агил — это ширма для непрофессионализма.Вы таки просто не умеете его готовить.
согласование проекта с заказчиком по деньгам и срокам, а также детальная разработка архитектуры приложения аналитиками и опытными разработчиками "на бумаге" в виде тзэто невозможно для сколь-нибудь сложных проектов, имхо
> И какой процент проектов сделанных по такому подходу оказался успешным?
Можно узнать, сколько стоящих проектов разработаны по-новому?
Веб-странички и прочие "высоконагруженные порталы" не учитываем.
---
"Narrowness of experience leads to narrowness of imagination."
Можно узнать, сколько стоящих проектов разработаны по-новому?
Веб-странички и прочие "высоконагруженные порталы" не учитываем.
---
"Narrowness of experience leads to narrowness of imagination."
Для меня мерило того, хороша методология или нет — это прибыльность проекта для всей команды и высокое качество продукта. Если у вас нет умных аналитиков и опытных разработчиков-архитекторов — мучайтесь с Агилом, выжимая соки из программистов. У каждого своя ниша 
Чтобы продавать "заказчику" - конечно ваш подход и удобнее и приятнее и проще.
А вот когда попробуете продать то же самое сколько-нибудь заметной аудитории - он и покажет свою несостоятельность.
Agile-методологии для продуктовой разработки, а не для красивых прототипчиков.
А вот когда попробуете продать то же самое сколько-нибудь заметной аудитории - он и покажет свою несостоятельность.
Agile-методологии для продуктовой разработки, а не для красивых прототипчиков.
Легче исправить строчку в тексте тз, чем выкинуть модуль из 10 тыс. строк программного кода.херово вы пишите код, что ж у вас исправление одной строчки ТЗ требует непропорциональных изменений в коде.
высокое качество исполнения
Высокое качество софта — это когда изменения в требованиях требует пропорционального изменение в софте, т.е. в коде. А у вас ровно наоборот, поэтому о высоком качестве вам не стоит заикаться.
Успешные проекты живут лет 10 и всё время меняются.
херово вы пишите код, что ж у вас исправление одной строчки ТЗ требует непропорциональных изменений в коде
Ты бредишь, Шурик?
Наоборот, описанный мной подход к разработке ПО экономит на написании кода, а при использовании других методологий выбрасывается много кода, так как ТЗ значительно изменяется уже на стадии кодирования.
Что ты понимаешь под продуктовой разработкой?
Если изготовление программного продукта "под ключ" на заказ, то тогда, мне кажется, ты не прав.
Если изготовление программного продукта "под ключ" на заказ, то тогда, мне кажется, ты не прав.
Всегда считал долбоебами тех, кто использует слова скрам и аджайл. На мой взгляд эти термины (канбан еще) блевотнее чем бизнес-спик.
Ты бредишь, Шурик?Нет.
Наоборот, описанный мной подход к разработке ПО экономит на написании кода, а при использовании других методологий выбрасывается много кода, так как ТЗ значительно изменяется уже на стадии кодирования.
Еще раз, в нормальный код изменения вносятся не сложнее (на самом деле проще чем в ТЗ. Кстати, давно хотел поинтересоваться, какой формат предпочитают крутые писатели ТЗ, MS Word? В каком формате и чем скрины для UI рисуют?
Всегда считал долбоебами тех, кто использует слова скрам и аджайл. На мой взгляд эти термины (канбан еще) блевотнее чем бизнес-спик.у меня так же, не могу понять откуда у меня такое отвращение к этому
> На мой взгляд эти термины (канбан еще) блевотнее чем бизнес-спик.
У нас один чудик решил внедрить этот канбан.
Занял целую доску под свои разноцветные бумажки.
Через неделю почти все бумажки оказались в состоянии
"мы работаем над этим" и остались там на пару месяцев.
Ещё через пару месяцев все забили на этот канбан.
(То, что подходит для организации перемещения гаек со склада в цех,
не обязательно подходит для написания кода, что, разумеется, вызывает
большое удивление у "менеджеров.")
---
"Мы рождены, чтоб Кафку сделать былью!"
У нас один чудик решил внедрить этот канбан.
Занял целую доску под свои разноцветные бумажки.
Через неделю почти все бумажки оказались в состоянии
"мы работаем над этим" и остались там на пару месяцев.
Ещё через пару месяцев все забили на этот канбан.
(То, что подходит для организации перемещения гаек со склада в цех,
не обязательно подходит для написания кода, что, разумеется, вызывает
большое удивление у "менеджеров.")
---
"Мы рождены, чтоб Кафку сделать былью!"
А у нас получилось внедрить одну из эджайл практик - лин. Эффект крайне положительный, хотя внедрение заряло около полугода, которое мы плакали, кололись, но продолжали жрать кактус. Благо, воли местного руководства хватило довести до рабочего состояния. Зато теперь при неуменьшившемся потоке задач и оставшейся по размеру команде стало самоочевидно, что время проебывается не у нас, а со стороны менеджмента, а у нас появилось время на r&d, эксперименты и овертаймить перестали.
Так что при всем скепсисе я начал спокойнее относиться к этим словам. Работающий скрам я тоже видел. Хотя неработающих я видел гораздо больше
Для - продуктовая разработка, это когда выпускаемые проекты целиком и полностью формируются в компании. Внешнего заказчика нет. А это значит что поставщиками требований выступают многочисленные пользователи, а не некий дядя.
Это не отменяет архитектуру, квартальное планирование и т.п. Однако вносит огромную долю изменчивости и неизбежную работу в стол - крупный модуль нельзя задеплоить в продакшн в виде прототипа - не поймут-с. А будучи задеплоенным, он может просто не зайти или вообще иметь отрицательный эффект. И должен быть выкинут.
А четкое неизменное тз - это святой грааль:) и вообще я с какого-то момента считаю, что совершенное тз равносильно программному коду.
P.S. Да и как везде пишут - все эти эджайлы, скрамы, канбаны это не серебряная пуля. Для того, чтобы это работало требуется чтобы в этом принимали участия все звенья процесса (скрам, когда у менеджмента самое частое слово лексикона ASAP - работать не будет). Более того, это потребует зачастую неслабую перестройку техпроцесса. И людей, которые не читали крутые отзывы а видели, как это может работать, а желательно и организовывающих это.
В среднем мое начальство склоняется к тому, что эджайл в том или ином виде можно внедрить где угодно так, что он будет работать. Но с весьма различными затратами. Обычное бизнес-десижн - нная сумма/время за нные плюшки при успехе.
Так что при всем скепсисе я начал спокойнее относиться к этим словам. Работающий скрам я тоже видел. Хотя неработающих я видел гораздо больше
Для - продуктовая разработка, это когда выпускаемые проекты целиком и полностью формируются в компании. Внешнего заказчика нет. А это значит что поставщиками требований выступают многочисленные пользователи, а не некий дядя.
Это не отменяет архитектуру, квартальное планирование и т.п. Однако вносит огромную долю изменчивости и неизбежную работу в стол - крупный модуль нельзя задеплоить в продакшн в виде прототипа - не поймут-с. А будучи задеплоенным, он может просто не зайти или вообще иметь отрицательный эффект. И должен быть выкинут.
А четкое неизменное тз - это святой грааль:) и вообще я с какого-то момента считаю, что совершенное тз равносильно программному коду.
P.S. Да и как везде пишут - все эти эджайлы, скрамы, канбаны это не серебряная пуля. Для того, чтобы это работало требуется чтобы в этом принимали участия все звенья процесса (скрам, когда у менеджмента самое частое слово лексикона ASAP - работать не будет). Более того, это потребует зачастую неслабую перестройку техпроцесса. И людей, которые не читали крутые отзывы а видели, как это может работать, а желательно и организовывающих это.
В среднем мое начальство склоняется к тому, что эджайл в том или ином виде можно внедрить где угодно так, что он будет работать. Но с весьма различными затратами. Обычное бизнес-десижн - нная сумма/время за нные плюшки при успехе.
> А четкое неизменное тз - это святой грааль
Когда высказываются в пользу проекта с проработкой техзадания
вместо потогонной системы "давай-давай, код выдавай," то никто
и никогда не подразумевает неизменности. Вносить в техзадание
изменения так же естественно, как вносить изменения в код.
> и вообще я с какого-то момента считаю, что совершенное тз
> равносильно программному коду.
У тебя неправильное понимание того, что такое техническое задание,
советую прочитать что-нибудь по теме, чтобы хотя бы разговаривать
с использованием одних и тех же понятий. Если хочется быть очень
формальным, можешь прочитать и ГОСТ 34.602-89.
---
"Vyroba umelych lidi, slecno, je tovarni tajemstvi."
Когда высказываются в пользу проекта с проработкой техзадания
вместо потогонной системы "давай-давай, код выдавай," то никто
и никогда не подразумевает неизменности. Вносить в техзадание
изменения так же естественно, как вносить изменения в код.
> и вообще я с какого-то момента считаю, что совершенное тз
> равносильно программному коду.
У тебя неправильное понимание того, что такое техническое задание,
советую прочитать что-нибудь по теме, чтобы хотя бы разговаривать
с использованием одних и тех же понятий. Если хочется быть очень
формальным, можешь прочитать и ГОСТ 34.602-89.
---
"Vyroba umelych lidi, slecno, je tovarni tajemstvi."
Вероятно, я просто не работал на проектах с достаточной культурой тех. заданий, спасибо за ссылку - ознакомлюсь. У нас на проектах существуют ldd, prd и иные design documents в достаточных количествах, судя по твоим словам их можно считать тз в некоторгм смысле. но я никогда, не смотрел на них с такой точки зрения..
использует слова скрам и аджайлкакие слова ты предлагаешь использовать вместо этих двух?
Чтобы продавать "заказчику" - конечно ваш подход и удобнее и приятнее и проще.этот подход неудобен даже для продажи одному заказчику
> У нас на проектах существуют ldd, prd и иные design documents
> в достаточных количествах, судя по твоим словам их можно
> считать тз в некоторгм смысле.
Нет, всё-таки, не "судя." Вы ведь не согласуете "LLD" с заказчиком?
Все эти документы --- конструкторская документация, относящаяся
к техническому проекту, а не техническое задание.
Тут надо, наверное, пояснить, что я понимаю, что всё это, по сути,
такая бюрократия, которую программисты традиционно не любят.
Конечно, можно твердить, что она не нужна и приводить в пример
"водопад," который тут ни при чём, но вся эта "бюрократия,"
всё-таки, не с дуба свалилась, а является обобщением
практического опыта, иногда --- построения довольно-таки больших
систем, порой самого настоящего космического масштаба, без шуток.
Поэтому тут дело стоит так: либо ты делаешь сколько-то проектов
"на коленке" и самостоятельно получаешь аналогичный опыт, порой
очень сильно наломавшись с каким-нибудь заказчиком, оказавшимся
маловменяемым или просто ушлым, либо ты изучаешь всё это чуть
заранее, чем, собственно, и должны заниматься втузы.
Кстати, мнение, что программисты не любят бюрократию, совершенно
необоснованное. По опыту, программисты запросто готовы переплюнуть
самого бюрократического бюрократа. Один из примеров, с "канбаном,"
см. выше.
---
"Мы диалектику учили не по Гегелю.
Бряцанием боёв она врывалась в стих..."
> в достаточных количествах, судя по твоим словам их можно
> считать тз в некоторгм смысле.
Нет, всё-таки, не "судя." Вы ведь не согласуете "LLD" с заказчиком?
Все эти документы --- конструкторская документация, относящаяся
к техническому проекту, а не техническое задание.
Тут надо, наверное, пояснить, что я понимаю, что всё это, по сути,
такая бюрократия, которую программисты традиционно не любят.
Конечно, можно твердить, что она не нужна и приводить в пример
"водопад," который тут ни при чём, но вся эта "бюрократия,"
всё-таки, не с дуба свалилась, а является обобщением
практического опыта, иногда --- построения довольно-таки больших
систем, порой самого настоящего космического масштаба, без шуток.
Поэтому тут дело стоит так: либо ты делаешь сколько-то проектов
"на коленке" и самостоятельно получаешь аналогичный опыт, порой
очень сильно наломавшись с каким-нибудь заказчиком, оказавшимся
маловменяемым или просто ушлым, либо ты изучаешь всё это чуть
заранее, чем, собственно, и должны заниматься втузы.
Кстати, мнение, что программисты не любят бюрократию, совершенно
необоснованное. По опыту, программисты запросто готовы переплюнуть
самого бюрократического бюрократа. Один из примеров, с "канбаном,"
см. выше.
---
"Мы диалектику учили не по Гегелю.
Бряцанием боёв она врывалась в стих..."
Программисты не бюрократию не любят, они не любят, когда прогресса по проекту нет. Программист должны создавать софт. Программист всегда находится в позиции, с которой ему хорошо видно есть прогресс по проекту или нет. Когда что-то препятствует созданию софта, они это не любят. Если это бюрократия, не любят бюрократию.
> Программисты не бюрократию не любят, они не любят,
> когда прогресса по проекту нет.
> Программист должны создавать софт.
Тягловый скот любит тянуть, поэтому его надо нагружать,
если его не нагружать, он перестаёт тянуть.
Очень желаю тебе нарваться на подкованного и ушлого заказчика,
чтобы тебе посоздавать софт за свой счёт, раз ты "создавать софт"
любишь. Может, тогда поумнеешь.
---
"Юношеству занятий масса.
Грамматикам учим дурней и дур мы."
> когда прогресса по проекту нет.
> Программист должны создавать софт.
Тягловый скот любит тянуть, поэтому его надо нагружать,
если его не нагружать, он перестаёт тянуть.
Очень желаю тебе нарваться на подкованного и ушлого заказчика,
чтобы тебе посоздавать софт за свой счёт, раз ты "создавать софт"
любишь. Может, тогда поумнеешь.
---
"Юношеству занятий масса.
Грамматикам учим дурней и дур мы."
Очень желаю тебе нарваться на подкованного и ушлого заказчика,Многие программисты (в том числе и я) работают за зарплату. ТК РФ неплохо защищает работника, чтобы не было "за свой счёт".
чтобы тебе посоздавать софт за свой счёт, раз ты "создавать софт"
любишь. Может, тогда поумнеешь.
Отсюда следует, что программисту выгоднее идти работать непосредственно к заказчику.
А тебе не заплатил ушлый заказчик на проекте космического масштаба?
> Многие программисты (в том числе и я) работают за зарплату.
> ТК РФ неплохо защищает работника, чтобы не было "за свой счёт".
ТК тебе не поможет, если тот, кто заключил договор со стороны
твоего начальства, лопух. Тебе могут наставить задач в пределах
твоих должностных обязанностей, но таких, что ты сто раз пожалеешь.
Хотя, если учесть твои склонности, возможно, что тебе это нравится.
> Отсюда следует, что программисту выгоднее идти работать
> непосредственно к заказчику.
Что ты называешь под "идти работать непосредственно к заказчику?"
Как его работник или как подрядчик?
> А тебе не заплатил ушлый заказчик на проекте космического масштаба?
Я поучаствовал в борьбе против ушлого заказчика на среднем проекте,
когда с нас требовали космического качества забесплатно, цепляясь
к словам в договоре. Тогда-то я и оценил прелести работы с инженерами
старой закалки: они могли ответить чётко и по существу, мало чего
понимая в ЛВС и программировании, но разбираясь в нормах.
Ещё один мой заказчик был в чём-то схож: они не желали платить
до окончания работ, но хотели очень много, поставить задачу
достаточно чётко, чтобы можно было ограничить её стоимость и сроки,
они не желали. Наученый предыдущим опытом, через некоторое время
я просто отказался продолжать до получения от них хотя бы ТТЗ.
---
"И опыт, сын ошибок трудных, и гений, парадоксов друг..."
> ТК РФ неплохо защищает работника, чтобы не было "за свой счёт".
ТК тебе не поможет, если тот, кто заключил договор со стороны
твоего начальства, лопух. Тебе могут наставить задач в пределах
твоих должностных обязанностей, но таких, что ты сто раз пожалеешь.
Хотя, если учесть твои склонности, возможно, что тебе это нравится.
> Отсюда следует, что программисту выгоднее идти работать
> непосредственно к заказчику.
Что ты называешь под "идти работать непосредственно к заказчику?"
Как его работник или как подрядчик?
> А тебе не заплатил ушлый заказчик на проекте космического масштаба?
Я поучаствовал в борьбе против ушлого заказчика на среднем проекте,
когда с нас требовали космического качества забесплатно, цепляясь
к словам в договоре. Тогда-то я и оценил прелести работы с инженерами
старой закалки: они могли ответить чётко и по существу, мало чего
понимая в ЛВС и программировании, но разбираясь в нормах.
Ещё один мой заказчик был в чём-то схож: они не желали платить
до окончания работ, но хотели очень много, поставить задачу
достаточно чётко, чтобы можно было ограничить её стоимость и сроки,
они не желали. Наученый предыдущим опытом, через некоторое время
я просто отказался продолжать до получения от них хотя бы ТТЗ.
---
"И опыт, сын ошибок трудных, и гений, парадоксов друг..."
ТК тебе не поможет, если тот, кто заключил договор со стороныТК помогает работнику не спеша выйти на рынок. А там уж рынок решит, что и кто кому нравится.
твоего начальства, лопух. Тебе могут наставить задач в пределах
твоих должностных обязанностей, но таких, что ты сто раз пожалеешь.
Хотя, если учесть твои склонности, возможно, что тебе это нравится.
Что ты называешь под "идти работать непосредственно к заказчику?"
Как его работник или как подрядчик?
на зарплату к заказчику
> ТК помогает работнику не спеша выйти на рынок.
> А там уж рынок решит, что и кто кому нравится.
У тебя очень странная точка зрения.
Советую всё-таки опуститься на землю и освоить хоть что-то из
гражданского права.
>> Что ты называешь под "идти работать непосредственно к заказчику?"
>> Как его работник или как подрядчик?
> на зарплату к заказчику
Я ещё раз повторю: даже маленькая неграмотность твоего начальства
при при составлении договора может причинить тебе лично немало
головной боли.
Кстати, по теме, как уже упоминалось все эти "агилы" как раз
помогают заказчику согнать семь потов с исполнителей, причём так,
что последние и не замечают, что могли вместо выдачи кода на-гора
заниматься более приятными вещами. Конечно, заказчик может это
сделать и неосознанно, но уж программисты-то должны понимать,
чем они занимаются, и понимать, что если им каждую неделю
присылают новое ТТЗ, это не может сократить срок разработки,
а вот сделать его бесконечным вполне может.
---
"И опыт, сын ошибок трудных, и гений, парадоксов друг..."
> А там уж рынок решит, что и кто кому нравится.
У тебя очень странная точка зрения.
Советую всё-таки опуститься на землю и освоить хоть что-то из
гражданского права.
>> Что ты называешь под "идти работать непосредственно к заказчику?"
>> Как его работник или как подрядчик?
> на зарплату к заказчику
Я ещё раз повторю: даже маленькая неграмотность твоего начальства
при при составлении договора может причинить тебе лично немало
головной боли.
Кстати, по теме, как уже упоминалось все эти "агилы" как раз
помогают заказчику согнать семь потов с исполнителей, причём так,
что последние и не замечают, что могли вместо выдачи кода на-гора
заниматься более приятными вещами. Конечно, заказчик может это
сделать и неосознанно, но уж программисты-то должны понимать,
чем они занимаются, и понимать, что если им каждую неделю
присылают новое ТТЗ, это не может сократить срок разработки,
а вот сделать его бесконечным вполне может.
---
"И опыт, сын ошибок трудных, и гений, парадоксов друг..."
вместо выдачи кода на-гораТы выбрал профессию, которая не по душе? Ну что ж бывает и такое.
заниматься более приятными вещами
> Ты выбрал профессию, которая не по душе? Ну что ж бывает и такое.
Видишь ли, даже если профессия и нравится, это не повод радоваться
заявлениям заказчика, что ты должен сделать кучу кода за просто так,
не получая даже на еду. Может быть, ты святой, который будет работать
и питаться воздухом, но я думаю, всё же, что остальные предпочтут
писать интересный код, чем заниматься удовлетворением очень странных
и неожиданных пожеланий заказчика, лишь бы тот заплатил деньги,
или выбрасывать кучу кода и платить по неустойке.
---
<<Вряд ли тот или иной коммунист будет кричать "ура", если вы
бросите его на прорыв и за это сократите ему жалованье в два
раза, хотя вам он об этом, возможно, ничего и не скажет.>>
И. Сталин
Видишь ли, даже если профессия и нравится, это не повод радоваться
заявлениям заказчика, что ты должен сделать кучу кода за просто так,
не получая даже на еду. Может быть, ты святой, который будет работать
и питаться воздухом, но я думаю, всё же, что остальные предпочтут
писать интересный код, чем заниматься удовлетворением очень странных
и неожиданных пожеланий заказчика, лишь бы тот заплатил деньги,
или выбрасывать кучу кода и платить по неустойке.
---
<<Вряд ли тот или иной коммунист будет кричать "ура", если вы
бросите его на прорыв и за это сократите ему жалованье в два
раза, хотя вам он об этом, возможно, ничего и не скажет.>>
И. Сталин
Оставить комментарий
otvertka07
кто какой использует? что выбрать?Это прочел но хотелось бы практических советов по выбору
в Agile немного терминология смущает