Здравствуйте, Igor Sukhov, Вы писали:

IS>Мой вопрос, простой как правда, как сделать эту нагрузку более равномерной?

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

On 27.02.2013 14:35, Vlad_SP wrote:

> Кому "приятнее работать"? Ты говоришь за себя лично или еще и "за того
> парня" из далекого-далекого Бангалора? (ну или где он там...)
Да все там просто с коммитами. В пятницу народ старается закрыть некий
объем работы, чтобы в воскресенье о ней не думать. А в понедельник со
свежими силами берется за следующую задачу. Вторник-среду-четверг
спокойно делают заланированное на неделю. Вот и 2 пика.
Тов. Начальнегу же нехер делать, и вместо того, чтобы самолетики клеить
или порнушку смотреть он начинает считать количество коммитов и строк и
мешать подчиненным работать. Жду следующую фазу, расстановку по офису
камер и пялинье в монитор системы видонаблюдения целый день.

On 27.02.2013 9:56, Vlad_SP wrote:

> А зачем ее вообще делать "равномерной"?
Вероятнее всего он считает, что народ в эти дни не работает. И
соответсвенно, как эфеективного менеджера, его это злит — он то пашет
круглые сутки напролет, не останавливаясь, небось по писем 100 в день.

Здравствуйте, Igor Sukhov, Вы писали:

Мне хватило одного слова в твоих сообщениях, чтобы понять, что твою "проблему" решать не стоит. Вот оно:

IS>как зачем — в условиях равномерной нагрузки как минимум приятнее работать, меньше стресса, как следствие лучше результат.

Не будем уже заморачиваться тем, что "меньше стресса" и "лучше результат" — это никак не связанные между собой посылки.

Дальнейшее, кстати, было "немного предсказуемо" (c):

IS>пары сообщений хватило понять что кроме забалтыванием, ты не способен ответить на вопрос. тебе в топик к вжуку.

Если ты не можешь сформулировать проблему в объективных терминах (твоё восприятие происходящего — это ещё не проблема), то поиски решения обречены на неудачу. И со всей неизбежностью ты скатишься к прямым "посыланиям" своих оппонентов, хорошо, если только в топик в Вжику. Ты же пытаешься решить несуществующую задачу — тут любое оппонирование покажется злодейством. И знаешь, мне тут видится некое подобие с бесконечным мусоленьем "правильных практик" и "наиправильнейших архитектур". Не настаиваю на точности аналогии, но что-то похожее есть.

По сути же равномерность нагрузки обеспечивается мелко дроблёными задачами и регулярным контролем их исполнения. Решение старо, как мир, но подозреваю, что субъективному критерию "приятности" оно соответствовать не будет. Хотя... Фо хум хау.

Здравствуйте, Igor Sukhov, Вы писали:

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

Здравствуйте, wraithik, Вы писали:

>>>> А а это важно "какие проекты", и почему?
V>>>Мне интересно, сам с такими не сталкавался никогда.
IS>>то есть "не важно"?

W>Я б сказал почти не реально, что в проекте человек будет кодить с постоянной скоростью. Бывает такое что лучше подольше подумать, и по меньше покодить, а бывает что думать не надо почти. И примерно ровный график становится не реальным.

то есть разная скорость кодирования конкретного человека будет обусловлена тем какой код он пишет — если это (1) простой и тривиальный код — то его он будет писаться быстро. новый код, (2) реализайия хитрого алгоритма, или код с непростой обработкой различных условий — пишется долго. такой подход предполагает что код всегда пишется более менее "начисто" с первого раза.

если это как то оправдано для кода первого типа, то для второго типа можно поступить по другому и решить — ну да код сложный — будет написан за 2-3-10 проходов. сначала описываться интерфейс, потом реализуются каркас, чтобы код хоть как то компилировался,
потом чтобы проходил самые простые тесты, потом чтобы не падал на более сложных случаях, потом чтобы корректоно обрабатывал все юз кейса, потом рефакторинг, затем код правится чтобы отвечать naming convenntions of coding style, потом просто документируется и код формально готов.

Здравствуйте, Igor Sukhov, Вы писали:

IS>Здравствуйте, wraithik, Вы писали:

>>>>> А а это важно "какие проекты", и почему?
V>>>>Мне интересно, сам с такими не сталкавался никогда.
IS>>>то есть "не важно"?

