потому что при записи на съемный ntfs раздел, данные некоторое время будут лежать в кеше. Так что если вытащить флешку не отмонтировав(это везопасное извлечение в винде), то очень много шансов получить битые фаилы
ИМХО — то что вы имеете в виду — это как раз отчет по версии это и будет тем самым планом. Есть estimate, есть n разрабов, есть m незакрытых тасков. Есть estimat'ы на текущие таски.
я скорее не догоняю, что не нравится в схеме, я не вижу сильно излишней формализации, кроме может еженедельного релиза версии и 3 пункта.
версия — это та-же итерация. так что все к месту. на версию намечаются некий набор фичей. они реализуются. По релизу версии раздаются люля тем, кто профакапил поставленные задачи, оставшееся переносится на след. итерацию.
1 — х*й. планы с реальностью совпадают на очень недолгом промежутке времени.
2 — итерация состоит из задач, на которые уходит время. Времени на задачу уходит примерно в 1.5-3 раза больше чем сказано изначально.
по мнению:
1 — jira — это инструмент учета задач и подсчета статистики. Заниматься этим в экселе имеет смысл, когда команда не более 2-5 человек, иначе неудобно.
2. и это правильно, чем больше за меня делает компьютер, тем больше я успеваю сделать
3. не сказал бы, в jira все-равно есть не все. jira — не «42»
4. программисту желательно быть ответственным за то время, которое он объявляет на задачу. Да, бывает, что вроде и сделал в срок, но вылазят какие-то мелкие недоработки которые надо править или мелкие фичи без которых не труЪ потому и множитель от 1.5 до 3 а то и поболее на время которое говорит программист.
5. хз. jira реально нужна, когда ПМ перестает успевать держать в голове или в экселе все сроки, розданные и запланированные задачи и прочее.
6. Заказчика стоит держать в курсе событий. Хотя бы по еженедельным версиям. При выписанном выше подходе, это сделать проще, нежели когда есть стопицот задач из которых 70% уже сделаны, 10% делаются уже полгода, остальное типа в процессе. Работал с таким подходом, спасибо.
Мое мнение, что это нормальный, рабочий workflow agile-like разработки. Может кое-что перекручено, но нормально. Главное — это заставить рзработчиков-раздолбаев заносить все правильно и в срок.
это нормальный вопрос. правда ответ напрашивается $99.90 — рождественская скидка. Но суть не меняется, разработчик должен представлять объем поставленной задачи. Да, потом указанное число может корректироваться в очень широких пределах, это жизнь :)
Вот за такие приколы не люблю динамическую типизацию…
я скорее не догоняю, что не нравится в схеме, я не вижу сильно излишней формализации, кроме может еженедельного релиза версии и 3 пункта.
1 — х*й. планы с реальностью совпадают на очень недолгом промежутке времени.
2 — итерация состоит из задач, на которые уходит время. Времени на задачу уходит примерно в 1.5-3 раза больше чем сказано изначально.
по мнению:
1 — jira — это инструмент учета задач и подсчета статистики. Заниматься этим в экселе имеет смысл, когда команда не более 2-5 человек, иначе неудобно.
2. и это правильно, чем больше за меня делает компьютер, тем больше я успеваю сделать
3. не сказал бы, в jira все-равно есть не все. jira — не «42»
4. программисту желательно быть ответственным за то время, которое он объявляет на задачу. Да, бывает, что вроде и сделал в срок, но вылазят какие-то мелкие недоработки которые надо править или мелкие фичи без которых не труЪ потому и множитель от 1.5 до 3 а то и поболее на время которое говорит программист.
5. хз. jira реально нужна, когда ПМ перестает успевать держать в голове или в экселе все сроки, розданные и запланированные задачи и прочее.
6. Заказчика стоит держать в курсе событий. Хотя бы по еженедельным версиям. При выписанном выше подходе, это сделать проще, нежели когда есть стопицот задач из которых 70% уже сделаны, 10% делаются уже полгода, остальное типа в процессе. Работал с таким подходом, спасибо.
Мое мнение, что это нормальный, рабочий workflow agile-like разработки. Может кое-что перекручено, но нормально. Главное — это заставить рзработчиков-раздолбаев заносить все правильно и в срок.
З.Ы. извините за не самую цензурную лексику
Оруэлл ошибся на 100 лет? :)
Насчет баг и фича: Это не баг, это отсутствие фичи, что далеко не баг.