80/20 правило тайм-менеджмента относятся к разработчикам?
попробуйте
Проверить, добавлен фрагмент или нет
if (getCurrentFragment() instanceof YourFragment)
Добавить фрагмент
replaceFragment(new HomeFragment(), "YourFragment");
[ 119] Методы
private void replaceFragment(Fragment fragment, String tag)
{
Fragment currentFragment = getCurrentFragment();
if (currentFragment != null)
getSupportFragmentManager().beginTransaction().remove(currentFragment).commit();
getSupportFragmentManager().beginTransaction().add(R.id.container_main, fragment, tag).commit();
}
public Fragment getCurrentFragment()
{
FragmentManager manager = getSupportFragmentManager();
return manager.findFragmentById(R.id.container_main);
}
private void popBackStack()
{
FragmentManager fragmentManager = getSupportFragmentManager();
int total = fragmentManager.getBackStackEntryCount();
for (int i = 0; i < total; i++)
{
fragmentManager.popBackStack();
}
}
9 ответов
Я думаю, что Закон Hofstadter применяется.
Это всегда занимает больше времени, чем Вы ожидаете, даже когда Вы принимаете Закон Hofstadter во внимание.
- Douglas Hofstadter
На более серьезной ноте смотрите на Критическое Цепочечное управление проектами. Это рекомендует дать две оценки для каждого шага в проекте. Каждый - оптимистическая оценка, что Вы приблизительно на 50% уверены, что можно встретиться, если все идет право. Другой более реалистическая оценка, которая принимает во внимание потерянное время и ошибки (мое перефразирование, не обвиняйте автора). Со временем и несколько проектов, которые Вы изучите, какая оценка более точна, и сколько. Это варьируется разработчиком, таким образом, необходимо отслеживать.
абсолютно! 80% моего времени потрачены на stackoverflow.com, и 20%, на самом деле работающих.
достаточно странно моя производительность совпадает с ним, когда-либо был...
... то же, поскольку это когда-либо было!
;-)
2 часа записи unittests и демонстрации функциональности Вашим клиентам рано сохранят Вас 8 часов отладки и перезаписи.
По-моему, Kozyarchuk разбирается в нем:
Проблемой не являются так плохие временные оценки, как это - плохие/невозможные оценки объема.
Показ результата или макетов результатов клиенту/менеджеру как можно раньше, при тестировании законности кодов, приводит к лучшему пониманию целей/требований.
Помните: Проект имеет успех, если он "делает клиентов счастливыми", когда он сделан, не, когда он отвечает требованиям, известным аналитику, когда проект был первоначально запущен.
Естественно это означает, что "перемещение цели" является правилом, не плохой вещью и ничем, чтобы бояться. Это также означает, что я, как руководитель проекта / архитектор, должен удостовериться, что стоит за изменения в объеме, могут / быть переданным и покрытым.
Как это сделано?
- Демонстрация рано, демонстрация часто (Пользователям и их менеджерам в той же комнате)
- Менталитет Запросов на изменение. (Таким образом, клиент знает то, что изменения и что те изменения стоимость, и таким образом, клиент может использовать их, чтобы повторно определить объем его проекта на заказ),
- Будьте честны, говорите с клиентом и разработчиками.. и удостоверьтесь, что они также говорят друг с другом.
Это всегда работает? НЕТ
Почему Вы даже спрашиваете о правиле 80/20? Вы заключили правило 90/90 в кавычки правильно. Вы уже знаете, что правила 90/90 относятся к разработчикам.
(Извините, что ответил фактами вместо шутки.)
Я трачу 20% своего времени, делая то, что я хочу и 80%, осуществляющих рефакторинг его.
Так, да, если Вы полагаете, что это "работает" в этом сначала 20%. Но, это длится, 80% делает это допускающим повторное использование, стоящим поддержания и удовольствия (вместо нагрузки) для использования в будущем.
Принцип Pereto применяется много к Разработчикам. Некоторые говорят, что 80% работы сделаны 20% Разработчиков. Кроме того, 80% ошибок сгенерированы 20% Разработчиков. Кроме того, 80% функций используются 20% пользователей. Это - примеры, о которых я услышал.
Да, 80/20 закон относится к разработке, но необходимо интерпретировать его по-другому:
- Первые 80% кода сделаны в 20% времени.
- Остающихся 80% времени недостаточно, чтобы сделать остающиеся 20% кода.
Я - со счетом Ящерица. Это ВСЕГДА занимает больше времени, чем ожидалось из-за очень неожиданных вещей или вероятно вещей, которые не были приняты во внимание.