Comments 36
Всем прекрасен RUP, одно но — цикл «проектирование» — «UML-спеки» — «кодирование» крайне длителен и неповоротлив; и в случае, если рахитекторы профакапили хотя бы одну итерацию, выдав кривой дизайн, 80% можно считать, что продукт не выйдет в срок.
Ну а так как все предусмотреть невозможно, в RUP приходится или брать архитекторов за космические деньги, или хз… привыкать и терпеть, наверное :)
Ну а так как все предусмотреть невозможно, в RUP приходится или брать архитекторов за космические деньги, или хз… привыкать и терпеть, наверное :)
Я не хочу преуменьшать заслуги разработчиков, тестировщиков и других ролей, но архитекторы — это 80% успеха проекта.
И да, они стоят очень дорого и при этом экономят массу времени тестировщикам, разработчикам и деньги заказчика. Т.ч. заплатить 100К архитектору и 30К всем остальным — будьте уверены, продукт получится качественый и выйдет в срок (если взять за основу идеальную ситуацию).
И да, они стоят очень дорого и при этом экономят массу времени тестировщикам, разработчикам и деньги заказчика. Т.ч. заплатить 100К архитектору и 30К всем остальным — будьте уверены, продукт получится качественый и выйдет в срок (если взять за основу идеальную ситуацию).
Я об этом и говорю ) У нас было соотношение ~~ 250К против 30-40К :)
Впрочем, существует противоположная точка зрения — минимум формализма при разработке, откуда растут ноги Agile. Опираясь на мнение Брукса, я могу сказать, что и сам пока не готов ответить, какой подход эффективнее для среднего по размерам проекта. Вероятно, профессионал сможет заставить проект «взлететь» в любом подходе — только управление рисками будет кардинально отличаться.
BTW, крупные проекты (100К ч/часов) только так и решаются — Agile из-за своих обильных коммуникаций «каждый с каждым» здесь сливает.
Впрочем, существует противоположная точка зрения — минимум формализма при разработке, откуда растут ноги Agile. Опираясь на мнение Брукса, я могу сказать, что и сам пока не готов ответить, какой подход эффективнее для среднего по размерам проекта. Вероятно, профессионал сможет заставить проект «взлететь» в любом подходе — только управление рисками будет кардинально отличаться.
BTW, крупные проекты (100К ч/часов) только так и решаются — Agile из-за своих обильных коммуникаций «каждый с каждым» здесь сливает.
Не понял, как коммуникации «каждый с каждым» влияют на успех Agile в крупных проектах
Будуемдумать, что это вопрос, и вы ждете ответа.
Крупному проекту соответствует крупный штат разработчиков — начиная с 30-50 чел. одних и более. В такой ситуации:
а) в Agile возникает слишком много малоэффективных коммуникаций, чтобы оставалось время еще и на работу — тут более естественна специализация по принципу роли «архитектор» — «кодер» — «сопровождение» и т.п. А для того, чтобы управлять «слоистой» командой, мало плана «на пальцах», типа скрам-бэклога — приходится подходить более формально. Малоэффективных — потому что задействованы слишком много, чтобы можно было с пользой пообщаться в форме диалога.
б) по сравнению с scrum-командой в 3 человека, где опоздание на пару дней одной команды решается так: «сместим фокус-фактор в следующей, а в этой дожмем, благо пару дней всего», в большой команде это — потерянный человеко-месяц, что крайне недопустимо. Это еще одна причина большей формализации процесса.
Крупному проекту соответствует крупный штат разработчиков — начиная с 30-50 чел. одних и более. В такой ситуации:
а) в Agile возникает слишком много малоэффективных коммуникаций, чтобы оставалось время еще и на работу — тут более естественна специализация по принципу роли «архитектор» — «кодер» — «сопровождение» и т.п. А для того, чтобы управлять «слоистой» командой, мало плана «на пальцах», типа скрам-бэклога — приходится подходить более формально. Малоэффективных — потому что задействованы слишком много, чтобы можно было с пользой пообщаться в форме диалога.
б) по сравнению с scrum-командой в 3 человека, где опоздание на пару дней одной команды решается так: «сместим фокус-фактор в следующей, а в этой дожмем, благо пару дней всего», в большой команде это — потерянный человеко-месяц, что крайне недопустимо. Это еще одна причина большей формализации процесса.
Да, это был вопрос.
Я не развиваю холивар, я просто довольно недавно начал свое знакомство с Agile и хотел бы разобраться.
В моем понимании, Agile вообще и Scrum в частности хорошо масштабируются. Я даже где-то читал, что Yahoo! успешно использовали Scrum на проекте в 700 разработчиков. И способствуют этому несколько специальных техник (Scrum of scrums, компонентные команды, участие архитектора в роли Product owner'а). И это не только устраняет недостатки, но и дает преимущества перед «слоистой командой».
По моему мнению большая «слоистость» и формализация делают команду неповоротливой. Любые факапы на ранних этапах и изменения требований на поздних стоят очень дорого.
Я не развиваю холивар, я просто довольно недавно начал свое знакомство с Agile и хотел бы разобраться.
В моем понимании, Agile вообще и Scrum в частности хорошо масштабируются. Я даже где-то читал, что Yahoo! успешно использовали Scrum на проекте в 700 разработчиков. И способствуют этому несколько специальных техник (Scrum of scrums, компонентные команды, участие архитектора в роли Product owner'а). И это не только устраняет недостатки, но и дает преимущества перед «слоистой командой».
По моему мнению большая «слоистость» и формализация делают команду неповоротливой. Любые факапы на ранних этапах и изменения требований на поздних стоят очень дорого.
мой бывший архитектор так напридумывал, что сайт еле крутится…
да, опытный архитектор — это 80% успеха
да, опытный архитектор — это 80% успеха
«Проектирование» отнюдь не эквивалентно «проектирование при помощи UML». Кроме того, большинство проектов куда как сильнее зависит от фазы «анализ предметной области и создание ТЗ». Людям, которые способны проектировать большие и сложные системы, данная статья не нужна. А остальным надо рассказывать о другом и по-другому.
Великолепная программа, которая обрастает костылями делает это из-за криворуких кодеров на поддержке, либо из-за кривой изначально архитектуры. Отсутствие документации далеко не самая важная причина.
Ладно, не буду дальше придираться к мелочам (а это можно сделать). Лучше спрошу: какова была цель написания статьи?
Много умных мыслей, красиво оформленные рисунки, но вот я никак не могу представить себе реального применения тому, что тут написано.
Конкретно об UML можно было написать куда как лучше и предметнее.
Единственным реальным примером применения всех этих диаграмм, возможно, будет работа на государство, когда тупые дяденьки и тетеньки просят кучу бумажек, которые потом никому нафиг не нужны.
Вы, случаем, не лектор в ВУЗе?
ЗЫ: Хватит экономить на работниках! Программист, который может, если припрет, и в архитектуру залезть, и заказчику письмицо написать, и покритиковать что-либо, будет в ~10 раз более производителен «кодера». А стоить будет не сильно дороже.
ЗЗЫ: Прошу прощения за корявый комментарий. Мыслей много, а выразить их все в одном комментарии тяжело.
Великолепная программа, которая обрастает костылями делает это из-за криворуких кодеров на поддержке, либо из-за кривой изначально архитектуры. Отсутствие документации далеко не самая важная причина.
Ладно, не буду дальше придираться к мелочам (а это можно сделать). Лучше спрошу: какова была цель написания статьи?
Много умных мыслей, красиво оформленные рисунки, но вот я никак не могу представить себе реального применения тому, что тут написано.
Конкретно об UML можно было написать куда как лучше и предметнее.
Единственным реальным примером применения всех этих диаграмм, возможно, будет работа на государство, когда тупые дяденьки и тетеньки просят кучу бумажек, которые потом никому нафиг не нужны.
Вы, случаем, не лектор в ВУЗе?
ЗЫ: Хватит экономить на работниках! Программист, который может, если припрет, и в архитектуру залезть, и заказчику письмицо написать, и покритиковать что-либо, будет в ~10 раз более производителен «кодера». А стоить будет не сильно дороже.
ЗЗЫ: Прошу прощения за корявый комментарий. Мыслей много, а выразить их все в одном комментарии тяжело.
>>Ладно, не буду дальше придираться к мелочам (а это можно сделать). Лучше спрошу: какова была цель написания статьи?
Цель статьи показать что такой подход суеществует и в определенных условиях эффективен. Можно все разложить в голове по полочкам и не забыть не один пункт из тз — что кстати может поставить под угрозу всю работу.
>>А стоить будет не сильно дороже.
Не соглашусь, как раз на порядок дороже. Зарплата архиектора может а 5 раз превыышать зарплату кодера.
>>А остальным надо рассказывать о другом и по-другому.
Статья не несет практической пользы — только теоритическую, а так же расширяет кругозор.
Цель статьи показать что такой подход суеществует и в определенных условиях эффективен. Можно все разложить в голове по полочкам и не забыть не один пункт из тз — что кстати может поставить под угрозу всю работу.
>>А стоить будет не сильно дороже.
Не соглашусь, как раз на порядок дороже. Зарплата архиектора может а 5 раз превыышать зарплату кодера.
>>А остальным надо рассказывать о другом и по-другому.
Статья не несет практической пользы — только теоритическую, а так же расширяет кругозор.
Я говорю просто о толковых программистах, которые еще не доросли до архитекторов. Таких тоже хватает. И именно из таких, возможно, и вырастают эти самые архитекторы. Так вот у них запросы по з/п не будут большими.
А вот кодеры за 25-30к рублей — это ужасно. Качество кода у них такое, что заставляет серьезно задуматься об экономической эффективности их найма.
> Статья не несет практической пользы — только теоритическую
Теоретическую? Какую именно? Что UML можно использовать при описании любых процессов? Стоило ли при этом писать статью о проектировании?
А вот кодеры за 25-30к рублей — это ужасно. Качество кода у них такое, что заставляет серьезно задуматься об экономической эффективности их найма.
> Статья не несет практической пользы — только теоритическую
Теоретическую? Какую именно? Что UML можно использовать при описании любых процессов? Стоило ли при этом писать статью о проектировании?
согл с цитатой:
>>Статья не несет практической пользы — только теоретическую
>Теоретическую? Какую именно? Что UML можно использовать при
>описании любых процессов? Стоило ли при этом писать статью о >проектировании?
с одной стороны были продекламированны книжные истины RUP
большинство из которых в реальных проектах мало используются.
статья имела бы реальную ценность, если бы был бы рассмотрен на примере конкретный проект с конкретными диаграммами.
>>Статья не несет практической пользы — только теоретическую
>Теоретическую? Какую именно? Что UML можно использовать при
>описании любых процессов? Стоило ли при этом писать статью о >проектировании?
с одной стороны были продекламированны книжные истины RUP
большинство из которых в реальных проектах мало используются.
статья имела бы реальную ценность, если бы был бы рассмотрен на примере конкретный проект с конкретными диаграммами.
1. Программисты не должны лезть в архитектуру. Должны надеть украинскую повязку от гриппа и кодить, кодить и ещё раз кодить.
2. Письма заказчику должны писать Product manager'ы или QA
3. Тестировщики должны писать test case'ы и тестить
но, если уж совсем подпёрло, то можно и совмещать:
2. Письма заказчику должны писать Product manager'ы или QA
3. Тестировщики должны писать test case'ы и тестить
но, если уж совсем подпёрло, то можно и совмещать:
Программист, который не способен разобраться в архитектуре и, если надо, внести в нее изменения (пусть и с согласования), не будет работать качественно. Он также не будет работать продуктивно. Качество его кода будет ужасным.
Кроме того, архитектору нужна обратная связь. Абсолютно правых людей не бывает. Кто будет давать ему эту самую обратную связь?
QA тоже ничего не должен заказчику писать. Проблема в том, что часто бывает так, что просят «опиши это», а потом, быстро пробежавшись взглядом, пересылают заказчику.
Поймите, что вы говорите об огромных проектах. Таких мало. Очень мало. И рассказывать надо о таких не как о теории, а как об опыте Microsoft, к примеру.
Как думаете, насколько были бы успешны facebook, vkontakte, twitter и т.п., если бы следовали этим правилам неукоснительно?
Кроме того, архитектору нужна обратная связь. Абсолютно правых людей не бывает. Кто будет давать ему эту самую обратную связь?
QA тоже ничего не должен заказчику писать. Проблема в том, что часто бывает так, что просят «опиши это», а потом, быстро пробежавшись взглядом, пересылают заказчику.
Поймите, что вы говорите об огромных проектах. Таких мало. Очень мало. И рассказывать надо о таких не как о теории, а как об опыте Microsoft, к примеру.
Как думаете, насколько были бы успешны facebook, vkontakte, twitter и т.п., если бы следовали этим правилам неукоснительно?
Почему то в этом описании начисто забыты фазы тестирования. Между тем использование RUP — это одна из возможностей сделать «прозрачным» тестирование и обеспечение качества.
Спасибо, поправил
Неплохо было бы разделить процесс анализа и формирования ТЗ на бизнес анализ (вариантов использования, определения границ системы) и системный анализ.
Мы видимо на немножко разных языках говорим… Специально посмотрел в нескольких словарях, везде определение слова «утилизация» сводится к «использование ресурсов, не находящих прямого применения по назначению». А что вы подразумеваете под этим словом?
не соглашусь с последним утверждением — про только кодера.
Отлично, если у вас очень крутой архитектор, но в реальности — на кого попадете.
можете попасть на такого «профессионала», что выть будете. а если у профессионала еще 20 лет работы опыта и железобетонная увереность в своей правоте — удачи.
зачастую реализовывать то, что подсовывают — это самоубийство. он будет проектировать, он — программировать и все будет хорошо. так не бывает. не напишите вы хорошую программу с кодерами.
Отлично, если у вас очень крутой архитектор, но в реальности — на кого попадете.
можете попасть на такого «профессионала», что выть будете. а если у профессионала еще 20 лет работы опыта и железобетонная увереность в своей правоте — удачи.
зачастую реализовывать то, что подсовывают — это самоубийство. он будет проектировать, он — программировать и все будет хорошо. так не бывает. не напишите вы хорошую программу с кодерами.
>>Отлично, если у вас очень крутой архитектор, но в реальности — на кого попадете.
У нас крутой =)
>>не напишите вы хорошую программу с кодерами
Кодер — это человек который не только синтаксис знает, вы преувеличиваете
У нас крутой =)
>>не напишите вы хорошую программу с кодерами
Кодер — это человек который не только синтаксис знает, вы преувеличиваете
я только сказал, что с кодерами вы программу не напишите, а про то, что кодер — это человек, который только синтаксис знает — я такого не говорил, это вы напидумывали. по вашему кодер
>> НЕ должен общаться с заказчиком, НЕ должен задумываться об архитектуре системы, не должен изобретать интерфейс к программе, он только должен кодировать – реализовывать алгоритмы, функционал, внешний вид, юзабилити, но не более…
разработчик, который не задумывется об архитектуре — это плохой разработчик — кодер.
а если бы был плохой? вы бы реализовывали 3 wrapper класса для одного поля, которое содержит одно поле String id?
Я видел столько проектов, которые загибались из-за архитекторов… и все были с космическими зарплатами.
Если проект в стиле абсолтной монархии — это огромные риски, сосредоточенные на одном человеке. анархия — еще хуже.
конституционная монархия — наш выбор :)
на самом деле — это два взгляда на проблемму управления проектами. есть 2 отличные книги -«Человеческий фактор» и «Мифический человекомесяц».
ваше мнение очень странное, если вы сам — программист. или вы архитектор? все равно странно. может вы заказчик?
в любом случае мне вас не переубедить.
но я думаю, вы поменяете свое мнение на этот счет со временем.
>> НЕ должен общаться с заказчиком, НЕ должен задумываться об архитектуре системы, не должен изобретать интерфейс к программе, он только должен кодировать – реализовывать алгоритмы, функционал, внешний вид, юзабилити, но не более…
разработчик, который не задумывется об архитектуре — это плохой разработчик — кодер.
а если бы был плохой? вы бы реализовывали 3 wrapper класса для одного поля, которое содержит одно поле String id?
Я видел столько проектов, которые загибались из-за архитекторов… и все были с космическими зарплатами.
Если проект в стиле абсолтной монархии — это огромные риски, сосредоточенные на одном человеке. анархия — еще хуже.
конституционная монархия — наш выбор :)
на самом деле — это два взгляда на проблемму управления проектами. есть 2 отличные книги -«Человеческий фактор» и «Мифический человекомесяц».
ваше мнение очень странное, если вы сам — программист. или вы архитектор? все равно странно. может вы заказчик?
в любом случае мне вас не переубедить.
но я думаю, вы поменяете свое мнение на этот счет со временем.
вы это в реальной жизни пробовали?
причем, когда заказчик новые хотелки на ходу придумывает.
хотелось бы увидеть статью, в которой описывалось бы создание и развитие реальной системы, а не сферической в вакууме.
причем, когда заказчик новые хотелки на ходу придумывает.
хотелось бы увидеть статью, в которой описывалось бы создание и развитие реальной системы, а не сферической в вакууме.
договор заключается и пишется техзадание, заказчик не может с бухтыбарахты изменить требования находу,
новые поделки — это приложение к договору, тоесть все капризы за ваши деньги =) — для этого и надо максимально формализовать чтобы было меньше мисандестендинга
новые поделки — это приложение к договору, тоесть все капризы за ваши деньги =) — для этого и надо максимально формализовать чтобы было меньше мисандестендинга
Да-да-да. Это вы веб студиям расскажите.
В 90% случаев заказчик понятия не имеет, чего хочет. И не будет, пока не получит готовую систему и не начнет ее пользовать.
Был бы заказчиком, ни за что не пошел бы туда, где вытягивают все требования в начале, дают подписать а потом размахивают этой бумажкой каждый раз когда требования уточняются/меняются.
Был бы заказчиком, ни за что не пошел бы туда, где вытягивают все требования в начале, дают подписать а потом размахивают этой бумажкой каждый раз когда требования уточняются/меняются.
>>90% случаев заказчик понятия не имеет
Откуда взята информация?
>>Был бы заказчиком, ни за что не пошел бы туда, где вытягивают все требования в начале
С другой стороны ведь можно сказать: «Был бы исполнителем, ни за что бы не имел дело с теми кто меняет всои требования каждый день и при отсутствии формальной доказательной базы», но в целом вы правы
Откуда взята информация?
>>Был бы заказчиком, ни за что не пошел бы туда, где вытягивают все требования в начале
С другой стороны ведь можно сказать: «Был бы исполнителем, ни за что бы не имел дело с теми кто меняет всои требования каждый день и при отсутствии формальной доказательной базы», но в целом вы правы
мне кажется у вас не очень много опыта, раз вы так говорите. без обид. тысячу раз пройдено, написанно в умных книжках и прочее: «Никогда разработка проекта не идет, как задумывалось».
и я говорю не только о веб-студиях, но и о огромных многомиллионных системах. есть такие умники — вы только кодеры… не бывает такого. это, извините — идиотизм.
и я говорю не только о веб-студиях, но и о огромных многомиллионных системах. есть такие умники — вы только кодеры… не бывает такого. это, извините — идиотизм.
Это и есть развитие реальной системы. Без грамотной документации оно превращается в головную боль. Даже хорошие разработчики через полгода забывают что и как они сделали. И в этом нет ничего необычного и неверного. Не говоря уже о ситуации со сменой разработчиков. Поддерживать системы с документацией на тяп-ляп — это ужасно. Сначала проводишь реверс-инженеринг, строишь все диаграммы, создаешь тест-лабу… И все это лишние затраты времени и денег.
Статью не читал. В чем мораль этого копипаста?
А не могли бы Вы раскрыть для кого и для чего составляются эти диаграммы?
Цель какова?
Цель? Шоб було?
Цель какова?
Цель? Шоб було?
Забавно в 2013, когда на дворе сплошной agile читать этот самоуверенный бред.
Sign up to leave a comment.
Проектирование программного обеспечения