Насколько четко определен программный продукт, прежде чем начинать кодировать?


13

Я хотел знать, насколько хорошо люди обычно определяют программный продукт перед тем, как начать программировать, и насколько хорошо он работает для них? Я имею в виду определение вариантов использования, анализ риска, рисование диаграмм классов и т. Д.

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

Другие более конкретные вопросы, вероятно, будут:

  1. Какой процент времени проекта обычно расходуется на этапах планирования до разработки?

  2. У вас есть определенные измеримые критерии, которым вы пытаетесь соответствовать, прежде чем начинать кодировать, или это более интуитивно?

  3. Вы рисуете все классы перед тем, как начинать кодировать, или в основном пытаетесь создать динамический дизайн с самого начала, ожидая, что все изменится?

Любой опыт, которым вы готовы поделиться, будет потрясающим!

Ответы:


10

Буквальный ответ на вопрос "насколько хорошо определен?" является

Хорошо определены, что вы можете начать.

Достаточно четко определены, чтобы вы могли определить начальный объем работы (для первоначальной концепции). Этого достаточно, чтобы помочь определить изменения, которые неизбежно произойдут.

Хорошо определены, что вы можете расставить приоритеты в спринтах.

Я имею в виду определение вариантов использования,

Всегда полезно. Но не все . Вы должны расставить приоритеты и охватить важные варианты использования в первую очередь. Другие варианты использования будут рассмотрены в последующих выпусках. Некоторые варианты использования будут иметь такой низкий приоритет, что они никогда не будут выполнены.

анализируя риск,

Вообще трата времени.

рисование диаграмм классов и т. д.

Если это поможет.

Какой процент времени проекта обычно расходуется на этапах планирования до разработки?

Это сильно варьируется. Купите хорошую книгу, например, Software Engineering Economics, чтобы получить «авторитетные» цифры.

У вас есть определенные измеримые критерии, которым вы пытаетесь соответствовать, прежде чем начинать кодировать, или это более интуитивно?

«Измеримое». Это почти невозможно определить.

«Кишки». Плохая политика

Вопрос в том, "понимаете ли вы, что делаете?"

Это не интуитивная вещь. Это вопрос да / нет.

Это не «измеримо», так как это просто вопрос да / нет.

И, далее, вы должны расставить приоритеты. Ты не все делаешь. Достаточно, чтобы справиться с первыми несколькими спринтами.

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

Вы не можете знать все заранее.

Не пытайся


лично я считаю, что тратить слишком много времени на написание диаграмм классов - пустая трата времени, так как модель и код с ней в любом случае меняются после вашего запуска.
AndersK

Я согласен, что вы не можете знать все заранее, но хороший проектный документ, по крайней мере, поможет вам определить область действия и особенности, когда это произойдет.
Тим Пост

@Tim Post: Хорошее предложение. Это способ определить, «насколько хорошо определены» в вопросе. Это «поможет вам определить область действия и особенности ползучести». Не намного больше, верно?
S.Lott

@Tim Post: «определить сферу» вводит в заблуждение. Это подразумевает, что в начале проекта вам доступны определенные знания о «объеме», что не соответствует действительности. Сфера действия будет меняться на протяжении всего жизненного цикла проекта по мере изменения потребностей бизнеса, поскольку ни один рынок не является статичным.
Рейн Хенрикс

@ Рейн Хенрикс: я немного подправил ответ, чтобы учесть твою точку зрения. Достаточно определения объема, чтобы начать. Я испытываю желание добавить «и не более».
S.Lott

2

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

Если ваш клиент находится далеко и не доступен для обратной связи в течение длительного периода времени, то ваша спецификация должна быть очень подробной.

В нашей компании мы создаем истории пользователей и играем в Planning Poker с разработчиками проекта. Это дает нам точное представление о часах, которые нужно потратить на историю пользователя.


«Представитель клиента» (роль, которую вы предлагаете для клиента) - это самая важная роль во всей команде. Если ваша команда не может получить ответы на вопросы по продукту и бизнесу, как они должны принять правильное решение?
Рейн Хенрикс