W>>Я б сказал почти не реально, что в проекте человек будет кодить с постоянной скоростью. Бывает такое что лучше подольше подумать, и по меньше покодить, а бывает что думать не надо почти. И примерно ровный график становится не реальным.

IS>то есть разная скорость кодирования конкретного человека будет обусловлена тем какой код он пишет — если это (1) простой и тривиальный код — то его он будет писаться быстро. новый код, (2) реализайия хитрого алгоритма, или код с непростой обработкой различных условий — пишется долго. такой подход предполагает что код всегда пишется более менее "начисто" с первого раза.

IS>если это как то оправдано для кода первого типа, то для второго типа можно поступить по другому и решить — ну да код сложный — будет написан за 2-3-10 проходов. сначала описываться интерфейс, потом реализуются каркас, чтобы код хоть как то компилировался,
IS>потом чтобы проходил самые простые тесты, потом чтобы не падал на более сложных случаях, потом чтобы корректоно обрабатывал все юз кейса, потом рефакторинг, затем код правится чтобы отвечать naming convenntions of coding style, потом просто документируется и код формально готов.

Я 1Сник.
Если мне мой начальник сидящий рядом начнет так трахать мозг, я уйду с работы. Блин, ну не реально сделать равномерно. Вернее мне, как программисту, это НЕ НАДО, вообще НЕ НАДО. Это и тебе как тимлиду/ПМу (или кто ты там) не надо по факту.
Важно чтобы ты мог контролировать выполнение задачи, и чтобы у тебя не было, что есть задача на 50 часов, и к концу ее ты узнаешь, что нихрена не сделано, и 40 часов тока что потерялись. Для этого дроби задачи на не большие. и контролируй их выполнение. Тогда цена ошибки будет снижена.

У меня сделано так.

Большой проект на подзадачи дробится, и по ним контроль.
При этом моему шефу пофиг, сколько я строк нашкодил сегодня, сколько завтра. А вот срыв сроков — не пофиг.

К нас есть система статистик. Мы заполняем отчеты о работе (сколько человеко-часов было потрачено на кого/какую задачу). Но анализ статистик по дням малоинтересен, а вот неподдельно дает информацию о работе сотрудника, т.к. там всплески и провалы нивелируется 40 часовой неделей.

Короче, не мешай людям работать. Нравится человеку один день по анекдотам шарится, другой хреначить за двоих, при этом попадая в сроки — пусть работает. Начнешь закручивать гайки, если спец хороший — пошлет.

Здравствуйте, Igor Sukhov, Вы писали:

IS>Ситуация такая — есть несколько небольших групп разработчиков, разделенных географически вместе пишущих, тестирующих (полный SDLC) in house софт.
IS>Заметил что рабочая нагрузка, в целом распределена неравномерно в течении недели, с двумя пиками — первый, конечно в понедельник, потом равномерное
IS>падение к пятнице, и небольшой пик в пятницу. Наверно такая ситуация неуникально.

IS>Мой вопрос, простой как правда, как сделать эту нагрузку более равномерной?

А кто их грузит ? Если это твои ребята то не грузи их так в понедельник и пятницу.

Здравствуйте, Igor Sukhov, Вы писали:

IS>под нагрузкой подразумевается количество работы, что меряется в написанных строчек кода, коммитов в систему контроля версий, проведенного времени за работой.

А зачем ее вообще делать "равномерной"?
Проект укладывается в сроки — вехи, сроки релизов и т.п.? Если да, то зачем тебе лишние управленческие активности?

Здравствуйте, Vlad_SP, Вы писали:

IS>>под нагрузкой подразумевается количество работы, что меряется в написанных строчек кода, коммитов в систему контроля версий, проведенного времени за работой.
V_S>А зачем ее вообще делать "равномерной"?
V_S>Проект укладывается в сроки — вехи, сроки релизов и т.п.? Если да, то зачем тебе лишние управленческие активности?
как зачем — в условиях равномерной нагрузки как минимум приятнее работать, меньше стресса, как следствие лучше результат.

Здравствуйте, Igor Sukhov, Вы писали:

IS>как зачем — в условиях равномерной нагрузки как минимум приятнее работать, меньше стресса, как следствие лучше результат.

