| 1 2 3 4 5 6 7 |
| Re[3]: Хороший agile | |
 | От: | grosborn | |
| Дата: | 18.04.08 11:43 | ||
| Оценка: | 6 (1) | ||
| > G>Ткни пожалуйста пальцем, где роли и компетенции? Как они сюда вообще лягут? Я честно понять хочу, но не могу... > > Вроде как, процесс это не регламентирует. Ну вот и я так понял. Ты более внимательно разбирался, тебе верю — никто о них и не упоминает, обычное дело. > По крайней мере — не нашел. Это в принципе для меня даже хорошо — дает большую свободу, можно любую ролевую модель попробовать натянуть. Скажем — у меня особые взгляды на ролевые модели, я как раз не люблю когда методология на них акцентируется, лучше обязанности раздавать по месту и индивидуально ИМХО. > > Меня вот больше интересует, как это ляжет на процесс продуктовой разработки — когда надо выпоскать регулярные bugfix release и периодические major releases. В этом случае у тебя есть тестеры, девелоперы, и кастомер саппорт. Что мне пока кажется — design by feature отлично увязывается с исправлениями дефектов — а подружить эти два процесса и обрабатывать разработку с поддержкой единообразно — это очень большой плюс, я считаю. Но это надо проверить. Моё мнение — эта технология представляет собой отдельный взгляд из серии "вы садитесь вдоль этой стенки, а вы — по диагонали комнаты". К _организации_ реального процесса имеет отношение процентов на 10. Пониманию и улучшению уже существующего процесса может помогать. Но так же может и в сторону увести, поскольку не систематична, не самодостаточна, не сбалансирована. К слову сказать — я сам не зная этого определения работал примерно по такой схеме частенько. А что касается в частности четкого разделения на фичи, так это очень хорошо при уже налаженном процессе. И абсолютно смертельно такое сочетание на ранних этапах, когда ещё продукт есть по сути недоносок. Потребителю, который поработает с системой недофич 5 минут, кошмары будут сниться всю жизнь. И каждый раз он будет плеваться при упоминании имени компании, такое сделавшей. Это я как всегда преувеличиваю конечно, но доля шутки тут есть. Posted via RSDN NNTP Server 2.1 beta |
| Re[5]: Хороший agile | |
 | От: | B0rG | |
| Дата: | 18.04.08 11:50 |
| Здравствуйте, Gaperton, Вы писали: G>"Вода", которую вы пропустили: Гапертон, вы как никто другой должны знать, что процесс управления разработки софта состоит из 1) Resource Management 2) Workload Management 3) Ecosystem Management RM — это люди, программы железо и т.д., т.е. "чем мы делаем софт". WM — это фичлисты, приоритизация, "что мы делаем". EM — это юзеры, зазазчики, сейлы и т.д., "для кого мы делаем". Любая методология разработки софта (тм) так или иначе пытается сказать, 1 главнее чем 2, но 3 главнее чем оба, или же наоборот. Так же у методологии есть область применения (ос на agile). Остальное вечером, тут еще рабочий день в разгаре. |
| Re[4]: Хороший agile | |
| От: | grosborn | |
| Дата: | 18.04.08 11:50 |
| > S>Кадры решают все! > > Хотите поговорить о кадрах — ну откройте отдельную тему — кадры решают все, и все с вами дружно согласятся, в том числе и я. А пока — может о процессах поговорим, а?  Кадры решают все! В том смысле, что кадры должны быть учтены в описании процесса. Без этого всё — вода... Posted via RSDN NNTP Server 2.1 beta |
| Re[4]: Хороший agile | |
 | От: | shrecher | |