Это отличный момент, спасибо! Я не задумывался о том, как участие клиента может так радикально изменить то, что лучше всего подходит для данного проекта. Определенно то, что я должен иметь в виду. Кроме того, я никогда не слышал о «Planning Poker», и, похоже, это будет очень ценно.
drewag

2

Насколько четко определен проект, должно быть достаточно, чтобы вы начали и знали, куда вы собираетесь двигаться в течение следующих двух недель.

Как Scrum Master, я бы просто сказал, что вам нужно определить общие характеристики вашего продукта в листе Excel или где-то еще, только чтобы отслеживать ваши функции. Создание пользовательских историй помогает много думать о том, что вам нужно дальше. Затем расставьте приоритеты для них: «Важнейшая или обязательная особенность сверху» и «Наименее снизу».

После того, как вы перечислили некоторые из наиболее важных функций, выберите функции, которые, по вашему мнению, вы можете разработать, приведите их в состояние Готово через две недели или месяц, если вы предпочитаете. Затем, взорвите эти выбранные функции, чтобы вы могли начать кодирование в несколько.

При кодировании вы наверняка будете думать о других элементах, которые необходимо разработать, чтобы привести выбранные функции в состояние «Готово». Готово означает, что вам больше нечего делать, то есть тестирование, кодирование, сборка, документирование выполнено!

В любое время список выбранных вами функций может расширяться, если вы достигаете поставленной цели, то есть вы можете разрабатывать все, о чем вы говорили в течение данного периода.

Короче говоря, ничто не должно быть идеальным. Добавьте некоторые идеи, поделитесь с товарищами и посмотрите, имеет ли смысл то, что написано, чтобы удовлетворить требования требуемого продукта. Если это так, то вы в! Чтобы было понятно, я пойду с простым продуктом управления клиентами. Что нужно?

As a user, I may manage the Customers;
As a system, I persist changes to the underlying data store;
As a user, I need to enter my credentials to be able to manage customers;
As a system, I have to authenticate the user against the Active Directory;

Ваш первый черновик может быть таким простым! Затем мы видим, что безопасность является важной частью нашей системы, достаточно ли она важна, чтобы сделать конечный приоритет (Д / Н)? Это будет зависеть от требований, которым вы должны соответствовать. Допустим, что управление клиентами является наиболее важной вещью здесь. Итак, в следующем спринте мы должны быть в состоянии управлять клиентами простым, но приемлемым способом. Что такое управление клиентами?

As a user, I may manage Customers;
    -> As a user, I add a customer to the system;
    -> As a user, I change a customer details;
    -> As a user, I delete a customer;
    -> As a system, I flag a deleted customer as being inactive instead of deleting it;
    -> As a user, I need to list the customers;
    -> As a user, I search the customers data bank for a given customer;
    -> ...

Это уже иллюстрирует достаточные функциональные возможности, чтобы можно было начать разработку приложения. Если вашим программистам нужны дальнейшие инструкции, то, возможно, один разработчик, который знаком с диаграммами классов, может спроектировать класс Customer, его свойства и методы! Но, насколько я понимаю, с этими немногими, которые я написал, у меня будет достаточно, чтобы начать. Некоторые функции могут быть добавлены или изменены по пути. Важно сосредоточиться на том, что, как вы сказали, будет сделано. В нашем примере это вещь управления клиентами. На данный момент нам не нужно заботиться об аутентификации пользователей. Это будет позже в следующем спринте.

Надеюсь, это поможет! знак равно


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

Пожалуйста! Я рад, что мое зерно соли могло помочь вам! =) Важно не определять слишком подробные функции, поскольку требования к продукту могут меняться по ходу процесса, потому что у клиента, когда он увидит, что вы уже сделали, могут появиться другие идеи или изменения в том, что вы Выполнено. Вам нужно будет соответствующим образом настроить продукт, чтобы он соответствовал новым требованиям. Итак, если вы создали все сразу в начале проекта, представьте, что это может привести к потере работы! Возможно, вы потратили несколько часов, чтобы просто выбросить его и перезапустить с нуля. Пусть оно эволюционирует =)
Уилл Маркуиллер