Кому "приятнее работать"? Ты говоришь за себя лично или еще и "за того парня" из далекого-далекого Бангалора? (ну или где он там...)

Здравствуйте, Igor Sukhov, Вы писали:

IS>Мой вопрос, простой как правда, как сделать эту нагрузку более равномерной?

Лучше сходите на хорошие курсы менеджмента в IT или как минимум почитайте хорошие книжки на эту тему, форум не поможет вам стать менеджером.

Здравствуйте, uncommon, Вы писали:

IS>>Здравствуйте, Vlad_SP, Вы писали:

IS>>>>под нагрузкой подразумевается количество работы, что меряется в написанных строчек кода, коммитов в систему контроля версий, проведенного времени за работой.
V_S>>>А зачем ее вообще делать "равномерной"?
V_S>>>Проект укладывается в сроки — вехи, сроки релизов и т.п.? Если да, то зачем тебе лишние управленческие активности?
IS>>как зачем — в условиях равномерной нагрузки как минимум приятнее работать, меньше стресса, как следствие лучше результат.

U>Похоже на ещё одного манагера, который возомнил, что знает как разработчикам делать их работу более эффективно. Осталось только этим разработчикам объяснить, что к чему. А то они же тупые, не знают ничего. Непонятно, как они вообще что-то умудряются сделать при такой неравномерной нагрузке.

выговорился, стало легче?
иди работай!
пожалуйста.

Здравствуйте, Igor Sukhov, Вы писали:
IS>если это как то оправдано для кода первого типа, то для второго типа можно поступить по другому и решить — ну да код сложный — будет написан за 2-3-10 проходов. сначала описываться интерфейс, потом реализуются каркас, чтобы код хоть как то компилировался,
IS>потом чтобы проходил самые простые тесты, потом чтобы не падал на более сложных случаях, потом чтобы корректоно обрабатывал все юз кейса, потом рефакторинг, затем код правится чтобы отвечать naming convenntions of coding style, потом просто документируется и код формально готов.

какие-то у вас, извините, куриные познания в области разработки софта. naming conventions и прочее все пишут с ходу. сам человек свой код рефактирит не может по определению (то есть может, но это совершенно бесполезно — рефактринг своего кода это попытка прыгнуть выше головы). разработка алгоритма чтобы сначала проходил только простые тесты вообще тупость какая-то. разработка тестов параллельно с кодом нужна редко и вообще это специфично. "никто так не делает", короче говоря

Здравствуйте, __kot2, Вы писали:

__>Здравствуйте, Igor Sukhov, Вы писали:
IS>>если это как то оправдано для кода первого типа, то для второго типа можно поступить по другому и решить — ну да код сложный — будет написан за 2-3-10 проходов. сначала описываться интерфейс, потом реализуются каркас, чтобы код хоть как то компилировался,
IS>>потом чтобы проходил самые простые тесты, потом чтобы не падал на более сложных случаях, потом чтобы корректоно обрабатывал все юз кейса, потом рефакторинг, затем код правится чтобы отвечать naming convenntions of coding style, потом просто документируется и код формально готов.

__>какие-то у вас, извините, куриные познания в области разработки софта. naming conventions и прочее все пишут с ходу. сам человек свой код рефактирит не может по определению (то есть может, но это совершенно бесполезно — рефактринг своего кода это попытка прыгнуть выше головы). разработка алгоритма чтобы сначала проходил только простые тесты вообще тупость какая-то. разработка тестов параллельно с кодом нужна редко и вообще это специфично. "никто так не делает", короче говоря

ну хорошо, ты взял все наиболее известные подходы в sw develepment-е и вывернул их наизнанку, ожидая что я тебе буду доказывать обратное. я конечно не буду тебе ничего доказывать, так как у твоих постов 0 value — потому что ты пишешь очевидный бред, т.к. код часто рефакторится самим автором, часто в сложных алгоритмах (тебе, мышевозу, это видимо не знакомо) реализуют сначала happy path, а тесты часто пишутся именно паралельно с разрабатываемым кодом.

НО, несмотря на это, я хочу уточнить о чем я говорил, — подход который есть сейчас несомненног работает, но это не значит что нет подхода который не только работает, но и позволяет делать работу на 20% быстрее, т.е. в 20% эффективнее. понятно что сидеть и бацать код как 10 или 20 лет назад несложно и мы все так делаем, НО будущее, если кто уже не заметил уже пришло — на дворе уже 2013 год.

