Каморка

В современной промышленной разработке программного обеспечения непосредственно...

Какое тонкое издевательство:) Чистейший аджайл, чувствуешь что поимели, но все так складно, как будто по согласию

aissp писал(а):

В современной промышленной разработке программного обеспечения непосредственно...

Какое тонкое издевательство:) Чистейший аджайл, чувствуешь что поимели, но все так складно, как будто по согласию

Такова судьба всех хомячков-девелоперов

да лучше под аджайлом чем на яве...

aissp писал(а):да лучше под аджайлом чем на яве...

Хомячки остаются хомячками независимо от того, на каком языке они пишут, то же самое можно сказать и про художников

ты про тех художников кто мелом на сарае тиражируют одну и туже картину?

Alusya писал(а):

aissp писал(а):=) Из Agile просто из рассылки

Вчера Хунь Лунь починил 9 багов, он стал героем дня. Сегодня цель для нашей комманды починить 130 багов (в среднем 2 бага на бойца) ...

Граждане ЕТО БРЕД!!!! Человек не может починить 8 багов за один день, или ето не баги

Интересно сколько он таким образом создал новых.

Слушала когда-то интересный training по тестированию, trainer-умный_дядька-практик сказал что (в очень среднем, так как depends от многих факторов) - один новый баг на 3-4 починенных. Потому очень не рекомендуется чинить баги перед окончанием тестинга и сдачи продукта, особенно если они (баги) не critical. Лучше оставить их для следующего релиза.

PS. На опыте убедилась в правильности этой идеи.

Meadie писал(а):Любая методология разработки программного обеспечения ставит своей задачей организовать работу программистов и тестировщиков (людей непосредственно создающих продукт) таким образом, чтобы получить на выходе продукт удовлетворящий требованиям Заказчика и обладающим необходимым качеством.

Как бы классно я жил, если бы это было так...

aissp писал(а):да лучше под аджайлом чем на яве...

Какое тонкое издевательство!

Stanislav писал(а):

aissp писал(а):да лучше под аджайлом чем на яве...

Какое тонкое издевательство!

Примитивные хомячковый перевод стрелок
Вместо того, что бы осознать свою хомячковость и перебороть ее

А вот еще все стали хвалить TDD.... ненавижу блин...
Стадные инстинкты правят человечеством...

Meadie писал(а):А если серьезно, то ключевым в agile methodology является человеческий фактор - именно от того, какие люди в нем заняты и зависит результат (это, кстати говоря, одна из основных идей книги Agile Testing

Человеческий фактор важен всегда и везде, с agile или без agile. Так что сложно занести это в достоинство данной технологии.

Meadie писал(а):В современной промышленной разработке программного обеспечения непосредственно изменение кода занимает не так уж и много времени.

Вот-вот. Именно так многие недалёкие манагеры и думают. Сидят, мол, эти программисты там, ерундой занимаются, а работы-то на полчаса, там изменил, да сям подправил.

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

Все эти методологии убивают креативность. Завод какой-то честное слово! У меня в конторе 24 митинга в месяц из них 20 for 15мин 2 часовых. Сказочная митинговя методология

badger писал(а):

Meadie писал(а):А если серьезно, то ключевым в agile methodology является человеческий фактор - именно от того, какие люди в нем заняты и зависит результат (это, кстати говоря, одна из основных идей книги Agile Testing

Человеческий фактор важен всегда и везде, с agile или без agile. Так что сложно занести это в достоинство данной технологии.

Высокие требования к человеческому фактору не являются достоинством agile methodology, скорее наборот, - это ее недостаток. Нехватка квалификации исполнителя может очень легко привести к серьезным проблемам.

Ведь, знаете, как на ответственных военных объектах дела делаются? На операцию по закручивании отдельной гайки есть своя собственная инструкция. Операцию выполняют три человека: исполнитель, его непосредственный начальник и контролер из другого подразделения. Начальник зачитывает вслух инструкцию, исполнитель ее выполняет (крутит гайку), а контролер проверяет, что все идет как надо. Подобным образом достигается качество выполнения работ. Замечу, что данный метод не требует высокой квалификации исполнителей.

В разработке коммерческого софта, конечно, все по другому. Но и здесь может быть два предельных варианта. Первый вариант - традиционный, когда при разработке новой функциональности конечному исполнителю (кодировщику) дается детальная спецификация, утвержденная или согласованная с заказчиком, что и как делать. Тут уже не место для дискуссий и митингов - нужно просто садится и писать код. Втрой вариант (agile methodology) - когда программисту дается ограниченная информация о новой функциональности - иногда, это просто строчка текста, иногда, короткие пользовательские сценарии. Вот тут нужно задавать вопросы, уточнять различные моменты и пр. Во многих случаях здесь хватает мнения своего ВА, но иногда за разъяснениями приходится обращаться непосредственно к заказчику. Часто вопросы появляются уже в процессе разработки новой функциональности. Все подобные вопросы должны обсуждаться и на них исполнитель должен получить ответ. В конечном итоге, ведь намного проще (и быстрее) несколько часов провести на митингах, обсуждая ключевые проблемы, чем писать многотомные спеки. А если у кого митинги организованы неграмотно - см. п.1. о квалификации и требованиях к исполнителям. Умение проводить продуктивные митинги в agile methodology не менее важно, чем умение писать хороший код, или хорошие спеки в тяжеловесных методологиях.

Meadie писал(а): В разработке коммерческого софта, конечно, все по другому. Но и здесь может быть два предельных варианта. Первый вариант - традиционный, когда при разработке новой функциональности конечному исполнителю (кодировщику) дается детальная спецификация, утвержденная или согласованная с заказчиком, что и как делать. Тут уже не место для дискуссий и митингов - нужно просто садится и писать код. Втрой вариант (agile methodology) - когда программисту дается ограниченная информация о новой функциональности - иногда, это просто строчка текста, иногда, короткие пользовательские сценарии.

Существует еще один, куда более предельный вариант, разработка стартапа, когда все эти методологии прокидываются
Только вот "просто программистов" в этом варианте не предусмотренно

Marmot писал(а): Существует еще один, куда более предельный вариант, разработка стартапа, когда все эти методологии прокидываются
Только вот "просто программистов" в этом варианте не предусмотренно

Ну да, не все же стартапы в результате успешны. Интересно, каков процент неудачи в результате бардака. А так да, все от людей зависит, особенно в стартапах.