UI programming
27 отговора
1358 прегледа
UI programming
След като прегледах няколко размишления на една опен-соурс Линукс звезда (Eric Raymond) върху това колко е напреднал Линукс и софтуера под Линукс по отношение на usability:
[линк]
и особено след като прочетох избрани коментари на същите тези размишления:
[линк]
започнах да разбирам колко е подценено UI програмирането въобще. Бил съм свидетел много пъти - при започването на един проект веднага се почва да се говори за едни бази данни, за едни тредове, АПИ-та и всякакви такива безумни глупости вместо да се почне от най-естествената гледна точка - как ще изглежда всичко това за потребителя. Много пъти съм виждал как се хабят месеци програмиране, само за да се види, че при ползването на софтуер-а елементарни неща, които юзъра очаква, просто не могат да сработят поради сложните неща изписани отдолу и се налага пренаписване на половината код.
Защо е това подценяване? "Айде сега да напишем 'бизнес логиката' пък после там дизайнерите ще измислят някакъв интерфейс там ще нагласиме и студентчетата дето взимат 250лв ще драгват дропват гридове и текстбоксове във Студиото и да ги нагласят покрай нашата мега-велика бизнес логика".
Трябва да се почне точно по-обратния начин - най-добрите хора да измислят как ще изглежда софтуер за нормални юзъри и как те ще го използват безпроблемно, а после студентчетата да пишат разни класове там и бази данни и тредове и не знам си какви си глупости. UI програмирането е най-трудната част от програмирането въобще и подценяването му е катострофално.
Защо са изписани десетки супер сложни ОС с огромна функционалност, а само една-единствена от тях въобще може да се използва нормално (е айде, две, предполагам гейовете нямат проблеми с Маковете). Защото няма добри UI
програмисти (освен в Майкрософт). Няма, понеже UI програмирането се подценява супер много.
[линк]
и особено след като прочетох избрани коментари на същите тези размишления:
[линк]
започнах да разбирам колко е подценено UI програмирането въобще. Бил съм свидетел много пъти - при започването на един проект веднага се почва да се говори за едни бази данни, за едни тредове, АПИ-та и всякакви такива безумни глупости вместо да се почне от най-естествената гледна точка - как ще изглежда всичко това за потребителя. Много пъти съм виждал как се хабят месеци програмиране, само за да се види, че при ползването на софтуер-а елементарни неща, които юзъра очаква, просто не могат да сработят поради сложните неща изписани отдолу и се налага пренаписване на половината код.
Защо е това подценяване? "Айде сега да напишем 'бизнес логиката' пък после там дизайнерите ще измислят някакъв интерфейс там ще нагласиме и студентчетата дето взимат 250лв ще драгват дропват гридове и текстбоксове във Студиото и да ги нагласят покрай нашата мега-велика бизнес логика".
Трябва да се почне точно по-обратния начин - най-добрите хора да измислят как ще изглежда софтуер за нормални юзъри и как те ще го използват безпроблемно, а после студентчетата да пишат разни класове там и бази данни и тредове и не знам си какви си глупости. UI програмирането е най-трудната част от програмирането въобще и подценяването му е катострофално.
Защо са изписани десетки супер сложни ОС с огромна функционалност, а само една-единствена от тях въобще може да се използва нормално (е айде, две, предполагам гейовете нямат проблеми с Маковете). Защото няма добри UI
програмисти (освен в Майкрософт). Няма, понеже UI програмирането се подценява супер много.
Re: UI programming
UI проблема е само симптом според мен. Истинския проблем е липсата на комуникация по една или друга причина и изтърваването на дебелоперите да правят каквото им е кеф в момента или да не правят каквото могат най-добре от страх...
Вчера четох това. Направо пасва като по поръчка в темата
.
Ако практикувахме някаква форма на Business Value Driven Software Development - XP, SCRUM, Crystal Clear, каквото друго се сетите... UI проблема щеше да се вижда от самото начало от клиента и щеше да се оправя на секундата. Какво по-добро от това?
Момчетата от CUPS отбора явно страдат от много прост проблем - липса на метафора и цел на проекта. Да се отбележи - и аз съм се борил като прасе с тиква с глупавото им творение и не успях да направя нищо! А се занимавам с линукси от маса време и определено не съм баба дето се чуди как да си изпечата рецепта на Иван Звездев.
--
"Agile is a mindset, not a set of practices, rules, or tools."
Tom Poppendieck
Вчера четох това. Направо пасва като по поръчка в темата
.
Ако практикувахме някаква форма на Business Value Driven Software Development - XP, SCRUM, Crystal Clear, каквото друго се сетите... UI проблема щеше да се вижда от самото начало от клиента и щеше да се оправя на секундата. Какво по-добро от това?
Момчетата от CUPS отбора явно страдат от много прост проблем - липса на метафора и цел на проекта. Да се отбележи - и аз съм се борил като прасе с тиква с глупавото им творение и не успях да направя нищо! А се занимавам с линукси от маса време и определено не съм баба дето се чуди как да си изпечата рецепта на Иван Звездев.
--
"Agile is a mindset, not a set of practices, rules, or tools."
Tom Poppendieck
Re: UI programming
А добро утро... 
Иначе причината веднага мога да ти я кажа от собствен опит. Повечето хора в форума, включая и аз преди време сме правили проект по поръчка за някой конкретен клиент - класически аутсорсинг. В този случай интерфейса няма особено значение, той дори не се споменава в уточняванията на requirements, а после при деливеритата самия клиент се приспособява постепенно към бозите които му пробутваме. В по-изродени случаи те сами си казват какво във интерфейса и начина на работа не им харесва и програмистите го оправят в движение.
Когато правиш обаче масов продукт нещата стават съвсем други. Основната разлика е че нямаш пряк контакт с клиентите а те могат да са хиляди и със всякакъв манталитет и начин на работа. Тогава се работи по-скоро на сляпо, и се стремиш да е максимално подобрен и "usable" интерфейса - значение вече има всеки цвят, разположението на елементите, текста на всяко съобщение, дали да има такова или по-друг начин да се процедира. Правят се и тестове със случайни хора, дали успяват да се ориентират в продукта и да започнат "интуитивно" да работят с него и то с удоволствие... В този случай интерфейса отнема 80 процента от времето, и това е логично защото той до голяма степен продава продукта и има пряка връзка с това дали клиента ще го хареса или не.
Иначе причината веднага мога да ти я кажа от собствен опит. Повечето хора в форума, включая и аз преди време сме правили проект по поръчка за някой конкретен клиент - класически аутсорсинг. В този случай интерфейса няма особено значение, той дори не се споменава в уточняванията на requirements, а после при деливеритата самия клиент се приспособява постепенно към бозите които му пробутваме. В по-изродени случаи те сами си казват какво във интерфейса и начина на работа не им харесва и програмистите го оправят в движение.
Когато правиш обаче масов продукт нещата стават съвсем други. Основната разлика е че нямаш пряк контакт с клиентите а те могат да са хиляди и със всякакъв манталитет и начин на работа. Тогава се работи по-скоро на сляпо, и се стремиш да е максимално подобрен и "usable" интерфейса - значение вече има всеки цвят, разположението на елементите, текста на всяко съобщение, дали да има такова или по-друг начин да се процедира. Правят се и тестове със случайни хора, дали успяват да се ориентират в продукта и да започнат "интуитивно" да работят с него и то с удоволствие... В този случай интерфейса отнема 80 процента от времето, и това е логично защото той до голяма степен продава продукта и има пряка връзка с това дали клиента ще го хареса или не.
Баланс му е майката
И този баланс е различен за всеки проект.
Ако пишеш web-сървър, да речем, едва ли ще смяташ, че най-важното нещо на света е как да го нагласим. Защото кучета го яли този web-сървър, даже ако отгатва мислите ми как да се конфигурира, ако е бааавен или лош като сигурност.
Иначе съм напълно съгласен, че трябва да се мисли как продукта ще се използва. В противен случай става упражнение по абстрактно програмиране.
Но не съм склонен да го нарека потребителски интерфейс - ако измислиш подходяща схема за използване, почти все едно е дали до нея се стига с прекрасно GUI, или с прост конфигурационен файл.
Ако пишеш web-сървър, да речем, едва ли ще смяташ, че най-важното нещо на света е как да го нагласим. Защото кучета го яли този web-сървър, даже ако отгатва мислите ми как да се конфигурира, ако е бааавен или лош като сигурност.
Иначе съм напълно съгласен, че трябва да се мисли как продукта ще се използва. В противен случай става упражнение по абстрактно програмиране.
Но не съм склонен да го нарека потребителски интерфейс - ако измислиш подходяща схема за използване, почти все едно е дали до нея се стига с прекрасно GUI, или с прост конфигурационен файл.
Re: Баланс му е майката
Ами да, аз затова всъщност внимавах никъде да не пиша GUI - а само UI - user interface. Под user interface аз лично разбирам не непременно един диалог с чекобоксове и дропдауни, а по-скоро колко е удобно като цяло да се ползва продукта от крайният му потребител.
За някои продукти е безспорно, че примено е по-удобно да се конфигурират през конзолата. За някои през Уин интерфейс. Някои през приложение. Или сбор от трите метода - който е по-удобен за потребителя.
А между другото това, че администрирането на уеб-сървър е непременно по-добре да става с конзола и конфигурационни файлове - не съм съгласен. Най-малкото поради факта, че трябва да се учи странен синтаксис и вероятността за грешки е по-голяма. Вярно - администраторите на уеб-сървръри са професионалисти и само с това се занимават, но доста често се налага други хора да вършат по-елементарни неща като рестрикции/права за достъп, тогава интуитивен интерфейс е незаменим. Който иска по-добър контрол и да знае какво става на ниско ниво - да гледа отдолу.
Ще ти дам пример - в Апаче, за да зададеш дефоултна страница за директория, трябва да знаеш, че съществува .htaccess (hidden by default). Значи, за да го намериш този файл трябва и да знаеш да напишеш ls -la вместо само dir. След това трябва да знаеш и как е името на параметъра и чак тогава да го напишеш:
DirectoryIndex index.php
В IIS с мишката даваш Properties -> Documents -> Add Default Document и избираш от менюто index.php.
Сам разбираш, че при Апаче се изисква много повече време, четене и знания от ИИС за една и съща задачка. С ИИС можеш да се ориентираш сам за 0 време. Така че дори и при уеб-сървърите интерфейса помага и не трябва да го подценяваш.
За някои продукти е безспорно, че примено е по-удобно да се конфигурират през конзолата. За някои през Уин интерфейс. Някои през приложение. Или сбор от трите метода - който е по-удобен за потребителя.
А между другото това, че администрирането на уеб-сървър е непременно по-добре да става с конзола и конфигурационни файлове - не съм съгласен. Най-малкото поради факта, че трябва да се учи странен синтаксис и вероятността за грешки е по-голяма. Вярно - администраторите на уеб-сървръри са професионалисти и само с това се занимават, но доста често се налага други хора да вършат по-елементарни неща като рестрикции/права за достъп, тогава интуитивен интерфейс е незаменим. Който иска по-добър контрол и да знае какво става на ниско ниво - да гледа отдолу.
Ще ти дам пример - в Апаче, за да зададеш дефоултна страница за директория, трябва да знаеш, че съществува .htaccess (hidden by default). Значи, за да го намериш този файл трябва и да знаеш да напишеш ls -la вместо само dir. След това трябва да знаеш и как е името на параметъра и чак тогава да го напишеш:
DirectoryIndex index.php
В IIS с мишката даваш Properties -> Documents -> Add Default Document и избираш от менюто index.php.
Сам разбираш, че при Апаче се изисква много повече време, четене и знания от ИИС за една и съща задачка. С ИИС можеш да се ориентираш сам за 0 време. Така че дори и при уеб-сървърите интерфейса помага и не трябва да го подценяваш.
Re: Баланс му е майката
Може би двойния подход е най-добър. Сигурно има средства дето да ти изгенерират .хтаксес след като си нацъкал с мишката.
В един проект ми се наложи автоматично да генерирам на всеки deploy такъв .хтаксес. Не искам да ме спират ако пак ми се наложи.
--
"Agile is a mindset, not a set of practices, rules, or tools."
Tom Poppendieck
В един проект ми се наложи автоматично да генерирам на всеки deploy такъв .хтаксес. Не искам да ме спират ако пак ми се наложи.
--
"Agile is a mindset, not a set of practices, rules, or tools."
Tom Poppendieck
Нищо не трябва да се подценява.
Моят опит показва, че нищо не трябва да се подценява.
Бил съм в проект, където никой не разбира от БД и нормализация. Правил съм си тъшак да казвам, че 3-та нормална форма е като направиш дизайна на БД за трети път. :-)
Въпреки, че такова нещо като дизайн на БД няма. То си е строго научен, ако щеш матиматически процес, където няма място за въображение, а само знания и прилагането им.
Та в този случай 30% от проблемите идваха от БД. Ми тя не беше консистентна и вместо да се направи консистентна, се правеха едни скирптчета дето се даваха на клиента да проверяват дали данните са консистентни. Пълен ташак. Ама иди обяснявай на хора, дето нищо не разбират, кво е тва нормализация. Колкото и хубаво GUI да имаш, данните на екрана като не са вярни, просто клиента иска да ти го начука.
Като говорим за студентчета те като почнат да пишат спиране немат. Такива глупости съм виждал. Клас с едно поле и три метода - сетер, гетер и екуалс. :-)
Да не говорим, че са царе на копи&пастето. След тях изтриваш 2/3 кода и той пак си работи по същия начин. Е тва как се поддържа?
И още нещо. UI-то не се преподава във ВУЗ-овете. Или се застъпва много малко. Но IU-то може да го видиш от другите програми и да се научиш от тях, като копираш. Докато ДБ нормализации, ООП и пр. се преподават и то доста добре. И разбира се тях не можеш да ги видиш в кода, освен ако не ползваш Линукс. :-)
Бил съм в проект, където никой не разбира от БД и нормализация. Правил съм си тъшак да казвам, че 3-та нормална форма е като направиш дизайна на БД за трети път. :-)
Въпреки, че такова нещо като дизайн на БД няма. То си е строго научен, ако щеш матиматически процес, където няма място за въображение, а само знания и прилагането им.
Та в този случай 30% от проблемите идваха от БД. Ми тя не беше консистентна и вместо да се направи консистентна, се правеха едни скирптчета дето се даваха на клиента да проверяват дали данните са консистентни. Пълен ташак. Ама иди обяснявай на хора, дето нищо не разбират, кво е тва нормализация. Колкото и хубаво GUI да имаш, данните на екрана като не са вярни, просто клиента иска да ти го начука.
Като говорим за студентчета те като почнат да пишат спиране немат. Такива глупости съм виждал. Клас с едно поле и три метода - сетер, гетер и екуалс. :-)
Да не говорим, че са царе на копи&пастето. След тях изтриваш 2/3 кода и той пак си работи по същия начин. Е тва как се поддържа?
И още нещо. UI-то не се преподава във ВУЗ-овете. Или се застъпва много малко. Но IU-то може да го видиш от другите програми и да се научиш от тях, като копираш. Докато ДБ нормализации, ООП и пр. се преподават и то доста добре. И разбира се тях не можеш да ги видиш в кода, освен ако не ползваш Линукс. :-)
Re: Баланс му е майката
Ами де-факто ИИС работи точно като Апачето - има си една скрита директорийка и в текстови файлове подобно на .хтаккесс е зададено всичко - примерно директорията се казва "_vti_pvt" и вътре файлът service е с подобен формат:
...
vti_timecreated:TR|26 Jan 2004 12:00:16 -0000
vti_extenderversion:SR|4.0.2.6513
vti_longfilenames:IX|1
vti_welcomenames:VX|Default.htm Default.asp index.htm iisstart.asp Default.aspx
vti_insecureserverurl:SR|[линк]
vti_secureserverurl:SR|[линк]
...
Така че нищи не пречи да си го изгенерираш. През доста добрия графичен интерфейс нищо не пречи и на потребителите, които не знаят какво е "vti_welcomenames" да си администрират безпроблемно. Най-доброто от двата свята.
...
vti_timecreated:TR|26 Jan 2004 12:00:16 -0000
vti_extenderversion:SR|4.0.2.6513
vti_longfilenames:IX|1
vti_welcomenames:VX|Default.htm Default.asp index.htm iisstart.asp Default.aspx
vti_insecureserverurl:SR|[линк]
vti_secureserverurl:SR|[линк]
...
Така че нищи не пречи да си го изгенерираш. През доста добрия графичен интерфейс нищо не пречи и на потребителите, които не знаят какво е "vti_welcomenames" да си администрират безпроблемно. Най-доброто от двата свята.
Re: Нищо не трябва да се подценява.
Ами ти разбира се си прав, но това което казваш всъщност е по-добре да не се подценяват нещата, по-добре е всички хора по всички звена на проекта да се професионалисти. Това е така, но може да стане само в Майкрософт.
В България ако един проект се прави от 50 човека, само 5 ще са много в час, 5 ще са в час, 20 ще знаят гоооре долу за какво става дума и 20 ще са зле. Тогава вече трябва ресурсите да се разпределят правилно и се правят приоритети.
Проблемът е, че в тези приоритети UI остава винаги на последно място, докато според мене трябва да е на първо. И именно тези примерно 5-10 най-зле хора от екипа се натоварват с UI, което е голяма грешка.
В България ако един проект се прави от 50 човека, само 5 ще са много в час, 5 ще са в час, 20 ще знаят гоооре долу за какво става дума и 20 ще са зле. Тогава вече трябва ресурсите да се разпределят правилно и се правят приоритети.
Проблемът е, че в тези приоритети UI остава винаги на последно място, докато според мене трябва да е на първо. И именно тези примерно 5-10 най-зле хора от екипа се натоварват с UI, което е голяма грешка.
Axa
Има доста GUI-та за конфигуриране на Апаче, обаче РЕАЛ АДМИНС не ги ползват, щото на сървърите дето работи Апаче, обикновено няма Х сървър. :-))
[линк]
[линк]
И както ти каза Муслон, за един път е по-лесно. Ама ако трябва да го направиш 1000 пъти, ще ти се отели вола да цъкаш с мишката. В този случай може да си направиш едно скриптче, дето да автоматизира работата. Е тука може да кажеш "Да ама трябва да знаеш скриптов език". Отговорът е, ако не знаеш цъкаш с мишока, ако знаеш и те мързи да цъкаш, пишеш скрипт.
Аре сега ми кажи, кой е по-добрият вариант? И кой вариант ти дава повече свобода?
[линк]
[линк]
И както ти каза Муслон, за един път е по-лесно. Ама ако трябва да го направиш 1000 пъти, ще ти се отели вола да цъкаш с мишката. В този случай може да си направиш едно скриптче, дето да автоматизира работата. Е тука може да кажеш "Да ама трябва да знаеш скриптов език". Отговорът е, ако не знаеш цъкаш с мишока, ако знаеш и те мързи да цъкаш, пишеш скрипт.
Аре сега ми кажи, кой е по-добрият вариант? И кой вариант ти дава повече свобода?
Re: Нищо не трябва да се подценява.
В отговор на:И именно тези примерно 5-10 най-зле хора от екипа се натоварват с UI, което е голяма грешка.
Пфф изправят ми се косите като си помисля за 2/5 от хората дето нищо не могат и правят, но седят в проекта и взимат пари. То на такива какво да им дадеш? Смееш ли да ги оставиш да пускат нишки и да се борят със синхронизации между такива?
Абе изобщо в тоя примерния 50-членен проект има ли смисъл от някой друг освен 10-те човека дето са навътре?
--
"Agile is a mindset, not a set of practices, rules, or tools."
Tom Poppendieck
Re: Axa
Ако знаеш как ми олекна като открих webmin. Вече не трябва да помня кое откъде се конфигурира 
и знае за повечето важни демони.
А и между другото - предполагам си искал да отговориш на Гуру, а не на мен.
--
"Agile is a mindset, not a set of practices, rules, or tools."
Tom Poppendieck
и знае за повечето важни демони.
А и между другото - предполагам си искал да отговориш на Гуру, а не на мен.
--
"Agile is a mindset, not a set of practices, rules, or tools."
Tom Poppendieck
Re: Axa
Ух! Това не трябваше да го казваш. Сега супер конзолните Линукс администратори от Младост-4 дето администрират Линукс сървъра на "Кънтъра" в кварталното инет клубче ще те разкъсат на части за това, че си позволяваш да ползваш нещо различни от конзолата за администрация.
Не си прав
и Microsoft нямат нищо общо (не ми се палят поредните flame-ве на тема професионализъм и доколко той е застъпен особено в големите корпорации).
Има изписани дебели книги как се създават проекти, жизнения им цикъл и т.н. Значи просто трябва да се спазват правилата и толкова. Разбира се, не сляпо, с разбиране и пригодени за конкретните условия; понякога може да се жертва нещо с цел да се максимизира друго - да речем кофти UI, но навреме предаден проект
След това си оправяш пропуските по интерфейса и си готов.
Мисля все пак, че бъркаш понятията. Не интерфейсът е най-важното, а начините, по които се предполага да се използва програмата. Така наречените use cases. Те трябва да се анализират, да се измисли дизайн, с който да могат да се реализират, този дизайн да бъде направен затворен в алгебричен смисъл (тоест да няма противоречия и да позволи алгоритми за използване, които не са хрумнали на задаващите изискванията, но са естествена част от дизайна) и отворен в смисъл позволяващ разширения.
След което вече се прави машината + интерфейса за конфигурирането й. Добре би било този интерфейс да не позволява тя да се конфигурира неправилно, както и да подсказва удобни конфигурации, подсказки и т.н. магьоснически неща
Има изписани дебели книги как се създават проекти, жизнения им цикъл и т.н. Значи просто трябва да се спазват правилата и толкова. Разбира се, не сляпо, с разбиране и пригодени за конкретните условия; понякога може да се жертва нещо с цел да се максимизира друго - да речем кофти UI, но навреме предаден проект
След това си оправяш пропуските по интерфейса и си готов.
Мисля все пак, че бъркаш понятията. Не интерфейсът е най-важното, а начините, по които се предполага да се използва програмата. Така наречените use cases. Те трябва да се анализират, да се измисли дизайн, с който да могат да се реализират, този дизайн да бъде направен затворен в алгебричен смисъл (тоест да няма противоречия и да позволи алгоритми за използване, които не са хрумнали на задаващите изискванията, но са естествена част от дизайна) и отворен в смисъл позволяващ разширения.
След което вече се прави машината + интерфейса за конфигурирането й. Добре би било този интерфейс да не позволява тя да се конфигурира неправилно, както и да подсказва удобни конфигурации, подсказки и т.н. магьоснически неща
Re: Не си прав
В отговор на:Не интерфейсът е най-важното, а начините, по които се предполага да се използва програмата. Така наречените use cases.
Абе аз разбирам под "интерфейс" точно начина по който трябва да се използва програмата. Сигурно могат да се пишат use cases за UI. Нещо като - ей тук трябва да можем с контекстно меню да избираме операция Х, там пък да е текстово поле, което да попълва автоматично като пишеш базирано на предишните данни.
Освен това цялата тази работа с дебелите книги за Големите Методологии май вече сме я виждали. Особено процента на успеваемостта й.
Още от сега виждам как бай Харалампи, клиента, написва 300 use case-а и след 3 месеца му дават перфектен софтуер. Хайде де! Ох отплеснах се пак в моята теория, че кофти УИ-то е само симптом на големия проблем.--
"Agile is a mindset, not a set of practices, rules, or tools."
Tom Poppendieck
Да поясня
Значи някой си направил с много пот методология. Приложима в определени ситуации според автора.
И какво става? Идва Пенчо, чете, възхищава се и мисли, че от него не се очаква да мисли.
А то не е така. Почти винаги хората обясняват защо трябва да се прави нещо и ако имаш достатъчно ум в главата ще помислиш и при теб ли доводите им са валидни. Ще разбереш логиката и как да се възползваш от нея.
Конкретно с use case-те, хич и не си мисли, че ще тръгна аз на бай Харалампи да разчитам. От него е статистиката, от мен се очаква да пресея плявата и да оценя _класовете_ проблеми, които набора иска да му се решат. И после да се опитам да обощя.
Иначе съм напълно съгласен, че рядко се мисли както трябва. Ама то не е лесно и тук съм съвсем сериозен.
И какво става? Идва Пенчо, чете, възхищава се и мисли, че от него не се очаква да мисли.
А то не е така. Почти винаги хората обясняват защо трябва да се прави нещо и ако имаш достатъчно ум в главата ще помислиш и при теб ли доводите им са валидни. Ще разбереш логиката и как да се възползваш от нея.
Конкретно с use case-те, хич и не си мисли, че ще тръгна аз на бай Харалампи да разчитам. От него е статистиката, от мен се очаква да пресея плявата и да оценя _класовете_ проблеми, които набора иска да му се решат. И после да се опитам да обощя.
Иначе съм напълно съгласен, че рядко се мисли както трябва. Ама то не е лесно и тук съм съвсем сериозен.
Re: Да поясня
В отговор на:Конкретно с use case-те, хич и не си мисли, че ще тръгна аз на бай Харалампи да разчитам. От него е статистиката, от мен се очаква да пресея плявата и да оценя _класовете_ проблеми, които набора иска да му се решат. И после да се опитам да обощя.
Как няма да разчиташ на човека? Че той ти дава парите за работата. Това ми беше идеята за методологията - надува се и не показва факта, че всеки е зависим от клиента. Това обобщяване и пресяване е доста трудоемко и не включва самия клиент в процеса. Ето ни хубав източник на грешки и неразбирания само защото нямаме коректив.
Как да улесним бай Харалампи? Как да му помогнем да сподели изискванията си най-лесно и да ги променя без болка, когато кака Петрана от хоремага реши да не му дава мастиката с отстъпка например? Хубав начин би бил ако УИ-то се виждаше бързо и веднага и предоставяше някаква бизнес стойност в самото начало на проекта.
--
"Agile is a mindset, not a set of practices, rules, or tools."
Tom Poppendieck
Re: UI programming
>и студентчетата дето взимат 250лв ще драгват дропват гридове и текстбоксове във Студиото
abe pich, ti nqkakyv komplex li imash ot studentite kakvo?
za mene si uporit kato bik i pochti tolkova umen
are sys zdrave i ti jelaq da se uprajnish v izpolzvaneto na duhovi muzikalni instrumenti ot organichen proizhod
mnogo typ forum, samo gluposti drynkate, are bez mene veche, spoko znam che nikoi nema da plache za mene, ma hich ne mi dreme
abe pich, ti nqkakyv komplex li imash ot studentite kakvo?
za mene si uporit kato bik i pochti tolkova umen
are sys zdrave i ti jelaq da se uprajnish v izpolzvaneto na duhovi muzikalni instrumenti ot organichen proizhod
mnogo typ forum, samo gluposti drynkate, are bez mene veche, spoko znam che nikoi nema da plache za mene, ma hich ne mi dreme