| Дата: | 18.04.08 11:51 |
| Здравствуйте, Gaperton, Вы писали: G>Здравствуйте, shrecher, Вы писали: S>>Кадры решают все! G>Хотите поговорить о кадрах — ну откройте отдельную тему — кадры решают все, и все с вами дружно согласятся, в том числе и я. А пока — может о процессах поговорим, а? Это как раз о процессах. Если кадры соответвуют поставленной задаче, то никакой процесс им не помеха. Точнее так, какой процесс им ненавижи, они все равно будут делать как им удобнее. А для неподходящих кадров, любой процесс самый модерновый процесс как мертвому припарка. |
| Re[3]: Хороший agile | |
| От: | grosborn | |
| Дата: | 18.04.08 11:56 |
| > Скажем — у меня особые взгляды на ролевые модели, я как раз не люблю когда методология на них акцентируется, лучше обязанности раздавать по месту и индивидуально ИМХО. А не опыт ли работы с заводскими инженерами заставляет тебя так действовать? Там действительно людей можно расставлять по разному, естественно несколько учитывая их способности. Posted via RSDN NNTP Server 2.1 beta |
| Re[5]: Хороший agile | |
 | От: | stump | |
| Дата: | 18.04.08 12:04 | ||
| Оценка: | 1 (1) +1 | ||
| Здравствуйте, Gaperton, Вы писали: 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. |
| Re[3]: Хороший agile | |
 | От: | RGB_Dart | |
| Дата: | 18.04.08 12:30 | ||
| Оценка: | 1 (1) +1 | ||
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 можно применять в любом случае — не взирая на методологию... |
| Re[3]: Хороший agile | |
 | От: | craft-brother | |
| Дата: | 18.04.08 13:20 |
| Здравствуйте, Gaperton, Вы писали: G>"Бизнес" был бы, если бы вы ответили содержательно. Я просил конкретной критики FDD. Рассуждения про "серебрянные пули" существования лучших способов и прочие общие слова мне малоинтересны. Этот ответ для меня совершенно бесполезен и оффтопичен. Ну, извини, ты первый начал…  Видимо, я был недостаточно убедителен в своем первом ответе. Подставь в свой начальный пост вместо FDD – «аспирин», а вместо Scrum и XP – «валерьянку» и «пурген», а вместо слова проект – «больной», и перечитай. G>«Я нашел легковесную методологию, которая не убьет проект, не противоречит здравому смыслу, и вполне жизнеспособна. [...] Более того — она мне нравится, и я ее рекомендую [...] Хороший процесс людям не нужен — им нужен в первую очередь простой процесс». Подставил? Перечитал? Людям нужен именно хороший процесс, который позволит им работать с наибольшей эффективностью, позволит решить свои проблеммы при наименьших затратах. А вовсе не простой процесс. Так вот, суть моего ответа заключалась в том, что пока ты не поставил больному диагноз, бессмысленно говорить о том, что "аспирин мне нравится, отговорите меня его применять". Применяй, если он лечит твоего больного, но рекомендовать его на все случаи жизни, ИМХО, не стоит. |
| Re[4]: Хороший agile | |
 | От: | Gaperton | |