1

Хорошо, что прекрасно работает для меня, это то, что функциональность «довольно хорошо» указана, а архитектура программного обеспечения очень слабо специфицирована.

Чтобы начать работать, мне нужно знать, над чем я работаю. Это не работает для меня, когда я просто понимаю потребности клиента. Даже если я пишу инструмент для собственного использования, я рисую экраны, описываю функциональность, что делает каждая кнопка, все. Иначе я не смогу начать.

С другой стороны, я разочаровался в том, чтобы действительно рисовать, как именно буду разрабатывать код. Может быть, это худшая практика, но она работает для меня. Я мог бы определить набор таблиц базы данных, которые я буду создавать, но не то, какие столбцы есть в каждой. Я мог бы подумать, какие объекты и классы мне нужны, но я определенно не рисую диаграммы.

Черт, иногда я даже не знаю, как сделать это правильно, пока я не сделал это неправильно. Я строю это однажды, срываю, и делаю это снова, теперь, когда я знаю как. На этом этапе я могу нарисовать довольно подробную дорожную карту и перезапустить.


Спасибо за обмен вашего опыта. Кажется, что это согласуется с консенсусом, что важно то, что вы, как разработчик, чувствуете себя достаточно комфортно, чтобы начать. Конечно, вы обнаружите, что изменили бы, если бы сделали это снова, иначе вы потратили слишком много времени на планирование. Я знаю чувство желания полностью переписать, как только продукт будет готов, и это своего рода то, чего я пытаюсь избежать;) (по крайней мере, в разумной степени).
drewag

1

Какой язык и методологию вы используете?

Некоторые языки, такие как Java и C ++, требуют большей исходной структуры, чем языки, такие как Common Lisp или Python (C ++ больше, чем Java, потому что рефакторинг проще в Java). Лео Броди (я думаю, что в «Thinking Forth») дал два совета о том, когда начинать кодирование: раньше, чем вам будет удобно в Forth, позже, чем вы хотите на другом языке.

Методология водопада (особенно когда ранний дизайн является результатом) потребует больше предварительной работы, чем гибкой (хотя вы и не хотите пренебрегать ранним планированием в гибких методах). Наличие хорошего набора автоматических тестов делает более безопасным изменение более крупных вещей и, следовательно, позволяет вам обходиться с меньшими затратами на предварительную работу.

Кроме того, это зависит от людей и их знания о типе программного обеспечения, которое будет создано. В какой-то момент, работая в основном с CRUD-приложениями, я мог написать целую программу, начиная с нескольких спецификаций и листа бумаги размером 3 x 5 дюймов. Я не могу написать то, что пишу сейчас, вот так.


Спасибо за перспективу. Я не думал, как язык и платформа могут повлиять на лучшие практики, когда дело доходит до управления проектами. Я говорю о Objective-C, UIKit и AppKit. Однако я также работаю на множестве других языков (C, C ++, C #, Java, Python и т. Д.). Это означает, что я должен быть осторожен, чтобы не предполагать, что определенный метод будет наилучшим для всех проектов, я должен настроить свою методологическую базу на целевой платформе и языке (и, возможно, выбрать язык, основанный на этом, если у меня есть выбор).
drewag

1

Здесь используются два полезных термина: MVP (минимальный жизнеспособный продукт) и MMF (минимальный товарный признак). MMF - это самая маленькая версия функции, которая обеспечивает ценность для бизнеса. MVP - это наименьшее количество MMF, которые являются жизнеспособными в качестве продукта. При запуске проекта лучше всего определить MMF и MVP и начать с этого.

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


Это действительно отличная терминология, спасибо! Это, безусловно, лучшая вещь для того, чтобы придумать что-то измеримое. Конечно, он не идеален, но кажется, что будет достаточно легко решить, является ли функция товарной и / или добавляет ли она ценность для продукта.
drewag
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.