Заранее извиняюсь, если не в тот форум влез, но, по-моему, вопрос достаточно близок к тематике форума.
Необходимо написать программу, обладающую некоторыми возможностями А и Б.
У каждой возможности есть несколько шагов развития, так сказать.
На примере работы с файлами:
1. Открытие файла с заданным в коде именем, лежащем в каталоге программы в удобном для программиста формате.
2. Открытие файла с любым именем и любым путем к нему.
3. Поддержка существующих форматов файлов.
4. Не только открытие, но и сохранение данных в файл.
и т.д..
Хочется распланировать развитие программы заранее. Я примерно представляю какими возможностями должна обладать программа в конце разработки.
Вопрос в том как разнести реализацию этих возможностей по версиям. Т.е. какие возможности и на каком уровне должны быть в версии 1.0, 2.0 и т.д.?
Существуют ли какие-то общепринятые методики в этом вопросе? Может быть, какие-то книги?
Здравствуйте, Ilias, Вы писали:
I>Заранее извиняюсь, если не в тот форум влез, но, по-моему, вопрос достаточно близок к тематике форума.
I>Необходимо написать программу, обладающую некоторыми возможностями А и Б. I>У каждой возможности есть несколько шагов развития, так сказать. I>На примере работы с файлами: I>1. Открытие файла с заданным в коде именем, лежащем в каталоге программы в удобном для программиста формате. I>2. Открытие файла с любым именем и любым путем к нему. I>3. Поддержка существующих форматов файлов. I>4. Не только открытие, но и сохранение данных в файл. I>и т.д..
I>Хочется распланировать развитие программы заранее. Я примерно представляю какими возможностями должна обладать программа в конце разработки. I>Вопрос в том как разнести реализацию этих возможностей по версиям. Т.е. какие возможности и на каком уровне должны быть в версии 1.0, 2.0 и т.д.?
I>Существуют ли какие-то общепринятые методики в этом вопросе? Может быть, какие-то книги?
Фантазировать не надо. На реализацию всех фич деньги даёт заказчик, и ему они собственно и нужны.
Надо просто у него спросить, что ему надо в первую очередь, а без чего он может пока прожить.
Менеджер, а уж тем более программисты, не должны решать такие вопросы.
Главное, что бы заказчик был адекватный и понимал, что всё и сразу он не получит. Надо что бы он понимал, что каждая фича будет ему стоить, что такое ROI и TTV.
Если же заказчик неадекватный или разработка по инициативе фирмы, то здесь
я приводил ссылку на статью, где похожий вопрос рассматривается (правда там немного на другом уровне), хотя, конечно, как исчёрпывающий источник его рассматривать не стоит.
Принцип такой: для каждой фичи надо оценить следующие параметры:
— полученное в результате реализации biznis-value
— "видимость" этой фичи для заказчика
— стоимость
— риск
— измеримость результата приносимого фичей
— время на реализацию
Далее, исходя из этих результатов, уже можно сформировать какой-то комплексный коэффициент "полезности" фич, и на его основе составить план.
Рецепт такой: вначале реализуем фичи, которые приносят
— максимальную пользу для заказчика (biznis-value)
— максимальную "видимость" для заказчика
— имеют минимальную стоимость
— имеют минимальный риск
— результат фичи может быть измерен
— минимальное время на реализацию
R>Если же заказчик неадекватный или разработка по инициативе фирмы, то
Тут как раз такой случай — по инициативе фирмы.
R>Принцип такой: для каждой фичи надо оценить следующие параметры: R>- полученное в результате реализации biznis-value R>- "видимость" этой фичи для заказчика R>- стоимость R>- риск R>- измеримость результата приносимого фичей R>- время на реализацию
Откуда я узнаю первые два пункта, если заказчика ещё нет? Да и вообще, если у программы только одна фича, то и вариант использования только один, а если их несколько, то и вариантов использования может быть множество и не понятно, как именно ее будет использовать тот или иной пользователь.
Здравствуйте, Ilias, Вы писали:
R>>Если же заказчик неадекватный или разработка по инициативе фирмы, то
I>Тут как раз такой случай — по инициативе фирмы.
R>>Принцип такой: для каждой фичи надо оценить следующие параметры: R>>- полученное в результате реализации biznis-value R>>- "видимость" этой фичи для заказчика R>>- стоимость R>>- риск R>>- измеримость результата приносимого фичей R>>- время на реализацию
I>Откуда я узнаю первые два пункта, если заказчика ещё нет? Да и вообще, если у программы только одна фича, то и вариант использования только один, а если их несколько, то и вариантов использования может быть множество и не понятно, как именно ее будет использовать тот или иной пользователь.
Пока ты с этим не определишься, всё равно никуда не двинешься. Не знаешь, значит надо исследовать, анализировать и оценивать.
Что значит, непонятно как пользователь будет использовать фичу? Её что можно использовать принципиально разными способами. Обычно фичу можно использовать именно так как её задумали разработчики. Ну, например, интересно услышать разные варианты использования инструмента "кисть" в графическом редакторе, или варинаты использования фичи "сохранить в файл".
Пока твой вопрос выглядит примерно так: "У нас есть две фичи Х и Y, про которые ничего не известно. Скажите какую из них реализовывать первой?". Пока ты о них не узнаешь принципиальные моменты, ничего решить будет нельзя.
Пример. Графический редактор. Есть 2 фичи: инструмент-прямая линия и инструмент кривая линия 3 порядка.
Оцениваем:
— полученное в результате реализации biznis-value
у прямой линии value больше, т.к. без неё мало что нарисуешь.
— "видимость" этой фичи для заказчика
считаем одинакого
Но опять же подчёркиваю, по всем пунктам тебе надо будет определиться самому. Если ты это не сделаешь, то никто это не сделает и никакие книги не помогут.
Здравствуйте, Ilias, Вы писали:
I>Необходимо написать программу, обладающую некоторыми возможностями А и Б. I>У каждой возможности есть несколько шагов развития, так сказать. I>На примере работы с файлами: I>1. Открытие файла с заданным в коде именем, лежащем в каталоге программы в удобном для программиста формате. I>2. Открытие файла с любым именем и любым путем к нему. I>3. Поддержка существующих форматов файлов. I>4. Не только открытие, но и сохранение данных в файл. I>и т.д..
I>Хочется распланировать развитие программы заранее. Я примерно представляю какими возможностями должна обладать программа в конце разработки. I>Вопрос в том как разнести реализацию этих возможностей по версиям. Т.е. какие возможности и на каком уровне должны быть в версии 1.0, 2.0 и т.д.? I>Существуют ли какие-то общепринятые методики в этом вопросе? Может быть, какие-то книги?
I>Я примерно представляю какими возможностями должна обладать программа в конце разработки.
Есть методы разработки программ "фича за фичей". Т.е. делать не сильно отличающиеся версии 1.0, 2.0 и т.д., а много внутренних полностью или почти полностью готовых версий. Таким образом сделав первую фичу и пощупав её руками, легче определить какая именно следующая фича была бы наиболее важна и полезна. При таком подходе, выпустить новую публичную версию можено практически в любой момент.
I>>Откуда я узнаю первые два пункта, если заказчика ещё нет? Да и вообще, если у программы только одна фича, то и вариант использования только один, а если их несколько, то и вариантов использования может быть множество и не понятно, как именно ее будет использовать тот или иной пользователь.
R>Пока ты с этим не определишься, всё равно никуда не двинешься. Не знаешь, значит надо исследовать, анализировать и оценивать.
R>Что значит, непонятно как пользователь будет использовать фичу? Её что можно использовать принципиально разными способами. Обычно фичу можно использовать именно так как её задумали разработчики. Ну, например, интересно услышать разные варианты использования инструмента "кисть" в графическом редакторе, или варинаты использования фичи "сохранить в файл".
То и значит — не понятно. Как можно использовать фичу набора текста в ворде? Можно объявления печатать в три строчки, а можно книги писать мегабайтные. Есть разница?
R>Пока твой вопрос выглядит примерно так: "У нас есть две фичи Х и Y, про которые ничего не известно. Скажите какую из них реализовывать первой?". Пока ты о них не узнаешь принципиальные моменты, ничего решить будет нельзя.
Нет. Не так. Он звучит так: "у меня есть две фичи, про которые я знаю как они будут работать в конце, но не знаю, какая из них будет ценнее для пользователя".
R>Пример. Графический редактор. Есть 2 фичи: инструмент-прямая линия и инструмент кривая линия 3 порядка.
А куда пример с кистью делся? Её как раз можно использовать по-разному. Один будет пытаться фотографии ретушировать и для этого ему будут нужны всякие хитрые режимы наложения, прозрачности и т.д., а другой — иконки рисовать и ему будет нужен простейший вариант — квадратная кисть размером в точку.
R>Но опять же подчёркиваю, по всем пунктам тебе надо будет определиться самому. Если ты это не сделаешь, то никто это не сделает и никакие книги не помогут.
Несомненно. Я не просил проделать за меня оценку. Я просил указать методики. Ты какую-то свою указал, но пока критики она особо не выдерживает.
Здравствуйте, _doctor, Вы писали: I>>Я примерно представляю какими возможностями должна обладать программа в конце разработки. _>Есть методы разработки программ "фича за фичей". Т.е. делать не сильно отличающиеся версии 1.0, 2.0 и т.д., а много внутренних полностью или почти полностью готовых версий. Таким образом сделав первую фичу и пощупав её руками, легче определить какая именно следующая фича была бы наиболее важна и полезна. При таком подходе, выпустить новую публичную версию можено практически в любой момент.
Т.е. брать одну фичу и реализовывать ее всё глубже и подробнее? А после того, как она будет реализована до конца — начинать с нуля другую?
_>Далее см. agile methods
Про agile methods слышал и сейчас запомнил. А есть какие-то альтернативы?
Здравствуйте, Ilias, Вы писали:
I>Т.е. брать одну фичу и реализовывать ее всё глубже и подробнее? А после того, как она будет реализована до конца — начинать с нуля другую?
Не просто одну, а наиболее необходимую в текущий момент и по возможности достаточно небольшую, для реализации за обозримое время (слишком большие фичи делить на мелкие). После её реализации, смотреть, что наиболее важно в текущий момент и начинать наиболее важное. Таким образом когда бы не понадобилось выпускать публичную версию, у вас всегда будет наиболее полное возможное к текущему сроку решение.
Разумеется, такой подход накладывает некоторые архитектурные требования. Например, при добавлении новой фичи, довольно высока вероятность изменений структуры приложения. Следовательно заметно большую ценность приобретает тестирование (особенно юнит-тесты) и архитектура устойчивая к изменениям (с низкой связностью).
_>>Далее см. agile methods I>Про agile methods слышал и сейчас запомнил. А есть какие-то альтернативы?
Альтернативы agile-методам мне известны две:
— code&fix того, на что ляжет глаз. На самом деле в случае всего одного-двух разработчиков, небольшого проекта и хорошего понимания того, зачем нужен продукт, это — может быть вполне рабочим методом;
— разновидности waterfall с предварительным анализом требований (читай: ваша разбивка фич по версиям и выяснение того, что именно должны эти фичи делать), проектированием системы, кодированием, тестированием и исправлением.
Альтернативы внутри agile-методов:
Самые известные — Scrum, XP
Популярный на rsdn — RUP. Но это не столько метод, сколько framework для построения своего метода. Так что начинать с него, я бы не советовал
Менее известные — например, разновидности Crystal
Здравствуйте, Lucker, Вы писали:
I>>Несомненно. Я не просил проделать за меня оценку. Я просил указать методики. Ты какую-то свою указал, но пока критики она особо не выдерживает.
L>Люблю задавать этот вопрос: а вам шашечки или ехать?
Здравствуйте, _doctor, Вы писали:
_>Здравствуйте, Ilias, Вы писали:
_>Не просто одну, а наиболее необходимую в текущий момент и по возможности достаточно небольшую, для реализации за обозримое время (слишком большие фичи делить на мелкие). После её реализации, смотреть, что наиболее важно в текущий момент и начинать наиболее важное. Таким образом когда бы не понадобилось выпускать публичную версию, у вас всегда будет наиболее полное возможное к текущему сроку решение.
_>Разумеется, такой подход накладывает некоторые архитектурные требования. Например, при добавлении новой фичи, довольно высока вероятность изменений структуры приложения. Следовательно заметно большую ценность приобретает тестирование (особенно юнит-тесты) и архитектура устойчивая к изменениям (с низкой связностью).
Я, в принципе, и собирался примерно так делать. Вопрос в том, что программа разрабатывается без конкретного заказчика, тсскзать, "на будущее" и потому я могу с трудом прикинуть какая из фич будет наиболее необходима сначала, а какая — потом.
Тесты собираюсь писать с самого начала, но есть сложность — программа связана с GUI и не особо понятно как ее работу можно тестировать автоматически. Но пробовать как-то буду.
_>>>Далее см. agile methods I>>Про agile methods слышал и сейчас запомнил. А есть какие-то альтернативы? _>Альтернативы agile-методам мне известны две: _>- code&fix того, на что ляжет глаз. На самом деле в случае всего одного-двух разработчиков, небольшого проекта и хорошего понимания того, зачем нужен продукт, это — может быть вполне рабочим методом;
Да, вполне может, но я и задумался о чем-то другом, потому что обычно так и писал и через некоторое время программа в какую-то хрень превращалась бессистемную. Хочется порядка и распланированного развития.
_>- разновидности waterfall с предварительным анализом требований (читай: ваша разбивка фич по версиям и выяснение того, что именно должны эти фичи делать), проектированием системы, кодированием, тестированием и исправлением.
_>Альтернативы внутри agile-методов: _>Самые известные — Scrum, XP _>Популярный на rsdn — RUP. Но это не столько метод, сколько framework для построения своего метода. Так что начинать с него, я бы не советовал _>Менее известные — например, разновидности Crystal
Здравствуйте, Ilias, Вы писали:
_>>Разумеется, такой подход накладывает некоторые архитектурные требования. Например, при добавлении новой фичи, довольно высока вероятность изменений структуры приложения. Следовательно заметно большую ценность приобретает тестирование (особенно юнит-тесты) и архитектура устойчивая к изменениям (с низкой связностью).
I>Я, в принципе, и собирался примерно так делать. Вопрос в том, что программа разрабатывается без конкретного заказчика, тсскзать, "на будущее" и потому я могу с трудом прикинуть какая из фич будет наиболее необходима сначала, а какая — потом.
Именно поэтому не стоит стоить слишком обширных планов сразу. Большое планирование при недостатке понимания может обернуться большим пшиком. Именно в ситуации слабого понимания требований полезно делать одну-две фичи и смотреть на реакцию хотя бы потенциальных клиентов (себя, родственников, друзей, скачивающий бесплатную trial-версию и т.д.)
I>Тесты собираюсь писать с самого начала, но есть сложность — программа связана с GUI и не особо понятно как ее работу можно тестировать автоматически. Но пробовать как-то буду.
Вот с чем действительно стоит разобраться перед началом проекта, так это с тем что-такое юнит-, функциональные, системымные тесты и зачем они нужны. Попробуйте начать с книги Мартина Фаулера Refactoring. Гуй тестировать автоматически очень сложно, а вот строить программу так, чтобы с гуем не было связано слишком много вполне можно. В той же книге Фаулера есть хороший пример. Не помню как именно он называется. Что-то вроде UI-duplication. Вспомню — напишу.
_>>Альтернативы agile-методам мне известны две: _>>- code&fix того, на что ляжет глаз. На самом деле в случае всего одного-двух разработчиков, небольшого проекта и хорошего понимания того, зачем нужен продукт, это — может быть вполне рабочим методом;
I>Да, вполне может, но я и задумался о чем-то другом, потому что обычно так и писал и через некоторое время программа в какую-то хрень превращалась бессистемную. Хочется порядка и распланированного развития.
На самом деле в случае всего одного-двух разработчиков, небольшого проекта и хорошего понимания того..
Здравствуйте, Ilias, Вы писали:
I>Здравствуйте, _doctor, Вы писали:
_>>Здравствуйте, Ilias, Вы писали:
_>>Не просто одну, а наиболее необходимую в текущий момент и по возможности достаточно небольшую, для реализации за обозримое время (слишком большие фичи делить на мелкие). После её реализации, смотреть, что наиболее важно в текущий момент и начинать наиболее важное. Таким образом когда бы не понадобилось выпускать публичную версию, у вас всегда будет наиболее полное возможное к текущему сроку решение.
_>>Разумеется, такой подход накладывает некоторые архитектурные требования. Например, при добавлении новой фичи, довольно высока вероятность изменений структуры приложения. Следовательно заметно большую ценность приобретает тестирование (особенно юнит-тесты) и архитектура устойчивая к изменениям (с низкой связностью).
I>Я, в принципе, и собирался примерно так делать. Вопрос в том, что программа разрабатывается без конкретного заказчика, тсскзать, "на будущее" и потому я могу с трудом прикинуть какая из фич будет наиболее необходима сначала, а какая — потом.
Исходя из простой логики, создание программы происходит в результате желание упростить какую либо деятельность конечного пользователя. А раз так, необходимо как можно лучше изучить то как работает пользователь сейчас, чтобы понять что улучшить.
IMHO полагая что пользователя сейчас нету, пишем продук на будущее, неизвестно какие приориты у фич является следствием отсутствие анализа целевой предметной области. И поэтому больше похоже на рулетку в казино.
Полагаю что эффективней будет смоделировать\анализировать прикладную область на основе ее тенденции развития (пусть даже с виртуальными пользователями) — понять суть работы конечных пользователей. Это даст видиние того что можно улучшить в их работе путем автоматизации с помощью нашей программы. Как резальтат мы получим набор фич по приоритетам. I>Тесты собираюсь писать с самого начала, но есть сложность — программа связана с GUI и не особо понятно как ее работу можно тестировать автоматически. Но пробовать как-то буду.
Ну как же, есть инструменты тестирования интерфейса. в Rational есть. Также WinRunner.
PS: выглядит идеально, но это единственный путь уменьшить риск создания мертворожденной программы
Здравствуйте, _doctor, Вы писали:
_>Здравствуйте, Ilias, Вы писали:
_>>>Разумеется, такой подход накладывает некоторые архитектурные требования. Например, при добавлении новой фичи, довольно высока вероятность изменений структуры приложения. Следовательно заметно большую ценность приобретает тестирование (особенно юнит-тесты) и архитектура устойчивая к изменениям (с низкой связностью).
I>>Я, в принципе, и собирался примерно так делать. Вопрос в том, что программа разрабатывается без конкретного заказчика, тсскзать, "на будущее" и потому я могу с трудом прикинуть какая из фич будет наиболее необходима сначала, а какая — потом. _>Именно поэтому не стоит стоить слишком обширных планов сразу. Большое планирование при недостатке понимания может обернуться большим пшиком. Именно в ситуации слабого понимания требований полезно делать одну-две фичи и смотреть на реакцию хотя бы потенциальных клиентов (себя, родственников, друзей, скачивающий бесплатную trial-версию и т.д.)
Могу порекомендовать сделать, как делают крупные компании — надо уже найти клиента/клиентов, которые согласятся "тестировать" предварительные версии и высказывать замечания/предложения, возможно за возможность потом бесплатно получить коммерческую версию, или хотя бы за скидку.
Microsoft, например, выкладывает все предварительные версии на веб-сайт — пожалуйста пользуйтесь бесплатно, заодно присылайте баг репорты и отзывы Конечно, если менее известная компания выложит продукт на сайт это врядли чем обернётся, поэтому придётся проявить больше активности.
Тогда вопросы по поводу порядка реализации фич отпадут сами собой. Иначе нет никакой гарантии, что фичи не то что реализованы в правильном порядке, а то, что вообще это нужные фичи. И даже, что сам продукт-то нужный
Здравствуйте, Ilias, Вы писали:
I>Существуют ли какие-то общепринятые методики в этом вопросе? Может быть, какие-то книги?
Сперва рисуются use casesв которых описывается все что с этой программой можно делать. Пишется все, без всякой цензуры. Затем для первой версии отбирается минимальный набор кейзов, позволяющих работать с программой. Для следующих версий по приоритету, который определют пользователи. Естественно, что список юзкейзов будет постоянно пополняться.
Здравствуйте, _doctor, Вы писали:
_>Здравствуйте, Ilias, Вы писали:
I>>Я, в принципе, и собирался примерно так делать. Вопрос в том, что программа разрабатывается без конкретного заказчика, тсскзать, "на будущее" и потому я могу с трудом прикинуть какая из фич будет наиболее необходима сначала, а какая — потом. _>Именно поэтому не стоит стоить слишком обширных планов сразу. Большое планирование при недостатке понимания может обернуться большим пшиком. Именно в ситуации слабого понимания требований полезно делать одну-две фичи и смотреть на реакцию хотя бы потенциальных клиентов (себя, родственников, друзей, скачивающий бесплатную trial-версию и т.д.)
Штука в том, что программа планирует быть совсем маленькой в плане фич. Если смотреть как пример текстовый редактор, то это "поддержка формата А" и "поддержка формата Б". И всё. Дальше пока идей нет и вряд ли там что-то можно будет придумать сильно больше. Хочется понять процесс планирования разработки вообще на этом маленьком примере. Грубо говоря тут вопрос стоит так — разрабатывать ли по чуть-чуть поддержку каждого формата в каждой новой версии или сделать сначала один целиком, а потом второй целиком.
I>>Тесты собираюсь писать с самого начала, но есть сложность — программа связана с GUI и не особо понятно как ее работу можно тестировать автоматически. Но пробовать как-то буду. _>Вот с чем действительно стоит разобраться перед началом проекта, так это с тем что-такое юнит-, функциональные, системымные тесты и зачем они нужны. Попробуйте начать с книги Мартина Фаулера Refactoring. Гуй тестировать автоматически очень сложно, а вот строить программу так, чтобы с гуем не было связано слишком много вполне можно. В той же книге Фаулера есть хороший пример. Не помню как именно он называется. Что-то вроде UI-duplication. Вспомню — напишу.
Про тесты я читал Кента Бека test driven development и мне понравилось Потому и хочу их писать сразу же в процессе разработки.
Фаулера нашел, скачал, буду читать.
Здравствуйте, ADG, Вы писали:
I>>Я, в принципе, и собирался примерно так делать. Вопрос в том, что программа разрабатывается без конкретного заказчика, тсскзать, "на будущее" и потому я могу с трудом прикинуть какая из фич будет наиболее необходима сначала, а какая — потом. ADG>Исходя из простой логики, создание программы происходит в результате желание упростить какую либо деятельность конечного пользователя. А раз так, необходимо как можно лучше изучить то как работает пользователь сейчас, чтобы понять что улучшить. ADG>IMHO полагая что пользователя сейчас нету, пишем продук на будущее, неизвестно какие приориты у фич является следствием отсутствие анализа целевой предметной области. И поэтому больше похоже на рулетку в казино. ADG>Полагаю что эффективней будет смоделировать\анализировать прикладную область на основе ее тенденции развития (пусть даже с виртуальными пользователями) — понять суть работы конечных пользователей. Это даст видиние того что можно улучшить в их работе путем автоматизации с помощью нашей программы. Как резальтат мы получим набор фич по приоритетам.
В принципе, примерно это я уже сделал. Получилось, грубо говоря, что фича А чуть более востребована, чем фича Б. Вопрос в том как это теперь реализовывать? Сначала всю фичу А целиком, а потом всю фичу Б целиком, или обе сразу, но по чуть-чуть?
I>>Тесты собираюсь писать с самого начала, но есть сложность — программа связана с GUI и не особо понятно как ее работу можно тестировать автоматически. Но пробовать как-то буду. ADG>Ну как же, есть инструменты тестирования интерфейса. в Rational есть. Также WinRunner.
Буду смотреть, разбираться.
ADG>PS: выглядит идеально, но это единственный путь уменьшить риск создания мертворожденной программы
На самом деле очень разумные рассуждения. Спасибо большое за советы.
Здравствуйте, Miroff, Вы писали:
M>Здравствуйте, Ilias, Вы писали:
I>>Существуют ли какие-то общепринятые методики в этом вопросе? Может быть, какие-то книги? M>Сперва рисуются use casesв которых описывается все что с этой программой можно делать. Пишется все, без всякой цензуры. Затем для первой версии отбирается минимальный набор кейзов, позволяющих работать с программой. Для следующих версий по приоритету, который определют пользователи. Естественно, что список юзкейзов будет постоянно пополняться.
Хм. Интересный подход. Буду думать. Спасибо большое.