Здравствуйте, Vzhyk, Вы писали:
V>On 06.05.2013 19:12, __kot2 wrote:
>> если вы пишете компилятор то да, с тестов и надо начинать
V>Ну я для всего, что чуть нетривиально для меня обычно тестик сначала
V>ваяю (или параллельно с кодом) — да и отлаживаться с ним проще.
ну это да, раз написал, нужно протестировать, все обязательно проверяешь на конкретным примерах. но вот чтобы тесты сидеть на код писать, заморачиваясь "покрытием кода тестами" это вообще фигня
у тестеров есть свои тест планы, пусть они тест сценарии прогоняет, нефиг код тестировать по отдельности, нужно целиком сразу все приложение.

Ситуация такая — есть несколько небольших групп разработчиков, разделенных географически вместе пишущих, тестирующих (полный SDLC) in house софт.
Заметил что рабочая нагрузка, в целом распределена неравномерно в течении недели, с двумя пиками — первый, конечно в понедельник, потом равномерное
падение к пятнице, и небольшой пик в пятницу. Наверно такая ситуация неуникально.

Мой вопрос, простой как правда, как сделать эту нагрузку более равномерной?

IS>Мой вопрос, простой как правда, как сделать эту нагрузку более равномерной?

Что понимается под "нагрузкой"? И почему она варьируется? И что за проект? Если саппорт чего-то, то в понедельник (первый день после 2х дней неработы) пика не избежать, он вызват отсутствием работников в выходные. В пятницу, соответственно, пик тоже будет всенепременно, т.к. другие организации (которые вам эти тикеты выставляют) тоже стараются по возможности больше дел закрыть до выходных.
В общем, нужно больше информации.

Здравствуйте, SkyDance, Вы писали:

IS>>Мой вопрос, простой как правда, как сделать эту нагрузку более равномерной?

SD>Что понимается под "нагрузкой"? И почему она варьируется? И что за проект? Если саппорт чего-то, то в понедельник (первый день после 2х дней неработы) пика не избежать, он вызват отсутствием работников в выходные. В пятницу, соответственно, пик тоже будет всенепременно, т.к. другие организации (которые вам эти тикеты выставляют) тоже стараются по возможности больше дел закрыть до выходных.
SD>В общем, нужно больше информации.

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

On 27.02.2013 5:24, Igor Sukhov wrote:

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

Здравствуйте, Vzhyk, Вы писали:

V>On 27.02.2013 5:24, Igor Sukhov wrote:

>> под нагрузкой подразумевается количество работы, что меряется в
>> написанных строчек кода, коммитов в систему контроля версий,
>> проведенного времени за работой.
V>А можно вопрос, что вы делаете, что у вас нельзя думать, а нужно только
V>по клавишам стучать? Что за проекты?
А а это важно "какие проекты", и почему?

On 27.02.2013 11:59, Igor Sukhov wrote:

> А а это важно "какие проекты", и почему?
Мне интересно, сам с такими не сталкавался никогда.

Здравствуйте, Vzhyk, Вы писали:

V>On 27.02.2013 11:59, Igor Sukhov wrote:

>> А а это важно "какие проекты", и почему?
V>Мне интересно, сам с такими не сталкавался никогда.
то есть "не важно"?

Здравствуйте, Vzhyk,

да мне-то как раз это все ясно, как ясно и то, откуда берутся два "пика" в понедельник и пятницу... Равно как и то, что одним программистам комфортнее работать при равномерной загрузке, другим же наоборот, комфортнее работать в "рваном" ритме. Я просто все жду, сможет ли коллега Igor Sukhov внятно объяснить, нафига понадобился весь этот цирк с "равномерной загрузкой" для всех?

Здравствуйте, Vlad_SP, Вы писали:

IS>>как зачем — в условиях равномерной нагрузки как минимум приятнее работать, меньше стресса, как следствие лучше результат.
V_S>Кому "приятнее работать"? Ты говоришь за себя лично или еще и "за того парня" из далекого-далекого Бангалора? (ну или где он там...)
а какая разница? объясни пожалуйста.

Здравствуйте, Igor Sukhov,