| Дата: | 18.04.08 14:08 |
| Здравствуйте, 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 манифест кажется пустыми словами и балшытом. Мое личное мнение, конечно. Но декларировать можно все что угодно — хоть удекларируйся. |
| Re[4]: Хороший agile | |
| От: | Gaperton | |
| Дата: | 18.04.08 14:21 |
| Здравствуйте, grosborn, Вы писали: G>Ну вот и я так понял. Ты более внимательно разбирался, тебе верю — никто о них и не упоминает, обычное дело. Нет, пока я еще не разобрался. G>Моё мнение — эта технология представляет собой отдельный взгляд из серии "вы садитесь вдоль этой стенки, а вы — по диагонали комнаты". К _организации_ реального процесса имеет отношение процентов на 10. Пониманию и улучшению уже существующего процесса может помогать. Но так же может и в сторону увести, поскольку не систематична, не самодостаточна, не сбалансирована. Ну-ну-ну. Подождите суждения общего характера высказывать. По частностям не разобрались пока. В сторону увести может все что угодно. Была бы дурь в голове. Назовите метод, который не может в сторону увести принципиально, в конце концов. Ведь нет таких. Сложная самодостаточная методология вроде RUP — стройна на бумаге, но трудно внедрябельна и понимабельна из-за как раз своей излишней систематичности и монструозности. Что делать? Ладно, предлагаю с FDD разбераться сначала. Вы сказали — несистематична, не самодостаточно, не сбалансирована. Раскройте тему пожалуйста. Почему так? Аргументы плиз. Интересны не общие суждения, а конкретные указания на конкретные косяки. Были бы интересны суждения — я б опрос зарядил, а не дискуссию. G>К слову сказать — я сам не зная этого определения работал примерно по такой схеме частенько. По FDD? G>А что касается в частности четкого разделения на фичи, так это очень хорошо при уже налаженном процессе. И абсолютно смертельно такое сочетание на ранних этапах, когда ещё продукт есть по сути недоносок. Потребителю, который поработает с системой недофич 5 минут, кошмары будут сниться всю жизнь. И каждый раз он будет плеваться при упоминании имени компании, такое сделавшей. Это я как всегда преувеличиваю конечно, но доля шутки тут есть. Не соглашусь. Четкое разделение на фичи необходимо продукту и на ранней стадии, а чтобы недофичей не было то надо добавить к этим фичлистам управление приоритетами и рисками. За фичлисты же зацепляется и маркетинг — фичлист вообще является центральным связующим документом между маркетингом и разработкой при разработке продукта. Это как раз то, чего многие не понимают и от этого страдают. И это чрезвычайно правильно, что в FDD делается на фичлистах акцент. Причем — даже не важно, как конкретно они там устроены. Я все равно устрою фичлист так, как мне надо  . |
| Re[4]: Хороший agile | |
| От: | Gaperton | |
| Дата: | 18.04.08 14:23 |
| Здравствуйте, grosborn, Вы писали: >> Скажем — у меня особые взгляды на ролевые модели, я как раз не люблю когда методология на них акцентируется, лучше обязанности раздавать по месту и индивидуально ИМХО. G>А не опыт ли работы с заводскими инженерами заставляет тебя так действовать? G>Там действительно людей можно расставлять по разному, естественно несколько учитывая их способности. Жизнь заставляет. Я стараюсь учитывать сильные и слабые стороны людей индивидуально, а не подходить к ним с общей гребенкой. Люди от этого лучше мотивированы и продуктивнее работают. |
| Re[6]: Хороший agile | |
| От: | Gaperton | |
| Дата: | 18.04.08 14:30 | ||
| Оценка: | +1 -2 | ||
| Здравствуйте, B0rG, Вы писали: BG>Любая методология разработки софта (тм) так или иначе пытается сказать, 1 главнее чем 2, но 3 главнее чем оба, или же наоборот. Так же у методологии есть область применения (ос на agile). Дискуссия — это когда отвечают на посты друг друга. Вы — монологируете, не слушая меня. Вы удаляете весь мой пост, и ведете беседу сам с собой. Borg, я не просил вас рассказывать мне прописных истин. Мне совершенно не интересно выслушивать отвлеченные философские рассуждения базового уровня. И меня раздражает, когда в ответ на конкретные просьбы меня начинают учить жизни в духе урока для умственно отсталых детей. Сказать больше нечего чтоли? Неужели не можете косяков в процессах FDD найти? Все, философская дискуссия закрыта, уважаемый коллега. Я вам отвечать ничего не буду, монологируйте дальше. |
| Re[5]: Хороший agile | |
 | От: | Аноним 820 | |
