Комментарии 16
Все тут боятся коронавируса, а надо Agile. Жаль что у больных этой заразой летальность низкая… Не ну правда ну блин методика организации работы… Вы серьезно? Что ж вы с ГОСТами так не носитесь — там тоже грамотно написано что и как нужно проектировать и в каком порядке
+2
Потому что по ГОСТУ нельзя «фигак, фигак ив продакшен» ;-)
+2
Agile не про ГОСТ, и даже не про ИТ. Agile про людей.
Agile и ГОСТы живут в разных измерениях.
Agile и ГОСТы живут в разных измерениях.
-2
Либо здесь врут либо я чего-то не понимаю
А где там что-то про ГОСТы?
Если чего нет в ГОСТАх значит оно либо ненужно, либо скоро там будет.
Очень интересное заявление. Про тот же секс у нас в ГОСТАх много написано? Или он не нужен? :)
И да в ГОСТах тоже есть «про людей»
Но не всё что есть про людей есть в гостах?
0
Либо здесь врут либо я чего-то не понимаю.
Да, с этим беда.
Вроде у людей в ИТ в среднем формальная логика должна быть лучше развита. Но нет.
Я немало с кем сталкивался, кто утверждал, что agile про ИТ.
На вопрос «почему», указывали на заголовок.
Я в ответ: «Ну ок, в заголовке есть software development, а в самой декларации есть что-нибудь более детальное про ИТ?»
Как ни странно, Agile Manifesto ничего ИТ-специфичного не декларирует.
Только про людей, и все что связано с людьми.
зы
И в ГОСТах тоже есть про людей.
Но с другого аспекта.
0
Понимаете в чем проблема — в подмене понятий. Здесь конкретно МЕТОДОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ.
Разработка программного обеспечения — это не про людей, это про процесс!
А если посмотреть внимательно — а какие методолгии вообще есть? В один ряд с этим непотребством встают реальные совокупности методов разработки — итерационный и водопад. Почему непотребство? Потому что под определение «метод» никак не подходят ни «идеи» не «принципы» Где последовательные шаги для достижения результата? Вот это вот: «сначала берем человека потом инструмент, потом делаем то-то...» А всем любителям порассуждать что там ничего нет про именно разработку ПО процитирую:
Принципы, которые разъясняет Agile Manifesto:
удовлетворение клиента за счёт ранней и бесперебойной поставки ценного программного обеспечения;
приветствие изменений требований даже в конце разработки (это может повысить конкурентоспособность полученного продукта);
частая поставка рабочего программного обеспечения (каждый месяц или неделю или ещё чаще);
тесное, ежедневное общение заказчика с разработчиками на протяжении всего проекта;
проектом занимаются мотивированные личности, которые обеспечены нужными условиями работы, поддержкой и доверием;
рекомендуемый метод передачи информации — личный разговор (лицом к лицу);
работающее программное обеспечение — лучший измеритель прогресса;
спонсоры, разработчики и пользователи должны иметь возможность поддерживать постоянный темп на неопределённый срок;
постоянное внимание улучшению технического мастерства и удобному дизайну;
простота — искусство не делать лишней работы;
лучшие технические требования, дизайн и архитектура получаются у самоорганизованной команды;
постоянная адаптация к изменяющимся обстоятельствам. Команда должна систематически анализировать возможные способы улучшения эффективности и соответственно корректировать стиль своей работы
А насчет ГОСТов — таки да секс во время разработки и производства промышленной продукции и ПО абсолютно не нужен.) Потому его там и нет) А вот если поищите то и водопад и тем более итерационную или спиральную разработку найдете — называться будет не так но оно, поверьте, регламентировано и прописано.
И в заключение — дорогие менегеры! Не пытайтесь натянуть сову на глобус! Что работает с ПО не работает с физическими объектами. Если в ПО спрятать лапшу и кошмар в коде легко — о внешнем виде кода ни кто кроме вас знать не будет. То извините с другими вещами хрен! Минимум это будет видно, максимум законы физики не дадут кошмару работать изначально, либо после первой же поломки с помощью отвертки найдут всю вашу «гибкость» внутри и больше вы ничего не продадите — это я на примерах пояснил. Продукт может получиться качественный только при грамотно поставленных изначальных требованиях — никак иначе!
Разработка программного обеспечения — это не про людей, это про процесс!
А если посмотреть внимательно — а какие методолгии вообще есть? В один ряд с этим непотребством встают реальные совокупности методов разработки — итерационный и водопад. Почему непотребство? Потому что под определение «метод» никак не подходят ни «идеи» не «принципы» Где последовательные шаги для достижения результата? Вот это вот: «сначала берем человека потом инструмент, потом делаем то-то...» А всем любителям порассуждать что там ничего нет про именно разработку ПО процитирую:
Принципы, которые разъясняет Agile Manifesto:
удовлетворение клиента за счёт ранней и бесперебойной поставки ценного программного обеспечения;
приветствие изменений требований даже в конце разработки (это может повысить конкурентоспособность полученного продукта);
частая поставка рабочего программного обеспечения (каждый месяц или неделю или ещё чаще);
тесное, ежедневное общение заказчика с разработчиками на протяжении всего проекта;
проектом занимаются мотивированные личности, которые обеспечены нужными условиями работы, поддержкой и доверием;
рекомендуемый метод передачи информации — личный разговор (лицом к лицу);
работающее программное обеспечение — лучший измеритель прогресса;
спонсоры, разработчики и пользователи должны иметь возможность поддерживать постоянный темп на неопределённый срок;
постоянное внимание улучшению технического мастерства и удобному дизайну;
простота — искусство не делать лишней работы;
лучшие технические требования, дизайн и архитектура получаются у самоорганизованной команды;
постоянная адаптация к изменяющимся обстоятельствам. Команда должна систематически анализировать возможные способы улучшения эффективности и соответственно корректировать стиль своей работы
А насчет ГОСТов — таки да секс во время разработки и производства промышленной продукции и ПО абсолютно не нужен.) Потому его там и нет) А вот если поищите то и водопад и тем более итерационную или спиральную разработку найдете — называться будет не так но оно, поверьте, регламентировано и прописано.
И в заключение — дорогие менегеры! Не пытайтесь натянуть сову на глобус! Что работает с ПО не работает с физическими объектами. Если в ПО спрятать лапшу и кошмар в коде легко — о внешнем виде кода ни кто кроме вас знать не будет. То извините с другими вещами хрен! Минимум это будет видно, максимум законы физики не дадут кошмару работать изначально, либо после первой же поломки с помощью отвертки найдут всю вашу «гибкость» внутри и больше вы ничего не продадите — это я на примерах пояснил. Продукт может получиться качественный только при грамотно поставленных изначальных требованиях — никак иначе!
+2
Где последовательные шаги для достижения результата?
В конкретных методиках вроде скрама и канбана.
Что работает с ПО не работает с физическими объектами
Очень категоричное утверждение. Тот же канбан и водопад например в информатику пришли из индустрии.
А вот если поищите то и водопад и тем более итерационную или спиральную разработку найдете — называться будет не так но оно, поверьте, регламентировано и прописано.
Вы наверное уже поискали и вам не составит труда процитировать то что вы нашли? Или это только ваши предположения?
Продукт может получиться качественный только при грамотно поставленных изначальных требованиях — никак иначе!
С чего вы решили что аджайл работает без грамотно поставленных изначальных требований? Именно в этом плане он от того же водопада ничем не отличается.
-1
если в манифесте вместо «программное обеспечение» подставить что-нибудь другое, например «услуга» или «изделие», что-нибудь принципиально изменится?
и регулярно сталкиваюсь с мнением, что agile — означает анархию, отсутствие целей и ответственности. если делаем тяп-ляп, значит делаем agile.
нет, в agile в целом, а скрам в частности, очень консервативен в плане требований, целей, ответственности, сроков и всего прочего, что нужно бизнесу для решения его проблем.
важно лишь понимать, что контекст у бизнеса бывает разный.
в одном контексте — отлично заходит agile, в другом контексте — научный, в третьем — армейский, и т.д.
Так это ж никто не оспаривает.
Вопрос только в подходах.
Можно сказать, уважаемый… (HR, юрист, бухгалтер, кладовщик и пр.), пока вы не напишите внятное ТЗ, мы палец о палец не ударим.
А можно сказать, давайте выясним, почему у вас эта проблема, и вместе найдем ее решение.
и регулярно сталкиваюсь с мнением, что agile — означает анархию, отсутствие целей и ответственности. если делаем тяп-ляп, значит делаем agile.
нет, в agile в целом, а скрам в частности, очень консервативен в плане требований, целей, ответственности, сроков и всего прочего, что нужно бизнесу для решения его проблем.
важно лишь понимать, что контекст у бизнеса бывает разный.
в одном контексте — отлично заходит agile, в другом контексте — научный, в третьем — армейский, и т.д.
Продукт может получиться качественный только при грамотно поставленных изначальных требованиях — никак иначе!
Так это ж никто не оспаривает.
Вопрос только в подходах.
Можно сказать, уважаемый… (HR, юрист, бухгалтер, кладовщик и пр.), пока вы не напишите внятное ТЗ, мы палец о палец не ударим.
А можно сказать, давайте выясним, почему у вас эта проблема, и вместе найдем ее решение.
0
Э-э-э. Весь человеческий опыт говорит, что любой манифест приводит к «анархии, отсутствию целей и т.д.»
Начиная с 10 заповедей и нагорной проповеди.
Хорошие же манифесты были.
К чему привели…
Манифест, он про людей.
Т.е. чтобы манифест работал нужны строго определенные люди с психофизическими характеристиками.
Их либо с 0 лет воспитывают, либо они извращают манифест до полной противоположности.
Начиная с 10 заповедей и нагорной проповеди.
Хорошие же манифесты были.
К чему привели…
Манифест, он про людей.
Т.е. чтобы манифест работал нужны строго определенные люди с психофизическими характеристиками.
Их либо с 0 лет воспитывают, либо они извращают манифест до полной противоположности.
0
Э-э-э. Весь человеческий опыт говорит, что любой манифест приводит к «анархии, отсутствию целей и т.д.»
Нет, не говорит.
Начиная с 10 заповедей и нагорной проповеди.
Хорошие же манифесты были. К чему привели…
И к чему они по вашему привели такому ужасному? Ну вот именно они и если посмотреть всю ситуацию «в сумме»?
0
«В сумме» они привели к
1) К массовым убийствам во имя веры
2) Продажи «индульгенций», т.е. коммерциализация религии
3) Расколу и различные трактовки «догматов веры»
В общем как обычно.
Люди начали использовать «идею» для решения своих меркантильных задач.
1) К массовым убийствам во имя веры
2) Продажи «индульгенций», т.е. коммерциализация религии
3) Расколу и различные трактовки «догматов веры»
В общем как обычно.
Люди начали использовать «идею» для решения своих меркантильных задач.
0
И это всё к чему они по вашему привели? То есть никаких других последствий не было? только эти и/или только негативные?
И тогда ещё следующий вопрос: а если бы десяти заповедей не было, то всё то что вы сейчас перечислили обязательно бы не произошло?
И тогда ещё следующий вопрос: а если бы десяти заповедей не было, то всё то что вы сейчас перечислили обязательно бы не произошло?
0
1) Нет не все. Это просто показатель, как намерения отличаются от реальности
2) Были. Как минимум чужаков перестали сразу резать и жрать, а вначале выясняют какому богу молиться.
3) Не произошло бы. Т.к. это особенности «имплементации»
2) Были. Как минимум чужаков перестали сразу резать и жрать, а вначале выясняют какому богу молиться.
3) Не произошло бы. Т.к. это особенности «имплементации»
0
Естественно намерения не всегда воплощаются в жизнь на 100%. Но они часто ведут как минимум к улучшению ситуации. И христианство в общем-то тоже к этому привело. И на мой взгляд как минимум до Средневековья от христианства было больше пользы чем вреда.
А уж утверждать что жадность, нетерпимость и ненависть к чужакам это "особенности имплементации христианства" это вообще смешно. Всё что вы перечислили встречалось и в куче других религий. И не только в монотеистических.
0
На мой взгляд вредным советом под номером «0» должно идти что-то вроде «Рассказывайте всем что Agile это 'серебрянная пуля', которая не то что подходит, а даже просто необходима абсолютно любой [ИТ-]фирме».
-1
Зарегистрируйтесь на Хабре , чтобы оставить комментарий
Agile: 9 вредных советов