а разница в том, что все люди — разные. Тебе, предположим, комфортнее работать при "равномерной" загрузке в течение недели. А, скажем, Сингху из Бангалора — наоборот, комфортнее работается в "рваном" ритме. Ну и зачем нужно всех причесывать под одну гребенку, если проект в целом идет успешно?

Здравствуйте, Vlad_SP, Вы писали:

V_S>а разница в том, что все люди — разные. Тебе, предположим, комфортнее работать при "равномерной" загрузке в течение недели. А, скажем, Сингху из Бангалора — наоборот, комфортнее работается в "рваном" ритме. Ну и зачем нужно всех причесывать под одну гребенку, если проект в целом идет успешно?

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

Здравствуйте, Igor Sukhov,

ты так и не ответил четко и ясно на вопрос "зачем?"

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


Чем вобщем-то черезмерно активные проджект менеджеры часто и занимаются. Особенно хорошо это чувствуется в больших корпорациях — назначат в 4 вечера в пятницу статус митинг и чешут свое ЧСВ репортя равномерную нагрузку в течении недели
ЗЫ: умные люди обычно в пятницу WFH делвют — и неспешно попивая пивко разравномеривают свою нагрузку в угоду манагеру

Здравствуйте, Igor Sukhov, Вы писали:

IS>Здравствуйте, Vzhyk, Вы писали:

V>>On 27.02.2013 11:59, Igor Sukhov wrote:

>>> А а это важно "какие проекты", и почему?
V>>Мне интересно, сам с такими не сталкавался никогда.
IS>то есть "не важно"?

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

Здравствуйте, Igor Sukhov, Вы писали:

IS>если это как то оправдано для кода первого типа, то для второго типа можно поступить по другому и решить — ну да код сложный — будет написан за 2-3-10 проходов. сначала описываться интерфейс, потом реализуются каркас, чтобы код хоть как то компилировался,
IS>потом чтобы проходил самые простые тесты, потом чтобы не падал на более сложных случаях, потом чтобы корректоно обрабатывал все юз кейса, потом рефакторинг, затем код правится чтобы отвечать naming convenntions of coding style, потом просто документируется и код формально готов.
Ты прикидывал какой оверхэд по времени и силам этот добавляет?


СУВ, Aikin

Здравствуйте, Aikin, Вы писали:

A>Здравствуйте, Igor Sukhov, Вы писали:

IS>>если это как то оправдано для кода первого типа, то для второго типа можно поступить по другому и решить — ну да код сложный — будет написан за 2-3-10 проходов. сначала описываться интерфейс, потом реализуются каркас, чтобы код хоть как то компилировался,
IS>>потом чтобы проходил самые простые тесты, потом чтобы не падал на более сложных случаях, потом чтобы корректоно обрабатывал все юз кейса, потом рефакторинг, затем код правится чтобы отвечать naming convenntions of coding style, потом просто документируется и код формально готов.
A>Ты прикидывал какой оверхэд по времени и силам этот добавляет?
и?

A>СУВ, Aikin

Здравствуйте, Igor Sukhov, Вы писали:

IS>>>если это как то оправдано для кода первого типа, то для второго типа можно поступить по другому и решить — ну да код сложный — будет написан за 2-3-10 проходов. сначала описываться интерфейс, потом реализуются каркас, чтобы код хоть как то компилировался,
IS>>>потом чтобы проходил самые простые тесты, потом чтобы не падал на более сложных случаях, потом чтобы корректоно обрабатывал все юз кейса, потом рефакторинг, затем код правится чтобы отвечать naming convenntions of coding style, потом просто документируется и код формально готов.
A>>Ты прикидывал какой оверхэд по времени и силам этот добавляет?
IS>и?
Так да или нет?

СУВ, Aikin

Здравствуйте, Aikin, Вы писали:

A>Здравствуйте, Igor Sukhov, Вы писали:

IS>>>>если это как то оправдано для кода первого типа, то для второго типа можно поступить по другому и решить — ну да код сложный — будет написан за 2-3-10 проходов. сначала описываться интерфейс, потом реализуются каркас, чтобы код хоть как то компилировался,
IS>>>>потом чтобы проходил самые простые тесты, потом чтобы не падал на более сложных случаях, потом чтобы корректоно обрабатывал все юз кейса, потом рефакторинг, затем код правится чтобы отвечать naming convenntions of coding style, потом просто документируется и код формально готов.
A>>>Ты прикидывал какой оверхэд по времени и силам этот добавляет?
IS>>и?
A>Так да или нет?
да вообще то ясно что не прикидывал.
а я что — судя по моему описанию такой подход потребует больше затрат по времени? несколько контринтуиивно.

