3361

xP Xd Agile ICONIX пр. / Agile and Iterations

« : 26 Декабря 2007, 16:25:34 »

Вот тут недавно поговорил с человеком, считающим себя экспертом Agile, и услышал такое мнение, что за итерацию Команда должна выпустить какую-то работающую ф-ть в продакшен.
Т.е. пройти все стадии от анализа до внедрения на продакшен за одну итерацию. Мне кажется это утопия для больших проектов и для начала любого проекта.
Я всегда представлял итерацию как набор каких-то тасков, кот. надо закрыть. Будь то аналитические таски, толи разработческие. Можно комбинировать несколько дисциплин, но все скомбенировать для большого проекта, а не по доработке багов, это мне кажется утопия.
Ближе к концу разработки мы можем этого добиться но не как не в начале или при доработке большого проекта!
Вы как думаете?

3362

Бизнес-анализ и Целеполагание / Re: Вопрос по "оригинальной методике бизнес моделирования" от автора Е.Б. Золоту

« : 26 Декабря 2007, 12:38:35 »

Эд,

Ну да одна под-глава не даст полного представления о том, что хотел сказать Коберн.
Всю главу можно прочесть здесь: http://alistair.cockburn.us/index.php/ASD_book_extract:_%22Unknowable_and_incommunicable%22
Просто до этого он рассказывает о том, что два человека, имеющих разный бэк-граунд, могут понять одни и то же предложение по разному. Поэтому, прежде чем начать разработку, надо всех участников погрузить в "domain", т.е. объяснить/рассказать предметную область. И чем ближе и дольше люди общаются, тем им меньше надо что-то писать, достаточно только сделать мазки, чтобы не забыть через месяц о чем кто-то хотел сказать.
И как раз мастерство аналитика - это:
"You need to discover how large a gap you can get by with at each moment, how much equivocality you can tolerate, and stop there."
"Вам надо понять - на сколько большие разрывы/шаги вы можете сделать в каждый конкретный момент, как много неоднозначности Вы можете допустить, и остановиться здесь"
Тут русские не причём, просто Коберн хотел показать, что для людей с другой культурой и без знания ПрОбл не возможно все описать, все равно будут недопонимания и двусмысленность.

3363

Управление Проектом / Re: Руководитель проекта, как им стать?

« : 26 Декабря 2007, 12:24:56 »

Ответ деньги - ИМХО  это тупиковая ветвь.
В любой профессии чтобы действительно преуспеть нужно иметь искренний интерес к ней.

p/s/   Средний РП получает меньше Хорошего Senior девелопера  ...
РП Сейчас много а разработчиков мало :-)

Никто не спорит, но:
1. Человеку не нравится программировать, значит он не станет "Хорошего Senior девелопера"
2. Пока не попробуешь, не поймешь. Или скорее даже так: если у человека есть качества, кот. должен обладать хор. МП, то ему это скорее всего понравится.
3. Естественно деньги не главное, но без этого никуда. Если человеку нравится заниматься научной работой, но за это не платят деньги, то ему приходится переквалифицироваться и, н-р, программировать. И кстати видел людей у кот. получилось хорошо переквалифицироваться, не потому что им это было тогда интересно, а п.ч. им надо было кушать, а потом и понравилось

3364

Управление Проектом / Re: Руководитель проекта, как им стать?

« : 26 Декабря 2007, 12:13:38 »

В данный момент, я читаю Фредерика Брукса, очень тяжело дается, иногда много раз главу перечитывать приходится, но интересно и занятно

Мне кстати книга не очень понравилась. Дочитал больше чем до половину и бросил.

Я не давно создал проект по развитию программы с открытым исходным кодом, думаю мне лишним не будет попытки в его развитии, вот ссылка . Может кому-то будет не лень дать рекомендации Подмигивающий

Добавил туда 3 задачи, кот. мне были бы интересны в данном проекте. Еще рекомендую посмотреть аналоги, чтобы добавить фичи, кот. нет у них.

3365

Бизнес-анализ и Целеполагание / Re: Вопрос по "оригинальной методике бизнес моделирования" от автора Е.Б. Золотухина

« : 25 Декабря 2007, 18:51:33 »

Ничего не понял

Эд, а ты всегда так читаешь англоязычную лит-ру??

3366

Проектирование / Re: Моделирование иерархической базы данных

« : 25 Декабря 2007, 17:12:17 »

Мы говорим о проекте автора или о проекции автора на существующие тулзы (например RequisitePro)?

Автор хотел комментов вот мы и сыпем, что на ум придет

3367

Управление Проектом / Re: Руководитель проекта, как им стать?

« : 25 Декабря 2007, 15:58:30 »

1. Почему Вы хотите стать РП , Что Вас привлекает в этой проффессии ? ( Аналогично вопросу Boatman )

Дима, а если ответ - деньги, ПМ можно элементарно больше зарабатывать, чем програмистом (возмем среднюю оценку). То человек не имеет право пойти в эту профессию? Другой вопрос есть ли у этого человека качества для ПМ и что человеку нужно узнать, чтобы стать ПМ?! И знает ли он чем придется заниматься там и сможет ли (опять же качества).

3368

