> G>Ткни пожалуйста пальцем, где роли и компетенции? Как они сюда вообще лягут? Я честно понять хочу, но не могу... > > Вроде как, процесс это не регламентирует.
Ну вот и я так понял. Ты более внимательно разбирался, тебе верю — никто о них и не упоминает, обычное дело.
> По крайней мере — не нашел. Это в принципе для меня даже хорошо — дает большую свободу, можно любую ролевую модель попробовать натянуть. Скажем — у меня особые взгляды на ролевые модели, я как раз не люблю когда методология на них акцентируется, лучше обязанности раздавать по месту и индивидуально ИМХО. > > Меня вот больше интересует, как это ляжет на процесс продуктовой разработки — когда надо выпоскать регулярные bugfix release и периодические major releases. В этом случае у тебя есть тестеры, девелоперы, и кастомер саппорт. Что мне пока кажется — design by feature отлично увязывается с исправлениями дефектов — а подружить эти два процесса и обрабатывать разработку с поддержкой единообразно — это очень большой плюс, я считаю. Но это надо проверить.
Моё мнение — эта технология представляет собой отдельный взгляд из серии "вы садитесь вдоль этой стенки, а вы — по диагонали комнаты". К _организации_ реального процесса имеет отношение процентов на 10. Пониманию и улучшению уже существующего процесса может помогать. Но так же может и в сторону увести, поскольку не систематична, не самодостаточна, не сбалансирована.
К слову сказать — я сам не зная этого определения работал примерно по такой схеме частенько.
А что касается в частности четкого разделения на фичи, так это очень хорошо при уже налаженном процессе. И абсолютно смертельно такое сочетание на ранних этапах, когда ещё продукт есть по сути недоносок. Потребителю, который поработает с системой недофич 5 минут, кошмары будут сниться всю жизнь. И каждый раз он будет плеваться при упоминании имени компании, такое сделавшей. Это я как всегда преувеличиваю конечно, но доля шутки тут есть.
RM — это люди, программы железо и т.д., т.е. "чем мы делаем софт".
WM — это фичлисты, приоритизация, "что мы делаем".
EM — это юзеры, зазазчики, сейлы и т.д., "для кого мы делаем".
Любая методология разработки софта (тм) так или иначе пытается сказать, 1 главнее чем 2, но 3 главнее чем оба, или же наоборот. Так же у методологии есть область применения (ос на agile).
Остальное вечером, тут еще рабочий день в разгаре.
> S>Кадры решают все! > > Хотите поговорить о кадрах — ну откройте отдельную тему — кадры решают все, и все с вами дружно согласятся, в том числе и я. А пока — может о процессах поговорим, а?
Кадры решают все!
В том смысле, что кадры должны быть учтены в описании процесса.
Без этого всё — вода...
Здравствуйте, Gaperton, Вы писали:
G>Здравствуйте, shrecher, Вы писали:
S>>Кадры решают все!
G>Хотите поговорить о кадрах — ну откройте отдельную тему — кадры решают все, и все с вами дружно согласятся, в том числе и я. А пока — может о процессах поговорим, а?
Это как раз о процессах. Если кадры соответвуют поставленной задаче, то никакой процесс им не помеха. Точнее так, какой процесс им ненавижи, они все равно будут делать как им удобнее. А для неподходящих кадров, любой процесс самый модерновый процесс как мертвому припарка.
> Скажем — у меня особые взгляды на ролевые модели, я как раз не люблю когда методология на них акцентируется, лучше обязанности раздавать по месту и индивидуально ИМХО.
А не опыт ли работы с заводскими инженерами заставляет тебя так действовать?
Там действительно людей можно расставлять по разному, естественно несколько учитывая их способности.
Здравствуйте, Gaperton, Вы писали:
G>"Вода", которую вы пропустили: G>
G>Хороший процесс людям не нужен — им нужен в первую очередь простой процесс, который был бы лучше полного бардака и мало мальски преемлем. Сложные процессы хороши — но их тяжело заставить работать на практике. Поэтому легковесные процессы — это естественный запрос индустрии — она возжелала хоть худого, но порядка.
G>Не понятно? Могу пояснить. Ничего нового и революционного в легком процессе быть и не должно. Его единственное достоинство — легковесность и низкие затраты на внедрение и поддержание. Его единственный плюс — он не должен быть полным дерьмом, если он при легковесности дает результат "удовлетворительно", на троечку — это очень хороший легкий процесс.
У вас ложное представление об Agie процессах, как о слегка упорядоченном бардаке. Такое отношение понятно, поскольку, по вашим словам, вы сами в agile не работали.
Но agile это вовсе не слегка упорядоченный бардак. Это просто другой процесс, который базируется на другом типе жизненного цикла продукта и на других методах delivery (не знаю как подобрать адекватный русский термин). Все что на виду: спринты, игра в планирование, бэклоги, парное кодирование, это все внешние проявления,- суть инструменты.
G>Для справки — воды в моих сообщениях вообще немного. Если вы как следует прочитали мое сообщение — то поняли бы, что меня мало интересует революционность и новизна, и что удивлять вас революционностью я не собираюсь. Вы бы поняли, что я прошу вас половить fdd на предмет косяков, почитав про нее в википедии. Итак, по существу вопроса вы что-нибудь скажете? А то философия меня начинает утомлять, честно.
BG>>И самое главное выбор процесса и методологии должен зависеть от экосистемы, например никому не придет в голову разрабатывать ОС на Agile.
G>А что такое Agile? Я этого не понимаю. Что такое FDD, Scrum, и XP — понять могу. А раз я не понимаю что такое Agile — то мне кажется странным утверждение, почему никому не придет в голову разрабатывать ОС на Agile.
Вто то и дело что не понимаете. Различие в самом способе производства. Традиционный способ производства софта подобен производству любых других материальных ценностей. Вы приходите в ателье и заказываете костюм. С вас снимают мерки, и через неделю приглашают на примерку, устраняют недочеты и через пару дней вы забираете готовый костюм. Это класичесский водопад.
Но дело в том что софт — это не обычный материальный товар, а род абстракции. И с ним методы применяемые к материальному производству работают плохо. Зато работают методы, которые к материальному производству не применимы. Вы не можете прийти в ателье на следующий день после примерки, одеть и начать носить недошитый жилет. А портной все это время будет бегать вокруг вас и превращать жилет в полноценный пиджак. Это не возможно. А с софтом возможно. И это называется agile.
G>Вот кстати — при помощи какого процесса и методологии разрабатывается Linux по вашему? Охарактеризуйте его пожалуйста. Неужто тяжеленный MIL-STD-434367856-SOME-SHIT?
Если говорить о ядре Linux, то сейчас он разрабатывается по методологии Open Source.
RGB>>Мне вот было бы интересно пообщаться на тему "применения agile (FDD) в fixed price проектах". Ибо почитал тут Фаулера и он говорит что agile и fixed price вместе не живут . А так хочется...
G>О! Нашел пост делюки на эту тему. G>http://www.featuredrivendevelopment.com/node/527 G>FDD реально мало общего со скрамом имеет. И это хорошо. А Делюка мне определенно нравится — нормальный ответ, вижу — сработает, возражений нет никаких.
Вы это серьезно?!
Де Люка пишет, как "классно" можно прикинуть сроки. "Если за две недели мы разработали domain model, то конструирование займет 6 месяцев". Дальше в комментах пишет, что это НЕ человеко-месяцы. Охренеть просто .
Он на полном серьезе говорит о сроке разработки, открещиваясь от трудоемкости и говорит как классно узнать сроки (но не трудоемкость!) в самом начале проекта (после первых 3х активностей).
...
Почитал дальше камменты там Ему (Люку) народ на все это указал и выцепил нормальное соотношение ролей. На 1 бизнес-эксперта три chief programmers, и на каждого chief programmer 4 девелопера. Оттуда народ вывел пример расчетов трудоемкости и ждет подтверждения мыслей. Люка пока молчит .
З.Ы.
А вообще, прочитав все это — мне не очень понятно, почему FDD = agile? Если почитать agile manifesto (например перевод здесь), то там есть фраза типа
"Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage."
А в FDD мы feature list формируем заранее. Итеративными (как я понимаю) являются только фазы конструирования.
З.Ы.Ы. Ну а вообще, 90% agile manifesto можно применять в любом случае — не взирая на методологию...
Здравствуйте, Gaperton, Вы писали:
G>"Бизнес" был бы, если бы вы ответили содержательно. Я просил конкретной критики FDD. Рассуждения про "серебрянные пули" существования лучших способов и прочие общие слова мне малоинтересны. Этот ответ для меня совершенно бесполезен и оффтопичен.
Ну, извини, ты первый начал…
Видимо, я был недостаточно убедителен в своем первом ответе.
Подставь в свой начальный пост вместо FDD – «аспирин», а вместо Scrum и XP – «валерьянку» и «пурген», а вместо слова проект – «больной», и перечитай.
G>«Я нашел легковесную методологию, которая не убьет проект, не противоречит здравому смыслу, и вполне жизнеспособна. [...] Более того — она мне нравится, и я ее рекомендую [...] Хороший процесс людям не нужен — им нужен в первую очередь простой процесс».
Подставил? Перечитал?
Людям нужен именно хороший процесс, который позволит им работать с наибольшей эффективностью, позволит решить свои проблеммы при наименьших затратах. А вовсе не простой процесс.
Так вот, суть моего ответа заключалась в том, что пока ты не поставил больному диагноз, бессмысленно говорить о том, что "аспирин мне нравится, отговорите меня его применять". Применяй, если он лечит твоего больного, но рекомендовать его на все случаи жизни, ИМХО, не стоит.
Здравствуйте, RGB_Dart, Вы писали:
RGB>>>Мне вот было бы интересно пообщаться на тему "применения agile (FDD) в fixed price проектах". Ибо почитал тут Фаулера и он говорит что agile и fixed price вместе не живут . А так хочется...
G>>О! Нашел пост делюки на эту тему. G>>http://www.featuredrivendevelopment.com/node/527 G>>FDD реально мало общего со скрамом имеет. И это хорошо. А Делюка мне определенно нравится — нормальный ответ, вижу — сработает, возражений нет никаких.
RGB>Вы это серьезно?! RGB>Де Люка пишет, как "классно" можно прикинуть сроки. "Если за две недели мы разработали domain model, то конструирование займет 6 месяцев". Дальше в комментах пишет, что это НЕ человеко-месяцы. Охренеть просто . RGB>Он на полном серьезе говорит о сроке разработки, открещиваясь от трудоемкости и говорит как классно узнать сроки (но не трудоемкость!) в самом начале проекта (после первых 3х активностей).
Ну зачем так волноваться. Ну сказал Люка глупость, ну бывает. Я это при беглом просмотре пропустил — потому что искал в тексте другое. Предлагаю обратить на это другое внимание. Главное — что он предлагает сделать domain model две недели, и продать это задешево, а по итогам domain model выдать прогноз всего проекта. Это — правильно. У нас в этот момент будет достаточно информации, чтобы дать нормальный качественный прогноз трудозатрат.
И делать прогноз можно вовсе не таким дебильным образом, как умножение длительности первой фазы на пи. А по нормальному — с оценкой вариаций сроков, и проверкой через коридоры метрик. Это в сущности не так важно. Важно — что есть предварительное проектирование и предполагается планирование. Сама технология планирования — вторична, фундаментальным косяком не является. Для оценки трудозатрат можно что угодно применять. Я, например, в любом случае воспользуюсь своим методом оценки трудозатрат, он гораздо совершеннее, чем придумки агилистов.
RGB>Почитал дальше камменты там Ему (Люку) народ на все это указал и выцепил нормальное соотношение ролей. На 1 бизнес-эксперта три chief programmers, и на каждого chief programmer 4 девелопера. Оттуда народ вывел пример расчетов трудоемкости и ждет подтверждения мыслей. Люка пока молчит .
Это какой-то странный расчет. Я все равно по другому считаю, и буду дальше считать по своему — мнение Люка насчет оценки трудозатрат мне малоинтересно, я и так неплохо fixed cost умею оценивать. Главное — что я могу свой метод оценки вписать в процесс FDD — потому что там есть хорошее место, куда оценки можно вписать. А вот в скраме и XP это вписывать просто некуда.
RGB>З.Ы. RGB>А вообще, прочитав все это — мне не очень понятно, почему FDD = agile? Если почитать agile manifesto (например перевод здесь), то там есть фраза типа RGB>"Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage." RGB>А в FDD мы feature list формируем заранее. Итеративными (как я понимаю) являются только фазы конструирования.
Да, мне тоже это непонятно, что общего у FDD и типичных agile вроде scrum и XP. FDD — не имеет косяков agile — вы назвали один из них зацитировав манифест . FDD выглядит как облегченнная классика.
Думаю, надо перестать употреблять термин agile — это скорее маркетинговый термин, заменив его на "легковесный процесс". Потому, что FDD безусловно легковесный процесс. О чем, собственно, я в исходном посте написал.
RGB>З.Ы.Ы. Ну а вообще, 90% agile manifesto можно применять в любом случае — не взирая на методологию...
Ну, а мне этот agile манифест кажется пустыми словами и балшытом. Мое личное мнение, конечно. Но декларировать можно все что угодно — хоть удекларируйся.
Здравствуйте, grosborn, Вы писали:
G>Ну вот и я так понял. Ты более внимательно разбирался, тебе верю — никто о них и не упоминает, обычное дело.
Нет, пока я еще не разобрался.
G>Моё мнение — эта технология представляет собой отдельный взгляд из серии "вы садитесь вдоль этой стенки, а вы — по диагонали комнаты". К _организации_ реального процесса имеет отношение процентов на 10. Пониманию и улучшению уже существующего процесса может помогать. Но так же может и в сторону увести, поскольку не систематична, не самодостаточна, не сбалансирована.
Ну-ну-ну. Подождите суждения общего характера высказывать. По частностям не разобрались пока. В сторону увести может все что угодно. Была бы дурь в голове. Назовите метод, который не может в сторону увести принципиально, в конце концов. Ведь нет таких. Сложная самодостаточная методология вроде RUP — стройна на бумаге, но трудно внедрябельна и понимабельна из-за как раз своей излишней систематичности и монструозности. Что делать? Ладно, предлагаю с FDD разбераться сначала.
Вы сказали — несистематична, не самодостаточно, не сбалансирована. Раскройте тему пожалуйста. Почему так? Аргументы плиз. Интересны не общие суждения, а конкретные указания на конкретные косяки. Были бы интересны суждения — я б опрос зарядил, а не дискуссию.
G>К слову сказать — я сам не зная этого определения работал примерно по такой схеме частенько.
По FDD?
G>А что касается в частности четкого разделения на фичи, так это очень хорошо при уже налаженном процессе. И абсолютно смертельно такое сочетание на ранних этапах, когда ещё продукт есть по сути недоносок. Потребителю, который поработает с системой недофич 5 минут, кошмары будут сниться всю жизнь. И каждый раз он будет плеваться при упоминании имени компании, такое сделавшей. Это я как всегда преувеличиваю конечно, но доля шутки тут есть.
Не соглашусь. Четкое разделение на фичи необходимо продукту и на ранней стадии, а чтобы недофичей не было то надо добавить к этим фичлистам управление приоритетами и рисками. За фичлисты же зацепляется и маркетинг — фичлист вообще является центральным связующим документом между маркетингом и разработкой при разработке продукта. Это как раз то, чего многие не понимают и от этого страдают. И это чрезвычайно правильно, что в FDD делается на фичлистах акцент. Причем — даже не важно, как конкретно они там устроены. Я все равно устрою фичлист так, как мне надо .
Здравствуйте, grosborn, Вы писали:
>> Скажем — у меня особые взгляды на ролевые модели, я как раз не люблю когда методология на них акцентируется, лучше обязанности раздавать по месту и индивидуально ИМХО.
G>А не опыт ли работы с заводскими инженерами заставляет тебя так действовать? G>Там действительно людей можно расставлять по разному, естественно несколько учитывая их способности.
Жизнь заставляет. Я стараюсь учитывать сильные и слабые стороны людей индивидуально, а не подходить к ним с общей гребенкой. Люди от этого лучше мотивированы и продуктивнее работают.
Здравствуйте, B0rG, Вы писали:
BG>Любая методология разработки софта (тм) так или иначе пытается сказать, 1 главнее чем 2, но 3 главнее чем оба, или же наоборот. Так же у методологии есть область применения (ос на agile).
Дискуссия — это когда отвечают на посты друг друга. Вы — монологируете, не слушая меня. Вы удаляете весь мой пост, и ведете беседу сам с собой. Borg, я не просил вас рассказывать мне прописных истин. Мне совершенно не интересно выслушивать отвлеченные философские рассуждения базового уровня. И меня раздражает, когда в ответ на конкретные просьбы меня начинают учить жизни в духе урока для умственно отсталых детей. Сказать больше нечего чтоли? Неужели не можете косяков в процессах FDD найти? Все, философская дискуссия закрыта, уважаемый коллега. Я вам отвечать ничего не буду, монологируйте дальше.
Re[5]: Хороший agile
От:
Аноним
Дата:
18.04.08 15:48
Оценка:
Здравствуйте, Gaperton, Вы писали:
G>Жизнь заставляет. Я стараюсь учитывать сильные и слабые стороны людей индивидуально, а не подходить к ним с общей гребенкой. Люди от этого лучше мотивированы и продуктивнее работают.
Роль — это всего лишь шапка, а на кого ее нацепить — это всегда надо решать индивидуально,
с учетом сильных и слабых сторон.
Здравствуйте, stump, Вы писали:
S>Здравствуйте, Gaperton, Вы писали:
G>>"Вода", которую вы пропустили: G>>
G>>Хороший процесс людям не нужен — им нужен в первую очередь простой процесс, который был бы лучше полного бардака и мало мальски преемлем. Сложные процессы хороши — но их тяжело заставить работать на практике. Поэтому легковесные процессы — это естественный запрос индустрии — она возжелала хоть худого, но порядка.
G>>Не понятно? Могу пояснить. Ничего нового и революционного в легком процессе быть и не должно. Его единственное достоинство — легковесность и низкие затраты на внедрение и поддержание. Его единственный плюс — он не должен быть полным дерьмом, если он при легковесности дает результат "удовлетворительно", на троечку — это очень хороший легкий процесс.
S>У вас ложное представление об Agie процессах, как о слегка упорядоченном бардаке. Такое отношение понятно, поскольку, по вашим словам, вы сами в agile не работали.
У вас ложное представление о моих представлениях об Agile процессах. И вы не читали моего первого поста, а если читали — то не поняли. Странно.
G>>А что такое Agile? Я этого не понимаю. Что такое FDD, Scrum, и XP — понять могу. А раз я не понимаю что такое Agile — то мне кажется странным утверждение, почему никому не придет в голову разрабатывать ОС на Agile.
S>Вто то и дело что не понимаете.
Прошу вас воздержиться от подобных замечаний. Не надо меня злить.
S>Различие в самом способе производства. Традиционный способ производства софта подобен производству любых других материальных ценностей. Вы приходите в ателье и заказываете костюм. С вас снимают мерки, и через неделю приглашают на примерку, устраняют недочеты и через пару дней вы забираете готовый костюм. Это класичесский водопад. S>Но дело в том что софт — это не обычный материальный товар, а род абстракции. И с ним методы применяемые к материальному производству работают плохо. Зато работают методы, которые к материальному производству не применимы. Вы не можете прийти в ателье на следующий день после примерки, одеть и начать носить недошитый жилет. А портной все это время будет бегать вокруг вас и превращать жилет в полноценный пиджак. Это не возможно. А с софтом возможно. И это называется agile.
Это не объяснение, это хорошая сказка на ночь. Аналогия довольно наивна, и, наверное хорошо действует на людей, плохо разбирающихся в процессах разработки софта. Вероятно — именно так и впаривают agile.
G>>Вот кстати — при помощи какого процесса и методологии разрабатывается Linux по вашему? Охарактеризуйте его пожалуйста. Неужто тяжеленный MIL-STD-434367856-SOME-SHIT?
S>Если говорить о ядре Linux, то сейчас он разрабатывается по методологии Open Source.
Надо же, кто бы мог подумать? А я-то думал они работают по Closed Sourcе.
ЗЫ: сколько умных слов не по теме — кошмар, но почему-то никто не в состоянии ничего предметно сказать про FDD, и прочитав его описание. Интересно — я вообще в профильную конфу "управление пректами" написал — или случайно попал в "священные войны"?
Здравствуйте, Аноним, Вы писали:
G>>Жизнь заставляет. Я стараюсь учитывать сильные и слабые стороны людей индивидуально, а не подходить к ним с общей гребенкой. Люди от этого лучше мотивированы и продуктивнее работают.
А>Роль — это всего лишь шапка, а на кого ее нацепить — это всегда надо решать индивидуально, А>с учетом сильных и слабых сторон.
Я оперирую обязанностями и ответственностью, а не ролями.
Здравствуйте, grosborn, Вы писали:
>> Хотите поговорить о кадрах — ну откройте отдельную тему — кадры решают все, и все с вами дружно согласятся, в том числе и я. А пока — может о процессах поговорим, а?
G>Кадры решают все! G>В том смысле, что кадры должны быть учтены в описании процесса.
Как именно они должны быть учтены в описании процесса? Пример пожалуйста.
G>Без этого всё — вода...
О сколько нам открытий чудных.
Здравствуйте, shrecher, Вы писали:
G>>Хотите поговорить о кадрах — ну откройте отдельную тему — кадры решают все, и все с вами дружно согласятся, в том числе и я. А пока — может о процессах поговорим, а?
S>Это как раз о процессах. Если кадры соответвуют поставленной задаче, то никакой процесс им не помеха. Точнее так, какой процесс им ненавижи, они все равно будут делать как им удобнее. А для неподходящих кадров, любой процесс самый модерновый процесс как мертвому припарка.
Блин, ну просто кто во что горазд. По теме есть что сказать? Конкретные проблемы в подходе FDD найти можете, которые будут мешать разработке?
Здравствуйте, craft-brother, Вы писали:
CB>Так вот, суть моего ответа заключалась в том, что пока ты не поставил больному диагноз, бессмысленно говорить о том, что "аспирин мне нравится, отговорите меня его применять". Применяй, если он лечит твоего больного, но рекомендовать его на все случаи жизни, ИМХО, не стоит.
На всякий случай напоминаю — я просил найти слабые стороны процесса FDD, а не выливать мне на уши тонны общих фраз.
Суть твоего ответа заключалась в том, что ты не умеешь анализировать процесс разработки по его описанию, определять сильные и слабые стороны, и границы его применимости. Понятно. Посмотрим, что скажут другие.
Re[7]: Хороший agile
От:
Аноним
Дата:
18.04.08 16:26
Оценка:
Здравствуйте, Gaperton, Вы писали:
G>Здравствуйте, Аноним, Вы писали:
G>>>Жизнь заставляет. Я стараюсь учитывать сильные и слабые стороны людей индивидуально, а не подходить к ним с общей гребенкой. Люди от этого лучше мотивированы и продуктивнее работают.
А>>Роль — это всего лишь шапка, а на кого ее нацепить — это всегда надо решать индивидуально, А>>с учетом сильных и слабых сторон.
G>Я оперирую обязанностями и ответственностью, а не ролями.
Но ведь обязанности как-то классифицированны и сгруппированы?
В общем не верю, что ты совсем не оперируешь ролями.
Если я у тебя спрошу, а кто у тебя руководитель проекта, то ты наверняка ответишь.
А иначе было бы очень странно...
Здравствуйте, Gaperton, Вы писали:
G>Блин, ну просто кто во что горазд. По теме есть что сказать? Конкретные проблемы в подходе FDD найти можете, которые будут мешать разработке?
Мне понравилось — особенно явный акцент на class ownership. Такое впечатление, что там много основано на здравом смысле и практическом опыте, а не на неких абстрактных размышлениях типа того, что если посадить двух программистов за один монитор, то они будут друг-за-другом надзирать и код получится идеальным. Может для абстрактных сферических программистов это и так, но ежу понятно, что два реальных человека поссорятся насмерть уже через пару недель такого плотного общения Вообще, мне кажется, что это правильная метода, надо будет изучить более подробно, спасибо за наводку
. А так хочется...
.