Здравствуйте, Igor Sukhov, Вы писали:

IS>а я что — судя по моему описанию такой подход потребует больше затрат по времени? несколько контринтуиивно.
Люди разные, кому-то удобнее по плану и маленькими шажками проблему решать, кому-то неделю ходить-ничего "не делать", а потом за пару часов нафигачить отличное решение (а на самом деле он просто медленно думает). Я не знаю к какому типу отношусь. Иногда к первому, бывает ко второму, но чаще совмещаю: маленькие шажки чтобы понять проблему, а далее уже "думать-думать-думать". Хотя наша работа провоцирует скорее чаще делать, чем больше думать (потому что цена ошибки низкая и всегда можно переделать).

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

СУВ, Aikin

Здравствуйте, Igor Sukhov, Вы писали:

IS>Здравствуйте, Vlad_SP, Вы писали:

IS>>>под нагрузкой подразумевается количество работы, что меряется в написанных строчек кода, коммитов в систему контроля версий, проведенного времени за работой.
V_S>>А зачем ее вообще делать "равномерной"?
V_S>>Проект укладывается в сроки — вехи, сроки релизов и т.п.? Если да, то зачем тебе лишние управленческие активности?
IS>как зачем — в условиях равномерной нагрузки как минимум приятнее работать, меньше стресса, как следствие лучше результат.

Похоже на ещё одного манагера, который возомнил, что знает как разработчикам делать их работу более эффективно. Осталось только этим разработчикам объяснить, что к чему. А то они же тупые, не знают ничего. Непонятно, как они вообще что-то умудряются сделать при такой неравномерной нагрузке.

On 06.05.2013 7:34, __kot2 wrote:

> разработка алгоритма чтобы сначала проходил только простые тесты вообще
> тупость какая-то.
Здесь есть деталь от дьявола — "простые".

> разработка тестов параллельно с кодом нужна редко и
> вообще это специфично.
А что ты имеешь в виду под разработкой кода и тестов? А то высказывание
у тебя провокационное, но не понятно, что ты вкладываешь в каждое
понятие в своем высказывании.

Здравствуйте, Igor Sukhov, Вы писали:
IS>ну хорошо, ты взял все наиболее известные подходы в sw develepment-е и вывернул их наизнанку, ожидая что я тебе буду доказывать обратное. я конечно не буду тебе ничего доказывать, так как у твоих постов 0 value — потому что ты пишешь очевидный бред, т.к. код часто рефакторится самим автором, часто в сложных алгоритмах (тебе, мышевозу, это видимо не знакомо) реализуют сначала happy path, а тесты часто пишутся именно паралельно с разрабатываемым кодом.

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

Здравствуйте, Vzhyk, Вы писали:
>> разработка тестов параллельно с кодом нужна редко и
>> вообще это специфично.
V>А что ты имеешь в виду под разработкой кода и тестов? А то высказывание
V>у тебя провокационное, но не понятно, что ты вкладываешь в каждое
V>понятие в своем высказывании.
если вы пишете компилятор то да, с тестов и надо начинать
если игрушку или там, Mp3 — плеер, то тесты будут смотреться смешнее карго-культа
есть некоторые пограничные случаи, но по большому счету они не нужны.
но тут же опять оговорка — если код модифицируется дикими обезьянами, то да, нужны обязательно даже на mp3-плеер

Здравствуйте, Igor Sukhov, Вы писали:

IS>Ситуация такая — есть несколько небольших групп разработчиков, разделенных географически вместе пишущих, тестирующих (полный SDLC) in house софт.
IS>Заметил что рабочая нагрузка, в целом распределена неравномерно в течении недели, с двумя пиками — первый, конечно в понедельник, потом равномерное
IS>падение к пятнице, и небольшой пик в пятницу. Наверно такая ситуация неуникально.

IS>Мой вопрос, простой как правда, как сделать эту нагрузку более равномерной?