Проектирование / Re: Моделирование иерархической базы данных

« : 25 Декабря 2007, 15:36:06 »

1. А я вообще не понял зачем тут группа? Нельзя просто требования связать в виде иерархии и привязать к Проекту?
2. А как мы бум трассировать требования?
3. Не понятно назначение RequirementPart? Это сам тесткс или ссылка место в тексте Requirement.Content? Если последнее, то м.б. оргнизовать как-то Requirement.Content в виде отдельных кусков?
4. Нужны атрибуты требований

Вообще, рекомендую посмотреть релизацию любого Wiki движка, там все есть для СУТ, надо только кое-что добавить, что спечифично для СУТ.

З.Ы. А вообще пора ФАК писать по ДК, а то сам уже забываю какие стрелочки куда идут и что обозначают

3369

Бизнес-анализ и Целеполагание / Re: Вопрос по "оригинальной методике бизнес моделирования" от автора Е.Б. Золоту

« : 25 Декабря 2007, 14:55:30 »

The Russian Programmers

A group in an American firm that was contracting their programming to a Russian company contacted me. They wanted me to teach them how to write use cases for Russian programmers who knew neither English nor the domain very well.

I said, "You can't hope to teach them the domain inside the requirements document. First teach them the domain, then write a short requirements document that speaks to someone knowledgeable in the domain."

After trying for hours to get me to reveal the secret of communicating across this enormous gap, they finally admitted they had previously (and successfully) worked simply by putting the key people in the same room. They were just hoping that I had a way to communicate the requirements across the ocean perfectly using use cases.

In the end, they improved on my suggestion. They wrote a short requirements document for their local domain experts and then flew one of those experts to Russia to translate, explain, and generally ensure that the programmers were doing the right thing.

The domain expert could jump the large gap presented by the short use case document and then produce, as needed, and only as needed, communication to fill in and reduce the size of the gaps so that the Russian programmers could jump across.

The domain expert did not attempt to communicate perfectly. He managed the continuous incompleteness of the communications by interacting with the programmers in person and watching what they produced. Luke Hohmann (1998) refers to this as "reducing the equivocality" in the communication.

What the domain expert understood was that he did not have to reduce the equivocality to zero. He only had to reduce it to the point that the Russian programmers could take meaningful action.

Given that complete communication is never possible, the task on a project is not to try for complete communication but to manage the incompleteness of our communications.

The target is to reduce equivocality enough for appropriate action to be taken. That means guessing how much is needed, where to stop, when and how to make the gaps smaller, and how to can help the receivers to jump larger gaps.

Software projects are short on time and money, and making the gap smaller costs both. You need to discover how large a gap you can get by with at each moment, how much equivocality you can tolerate, and stop there.

3370

Бизнес-анализ и Целеполагание / Re: Вопрос по "оригинальной методике бизнес моделирования" от автора Е.Б. Золоту

« : 24 Декабря 2007, 19:02:29 »

Вот тут недавно перечитывал свой пост, много дельных мыслей в нем высказано:
http://www.uml2.ru/forum/index.php?topic=71.0

Единственное, что можно сказать, что все приходит с опытом, сначала Вы метаетесь в поисках лучшего, а потом просто делаете, т.к. знаете что это правильно, т.е. модель адекватна.
А вообще сейчас моден Агиле, кот. говорит - минимум артефактов, максимум коммуникаций. Прочтите например Коберна, Agile Software Development, глава Russian Programmers, мне очень понравилось.

З.Ы. А вообще, Золотухина далеко не истина в последней инстанции.

3371

Управление Проектом / Re: Руководитель проекта, как им стать?

« : 22 Декабря 2007, 23:04:01 »

Давайте начнем с такого вопроса: Какими качествами должен облададать успешный ПМ? Не профессиоанльными, а общечеловеческими.

3372

Работа / Re: Наиболее продуктивные условия работы для аналитика

« : 21 Декабря 2007, 12:01:57 »

Кому надо могу дать почитать.

Андрей, это лучше запостить в теме Московский книжный клуб аналитиков

З.Ы. А вообще столько книг интересных, когда только читать

3373

Сообщество Аналитиков / Re: Составление сертификационных тестов для Аналитиков

« : 21 Декабря 2007, 11:59:45 »

ps: даже не представляю кому нужен будет 'базовый'

Это пока только первые мысли. Может вообще после обдумывания все кардинально изменится.

3374

Сообщество Аналитиков / Re: Составление сертификационных тестов для Аналитиков

« : 21 Декабря 2007, 11:58:40 »

Лучше сначала ознакомиться с аналогичными тестами (может они есть на brainbench?) ...

Естественно, бум брать везде.

уровень:  картинка + вопрос + выбор вариантов ответов?

Не понял. Если спрашивали на счет как будет построен вопрос, то примерно так. Так же можно сделать тесты по выполнению задания по моделированию и его проверку. Это надо смотреть.

3375

Обучение / Re: Опыт преподавания объектно-ориентированного подхода в моделировании, анализе

« : 20 Декабря 2007, 20:58:14 »

Виктор,

Так не обязательно в каникулы, можно и попозже. Главное чтобы было желание и не затягивалось оно на долго.