На главную Наши проекты:
Журнал   ·   Discuz!ML   ·   Wiki   ·   DRKB   ·   Помощь проекту
ПРАВИЛА FAQ Помощь Участники Календарь Избранное RSS
msm.ru
! Правила раздела:
1. Название темы - краткое описание кто/что против кого/чего
2. В первом сообщении - список параметров, по которым идет сравнение.
3. Старайтесь аргументировать свои высказывания. Фразы типа "Венда/Слюникс - ацтой" считаются флудом.
4. Давайте жить дружно и не доводить обсуждение до маразма и личных оскорблений.
Модераторы: Модераторы, Комодераторы
Страницы: (4) 1 2 [3] 4  все  ( Перейти к последнему сообщению )  
> UML vs Нафиг
   
пользуете ли вы это в своей деятельности?
Гости не могут просматривать результаты голосования.
Гости не могут голосовать 
    Цитата D_KEY @
    Ну это зависит уже от способностей людей, не от подхода
    Гораздо хуже будет, если ты будешь все заранее продумывать, а потом в середине или к концу проекта придется требования менять. Так что если есть такие риски (а они сейчас почти всегда есть), лучше больше обратной связи собирать, fail fast и все такое.

    Но опять же, это смотря что разрабатываешь, «mission critical» софт обычно имеет чёткие, строгие и полностью заранее известные требования.

    И не обязательно прям всё продумывать. Проблема во всех этих agile методологиях в том, что бизнесу часто не интересен рефакторинг совсем, типа сделал фичу — делай следующую, в результате имеем нагромождение костылей и говнокода вместо адаптации архитектуры, оптимизации алгоритмов и т.п.
      Цитата D_KEY @
      Ну это зависит уже от способностей людей, не от подхода

      Да да расскажи плиз, как писать сложную систему(комплекс различных модулей, которые будут взаимодействовать между собой) с нуля, команде разрабов, без диаграмм? Ты помниться обещался рассказать позже, но видимо забыл?

      Добавлено
      Цитата D_KEY @
      Гораздо хуже будет, если ты будешь все заранее продумывать, а потом в середине или к концу проекта придется требования менять. Так что если есть такие риски (а они сейчас почти всегда есть), лучше больше обратной связи собирать, fail fast и все такое.

      Зачем продумывать все? Вот как раньше софт писали, налабали какой нибудь WinAmp там или тот же Far, круто есть программулина, но что если люди захотят другой функционал, какой нибудь такой которого нет, или изменить существующий? Это решается очень просто - моды/плагины. Вплоть до смены внешнего вида и поведения. И ниче, ничего не нужно было менять и переписывать. А сейчас повсеместно поди требования меняют и переписывают там что то.
      А что ты будешь делать если у тебя несколько крупных заказчиков требуют разный функционал, порой даже противоречивый?

      Добавлено
      Цитата korvin @
      бизнесу часто не интересен рефакторинг совсем

      Бизнесу не интересен рефакторинг в принципе, ну за исключением самой конторы-разработчика.
      Сообщение отредактировано: Wound -
        Цитата Wound @
        Бизнесу не интересен рефакторинг в принципе, ну за исключением самой конторы-разработчика.

        Не знаю, что ты подразумеваешь под «бизнесом», но я имел в виду в том числе и компании, разрабатывающие софтварный продукт, тысячи их.
          Цитата korvin @
          Не знаю, что ты подразумеваешь под «бизнесом», но я имел в виду в том числе и компании, разрабатывающие софтварный продукт, тысячи их.

          Ну я думал ты про заказчиков пишешь. Заказчикам рефакторинг нафиг не уперся, компаниям - которые разрабатывают ПО, тут да, это актуально.
            Цитата korvin @
            Но опять же, это смотря что разрабатываешь, «mission critical» софт обычно имеет чёткие, строгие и полностью заранее известные требования.

            Нет, кстати. Там обычно есть стандарты и пр., но по одному и тому же стандарту можно сделать совершенно разные продукты, которые будут им соответствовать ;)

            Добавлено
            Цитата korvin @
            И не обязательно прям всё продумывать. Проблема во всех этих agile методологиях в том, что бизнесу часто не интересен рефакторинг совсем, типа сделал фичу — делай следующую, в результате имеем нагромождение костылей и говнокода вместо адаптации архитектуры, оптимизации алгоритмов и т.п.

            Это проблема коммуникаций. Если речь конкретно про скрам, то коммуникаций между командой разработки и владельцем продукта. Я такое видел и видел, как это решается :)

            Добавлено
            Цитата Wound @
            Да да расскажи плиз, как писать сложную систему(комплекс различных модулей, которые будут взаимодействовать между собой) с нуля, команде разрабов, без диаграмм?

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

            Как я рекомендовал бы действовать? Сформировать видение продукта, затем можно использовать impact mapping и story mapping, сформировать MVP.
            Опираясь на это, спроектировать гибкий каркас системы, я бы использовал подход C4(без последней C) в сочетании с рассмотрением рисков(совместно с разработчиками и бизнесом) на каждом шаге. Далее уже идем итеративно и инкрементально, делаем небольшую систему, опираясь на хорошие инженерные практики и принципы (от шаблонов проектирования, *DD до CI/CD) и создаем себе инфраструктуру для быстрой разработки с тестами на всех уровнях, код ревью и пр., и на каждой итерации наращиваем продукт, опираясь на обратную связь от пользователей, заказчиков и пр., показывая или уже поставляя продукт после каждой итерации. Общее требование к архитектуре - гибкость (по факту, если следовать хорошим практикам и принципам, то она будет). Остальное уже в зависимости от продукта.

            Это все требует высокой квалификации. Это недостаток в некоторых случаях.
              Цитата Wound @
              компаниям - которые разрабатывают ПО, тут да, это актуально.

              Нет, они такие же заказчики, точнее их клиенты, ПО пишется не просто так, а для кого-то/чего-то, в случае софтверной компании (даже таких чисто софтверных, как JetBrains, например), есть клиенты/пользователи/рынок/конкуренты, которых можно назвать «заказчиками».

              Цитата D_KEY @
              Нет, кстати. Там обычно есть стандарты и пр., но по одному и тому же стандарту можно сделать совершенно разные продукты, которые будут им соответствовать

              Кроме стандартов есть требования к реализации (те же системы реального времени и т.п., думаю тут Qraizer может рассказать, например).

              Цитата D_KEY @
              Это проблема коммуникаций.

              Нет, это проблема самого подхода: на каждом этапе скоуп ограничен, особенно временными рамками. Нельзя при решении небольшой задачи проводить повсеместный рефакторинг, например, даже если он выглядит очень полезным. Задача уже оценена по времени/усилиям и вообще при заявлении, что «тут нужно подрефакторить всё и это займёт в 5 раз больше времени, чем простое решение», тебя пошлют нахрен, потому что коллега оценит решение этой задачи как требующее в пять раз меньше времени, чем ты оценил (с рефакторингом), то руководство посчитает, что ты неэффективный мудак, а твой коллега — настоящий профессионал, независимо от того, насколько говнокодное будет его решение и насколько высок окажется тех.долг, главное, что он задачу решил быстрее.
                Цитата D_KEY @
                Я такое видел и видел, как это решается :)

                Частные подробности могу при встрече рассказать. А в общих чертах, PO обязательно должен понимать, что мы вставляем костыли и что за это нужно заплатить потом. Т.е. приходит он с какой-то бизнес задачей(user story или еще чего), команда дает оценки и прогноз, когда сделает. Если уже тут команда снижает оценку и костылит, то проблема в команде и ее ответственности за качество. Если же прогноз дан с учетом нормально сделанного решения и PO согласен, то все должно быть ок. Если же PO говорит, что пипец как срочно, сделайте плиз раньше, то начинается торг. Мы можем убрать часть требований, если это позволит быстрее сделать без потери качества, а можем решить, что сейчас сделаем прототип или костыль вставис, но тут же в бэклог заносим пункт на создание нормального решения и обсуждаем, когда нужно.
                Нормальный PO понимает(а если нет, можно объяснить), что костыли рано или поздно приведут к тому, что мы или замедлимся или вообще не сможем делать нужные фичи впоследствии.

                Добавлено
                Цитата korvin @
                Цитата D_KEY @
                Нет, кстати. Там обычно есть стандарты и пр., но по одному и тому же стандарту можно сделать совершенно разные продукты, которые будут им соответствовать

                Кроме стандартов есть требования к реализации (те же системы реального времени и т.п., думаю тут Qraizer может рассказать, например).

                Все верно, но ты всё равно можешь сделать очень разные продукты, которые будут соответствовать этим внешним требованиям. Их обязательно нужно учитывать и такая ситуация даже проще в плане проектирования, чем когда таких ограничений нет.
                  Цитата korvin @
                  Нет, они такие же заказчики, точнее их клиенты, ПО пишется не просто так, а для кого-то/чего-то, в случае софтверной компании (даже таких чисто софтверных, как JetBrains, например), есть клиенты/пользователи/рынок/конкуренты, которых можно назвать «заказчиками».

                  Ну ок, тут ты прав, софтварные конторы(заказчики) для которых пишут другие софтварных конторы - я как то не учел.
                  Сообщение отредактировано: Wound -
                    Цитата korvin @
                    Цитата D_KEY @
                    Это проблема коммуникаций.

                    Нет, это проблема самого подхода

                    Смотри выше. Я видел, когда такая проблема была и как она ушла после фикса проблем в коммуникации.

                    Добавлено
                    Цитата korvin @
                    Задача уже оценена по времени/усилиям и вообще при заявлении, что «тут нужно подрефакторить всё и это займёт в 5 раз больше времени, чем простое решение», тебя пошлют нахрен, потому что коллега оценит решение этой задачи как требующее в пять раз меньше времени, чем ты оценил (с рефакторингом), то руководство посчитает, что ты неэффективный мудак, а твой коллега — настоящий профессионал, независимо от того, насколько говнокодное будет его решение и насколько высок окажется тех.долг, главное, что он задачу решил быстрее.

                    То, что ты тут описал противоречит agile подходу :)
                    У тебя в agile независимые и самостоятельные команды, принимающие решения об объеме работ, которые они берут в итерацию.
                    Если это не так, то у тебя не agile и тогда говорить нужно о другом.
                      Цитата D_KEY @
                      Все верно, но ты всё равно можешь сделать очень разные продукты, которые будут соответствовать этим внешним требованиям. Их обязательно нужно учитывать и такая ситуация даже проще в плане проектирования, чем когда таких ограничений нет.

                      Ага, но проектирование тут всё равно идёт сильно вперёд, и оно более скурпулёзное, нельзя просто взять и agile'овски сказать: а давайте сделаем вот так, потом посмотрим, что будет, проанализируем реакцию пользователей, т.к. какой-нибдь томограф может выжечь пациенту мозг (или типа того, я утрирую, но думаю, ты понял)

                      Цитата D_KEY @
                      Я видел, когда такая проблема была и как она ушла после фикса проблем в коммуникации.

                      Вот у нас подумывают взять скрам-мастера в команду, пойдёшь? (P.S. есть код на плюсах, если что)

                      Цитата D_KEY @
                      То, что ты тут описал противоречит agile подходу
                      У тебя в agile независимые и самостоятельные команды, принимающие решения об объеме работ, которые они берут в итерацию.

                      Нет, не противоречит, ибо «сверху» всегда навязываются минимальные сроки, а «снизу» пытаются «выторговать» более комфортные сроки. Может, это и не agile, но это то, во что этот «agile» вырождается на практике.
                        Пруфы противоречий.
                        3 из 12 принципов agile (можно обнаружить на сайте манифеста):
                        Цитата
                        Build projects around motivated individuals.
                        Give them the environment and support they need,
                        and trust them to get the job done.

                        ...

                        Continuous attention to technical excellence
                        and good design enhances agility.

                        ...

                        The best architectures, requirements, and designs
                        emerge from self-organizing teams.


                        Добавлено
                        Цитата korvin @
                        Может, это и не agile, но это то, во что этот «agile» вырождается на практике.

                        У нас разная практика :-?
                        У меня другой опыт, я видел то, о чем пишу.
                        Пункты из принципов я привел. Могу из scrum гайда еще привести.
                          Цитата D_KEY @
                          Создавать нужно продукты, которые решают проблемы пользователей или другого бизнеса, а не "сложные системы" - это уже средство для этого. Насмотрелся я на overengineering в своей жизни...

                          D_KEY, ну хватит. Ну хватит вот это отходить от темы и писать про какие то проблемы каких то пользователей.
                          Давай уточним, система например как 1С Предприятие - это сложная система? Система например как 3D Studio Max - это сложная истема? это же всего лишь программы. Хорошо, вот тут выше упомянули JetBrains, давай возьмем тот же IntelliJ IDEA - это сложнная система? Давай еще для сравнения возьмем например этот форум - это сложная система? Ну и для пущего эффекта возьмем например - игру "Волк ловит яйца в корзину", которую можно скачать на Google Play, это сложная система?
                          Ясный перец с менеджментской точки зрения речь будет идти о продуктах. Но мы же не менеджмент, правда? Мы разрабы, а значит речь идет о системах.
                          Я не знаю на что ты там насмотрелся, но с моей точки зрения в IT мире существует огромное множество сложных систем, под сложной системой я подразумеваю некий набор компонентов, которые взаимодействуют между собой как то там. Вот и все.

                          Цитата D_KEY @
                          Как я рекомендовал бы действовать? Сформировать видение продукта, затем можно использовать impact mapping и story mapping,

                          Можно нормально, без вот этих вот ваших true story, sad but true, etc. Мы все такие на российском форуме общаемся как бы.
                          И по подробне раскажи про "сформировать видение продукта"? Как это будет происходить?

                          К тебе приходит заказчик, говорит мне нужна вот такая вот система, с такими вот параметрами, и уметь она должна это вот это и это, заказчик шарит в теме, он ни какой то холуй, которого можно загрузить вот этими "impact mapping" и "true story", он знает что хочет получить дает тебе ТЗ написанное в общих чертах что и как, ясный перец без описания интерфейсов и всяких программных сущностей, он как бы не по этим делам. Ну и? Твои действия?


                          Цитата D_KEY @
                          Опираясь на это, спроектировать гибкий каркас системы, я бы использовал подход C4(без последней C) в сочетании с рассмотрением рисков(совместно с разработчиками и бизнесом) на каждом шаге.

                          Вот как раз в этом и вопрос - как спроектировать гибкий каркас системы, не взглянув на задачу прищурившись из далека? Расскажи секрет плиз ))

                          Цитата D_KEY @
                          Далее уже идем итеративно и инкрементально, делаем небольшую систему, опираясь на хорошие инженерные практики и принципы (от шаблонов проектирования, *DD до CI/CD) и создаем себе инфраструктуру для быстрой разработки с тестами на всех уровнях, код ревью и пр., и на каждой итерации наращиваем продукт, опираясь на обратную связь от пользователей, заказчиков и пр., показывая или уже поставляя продукт после каждой итерации. Общее требование к архитектуре - гибкость (по факту, если следовать хорошим практикам и принципам, то она будет). Остальное уже в зависимости от продукта.

                          Это уже реализация, но как ты людям все это объяснишь что надо делать? Представь что ты пошел вот от команды как архитектор и тимлид, тебе все расписали, рассказали, ты предложил какие то обходные пути и решения, в итоге вы на чем то там сошлись, ты все это для себя зафикисровал, теперь тебе нужно рассказать разрабам - че делаем, как это ожидается выглядеть, че там есть и все такое. Ты как им это все будешь объяснять? Я так понимаю портянку кода напишешь - нати курите, дальше сами? Или блок-схемы начнешь рисовать на доске?
                          Сообщение отредактировано: Wound -
                            D_KEY, давай начнём с того, что это не «принципы», а «рекомендации», «подсказки», которые вывели для себя эти уважаемые люди, что не означает автоматически их абсолютность и уместность применения везде и всюду.

                            Ну вот из перечисленных тобой ни один не соблюдается на практике. Потому что бизнесу не интересен _этот_ agile, ему интересно только увеличение скорости delivery.
                              Цитата korvin @
                              Ага, но проектирование тут всё равно идёт сильно вперёд, и оно более скурпулёзное, нельзя просто взять и agile'овски сказать: а давайте сделаем вот так, потом посмотрим, что будет, проанализируем реакцию пользователей, т.к. какой-нибдь томограф может выжечь пациенту мозг (или типа того, я утрирую, но думаю, ты понял)

                              У тебя у любой фичи практически будет mission critical часть и нет.
                              Если это не так, если ты руководствуешься только такими требованиями и нет никаких продуктовых гипотез, то тебе не нужен никакой agile.
                                Цитата D_KEY @
                                У нас разная практика
                                У меня другой опыт, я видел то, о чем пишу.
                                Пункты из принципов я привел. Могу из scrum гайда еще привести.

                                Видимо, разная. Я пока наблюдаю гонку за фичами. И вообще за скоростью.
                                0 пользователей читают эту тему (0 гостей и 0 скрытых пользователей)
                                0 пользователей:
                                Страницы: (4) 1 2 [3] 4  все


                                Рейтинг@Mail.ru
                                [ Script execution time: 0,0782 ]   [ 17 queries used ]   [ Generated: 4.02.23, 23:02 GMT ]