Если тебе нужно, чтобы они работали равномерно, но неэффективно, расставь майлстоуны (или что у вас используется) для одних в понедельник, для вторых во вторник, для третьих в среду, та комманда, которая будет пред "релизом" будет пинать всех остальных и создавать видимость работы. А так оставь их в покое -- они вошли в ритм. Если тебя именно ритм не устраивает (продалбываете сроки), то ставь сроки на этап жестче.

On 06.05.2013 19:12, __kot2 wrote:

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

On 06.05.2013 20:46, __kot2 wrote:

> но вот чтобы тесты сидеть на код писать,
> заморачиваясь "покрытием кода тестами" это вообще фигня
Это не фигня — это когда "собаке делать нечего".

Здравствуйте, Igor Sukhov, Вы писали:

IS>Ситуация такая — есть несколько небольших групп разработчиков, разделенных географически вместе пишущих, тестирующих (полный SDLC) in house софт.
IS>Заметил что рабочая нагрузка, в целом распределена неравномерно в течении недели, с двумя пиками — первый, конечно в понедельник, потом равномерное
IS>падение к пятнице, и небольшой пик в пятницу. Наверно такая ситуация неуникально.

IS>Мой вопрос, простой как правда, как сделать эту нагрузку более равномерной?

Вопрос за чем? бонус то какой от этого?

Здравствуйте, Igor Sukhov, Вы писали:

IS>Здравствуйте, __kot2, Вы писали:

__>>Здравствуйте, Igor Sukhov, Вы писали:
IS>>>если это как то оправдано для кода первого типа, то для второго типа можно поступить по другому и решить — ну да код сложный — будет написан за 2-3-10 проходов. сначала описываться интерфейс, потом реализуются каркас, чтобы код хоть как то компилировался,
IS>>>потом чтобы проходил самые простые тесты, потом чтобы не падал на более сложных случаях, потом чтобы корректоно обрабатывал все юз кейса, потом рефакторинг, затем код правится чтобы отвечать naming convenntions of coding style, потом просто документируется и код формально готов.

__>>какие-то у вас, извините, куриные познания в области разработки софта. naming conventions и прочее все пишут с ходу. сам человек свой код рефактирит не может по определению (то есть может, но это совершенно бесполезно — рефактринг своего кода это попытка прыгнуть выше головы). разработка алгоритма чтобы сначала проходил только простые тесты вообще тупость какая-то. разработка тестов параллельно с кодом нужна редко и вообще это специфично. "никто так не делает", короче говоря

IS>ну хорошо, ты взял все наиболее известные подходы в sw develepment-е и вывернул их наизнанку, ожидая что я тебе буду доказывать обратное. я конечно не буду тебе ничего доказывать, так как у твоих постов 0 value — потому что ты пишешь очевидный бред, т.к. код часто рефакторится самим автором, часто в сложных алгоритмах (тебе, мышевозу, это видимо не знакомо) реализуют сначала happy path, а тесты часто пишутся именно паралельно с разрабатываемым кодом.

IS>НО, несмотря на это, я хочу уточнить о чем я говорил, — подход который есть сейчас несомненног работает, но это не значит что нет подхода который не только работает, но и позволяет делать работу на 20% быстрее, т.е. в 20% эффективнее. понятно что сидеть и бацать код как 10 или 20 лет назад несложно и мы все так делаем, НО будущее, если кто уже не заметил уже пришло — на дворе уже 2013 год.

Вы пытаетесь выжать проценты *бесплатно*, над этим вопросом бьется вся менеджерская элита энтерпрайза.

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

Здравствуйте, Igor Sukhov, Вы писали:

IS>Ситуация такая — есть несколько небольших групп разработчиков, разделенных географически вместе пишущих, тестирующих (полный SDLC) in house софт.
IS>Заметил что рабочая нагрузка, в целом распределена неравномерно в течении недели, с двумя пиками — первый, конечно в понедельник, потом равномерное
IS>падение к пятнице, и небольшой пик в пятницу. Наверно такая ситуация неуникально.

IS>Мой вопрос, простой как правда, как сделать эту нагрузку более равномерной?

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

А>Какое занудство. Дай другим жить как им хочется, это ихняя жизнь. Работа программиста заключается в написании кода, а не в том, чтоб подчиняться.

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