| Дата: | 18.04.08 14:48 |
| Здравствуйте, Gaperton, Вы писали: G>Жизнь заставляет. Я стараюсь учитывать сильные и слабые стороны людей индивидуально, а не подходить к ним с общей гребенкой. Люди от этого лучше мотивированы и продуктивнее работают. Роль — это всего лишь шапка, а на кого ее нацепить — это всегда надо решать индивидуально, с учетом сильных и слабых сторон. |
| Re[6]: Хороший agile | |
| От: | Gaperton | |
| Дата: | 18.04.08 15:11 |
| Здравствуйте, stump, Вы писали: S>Здравствуйте, Gaperton, Вы писали: 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, и прочитав его описание. Интересно — я вообще в профильную конфу "управление пректами" написал — или случайно попал в "священные войны"? |
| Re[6]: Хороший agile | |
| От: | Gaperton | |
| Дата: | 18.04.08 15:13 |
| Здравствуйте, Аноним, Вы писали: G>>Жизнь заставляет. Я стараюсь учитывать сильные и слабые стороны людей индивидуально, а не подходить к ним с общей гребенкой. Люди от этого лучше мотивированы и продуктивнее работают. А>Роль — это всего лишь шапка, а на кого ее нацепить — это всегда надо решать индивидуально, А>с учетом сильных и слабых сторон. Я оперирую обязанностями и ответственностью, а не ролями. |
| Re[5]: Хороший agile | |
| От: | Gaperton | |
| Дата: | 18.04.08 15:15 |
| Здравствуйте, grosborn, Вы писали: >> Хотите поговорить о кадрах — ну откройте отдельную тему — кадры решают все, и все с вами дружно согласятся, в том числе и я. А пока — может о процессах поговорим, а? G>Кадры решают все! G>В том смысле, что кадры должны быть учтены в описании процесса. Как именно они должны быть учтены в описании процесса? Пример пожалуйста.G>Без этого всё — вода... О сколько нам открытий чудных. |
| Re[5]: Хороший agile | |
| От: | Gaperton | |
| Дата: | 18.04.08 15:18 |
| Здравствуйте, shrecher, Вы писали: G>>Хотите поговорить о кадрах — ну откройте отдельную тему — кадры решают все, и все с вами дружно согласятся, в том числе и я. А пока — может о процессах поговорим, а? S>Это как раз о процессах. Если кадры соответвуют поставленной задаче, то никакой процесс им не помеха. Точнее так, какой процесс им ненавижи, они все равно будут делать как им удобнее. А для неподходящих кадров, любой процесс самый модерновый процесс как мертвому припарка. Блин, ну просто кто во что горазд. По теме есть что сказать? Конкретные проблемы в подходе FDD найти можете, которые будут мешать разработке? |
| Re[4]: Хороший agile | |
| От: | Gaperton | |
| Дата: | 18.04.08 15:26 |
| Здравствуйте, craft-brother, Вы писали: CB>Так вот, суть моего ответа заключалась в том, что пока ты не поставил больному диагноз, бессмысленно говорить о том, что "аспирин мне нравится, отговорите меня его применять". Применяй, если он лечит твоего больного, но рекомендовать его на все случаи жизни, ИМХО, не стоит. На всякий случай напоминаю — я просил найти слабые стороны процесса FDD, а не выливать мне на уши тонны общих фраз. Суть твоего ответа заключалась в том, что ты не умеешь анализировать процесс разработки по его описанию, определять сильные и слабые стороны, и границы его применимости. Понятно. Посмотрим, что скажут другие. |
| Re[7]: Хороший agile | |
| От: | Аноним 820 | |
| Дата: | 18.04.08 15:26 |
| Здравствуйте, Gaperton, Вы писали: G>Здравствуйте, Аноним, Вы писали: G>>>Жизнь заставляет. Я стараюсь учитывать сильные и слабые стороны людей индивидуально, а не подходить к ним с общей гребенкой. Люди от этого лучше мотивированы и продуктивнее работают. А>>Роль — это всего лишь шапка, а на кого ее нацепить — это всегда надо решать индивидуально, А>>с учетом сильных и слабых сторон. G>Я оперирую обязанностями и ответственностью, а не ролями. Но ведь обязанности как-то классифицированны и сгруппированы? В общем не верю, что ты совсем не оперируешь ролями. Если я у тебя спрошу, а кто у тебя руководитель проекта, то ты наверняка ответишь. А иначе было бы очень странно... |
| Re[6]: Хороший agile | |
 | От: | COFF | |
| Дата: | 18.04.08 15:39 |
| Здравствуйте, Gaperton, Вы писали: G>Блин, ну просто кто во что горазд. По теме есть что сказать? Конкретные проблемы в подходе FDD найти можете, которые будут мешать разработке? Мне понравилось — особенно явный акцент на class ownership. Такое впечатление, что там много основано на здравом смысле и практическом опыте, а не на неких абстрактных размышлениях типа того, что если посадить двух программистов за один монитор, то они будут друг-за-другом надзирать и код получится идеальным. Может для абстрактных сферических программистов это и так, но ежу понятно, что два реальных человека поссорятся насмерть уже через пару недель такого плотного общения Вообще, мне кажется, что это правильная метода, надо будет изучить более подробно, спасибо за наводку |
| 1 2 3 4 5 6 7 |